Embed Size (px)
Citation preview
, , 1–27()c�
Kluwer AcademicPublishers,Boston.Manufacturedin TheNetherlands.
The Gaia Methodology for Agent-Oriented Analysis andDesign��������� ��������������������
[email protected] Electronic Engineering, QueenMary andWestfieldCollege, LondonE1 4NS,UK
�������������������� �������!�[email protected]
Departmentof Electronic Engineering, QueenMary andWestfieldCollege, LondonE1 4NS,UK
���#"��$�&%������'[email protected]
Departmentof ComputerScience, University of Melbourne, Parkville 3052,Australia
Received
Abstract. ThisarticlepresentsGaia:amethodologyfor agent-orientedanalysisanddesign.TheGaiamethodol-ogy is bothgeneral,in thatit is applicableto a wide rangeof multi-agentsystems,andcomprehensive, in that itdealswith boththemacro-level (societal)andthemicro-level (agent)aspectsof systems.Gaiais foundedon theview of amulti-agentsystemasacomputationalorganisationconsistingof variousinteractingroles.WeillustrateGaiathroughacasestudy(anagent-basedbusinessprocessmanagementsystem).
1. Introduction
Progressin softwareengineeringover the pasttwo decadeshasbeenmadethroughthedevelopmentof increasinglypowerful andnaturalhigh-level abstractionswith which tomodelanddevelopcomplex systems.Proceduralabstraction,abstractdatatypes,and,mostrecently, objectsandcomponentsareall examplesof suchabstractions.It is ourbelief thatagentsrepresentasimilaradvancein abstraction:they maybeusedby softwaredeveloperstomorenaturallyunderstand,model,anddevelopanimportantclassof complex distributedsystems.
If agentsareto realisetheir potentialasa softwareengineeringparadigm,thenit is nec-essaryto develop softwareengineeringtechniquesthat arespecificallytailoredto them.Existingsoftwaredevelopmenttechniques(for example,object-orientedanalysisandde-sign [2, 6]) areunsuitablefor this task. Thereis a fundamentalmismatchbetweentheconceptsusedbyobject-orienteddevelopers(andindeed,byothermainstreamsoftwareen-gineeringparadigms)andtheagent-orientedview [32, 34]. In particular, extantapproachesfail to adequatelycaptureanagent’sflexible, autonomousproblem-solvingbehaviour, therichnessof anagent’s interactions,andthecomplexity of anagentsystem’sorganisationalstructures.For thesereasons,thisarticleintroducesa methodologycalledGaia,whichhasbeenspecificallytailoredto theanalysisanddesignof agent-basedsystems1.
The remainderof this article is structuredasfollows. We begin, in the following sub-section,by discussingthecharacteristicsof applicationsfor which we believe Gaiais ap-propriate. Section2 givesan overview of the mainconceptsusedin Gaia. Agent-basedanalysisis discussedin section3, anddesignin section4. The useof Gaiais illustratedby meansof a casestudyin section5, wherewe show how it wasappliedto thedesignof
( )+*,*.- /.0!12/,3.4!57684�9:9�129;3;<�5>=.9:/@?.129:9�A
a real-world agent-basedsystemfor businessprocessmanagement[20]. Relatedwork isdiscussedin section6, andsomeconclusionsarepresentedin section7.
DomainCharacteristics
Beforeproceeding,it is worthcommentingon thescopeof ourwork, andin particular, onthecharacteristicsof domainsfor whichwebelieveGaiais appropriate.It is intendedthatGaiabeappropriatefor thedevelopmentof systemssuchasADEPT [20] andARCHON [19].Thesearelarge-scalereal-world applications,with thefollowing maincharacteristics:
B Agentsarecoarse-grainedcomputationalsystems,eachmakinguseof significantcom-putationalresources(think of eachagentashaving theresourcesof a UNIX process).
B It is assumedthat the goal is to obtaina systemthat maximisessomeglobal qualitymeasure,but which maybesub-optimalfrom thepoint of view of thesystemcompo-nents.Gaiais not intendedfor systemsthatadmitthepossibilityof trueconflict2.
B Agentsareheterogeneous,in that differentagentsmay be implementedusingdiffer-entprogramminglanguages,architectures,andtechniques.We make no assumptionsaboutthedeliveryplatform.
B The organisationstructureof the systemis static,in that inter-agentrelationshipsdonotchangeat run-time.
B The abilities of agentsand the servicesthey provide are static, in that they do notchangeat run-time.
B The overall systemcontainsa comparatively small numberof differentagenttypes(lessthan100).
Gaiadealswith both themacro(societal)level andthemicro (agent)level aspectsof de-sign. It representsan advanceover previous agent-orientedmethodologiesin that it isneutralwith respectto boththetargetdomainandtheagentarchitecture(seesection6 fora moredetailedcomparison).
2. A Conceptual Framework
Gaiais intendedto allow ananalystto gosystematicallyfrom a statementof requirementsto a designthat is sufficiently detailedthat it canbe implementeddirectly. Note that weview therequirementscapturephaseasbeingindependentof theparadigmusedfor analy-sisanddesign.In applyingGaia,theanalystmovesfrom abstractto increasinglyconcreteconcepts.Eachsuccessive move introducesgreaterimplementationbias,andshrinksthespaceof possiblesystemsthatcouldbe implementedto satisfytheoriginal requirementsstatement.(See[21, pp216-222]for a discussionof implementationbias.) Analysisanddesigncanbe thoughtof asa processof developingincreasinglydetailedmodelsof thesystemto beconstructed.Themainmodelsusedin Gaiaaresummarisedin Figure1
=.9�=;-8A,<�1C<D=.9:/E/;4�<81C3;9 F
requirements
roles model
services modelagent modelmodel
acquaintance
statement
model
interactions
design
analysis
Figure1. RelationshipsbetweenGaia’s models
Gaiaborrowssometerminologyandnotationfrom object-orientedanalysisanddesign,(specifically, FUSION [6]). However, it is not simply a naive attemptto applysuchmeth-odsto agent-orienteddevelopment.Rather, it providesan agent-specificsetof conceptsthroughwhichasoftwareengineercanunderstandandmodelacomplex system.In partic-ular, Gaiaencouragesa developerto think of building agent-basedsystemsasaprocessoforganisationaldesign.
The main Gaianconceptscan be divided into two categories: abstract and concrete;abstractandconcreteconceptsaresummarisedin Table1. Abstractentitiesarethoseusedduringanalysisto conceptualisethesystem,but which do not necessarilyhave any directrealisationwithin the system. Concreteentities,in contrast,areusedwithin the designprocess,andwill typically havedirectcounterpartsin therun-timesystem.
3. Analysis
The objective of the analysisstageis to develop an understandingof the systemanditsstructure(without referenceto any implementationdetail). In our case,this understand-ing is capturedin the system’s organisation. We view an organisationasa collectionofroles, that standin certainrelationshipsto oneanother, andthat take part in systematic,institutionalisedpatternsof interactionswith otherroles— seeFigure2.
Themostabstractentity in ourconcepthierarchyis thesystem. Althoughtheterm“sys-tem” is usedin its standardsense,it alsohasa relatedmeaningwhen talking aboutan
G )+*,*.- /.0!12/,3.4!57684�9:9�129;3;<�5>=.9:/@?.129:9�A
Table1. Abstractandconcreteconceptsin Gaia
AbstractConcepts ConcreteConcepts
Roles AgentTypesPermissions ServicesResponsibilities AcquaintancesProtocolsActivitiesLivenesspropertiesSafetyproperties
agent-basedsystem,to mean“society” or “organisation”.That is, we think of an agent-basedsystemasanartificial societyor organisation.
Theideaof asystemasasocietyis usefulwhenthinkingaboutthenext level in thecon-cepthierarchy:roles. It mayseemstrangeto think of a computersystemasbeingdefinedby a setof roles,but theideais quitenaturalwhenadoptinganorganisationalview of theworld. Considera humanorganisationsuchasa typical company. Thecompany hasrolessuchas“president”,“vice president”,andsoon. Note that in a concreterealisationof acompany, theseroleswill be instantiatedwith actualindividuals:therewill beanindivid-ualwhotakesontheroleof president,anindividualwhotakesontheroleof vicepresident,andsoon. However, theinstantiationis not necessarilystatic.Throughoutthecompany’slifetime, many individualsmaytake on therole of company president,for example.Also,thereis not necessarilya one-to-onemappingbetweenrolesandindividuals. It is not un-usual(particularlyin smallor informally definedorganisations)for oneindividual to takeon many roles. For example,a singleindividual might take on the role of “tea maker”,“mail fetcher”,andsoon. Conversely, theremaybemany individualsthattakeonasinglerole,e.g.,“salesman”3.
A role is definedby four attributes: responsibilities, permissions, activities, andproto-cols. Responsibilitiesdeterminefunctionalityand,assuch,areperhapsthe key attributeassociatedwith a role. An exampleresponsibilityassociatedwith the role of companypresidentmight be calling the shareholdersmeetingevery year. Responsibilitiesaredi-videdinto two types: livenesspropertiesandsafetyproperties[27]4. Livenesspropertiesintuitively statethat“somethinggoodhappens”.They describethosestatesof affairsthatanagentmustbringabout,givencertainenvironmentalconditions.In contrast,safetyprop-ertiesareinvariants. Intuitively, a safetypropertystatesthat“nothing badhappens”(i.e.,thatanacceptablestateof affairsis maintainedacrossall statesof execution).An examplemightbe“ensurethereactortemperaturealwaysremainsin therange0-100”.
In orderto realiseresponsibilities,a role hasa setof permissions. Permissionsarethe“rights” associatedwith a role. Thepermissionsof a role thusidentify theresourcesthatareavailableto thatrole in orderto realiseits responsibilities.In thekindsof systemthatwe have typically modelled,permissionstendto be informationresources. For example,a role might have associatedwith it the ability to reada particularitem of information,
=.9�=;-8A,<�1C<D=.9:/E/;4�<81C3;9 H
properties
safety
system
responsibilities
roles interactions
permissions
liveness
properties
Figure2. AnalysisConcepts
or to modify anotherpieceof information. A role canalsohave the ability to generateinformation.
Theactivitiesof a rolearecomputationsassociatedwith therole thatmaybecarriedoutby theagentwithout interactingwith otheragents.Activitiesarethus“private”actions,inthesenseof [28].
Finally, a role is alsoidentifiedwith a numberof protocols, which definetheway that itcaninteractwith otherroles.For example,a “seller” rolemighthave theprotocols“Dutchauction”and“English auction”associatedwith it; theContractNet Protocolis associatedwith theroles“manager”and“contractor”[30].
Thus,theorganisationmodelin Gaiais comprisedof two furthermodels:therolesmodel(section3.1)andthe interactionmodel(section3.2).
3.1. TheRolesModel
The rolesmodel identifiesthe key rolesin the system.Herea role canbe viewed asanabstractdescriptionof anentity’s expectedfunction. In otherterms,a role is moreor lessidentical to the notion of an office in the sensethat “prime minister”, “attorney generalof theUnitedStates”,or “secretaryof statefor Education”areall offices. Suchroles(oroffices)arecharacterisedby two typesof attribute5:
B Thepermissions/rightsassociatedwith therole.
I )+*,*.- /.0!12/,3.4!57684�9:9�129;3;<�5>=.9:/@?.129:9�A
A role will have associatedwith it certainpermissions,relating to the type andtheamountof resourcesthat can be exploited whencarryingout the role. In our case,theseaspectsarecapturedin anattributeknown astherole’spermissions.
B Theresponsibilitiesof therole.
A role is createdin orderto do something.That is, a role hasa certainfunctionality.This functionalityis representedby anattributeknown astherole’s responsibilities.
Permissions Thepermissionsassociatedwith a rolehave two aspects:
B they identify theresourcesthatcanlegitimatelybeusedto carryout therole — intu-itively, they saywhatcanbespentwhile carryingout therole;
B they statetheresourcelimits within whichtheroleexecutormustoperate— intuitively,they saywhatcan’t bespentwhile carryingout therole.
In general,permissionscanrelateto any kind of resource.In a humanorganisation,forexample,a role might begivena monetarybudget,a certainamountof personeffort, andso on. However, in Gaia, we think of resourcesas relating only to the information orknowledge the agenthas. That is, in orderto carry out a role, anagentwill typically beable to accesscertaininformation. Somerolesmight generateinformation; othersmayneedto accessa pieceof information but not modify it, while yet othersmay needtomodify theinformation.We recognisethata richermodelof resourcesis requiredfor thefuture,althoughfor themoment,werestrictourattentionsimply to information.
Gaia makes useof a formal notationfor expressingpermissionsthat is basedon theFUSION notationfor operationschemata[6, pp26–31].To introduceour conceptswe willusetheexampleof a COFFEEFILLER role (thepurposeof this role is to ensurethatacoffeepot is keptfull of coffeefor a groupof workers).Thefollowing is a simpleillustrationofthepermissionsassociatedwith therole COFFEEFILLER:
J�K7L�MON coffeeStatus // full or emptyP>Q L R#STK7N coffeeStock // stock levelof coffee
Thisspecificationdefinestwo permissionsfor COFFEEFILLER: it saysthattheagentcarry-ing out therolehaspermissionto accessthevaluecoffeeStatus, andhaspermissionto bothreadandmodify thevaluecoffeeStock. Thereis alsoa third typeof permission,generates,which indicatesthat the role is the producerof a resource(not shown in the example).Notethatthesepermissionsrelateto knowledgethat theagenthas. Thatis, coffeeStatusisa representationon thepartof theagentof somevaluein therealworld.
Somerolesareparameterisedby certainvalues. For example,we cangeneralisetheCOFFEEFILLER roleby parameterisingit with thecoffeemachinethatis to bekeptrefilled.This is specifiedin apermissionsdefinitionby thesupplied keyword,asfollows:
J�K7L�MON N8U VOV W X K7M coffeeMaker // nameof coffeemakercoffeeStatus // full or emptyP>Q L R#STK7N coffeeStock // stock levelof coffee
=.9�=;-8A,<�1C<D=.9:/E/;4�<81C3;9 Y
Table 2. Operatorsfor livenessex-pressions
Operator Interpretation
x Z y x followedby yx [ y x or y occursx\ x occurs0 or moretimesx] x occurs1 or moretimesxω x occursinfinitely often^x_ x is optionalx ` y x andy interleaved
Responsibilities The functionalityof a role is definedby its responsibilities. Thesere-sponsibilitiescanbedividedinto two categories:livenessandsafetyresponsibilities.
Livenessresponsibilitiesarethosethat,intuitively, statethat“somethinggoodhappens”.Livenessresponsibilitiesareso calledbecausethey tendto say that “somethingwill bedone”,andhencethattheagentcarryingout therole is still alive. Livenessresponsibilitiestendto follow certainpatterns.For example,theguaranteedresponsetypeof achievementgoal hasthe form “a requestis always followed by a response”.The infinite repetitionachievementgoalhasthe form “x will happeninfinitely often”. Note that thesetypesofrequirementshave beenwidely studiedin thesoftwareengineeringliterature,wheretheyhaveprovento benecessaryfor capturingpropertiesof reactivesystems[27].
In orderto illustratethe variousconceptsassociatedwith roles,we will continuewithour runningexampleof the COFFEEFILLER role. Examplesof livenessresponsibilitiesforthe COFFEEFILLER rolemightbe:
B wheneverthecoffeepot is empty, fill it up;
B wheneverfreshcoffeeis brewed,makesuretheworkersknow aboutit.
In Gaia,livenesspropertiesarespecifiedvia a livenessexpression, whichdefinesthe“life-cycle” of the role. Livenessexpressionsare similar to the life-cycle expressionof FU-SION [6], which arein turn essentiallyregularexpressions.Our livenessexpressionshavean additionaloperator, “ω”, for infinite repetition(seeTable2 for moredetails). Theythusresembleω-regularexpressions,which areknown to besuitablefor representingthepropertiesof infinite computations[32].
Livenessexpressionsdefinethepotentialexecutiontrajectoriesthroughthevariousac-tivitiesandinteractions(i.e.,overtheprotocols)associatedwith therole. Thegeneralformof a livenessexpressionis:
ROLENAME a expression
where ROLENAME is the nameof the role whoselivenesspropertiesarebeingdefined,andexpressionis the livenessexpressiondefiningthe livenesspropertiesof ROLENAME.
b )+*,*.- /.0!12/,3.4!57684�9:9�129;3;<�5>=.9:/@?.129:9�A
The atomic componentsof a livenessexpressionare either activities or protocols. Anactivity is somewhatlike a methodin object-orientedterms,or a procedurein a PASCAL-like language.It correspondsto a unit of actionthat theagentmayperform,which doesnot involve interactionwith any otheragent. Protocols,on the otherhand,areactivitiesthat do requireinteractionwith otheragents. To give the readersomevisual clues,wewrite protocolnamesin a sansserif font (asin xxx), anduseasimilar font, underlined,foractivity names(asin yyy).
To illustratelivenessexpressions,consideragaintheabove-mentionedresponsibilitiesofthe COFFEEFILLER role:
COFFEEFILLER adc Fill e InformWorkers e CheckStock e AwaitEmpty f ω
This expressionsaysthat COFFEEFILLER consistsof executingtheprotocol Fill, followedby theprotocol InformWorkers, followedby theactivity CheckStock andtheprotocol AwaitEmpty.Thesequentialexecutionof theseprotocolsandactivities is thenrepeatedinfinitely often.For themoment,weshalltreattheprotocolssimplyaslabelsfor interactionsandshallnotworry abouthow they areactuallydefined(thismatterwill bediscussedin section3.2).
Complex livenessexpressionscanbemadeeasierto readby structuringthem.A simpleexampleillustrateshow this is done:
COFFEEFILLER adc All f ω
ALL a Fill e InformWorkers e CheckStock e AwaitEmpty
Thesemanticsof suchdefinitionsarestraightforwardtextual substitution.In many cases,it is insufficient simply to specifythe livenessresponsibilitiesof a role.
This is becauseanagent,carryingoutarole,will berequiredto maintaincertaininvariantswhile executing. For example,we might requirethat a particularagenttaking part inanelectroniccommerceapplicationnever spendsmoremoney thanit hasbeenallocated.Theseinvariantsarecalledsafetyconditions,becausethey usuallyrelateto theabsenceofsomeundesirableconditionarising.
Safetyrequirementsin Gaiaarespecifiedby meansof a list of predicates.Thesepred-icatesare typically expressedover the variableslisted in a role’s permissionsattribute.Returningto our COFFEEFILLER role, anagentcarryingout this role will generallybere-quired to ensurethat the coffee stock is never empty. We cando this by meansof thefollowing safetyexpression:
B coffeeStock g 0
By convention,we simply list safetyexpressionsasa bulleted list, eachitem in the listexpressingan individual safetyresponsibility. It is implicitly assumedthat theserespon-sibilities apply acrossall statesof the systemexecution. If the role is of infinitely longduration(asin the COFFEEFILLER example),thentheinvariantsmustalwaysbetrue.
It is now possibleto preciselydefinetheGaiarolesmodel. A rolesmodelis comprisedof asetof roleschemata, onefor eachrole in thesystem.A roleschemadrawstogetherthe
=.9�=;-8A,<�1C<D=.9:/E/;4�<81C3;9 h
RoleSchema: nameof role
Description shortEnglishdescriptionof theroleProtocolsandActivities protocolsandactivitiesin which therole playsa partPermissions “rights” associatedwith theroleResponsibilities
Liveness livenessresponsibilitiesSafety safetyresponsibilities
Figure3. Templatefor RoleSchemata
RoleSchema: COFFEEFILLER
Description:This role involvesensuringthat the coffee pot is kept filled, andinforming the workerswhenfreshcoffeehasbeenbrewed.
ProtocolsandActivities:Fill, InformWorkers, CheckStock, AwaitEmpty
Permissions: ikjmlmn�o oqp�r8r8s t juncoffeeMaker // nameof coffeemaker
coffeeStatus // full or emptyv w l8x yzjuo coffeeStock // stock levelof coffee
ResponsibilitiesLiveness:
COFFEEFILLER {}| Fill Z InformWorkers Z CheckStock Z AwaitEmpty ~ ωSafety:�
coffeeStock g 0
Figure4. Schemafor role COFFEEFILLER
variousattributesdiscussedaboveinto asingleplace(Figure3). An exemplarinstantiationis givenfor the COFFEEFILLER role in Figure4. Thisschemaindicatesthat COFFEEFILLER
haspermissionto readthecoffeeMaker parameter(thatindicateswhichcoffeemachinetherole is intendedto keepfilled), andthecoffeeStatus(thatindicateswhetherthemachineisfull or empty).In addition,therolehaspermissionto changethevaluecoffeeStock.
3.2. TheInteractionModel
Thereareinevitably dependenciesandrelationshipsbetweenthevariousrolesin a multi-agentorganisation.Indeed,suchinterplayis centralto theway in which thesystemfunc-tions. Given this fact, interactionsobviously needto be capturedandrepresentedin the
��� )+*,*.- /.0!12/,3.4!57684�9:9�129;3;<�5>=.9:/@?.129:9�A
CoffeeFiller
Fill
CoffeeMachine
Fill coffee machine
supplied coffeeMaker
coffeeStock
Figure5. The Fill ProtocolDefinition
analysisphase.In Gaia,suchlinks betweenrolesarerepresentedin the interactionmodel.Thismodelconsistsof a setof protocoldefinitions, onefor eachtypeof inter-role interac-tion. Herea protocolcanbeviewedasaninstitutionalisedpatternof interaction.That is,a patternof interactionthathasbeenformally definedandabstractedaway from any par-ticular sequenceof executionsteps.Viewing interactionsin this way meansthatattentionis focusedon theessentialnatureandpurposeof theinteraction,ratherthanonthepreciseorderingof particularmessageexchanges(cf. theinteractiondiagramsof OBJECTORY [6,pp198–203]or thescenariosof FUSION [6]).
Thisapproachmeansthatasingleprotocoldefinitionwill typically giveriseto anumberof messageinterchangesin therun timesystem.For example,consideranEnglishauctionprotocol. This involvesmultiple roles (sellersandbidders)andmany potentialpatternsof interchange(specificprice announcementsandcorrespondingbids). However at theanalysisstage,suchpreciseinstantiationdetailsareunnecessary, andtoopremature.
A protocoldefinitionconsistsof thefollowing attributes:
B purpose: brief textual descriptionof the natureof the interaction(e.g.,“informationrequest”,“scheduleactivity” and“assigntask”);
B initiator: therole(s)responsiblefor startingtheinteraction;
B responder: therole(s)with which theinitiator interacts;
B inputs: informationusedby therole initiator while enactingtheprotocol;
B outputs: informationsuppliedby/to the protocolresponderduring the courseof theinteraction;
B processing: brief textual descriptionof any processingtheprotocolinitiator performsduringthecourseof theinteraction.
As an illustration,considerthe Fill protocol,which formspartof the COFFEEFILLER role(Figure5). This statesthat the protocol Fill is initiated by the role COFFEEFILLER andinvolvesthe role COFFEEMACHINE. Theprotocolinvolves COFFEEFILLER puttingcoffeein themachinenamedcoffeeMaker, andresultsin COFFEEMACHINE beinginformedaboutthevalueof coffeeStock. We will seefurtherexamplesof protocolsin section5.
=.9�=;-8A,<�1C<D=.9:/E/;4�<81C3;9 ���
3.3. TheAnalysisProcess
Theanalysisstageof Gaiacannow besummarised:
1. Identify therolesin thesystem.Rolesin asystemwill typically correspondto:
B individuals,eitherwithin anorganisationor actingindependently;B departmentswithin anorganisation;orB organisationsthemselves.
Output: A prototypicalrolesmodel— a list of thekey rolesthatoccurin thesystem,eachwith aninformal,unelaborateddescription.
2. For eachrole, identify anddocumenttheassociatedprotocols. Protocolsarethepat-ternsof interactionthatoccurin thesystembetweenthevariousroles.For example,aprotocolmaycorrespondto anagentin theroleof BUYER submittinga bid to anotheragentin theroleof SELLER.
Output: An interactionmodel,whichcapturestherecurringpatternsof inter-roleinter-action.
3. Usingtheprotocolmodelasabasis,elaboratetherolesmodel.
Output: A fully elaboratedrolesmodel,whichdocumentsthekey rolesoccurringin thesystem,theirpermissionsandresponsibilities,togetherwith theprotocolsandactivitiesin which they participate.
4. Iteratestages(1)–(3).
4. Design
Theaim of a “classical”designprocessis to transformtheabstractmodelsderivedduringthe analysisstageinto modelsat a sufficiently low level of abstractionthat they canbeeasilyimplemented.This is not thecasewith agent-orienteddesign,however. Rather, theaim in Gaiais to transformtheanalysismodelsinto a sufficiently low level of abstractionthattraditionaldesigntechniques(includingobject-orientedtechniques)maybeappliedinorderto implementagents.To put it anotherway, Gaiais concernedwith how a societyofagentscooperateto realisethesystem-level goals,andwhatis requiredof eachindividualagentin orderto do this. Actually howanagentrealisesits servicesis beyondthescopeofGaia,andwill dependon theparticularapplicationdomain.
The Gaiadesignprocessinvolvesgeneratingthreemodels(seeFigure1). The agentmodelidentifiestheagenttypesthatwill makeup thesystem,andtheagentinstancesthatwill beinstantiatedfrom thesetypes.Theservicesmodelidentifiesthemainservicesthatare requiredto realisethe agent’s role. Finally, the acquaintancemodeldocumentsthelinesof communicationbetweenthedifferentagents.
�>( )+*,*.- /.0!12/,3.4!57684�9:9�129;3;<�5>=.9:/@?.129:9�A
Table3. InstanceQualifiers
Qualifier Meaning
n therewill beexactlyn instancesmZ Z n therewill bebetweenm andn instances\ therewill be0 or moreinstances] therewill be1 or moreinstances
4.1. TheAgentModel
Thepurposeof theGaiaagentmodelis to documentthevariousagent typesthatwill beusedin thesystemunderdevelopment,andtheagentinstancesthatwill realisetheseagenttypesat run-time.
An agenttypeis bestthoughtof asasetof agentroles.Theremayin factbeaone-to-onecorrespondencebetweenroles(asidentifiedin therolesmodel— seesection3.1)andagenttypes. However, this neednot be the case.A designercanchooseto packagea numberof closelyrelatedrolesin thesameagenttypefor thepurposesof convenience.Efficiencywill alsobeamajorconcernat thisstage:adesignerwill almostcertainlywantto optimisethedesign,andoneway of doingthis is to aggregatea numberof agentrolesinto a singletype. An exampleof wheresucha decisionmaybenecessaryis wherethe“footprint” ofan agent(i.e., its run-timerequirementsin termsof processorpower or memoryspace)is so large that it is moreefficient to deliver a numberof roles in a singleagentthantodeliver a numberof agentseachperforminga singlerole. Thereis obviously a trade-offbetweenthe coherenceof an agenttype (how easilyits functionalitycanbe understood)and the efficiency considerationsthat comeinto play whendesigningagenttypes. Theagentmodelis definedusinga simpleagent typetree, in which leaf nodescorrespondtoroles, (asdefinedin the rolesmodel),andothernodescorrespondto agenttypes. If anagenttype t1 haschildrent2 and t3, thenthis meansthat t1 is composedof the rolesthatmakeup t2 andt3.
We documenttheagentinstancesthatwill appearin a systemby annotatingagenttypesin theagentmodel(cf. thequalifiersfrom FUSION [6]). An annotationn meansthattherewill beexactlyn agentsof this typein therun-timesystem.An annotationme$e n meansthattherewill beno lessthanm andnomorethann instancesof this typein a run-timesystem(m � n). An annotation� meansthattherewill bezeroor moreinstancesat run-time,and�
meansthattherewill beoneor moreinstancesat run-time(seeTable3).
Note that inheritanceplaysno part in Gaiaagentmodels. Our view is that agentsarecoarsegrainedcomputationalsystems,andanagentsystemwill typically containonly acomparatively smallnumberof rolesandtypes,with oftena one-to-onemappingbetweenthem.For thisreason,webelievethatinheritancehasnousefulpartto playin thedesignofagenttypes.(Of course,whenit comesto actuallyimplementingagents,inheritancemaybeusedto greateffect, in thenormalobject-orientedfashion.)
=.9�=;-8A,<�1C<D=.9:/E/;4�<81C3;9 �>F
4.2. TheServicesModel
As its namesuggests,the aim of the Gaiaservicesmodel is to identify the servicesas-sociatedwith eachagentrole, andto specifythemainpropertiesof theseservices.By aservice,we meana functionof theagent. In OO terms,a servicewould correspondto amethod;however, we do not meanthatservicesareavailablefor otheragentsin thesamewaythatanobject’smethodsareavailablefor anotherobjectto invoke.Rather, aserviceissimplyasingle,coherentblockof activity in whichanagentwill engage.It shouldbeclearthereeveryactivity identifiedat theanalysisstagewill correspondto a service,thoughnoteveryservicewill correspondto anactivity.
For eachservicethat may be performedby an agent,it is necessaryto documentitsproperties. Specifically, we must identify the inputs, outputs, pre-conditions, andpost-conditionsof eachservice. Inputsandoutputsto serviceswill be derived in an obviousway from theprotocolsmodel.Pre-andpost-conditionsrepresentconstraintson services.Thesearederived from the safetypropertiesof a role. Note thatby definition,eachrolewill beassociatedwith at leastoneservice.
The servicesthat an agentwill perform are derived from the list of protocols,activ-ities, responsibilitiesand the livenesspropertiesof a role. For example, returning tothe coffee example,therearefour activities andprotocolsassociatedwith this role: Fill,InformWorkers, CheckStock, and AwaitEmpty. In general,therewill beat leastoneserviceassociatedwith eachprotocol. In thecaseof CheckStock, for example,theservice(whichmayhave thesamename),will takeasinput thestocklevel andsomethresholdvalue,andwill simply comparethetwo. Thepre-andpost-conditionswill bothstatethat thecoffeestocklevel is greaterthan0. This is oneof thesafetypropertiesof therole COFFEEFILLER.
The Gaiaservicesmodeldoesnot prescribean implementationfor the servicesit doc-uments. The developeris free to realisethe servicesin any implementationframeworkdeemedappropriate.For example,it may be decidedto implementservicesdirectly asmethodsin anobject-orientedlanguage.Alternatively, a servicemaybedecomposedintoa numberof methods.
4.3. TheAcquaintanceModel
Thefinal Gaiadesignmodelis probablythesimplest:theacquaintancemodel. Acquain-tancemodelssimplydefinethecommunicationlinks thatexist betweenagenttypes.Theydo not definewhatmessagesaresentor whenmessagesaresent— they simply indicatethatcommunicationpathwaysexist. In particular, thepurposeof anacquaintancemodelis to identify any potentialcommunicationbottlenecks,whichmaycauseproblemsat run-time (seesection5 for anexample).It is goodpracticeto ensurethatsystemsarelooselycoupled,andtheacquaintancemodelcanhelp in doingthis. On thebasisof theacquain-tancemodel,it maybefoundnecessaryto revisit theanalysisstageandrework thesystemdesignto removesuchproblems.
An agentacquaintancemodelis simply a graph,with nodesin thegraphcorrespondingto agenttypesandarcsin the graphcorrespondingto communicationpathways. Agentacquaintancemodelsaredirectedgraphs,andso an arc a � b indicatesthat a will send
� G )+*,*.- /.0!12/,3.4!57684�9:9�129;3;<�5>=.9:/@?.129:9�A
messagesto b, but not necessarilythatb will sendmessagesto a. An acquaintancemodelmaybederivedin astraightforwardway from theroles,protocols,andagentmodels.
4.4. TheDesignProcess
TheGaiadesignstagecannow besummarised:
1. Createanagentmodel:
B aggregaterolesinto agenttypes, andrefineto form anagenttypehierarchy;B documenttheinstancesof eachagenttypeusinginstanceannotations.
2. Developa servicesmodel,by examiningactivities, protocols,andsafetyandlivenesspropertiesof roles.
3. Developanacquaintancemodelfrom theinteractionmodelandagentmodel.
5. A Case Study: Agent-Based Business Process Management
Thissectionbriefly illustrateshow Gaiacanbeapplied,throughacasestudyof theanalysisand designof an agent-basedsystemfor managinga British Telecombusinessprocess(see[20] for moredetails).For reasonsof brevity, we omit somedetails,andaim insteadto giveageneralflavourof theanalysisanddesign.
Theparticularapplicationis providing customerswith a quotefor installinga networkto deliver a particulartypeof telecommunicationsservice.This activity involvesthe fol-lowing departments:the customerservicedivision (CSD), the designdivision (DD), thelegal division (LD) andthevariousorganisationswho provide theout-sourcedserviceofvettingcustomers (VCs). Theprocessis initiatedby acustomercontactingtheCSDwith asetof requirements.In parallelto capturingtherequirements,theCSDgetsthecustomervetted.If thecustomerfails thevettingprocedure,thequoteprocessterminates.Assumingthecustomeris satisfactory, their requirementsaremappedagainsttheserviceportfolio. Ifthey canbemetby a standardoff-the-shelfitem thenanimmediatequotecanbeoffered.In thecaseof bespokeservices,however, theprocessis morecomplex. DD startsto designa solutionto satisfythe customer’s requirementsandwhilst this is occurringLD checksthelegality of theproposedservice.If thedesiredserviceis illegal, thequoteprocesster-minates.Assumingtherequestedserviceis legal, thedesignwill eventuallybecompletedandcosted.DD theninformsCSDof thequote.CSD,in turn, informsthecustomer. Thebusinessprocessthenterminates.
Moving from this process-orienteddescriptionof the system’s operationto an organi-sationalview is comparatively straightforward. In many casesthereis a oneto onemap-ping betweendepartmentsandroles. CSD’s behaviour falls into two distinct roles: oneactingasan interfaceto thecustomer( CUSTOMERHANDLER, Figure6), andoneoversee-ing theprocessinsidetheorganisation( QUOTEMANAGER, Figure7). Thus,theVC’s, theLD’s, and the DD’s behaviour are coveredby the roles CUSTOMERVETTER (Figure 8),LEGALADVISOR (Figure9), and NETWORKDESIGNER (Figure10) respectively. The finalrole is thatof the CUSTOMER (Figure11)whorequiresthequote.
=.9�=;-8A,<�1C<D=.9:/E/;4�<81C3;9 �>H
RoleSchema: CUSTOMERHANDLER (CH)
Description:Receivesquoterequestfromthecustomerandoverseesprocessto ensureappropriatequoteis returned.
ProtocolsandActivities:AwaitCall, ProduceQuote, InformCustomer
Permissions:ikjmlmn�o�o�p8r8r8s t juncustomerDetails // customercontactinformationo�p8r8r8s t juncustomerRequirements // whatcustomerwants
quote // completedquoteor nil
ResponsibilitiesLiveness:
CUSTOMERHANDLER {�| AwaitCall Z GenerateQuote ~ ωGENERATEQUOTE {�| ProduceQuote Z InformCustomer ~
Safety:�true
Figure6. Schemafor role CUSTOMERHANDLER
With the respective role definitionsin place,the next stageis to definethe associatedinteractionmodelsfor theseroles. Herewe focuson the interactionsassociatedwith theQUOTEMANAGER role. Thisroleinteractswith the CUSTOMER roletoobtainthecustomer’srequirements( GetCustomerRequirements protocol,Figure12c)andwith the CUSTOMERVETTER
role to determinewhetherthecustomeris satisfactory( VetCustomer protocol,Figure12a).If the customerprovesunsatisfactory, thesearethe only two protocolsthat areenacted.If thecustomeris satisfactorythentheir requestis costed.This costinginvolvesenactingactivity CostStandardService for frequentlyrequestedservicesor the CheckServiceLegality
(Figure12b)and CostBespokeService (Figure12d)protocolsfor non-standardrequests.Having completedour analysisof the application,we now turn to the designphase.
The first model to be generatedis the agentmodel (Figure 13). This shows, for mostcases,a one-to-onecorrespondencebetweenrolesandagenttypes. The exceptionis forthe CUSTOMERHANDLER and QUOTEMANAGER roleswhich, becauseof their high degreeof interdependencearegroupedinto asingleagenttype.
The secondmodel is the servicesmodel. Again becauseof spacelimitations we con-centrateon the QUOTEMANAGER role andthe CustomerServiceDivision Agent. Basedon the QUOTEMANAGER role,sevendistinctservicescanbeidentified(Table3). FromtheGetCustomerRequirements protocol,we derive theservice“obtaincustomerrequirements”.Thisservicehandlestheinteractionfrom theperspectiveof thequotemanager. It takesthecustomerDetailsas input and returnsthe customerRequirementsas output (Figure12c).Therearenoassociatedpre-or post-conditions.
Theserviceassociatedwith the VetCustomer protocolis “vet customer”.Its inputs,de-rivedfrom theprotocoldefinition(Figure12a),arethecustomerDetailsandits outputsarecreditRating. Thisservicehasa pre-conditionthatanappropriatecustomervettermustbe
�>I )+*,*.- /.0!12/,3.4!57684�9:9�129;3;<�5>=.9:/@?.129:9�A
RoleSchema: QUOTEMANAGER (QM)
Description:Responsiblefor enactingthequoteprocess.Generatesa quoteor returnsnoquote(nil) if customerisinappropriateor serviceis illegal.
ProtocolsandActivities:VetCustomer, GetcustomerRequirements, CostStandardService, CheckServiceLegality,CostBespokeService
Permissions:i�j�l n8o o�p8r8r8s t juncustomerDetails // customercontactinformationo�p8r8r8s t juncustomerRequirements // detailedservicerequirements
creditRating // customer’s credit ratingserviceIsLegal // booleanfor bespoke requestsyzj x�j i�l��2j�oquote // completedquoteor nil
ResponsibilitiesLiveness:
QUOTEMANAGER { QuoteResponseQUOTERESPONSE {�| VetCustomer ` GetcustomerRequirements ~�[| VetCustomer ` GetcustomerRequirements ~CZ
CostServiceCOSTSERVICE { CostStandardService [| CheckServiceLegality ` CostBespokeService ~
Safety:�creditRating� bad � quote� nil
�serviceIsLegal � false � quote� nil
Figure7. Schemafor role QUOTEMANAGER
available(derivedfrom the TenderContract interactionon the VetCustomer protocol)andapostconditionthatthevalueof creditRatingis non-null(becausethis formspartof asafetyconditionof the QUOTEMANAGER role).
Thethirdserviceinvolvescheckingwhetherthecustomerissatisfactory(thecreditRatingsafetyconditionof QUOTEMANAGER). If thecustomeris unsatisfactorythenonly thefirstbranchof the QuoteRespose livenesscondition(Figure7) getsexecuted.If thecustomerissatisfactory, the CostService livenessrouteis executed.
The next servicemakesthe decisionof which pathof the CostService livenessexpres-siongetsexecuted.Either theserviceis of a standardtype(executetheservice“producestandardcosting”) or it is a bespoke servicein which casethe CheckServiceLegality andCostBespokeService protocolsareenacted.In the latter case,theprotocolsareassociatedwith the service“producebespoke costing”. This serviceproducesa non-nil value forquoteaslongastheserviceIsLegal safetycondition(Figure7) is notviolated.
Thefinal serviceinvolvesinforming thecustomerof thequote.This, in turn,completesthe CUSTOMERHANDLER role.
=.9�=;-8A,<�1C<D=.9:/E/;4�<81C3;9 �TY
Ser
vice
Inpu
tsO
utpu
tsP
re-c
ondi
tion
Pos
t-co
nditi
on
obta
incu
stom
erre
-qu
irem
ents
cust
om
erD
eta
ilscu
sto
me
rRe
qu
irem
en
tstr
uetr
ue
vetc
usto
mer
cust
om
erD
eta
ilscr
ed
itRa
ting
cust
omer
vette
rava
ilabl
ecr
ed
itRa
ting
��� nilch
eck
cust
omer
satis
-fa
ctor
ycr
ed
itRa
ting
con
tinu
atio
nD
eci
sio
nco
ntin
ua
tion
De
cisi
on
�
nil
con
tinu
atio
nD
eci
sio
n
���
nil
chec
kser
vice
type
cust
om
erR
eq
uirem
en
tsse
rvic
eTy
pe
cre
ditR
atin
g
��� bad
serv
ice
Typ
e
�
� sta
nd
ard
� besp
oke
�
prod
uce
stan
dard
ser-
vice
cost
ing
serv
ice
Typ
e,cu
sto
me
rRe
qu
irem
en
tsq
uo
tese
rvic
eTy
pe
� stan
da
rd
�
qu
ote
� nilq
uo
te
��� nil
prod
uce
besp
oke
ser-
vice
cost
ing
serv
ice
Typ
e,cu
sto
me
rRe
qu
irem
en
tsq
uo
te,s
erv
ice
IsL
ega
lse
rvic
eTy
pe
�
be
spo
ke
� qu
ote
�
nil
� serv
ice
IsL
ega
l
� qu
ote
��� nil� �
� qu
ote
�
nil
��� se
rvic
eIs
Lega
l�
info
rmcu
stom
ercu
sto
me
rDe
tails,
qu
ote
true
cust
omer
skno
wqu
ote
Tab
le3
.The
serv
ices
mod
el
�>b )+*,*.- /.0!12/,3.4!57684�9:9�129;3;<�5>=.9:/@?.129:9�A
RoleSchema: CUSTOMERVETTER (CV)
Description:Checkscreditratingof suppliedcustomer.
ProtocolsandActivities:VettingRequest, VettingResponse
Permissions:ikjmlmn�o oqp8r�r8s t juncustomerDetails // customercontactinformation
customerRatingInformation// credit rating informationyzj x j i�lm�2juocreditRating // credit ratingof customer
ResponsibilitiesLiveness:
CUSTOMERVETTER {}| VettingRequest Z VettingResponse ~Safety:�
infoAvailable� customerDetails� customerRatingInformation
Figure8. Schemafor role CUSTOMERVETTER
RoleSchema: LEGALADVISOR (LA)
Description:Determineswhethergivenbespoke servicerequestis legalor not.
ProtocolsandActivities:LegalCheckRequest, LegalCheckResponse
Permissions:ikjmlmn�o oqp8r�r8s t juncustomerRequirements // detailsof proposedserviceyzj x j i�lm�2juo
serviceIsLegal // trueor false
ResponsibilitiesLiveness:
LEGALADVISOR {�| LegalCheckRequest Z LegalCheckResponse ~Safety:�
true
Figure9. Schemafor role LEGALADVISOR
Thefinal modelis theacquaintancemodel,which shows thecommunicationpathwaysthatexistbetweenagents(Figure14).
=.9�=;-8A,<�1C<D=.9:/E/;4�<81C3;9 �>h
RoleSchema: NETWORKDESIGNER (ND)
Description:Designandcostnetwork to meetbespoke servicerequestrequirements.
ProtocolsandActivities:CostingRequest, ProduceDesign, ReturnCosting
Permissions:ikjmlmn�o oqp8r�r8s t juncustomerRequirements // detailsof proposedservice
serviceIsLegal // booleanyzj x j i�lm�2juoquote // costof realisingservice
ResponsibilitiesLiveness:
NETWORKDESIGNER {}| CostingRequest Z ProduceDesign Z ReturnCosting ~Safety:�
serviceIsLegal � true
Figure10. Schemafor role NETWORKDESIGNER
RoleSchema: CUSTOMER (CUST)
Description:Organisationor individual requiringaservicequote.
ProtocolsandActivities:MakeCall, GiveRequirements
Permissions:yzj x j�i�lm�2juocustomerDetails // Ownerof customerinformationcustomerRequirements // Ownerof customerrequirements
ResponsibilitiesLiveness:
CUSTOMER {�| MakeCall Z GiveRequirements ~ +Safety:�
true
Figure11. Schemafor role CUSTOMER
6. Related Work
In recenttimestherehasbeenasurgeof interestin agent-orientedmodellingtechniquesandmethod-ologies.Thevariousapproachesmayberoughlygroupedasfollows:
(�� )+*,*.- /.0!12/,3.4!57684�9:9�129;3;<�5>=.9:/@?.129:9�A
QM
CostingRequest
ND
ask for costing
ReturnCosting
CH, QMND
design network andcost solution
customerRequirements
customerRequirements
quote
TenderContract
QM
select which CV to
award contract tovettingRequirements
VettingRequest
QM CV
customer
ask for vetting of
customerDetails
VettingResponse
CV QM
perform vetting and
return credit rating
customerDetails
customerRatingInfo
creditRating
CV QM
LegalCheckRequest
LA
service’s legality
ask for check of
customerRequirements
customerRequirements
LegalCheckResponse
LA QM, ND
check service legality
serviceIsLegal
(a) (b)
(c) (d)
QM
RequirementsRequest
CUST
requirements
details of customer’s
customerDetails
CUST QM
details
provide service
customerRequirements
GiveRequirements
Figure 12. Definition of protocols associatedwith the QUOTEMANAGER role: (a) VetCustomer,(b) CheckServiceLegality, (c) GetCustomerRequirements, and(d) CostBespokeService.
CustomerAgent
Customer CustomerHandler QuoteManager
CustomerServiceDivisionAgent1
CustomerVetter
VetCustomerAgent3..10
NetworkDesignerAgent
NetworkDesigner
1..10LegalAdvisorAgent
LegalAdvisor
1..5+
Figure13. Theagentmodel
¡ thosesuchas[4, 24] which take existing OO modellingtechniquesor methodologiesastheirbasis,seekingeitherto extendandadaptthemodelsanddefinea methodologyfor their use,orto directlyextendtheapplicabilityof OOmethodologiesandtechniques,suchasdesignpatterns,to thedesignof agentsystems,
=.9�=;-8A,<�1C<D=.9:/E/;4�<81C3;9 (!�
CustomerServiceDivisionAgent
CustomerAgent
NetworkDesignAgent LegalAdvisorAgentVetCustomerAgent
Figure14. Theacquaintancemodel
¡ thosesuchas[3, 17] whichbuild uponandextendmethodologiesandmodellingtechniquesfromknowledgeengineering,providing formal, compositionalmodellinglanguagessuitablefor theverificationof systemstructureandfunction,¡ thosewhich take existing formal methodsandlanguages,for exampleZ [31], andprovide def-initions within sucha framework thatsupportthespecificationof agentsor agentsystems[26],and¡ thosewhich have essentiallybeendevelopedde novo for particularkinds of agentsystems.CASSIOPEIA [7], for example,supportsthedesignof ContractNet [29] basedsystemsandhasbeenappliedto RobotSoccer.
Thesedesignmethodologiesmayalsobedividedinto thosethatareessentiallytop-down approachesbasedon progressive decompositionof behaviour, usually building (as in Gaia) on somenotionof role, andthosesuchas CASSIOPEIA that arebottom-upapproacheswhich begin by identifyingelementaryagentbehaviours. A very useful survey which classifiesandreviews theseandothermethodologieshasalsoappeared[16].
The definitionanduseof variousnotionsof role, responsibility, interaction,teamandsocietyororganizationin particularmethodsfor agent-orientedanalysisanddesignhasinheritedor adaptedmuchfrom moregeneralusesof theseconceptswithin multi-agentsystems,includingorganization-focussedapproachessuchas [14, 9, 18] andsociologicalapproachessuchas [5]. However, it isbeyond thescopeof this article to comparetheGaiadefinitionanduseof theseconceptswith thisheritage.
Instead,wewill focushereontherelationshipbetweenGaiaandotherapproachesbasedthatbuilduponOO techniques,in particularthe kgr approach[24, 23]. But it is perhapsusefulto begin bysummarizingwhy OO modellingtechniquesanddesignmethodologiesthemselvesarenot directlyapplicableto multi-agentsystemdesign.
6.1. Shortcomingsof ObjectOrientedtechniques
Thefirst problemconcernsthemodellingof individual agentsor agentclasses.While therearesu-perficialsimilaritiesbetweenagentsandobjects,representinganagentasanobject,i.e., asa setofattributesandmethods,is not very usefulbecausethe representationis too fine-grained,operatingat an inappropriatelevel of abstraction.An agentsorepresentedmayappearquitestrange,perhapsexhibiting only onepublicmethodwhosefunctionis to receivemessagesfrom otheragents.Thusanobjectmodeldoesnot capturemuchusefulinformationaboutanagent,andpowerful OO conceptssuchasinheritanceandaggregationbecomequiteuselessasa resultof thepoverty of therepresen-tation.
Thereare several reasonsfor this problem. One is that the agentparadigmis basedon a sig-nificantly strongernotion of encapsulationthanthe objectparadigm. An agent’s internal stateis
(�( )+*,*.- /.0!12/,3.4!57684�9:9�129;3;<�5>=.9:/@?.129:9�A
usuallyquiteopaqueand,in somesystems,thebehaviours thatanagentwill performuponrequestarenot evenmadeknown until it advertisesthemwithin anactive system.Relatedto this is thekeycharacteristicof autonomy:agentscannotnormallybecreatedanddestroyed in the liberal mannerallowedwithin objectsystemsandthey have morefreedomto determinehow they mayrespondtomessages,including,for example,by choosingto negotiatesomeagreementabouthow ataskwill beperformed.As theunderlyingcommunicationmodelis usuallyasynchronousthereis no predefinednotionof flow of controlfrom oneagentto another:anagentmayautonomouslyinitiate internalorexternalbehaviour at any time, not just whenit is senta message.Finally, anagent’s internalstate,includingits knowledge,mayneedto berepresentedin amannerthatcannoteasilybetranslatedintoasetof attributes;in any caseto dosowouldconstituteaprematureimplementationbias.
Thesecondproblemconcernsthepower of objectmodelsto adequatelycapturetherelationshipsthatholdbetweenagentsin amulti-agentsystem.While thesecondarymodelsin commonusein OOmethodologiessuchasusecasesandinteractiondiagramsmayusefullybeadapted(with somewhatdifferentsemantics),theObjectModel,whichconstitutestheprimaryspecificationof anOOsystem,capturesassociationsbetweenobject classesthat model largely static dependenciesand pathsofaccessibilitywhicharelargely irrelevantin a multi-agentsystem.Only theinstantiationrelationshipbetweenclassesandinstancescanbe directly adopted.Importantaspectsof relationshipsbetweenagentssuchas their repertoireof interactionsand their degreeof control or influenceupon eachotherarenot easilycaptured.The essentialproblemhereis theuniformity andstaticnatureof theOO objectmodel. An adequateagentmodelneedsto capturetheserelationshipsbetweenagents,their dynamicnature,andperhapsalsorelationshipsbetweenagentsandnon-agentelementsof thesystem,includingpassive or abstractonessuchasthosemodelledhereasresources.
Both of theseareproblemsconcerningthesuitability of OO modellingtechniquesfor modellinga multi-agentsystem. Another issueis the applicability of OO methodologiesto the processofanalyzinganddesigninga multi-agentsystem.OO methodologiestypically consistof an iterativerefinementcycleof identifyingclasses,specifyingtheir semanticsandrelationships,andelaboratingtheir interfacesandimplementation.At this level of abstraction,they appearsimilar to typical AOmethodologies,which usuallyproceedby identifying rolesandtheir responsibilitiesandgoals,de-velopinganorganizationalstructure,andelaboratingtheknowledgeandbehavioursassociatedwitha roleor agent.
However, thissimilarity disappearsatthelevel of detailrequiredby themodels,asthekey abstrac-tions involvedarequitedifferent. For example,thefirst stepof objectclassidentificationtypicallyconsiderstangiblethings, roles, organizations,eventsand even interactionsas candidateobjects,whereastheseneedto beclearlydistinguishedandtreateddifferentlyin anagent-orientedapproach.Theuniformity andconcretenessof theobjectmodelis thebasisof theproblem;OOmethodologiesprovideguidanceor inspirationratherthanadirectlyusefulapproachto analysisanddesign.
6.2. Comparisonwith theKGR approach
The KGR approach[24, 23] was developedto fulfill the needfor a principled approachto thespecificationof complex multi-agentsystemsbasedon the belief-desire-intention(BDI) technol-ogy of theProceduralReasoningSystem(PRS) andtheDistributedMulti-Agent ReasoningSystem(DMARS) [25, 8]. A key motivation of the work wasto provided useful, familiar mechanismsforstructuringandmanagingthecomplexity of suchsystems.
The first andmostobvious differencebetweenthe approachproposedhereandKGR is one ofscope.Our methodologydoesnot attemptto unify theanalysisandabstractdesignof a multi-agentsystemwith its concretedesignandimplementationwith aparticularagenttechnology, regardingtheoutputof theanalysisanddesignprocessasanabstractspecificationto which traditionallower-leveldesignmethodologiesmaybeapplied.KGR, by contrast,makesa strongarchitecturalcommitment
=.9�=;-8A,<�1C<D=.9:/E/;4�<81C3;9 (�F
to BDI architecturesandproposesa designelaborationandrefinementprocessthatleadsto directlyexecutableagentspecifications.Given the proliferationof availableagenttechnologies,thereareclearlyadvantagesto a moregeneralapproach,asproposedhere. However, thedownsideis that itcannotprovideasetof models,abstractionsandterminologythatmaybeuseduniformly throughoutthesystemlife cycle. Furthermore,theremaybea needfor iterationof theAO analysisanddesignprocessif thelower-level designprocessrevealsissuesthatarebestresolvedat theAO level. A re-searchproblemfor ourapproachandotherslikeit is whetherandhow theadequacy andcompletenessof its outputscanbeassessedindependentlyof any traditionaldesignprocessthatfollows.
A seconddifferenceis thatin this work a cleardistinctionis madebetweentheanalysisphase,inwhich the rolesandinteractionmodelsarefully elaborated,andthe designphase,in which agent,servicesandacquaintancemodelsaredeveloped.TheKGR approachdoesnot make sucha distinc-tion, proposinginsteadthe progressive elaborationandrefinementof agentandinteractionmodelswhich capturerespectively roles,agentsandservices,and interactionsandacquaintances.Whilebothmethodologiesbegin with the identificationof rolesandtheir properties,herewe have chosento modelseparatelyabstractagents(roles),concreteagentsandtheservicesthey provide. KGR, ontheotherhand,employsamoreuniformagentmodelwhichadmitsbothabstractagentsandconcreteagentclassesandinstancesandallows themto be organizedwithin an inheritancehierarchy, thusallowing multiple levelsof abstractionandthedefermentof identificationof concreteagentclassesuntil latein thedesignprocess.
While bothapproachesemploy responsibilitiesasanabstractionusedto decomposethestructureof arole,they differ significantlyasto how thesearerepresentedanddeveloped.Hereresponsibilitiesconsistof safetyandlivenesspropertiesbuilt up from alreadyidentifiedinteractionsandactivities.By contrast,KGR treatsresponsibilitiesasabstractgoals,triggeredby eventsor interactions,andadoptsastrictly top-down approachto decomposingtheseinto servicesandlow level goalsfor whichactivity specificationsmaybeelaborated.Therearesimilaritieshowever, for despitetheabsenceofexplicit goalsin our approach,safetypropertiesmaybeviewedasmaintenancegoalsandlivenesspropertiesasgoalsof achievement. The notion of permissions,however, is absentfrom the KGRapproach,whereasthenotionof protocolsmaybedevelopedto a muchgreaterdegreeof detail,forexampleasin [22]. Thereprotocolsareemployed asmoregenericdescriptionsof behaviour thatmayinvolve entitiesnotmodelledasagents,suchasthecoffeemachine.
To summarizethekey differences,theKGR approach,by makingacommitmentto implementationwith aBDI agentarchitecture,is ableto employ aniterativetop-down approachto elaboratingasetofmodelsthatdescribeamulti-agentsystematboththemacro-andmicro-level, to makemoreextensiveuseof OO modellingtechniques,andto produceexecutablespecificationsasits final output. Theapproachwe have describedhereis a mixed top-down andbottom-upapproachwhich employs amorefine-grainedanddiversesetof genericmodelsto capturetheresultof theanalysisanddesignprocess,and tries to avoid any prematurecommitment,either architectural,or as to the detaileddesignandimplementationprocesswhichwill follow. Weenvisage,however, thatour approachcanbesuitablyspecializedfor specificagentarchitecturesor implementationtechniques;this is asubjectfor furtherresearch.
7. Conclusions and Further Work
In this article,we have describedGaia,a methodologyfor the analysisanddesignof agent-basedsystems. The key conceptsin Gaia are roles, which have associatedwith them responsibilities,permissions,activities,andprotocols.Rolescaninteractwith oneanotherin certaininstitutionalisedways,whicharedefinedin theprotocolsof therespective roles.
Thereareseveral issuesremainingfor futurework.
( G )+*,*.- /.0!12/,3.4!57684�9:9�129;3;<�5>=.9:/@?.129:9�A
¡ Self-InterestedAgents.
Gaiadoesnot explicitly attemptto dealwith systemsin which agentsmaynot sharecommongoals.This classof systemsrepresentsarguablythemostimportantapplicationareafor multi-agentsystems,andit is thereforeessentialthatamethodologyshouldbeableto dealwith it.¡ Dynamicandopensystems.
Opensystems— in which systemcomponentsmayjoin andleave at run-time,andwhich maybecomposedof entitiesthata designerhadno knowledgeof at design-time— have long beenrecognisedasadifficult classof systemto engineer[15, 13].¡ Organisationstructures.
Anotheraspectof agent-basedanalysisanddesignthat requiresmorework is thenotionof anorganisationalstructure.At themoment,suchstructuresareonly implicitly definedwithin Gaia— within the role and interactionmodels. However, direct, explicit representationsof suchstructureswill beof valuefor many applications.For example,if agentsareusedto modellargeorganisations,thentheseorganisationswill have an explicitly definedstructure.Representingsuchstructuresmay be the only way of adequatelycapturingandunderstandingthe organisa-tion’s communicationandcontrolstructures.More generally, thedevelopmentof organisationdesignpatternsmightbeusefulfor reusingsuccessfulmulti-agentsystemstructures(cf. [12]).¡ CooperationProtocols.
Therepresentationof inter-agentcooperationprotocolswithin Gaiais currentlysomewhat im-poverished.In futurework, wewill needto provideamuchricherprotocolspecificationframe-work.¡ InternationalStandards.
Gaiawasnot designedwith any particularstandardfor agentcommunicationin mind (suchasthe FIPA agentcommunicationlanguage[11]). However, in the event of widescaleindustrialtakeupof suchstandards,it mayprove usefulto adaptour methodologyto becompatiblewithsuchstandards.¡ FormalSemantics.
Finally, webelieve thatasuccessfulmethodologyis onethatis not only of pragmaticvalue,butonethat alsohasa well-defined,unambiguousformal semantics.While the typical developerneedneverevenbeawareof theexistenceof suchasemantics,it is neverthelessessentialto haveapreciseunderstandingof whattheconceptsandtermsin amethodologymean[33].
Acknowledgments
This articleis a muchextendedversionof [35]. We aregratefulto theparticipantsof theAgents99conference,whogaveusmuchusefulfeedback.
Notes
1. In Greekmythology, GaiawasthemotherEarthfigure. More pertinently, Gaiais thenameof aninfluentialhypothesisputforwardby theecologistJamesLovelock,to theeffect thatall theliving organismsontheEarthcanbeunderstoodascomponentsof a singleentity, which regulatestheEarth’s environment.Thethemeofmany heterogeneousentitiesactingtogetherto achieve asinglegoalis acentralthemein multi-agentsystemsresearch[1], andwasakey considerationin thethedevelopmentof ourmethodology.
2. To be moreprecise,we believe suchsystemswill requireadditionalmodelsover andabove thosethat weoutlinein thecurrentversionof themethodology.
=.9�=;-8A,<�1C<D=.9:/E/;4�<81C3;9 (�H
3. The third case,which we have not yet elaboratedin the methodology, is that a single role representsthecollective behaviour of a numberof individuals. This view is importantfor modellingcooperative andteamproblemsolving andalso for bridging the gapbetweenthe micro andthe macrolevels in an agent-basedsystem.
4. Themostwidely usedformalismfor specifyinglivenessandsafetypropertiesis temporallogic, andin pre-viouswork, theuseof suchformalismhasbeenstronglyadvocatedfor usein agentsystems[10]. Althoughit hasundoubtedstrengthsasamathematicaltool for expressinglivenessandsafetyproperties,thereis somedoubtaboutits viability asa tool for useby everydaysoftwareengineers.Wehave thereforechosenanalter-native approachto temporallogic, basedonregularexpressions,asthesearelikely to bebetterunderstoodbyour targetaudience.
5. For the moment,we do not explicitly model the creationanddeletionof roles. Thus roles arepersistentthroughoutthesystem’s lifetime. In thefuture,weplanto make thisamoredynamicprocess
References
1. A. H. Bond andL. Gasser, editors. Readingsin DistributedArtificial Intelligence. MorganKaufmannPublishers:SanMateo,CA, 1988.
2. G. Booch.Object-OrientedAnalysisandDesign(secondedition). Addison-Wesley: Reading,MA, 1994.3. F. Brazier, B. Dunin-Keplicz,N. R. Jennings,andJ.Treur. Formalspecificationof multi-agentsystems:a
real-world case.In Proceedingsof theFirst InternationalConferenceonMulti-AgentSystems(ICMAS-95),pages25–32,SanFrancisco,CA, June1995.
4. Birgit Burmeister. Modelsandmethodologiesfor agent-orientedanalysisanddesign. In KlausFischer,editor, Working Notesof the KI’96 Workshopon Agent-OrientedProgrammingand DistributedSystems.1996.DFKI DocumentD-96-06.
5. C. Castelfranchi.Commitments:from individual intentionsto groupsandorganizations.In ProceedingsoftheFirst InternationalConferenceonMulti-AgentSystems(ICMAS-95), pages41–48,SanFrancisco,CA,June1995.
6. D. Coleman,P. Arnold, S. Bodoff, C. Dollin, H. Gilchrist, F. Hayes,andP. Jeremaes.Object-OrientedDevelopment:TheFUSION Method. PrenticeHall International:HemelHempstead,England,1994.
7. AnneCollinot, Alexis Drogoul,andPhilippeBenhamou.Agentorienteddesignof asoccerrobotteam.InProceedingsof theSecondInternationalConferenceon Multi-Agent Systems(ICMAS-96), Kyoto, Japan,1996.
8. M. d’Inverno, D. Kinny, M. Luck, and M. Wooldridge. A formal specificationof dMARS. In M. P.Singh,A. Rao,andM. J.Wooldridge,editors,Intelligent AgentsIV (LNAI Volume1365), pages155–176.Springer-Verlag:Berlin, Germany, 1997.
9. JacquesFerberandOlivier Gutknecht.A meta-modelfor theanalysisanddesignof organizationsin multi-agentsystems.In Proceedingsof theThird InternationalConferenceonMulti-AgentSystems(ICMAS-98),pages128–135,Paris,France,1998.
10. M. FisherandM. Wooldridge.On theformal specificationandverificationof multi-agentsystems.Inter-nationalJournalof CooperativeInformationSystems, 6(1):37–65,1997.
11. TheFoundationfor IntelligentPhysicalAgents.Seehttp://www.fipa.org/.12. E. Gamma,R. Helm,R. Johnson,andJ.Vlissides.DesignPatterns. Addison-Wesley: Reading,MA, 1995.13. L. Gasser. Socialconceptionsof knowledgeandaction: DAI foundationsandopensystemssemantics.
Artificial Intelligence, 47:107–138,1991.14. L. Gasser, C. Braganza,and N. Hermann. MACE: A flexible testbedfor distributed AI research. In
M. Huhns,editor, DistributedArtificial Intelligence, pages119–152.PitmanPublishing:LondonandMor-ganKaufmann:SanMateo,CA, 1987.
15. C. Hewitt. Openinformationsystemssemanticsfor distributedartificial intelligence.Artificial Intelligence,47:79–106,1991.
16. C. A. Iglesias,M. Garijo, andJ.C. Gonzalez.A survey of agent-orientedmethodologies.In J.P. Muller,M. P. Singh,andA. S. Rao,editors,Intelligent AgentsV — Proceedingsof theFifth InternationalWork-shoponAgentTheories,Architectures,andLanguages(ATAL-98), LectureNotesin Artificial Intelligence.Springer-Verlag,Heidelberg, 1999.
17. CarlosIglesias,MercedesGarijo,JoseC.Gonzalez,andJuanR.Velasco.Analysisanddesignof multiagentsystemsusingMAS-CommonKADS. In M. P. Singh,A. Rao,andM. J. Wooldridge,editors,IntelligentAgentsIV (LNAI Volume1365), pages313–326.Springer-Verlag:Berlin, Germany, 1998.
(�I )+*,*.- /.0!12/,3.4!57684�9:9�129;3;<�5>=.9:/@?.129:9�A
18. Toru Ishida,LesGasser, andMakoto Yokoo. Organizationselfdesignof productionsystems.IEEETrans-actionsonKnowledge andDataEngineering, 4(2):123–134,April 1992.
19. N. R. Jennings,J. Corera,I. Laresgoiti,E. H. Mamdani,F. Perriolat,P. Skarek,andL. Z. Varga. UsingARCHON to develop real-world DAI applicationsfor electricity transportationmanagementandparticleaccelerationcontrol. IEEEExpert, 11(6):60–88,December1996.
20. N. R. Jennings,P. Faratin,M. J. Johnson,T. J. Norman,P. O’Brien, andM. E. Wiegand. Agent-basedbusinessprocessmanagement.InternationalJournalof CooperativeInformationSystems, 5(2-3):105–130,1996.
21. C. B. Jones.SystematicSoftware DevelopmentusingVDM (secondedition). PrenticeHall, 1990.22. D. Kinny. The AGENTISagentinteractionmodel. In J. P. Muller, M. P. Singh,andA. S. Rao,editors,
Intelligent AgentsV — Proceedingsof theFifth InternationalWorkshopon AgentTheories,Architectures,andLanguages(ATAL-98), LectureNotesin Artificial Intelligence.Springer-Verlag,Heidelberg, 1999.
23. D. Kinny andM. Georgeff. Modellinganddesignof multi-agentsystems.In J.P. Muller, M. Wooldridge,andN. R.Jennings,editors,IntelligentAgentsIII (LNAI Volume1193), pages1–20.Springer-Verlag:Berlin,Germany, 1997.
24. D. Kinny, M. Georgeff, andA. Rao. A methodologyandmodellingtechniquefor systemsof BDI agents.In W. VandeVeldeandJ.W. Perram,editors,AgentsBreakingAway: Proceedingsof theSeventhEuropeanWorkshopon ModellingAutonomousAgentsin a Multi-Agent World, (LNAI Volume1038), pages56–71.Springer-Verlag:Berlin, Germany, 1996.
25. David Kinny. TheDistributedMulti-Agent ReasoningSystemArchitecture and Language Specification.AustralianAI Institute,Level 6, 171La TrobeStreet,Melbourne,Australia,1993.
26. M. Luck, N. Griffiths, andM. d’Inverno. Fromagenttheoryto agentconstruction:A casestudy. In J. P.Muller, M. Wooldridge,andN. R. Jennings,editors,Intelligent AgentsIII (LNAI Volume1193), pages49–64.Springer-Verlag:Berlin, Germany, 1997.
27. A. Pnueli. Specificationanddevelopmentof reactive systems. In InformationProcessing86. ElsevierSciencePublishersB.V.: Amsterdam,TheNetherlands,1986.
28. Y. Shoham.Agent-orientedprogramming.Artificial Intelligence, 60(1):51–92,1993.29. R. G. Smith. The CONTRACT NET: A formalism for the control of distributed problemsolving. In
Proceedingsof theFifth InternationalJoint Conferenceon Artificial Intelligence(IJCAI-77), Cambridge,MA, 1977.
30. R. G. Smith. A Framework for DistributedProblemSolving. UMI ResearchPress,1980.31. M. Spivey. TheZ Notation(secondedition). PrenticeHall International:HemelHempstead,England,
1992.32. M. Wooldridge.Agent-basedsoftwareengineering.IEE ProceedingsonSoftwareEngineering, 144(1):26–
37,February1997.33. M. WooldridgeandN. R. Jennings.Intelligentagents:Theoryandpractice.TheKnowledge Engineering
Review, 10(2):115–152,1995.34. M. WooldridgeandN. R. Jennings.Pitfalls of agent-orienteddevelopment.In Proceedingsof theSecond
InternationalConferenceon AutonomousAgents(Agents98), pages385–391,Minneapolis/StPaul, MN,May 1998.
35. M. Wooldridge,N. R. Jennings,andD. Kinny. A methodologyfor agent-orientedanalysisanddesign.In Proceedingsof the Third InternationalConferenceon AutonomousAgents(Agents99), pages69–76,Seattle,WA, May 1999.
