the Gaia Methodology for Agent-Oriented Analysis and Design

8/6/2019 the Gaia Methodology for Agent-Oriented Analysis and Design

1/54

Developing Multiagent Systems:

The Gaia MethodologyFRANCO ZAMBONELLIUniversit a di Modena e Reggio EmiliaNICHOLAS R. JENNINGSUniversity of SouthamptonandMICHAEL WOOLDRIDGEUniversity of Liverpool

Systems composed of interacting autonomous agents offer a promising software engineering ap-

proach for developing ap plications in complex doma ins. However, th is multiagent system paradigmintroduces a nu mber of new abstractions and design/development issues when compar ed with moretra ditional appr oaches to software development. Accordingly, new ana lysis and design met hodolo-gies, as well as new tools, are needed to effectively engineer such systems. Against this background,the contribution of this article is twofold. First, we synthesize and clarify the key abstractions of agent-based computing as they pertain to agent-oriented software engineering. In particular, weargue th at a m ultiagent system can na tur ally be viewed and architected as a computational organization , and we identify the appropriate organizational abstractions that are central to the analysisand design of such systems. Second, we detail and extend the Gaia methodology for the analysisand design of multiagent systems. Gaia exploits the aforementioned organizational abstractionsto provide clear guidelines for the ana lysis and design of complex and open software system s. Tworepresent at ive case st udies ar e intr oduced to exemplify Gaias concepts an d to show its use a ndeffectiveness in different t ypes of multiagent system.

Categories an d Su bject Descriptors: D.2.10 [ S o f tw a r e E n g i n e e r i n g ]: Design methodologies ;I.2.11 [ Art ic ia l In te l l igence ]: Distributed Articial Intelligence mu ltiagent systems

General Terms: Algorithms, Design

Additional Key Words and P hra ses: Multiagent s ystems, agent-oriented software engineering, anal-ysis and design meth odologies, distribut ed systems, software a rchitectures

Authors addresses: F. Zambonelli, Dipartimen to di Scienze e Metodi dellIngegneria, Un iversit adi Modena e Reggio Emilia, Via Allegri 1342100 Reggio Emilia, Italy; email: [email protected]; N. R. J ennings, School of Electronics a nd Computer Science, University of South ampt on,South am pton SO17 1BJ , UK; email: [email protected]; M. Wooldridge, Depar tm ent of Comput erScience, Un iver sit y of Liver pool, Liverpool L69 7ZF, UK; ema il: M.J.Wooldrid [email protected] .Permission to make digital or hard copies of part or all of this work for personal or classroom use isgrant ed without fee provided tha t copies are not ma de or distributed for prot or direct commercialadvantage and that copies show th is notice on t he rst page or init ial screen of a display alongwith t he full cita tion. Copyrights for component s of this work owned by others t han ACM must behonored. Abstracting with credit is per mitt ed. To copy other wise, to republish, to post on servers,to redistribut e to lists, or to use an y component of this work in other works r equires prior specicpermission and /or a fee. Permissions ma y be requested from P ublicat ions Dept ., ACM, Inc., 1515Broadwa y, New York, N Y 10036 USA, fax: + 1 (212) 869-0481, or perm [email protected] 2003 ACM 1049-331X/03/0700-0317 $5.00

ACM Trans actions on Softwar e En gineering a nd Met hodology, Vol. 12, No. 3, Ju ly 2003, Pages 317370.


2/54

318 F. Zambonelli et al.

1. INTRODUCTION

The char acterist ics and expectations of software systems have chan ged dra-

mat ica l ly in the pas t few years, wi th the result tha t a range of new soft -ware en gineering cha llenges ha ve arisen [Tenn enhouse 2000; Zambonelli an dParunak 2003]. First, most software systems are now de facto concurrent anddistributed, an d a re expected t o interact with component s a nd exploit servicesthat are dynamically found in the network. Second, software systems are be-coming always-on entit ies th at cannot be stopped, restored, and maintainedin th e tra ditiona l way. Third, and a s a n atu ral consequence of the rst t wo cha r-acteristics, software systems tend to be open, in that they exist in a dynamicoperating environment where new components join and existing componentsleave on a cont inuous basis, and where t he operating conditions them selves ar elikely to chan ge in un predictable ways. These char acteristics apply, for exam-ple, to the semantic web [Berners-Lee et al. 2001], to grid computing [Fosterand Kesselman 1999], and to pervasive environments [Abelson et al . 2000;

Tennenhouse 2000].Given this new landscape, we advocate the use of m ultiagent system s (MASs)

as a software engineering pa radigm for designing and developing complexsoftware systems [Wooldridge and Jennings 1995; Jennings 2001; Wooldridge2002]. In MASs, applications are designed a nd developed in terms of au -tonomous software entities ( agents ) tha t can exibly achieve their objectivesby interacting with one another in terms of high-level protocols and languages.These char acteristics a re well suited t o tackling th e emer ging complexities fora number of reasons. First, the autonomy of the application components (i.e.,the abili ty for an agent to decide what actions i t should take at what t ime[Wooldridge an d Jen nings 1995]) re ects the decentralized nature of moderndistributed systems [Tennenhouse 2000] and can be considered as the natu-ral extension to the notions of modularity and encapsulation for systems thatare owned by different stakeholders [Parunak 1997]. Second, the exible wayin which agents operate (balancing reactive behavior in response to the en-vironment, with proactive behaviour towards the achievement of their designobjectives [Wooldridge and Jennings 1995]) is suited to the dynamic and unpre-dictable situations in which software is now expected to operate [Zambonelliet a l. 2001a]. Finally, th e high-level and dyna mic natu re of multiagent intera c-tions is appropriate to open systems in which the constituent components andtheir interaction patterns constantly change [Estrin et al. 2002; Ripeani et al.2002; Ricci et al. 2002].

As is the case with any new software engineering paradigm, the successfuland widespread deployment of complex software systems based on MASs re-quires not only new models and technologies, but also the identi cation of anappr opriat e set of softwar e engineering abstractions . These abstractions serveas a reference for system identi cation and analysis, as well as providing thebasis of methodologies that enable developers to engineer such systems in arobust, reliable, and repeatable fashion. In the last few years, there have beenseveral att empts to identify appr opriat e abstr actions for MASs, and to developsuch softwar e engineering meth odologies accordingly. However, most of th is

ACM Trans actions on Softwar e En gineering a nd Methodology, Vol. 12, No. 3, Ju ly 2003.


3/54

Developing Multiagent Systems: The Gaia Methodology 319

work is either tu ned t o speci c systems and agent architectures (e.g., Ferberand Gut knecht [1998]a nd Bussma nn [1998]) th us, it lacks generality or elseit is de ned as a s imple exten sion ofexistin g object-oriented met hodologies (e.g.,Iglesias et al. [1999] and Bauer et al. [2001]) and is thus dependent on ab-stractions and tools that are unsuitable for modeling agent-based systems.

Against this background, a number of proposals have recently attemptedto de ne complete a nd general m ethodologies, built a round agent-speci c ab-stractions and speci cally tailored to the analysis and design of MASs [Woodet al. 2001; Caire et al. 2002; Bresciani et al. 2001; Wooldridge et al. 2000]. Al-th ough th ese meth odologies adopt different t erm inologies and pr ovide differentabstr actions, t hey a ll recognize th at the process of building MASs is ra dicallydifferent from the process of building more traditional software systems. Inparticular, they all recognize (to varying extents) the idea that a MAS can beconceived in terms of an organized society of individuals in which each agentplays speci c roles and interacts with other agents according to protocols de-

termined by the roles of the involved agents (cf. the more traditional functionalcomposition view of system architectures [Shaw et al. 1995]). However, in thisart icle, we sh ow t ha t an organization is more t ha n simply a collection of roles(as most m ethodologies a ssume), and tha t in order to effectively build a MASin organizationa l terms, furt her organization-oriented a bstra ctions need to bedevised and placed in the context of a methodology.

To this end, this paper advances the state of the art in agent-oriented soft-ware engineering in two important ways:

It articulates the role of agent-based computing as a software engineeringparadigm and identi es the set of organizational abstractions tha t are nec-essary for designing a nd building system s in complex, open environm ents.

It extends the Gaia methodology to exploit these new organizational ab-

str actions. Th ese extensions, while preserving th e simplicity of the originalGaia pr oposal, enable it t o be used in t he a na lysis and design of open MASs(whereas previously it could only be used for closed communities of cooper-ating agents).

The r ema inder of this ar ticle is orga nized as follows: Section 2 deta ils the keyconcepts of agent-based comput ing as th ey perta in t o agent-oriented softwar eengineering. It also outlines the similarities and differences with object- andcomponent-based methods. Section 3 focuses on the organizational metaphorand describes and motivates the organizationa l abstractions th at a re necessaryfor agent-oriented software engineering. Section 4 details how these abstrac-tions are exploited in Gaia in order to provide a methodology for the analysisand design of MASs. Section 5 discusses related work. Section 6 concludes andoutlines some open issues.

2. A SOFTWARE ENGINEERING PERSPECTIVEON AGENT-BASED COMPUTING

This section introduces the key concepts of agents and MASs and outline themain differences with work in object/component-based computing and software



4/54


architectures. The aim is to present the arguments as to why agent-orientedsoftwar e engineering is a suitable pa radigm for designing a nd building today scomplex systems.

2.1 Basic Concepts

Th e rst key concept is that ofan agent ;here viewed as a software entity exhibit-ing the following characteristics in pursuit of its design objectives [Wooldridgeand Jennings 1995]:

Autonomy . An agent is not passively subject to a global, external ow of con-trol in its actions. That is, an agent h as its own inter nal t hrea d of execut ion,typically oriented to the achievement of a speci c task, and i t decides foritself what actions it should perform at what time.

Situatedness . Agents perform their actions while si tuated in a particularenvironmen t. The environmen t may be a computa tiona l one (e.g., a Website)or a physical one (e.g., a manufacturing pipeline), and an agent can senseand effect some portions it.

Proactivity . In order to accomplish its design objectives in a dynamic andunpredictable environment th e agent m ay need to act to ensure t hat i ts setgoals are achieved and that new goals are opportunistically pursued when-ever appropriate.

For insta nce, a software componen t in char ge of lterin g emails can be viewedas a (simple) agent [Maes 1994]. I t is autonomous if i t is implemented as athr eaded a pplication logically detached from th e client m ail reader an d if it isassigned th e speci c task of an alyzing a nd modifying th e cont ent of some usermailboxes. It is proactive in th at it can dr aw its u ser s at tent ion t o speci c newmails or to speci c situations occurring in its folders. It is situated in that itlives in a world of mailboxes and it can sense changes in the mailboxes and caneffect their state.

Agents can be useful a s st and-alone entit ies t hat are delegated particulartasks on behalf of a user (as in the above example and in goal-driven robots[Mata ric 1992]). However, in the ma jority ofcases, agent s exist in environmen tsthat conta in o ther agents . In these multiagent systems , the global behaviorderives from th e interaction among th e consti tuent agents. This brings us tothe second key concept of agent-based computing, that of sociality [Wooldridgeand Jennings 1995]:

agents intera ct (cooperat e, coordinate or negotiate) with one an other, eitherto achieve a common objective or becau se th is is necessar y for them to achieve

their own objectives.Broadly speaking, it is possible to distinguish between two main classes of

MASs:

distributed problem solving systems in which the component agents are ex-plicitly designed to cooperat ively achieve a given goal;



5/54


open systems in which agents are not co-designed to share a common goal,and have been possibly developed by different people to achieve differentobjectives. Moreover, the composition of the system can dynamically vary asagents enter and leave the system.

The former class of systems includes applications that are primarily devotedto solving comput at ionally int ensive problems by assigning t he ta sk of explor-ing different portions of the search space to different agents, with the goal of expediting th e sear ch (e.g., Paru na k [1997]). This class a lso includes t hose soft-ware systems that are devoted to controlling an d directing a single physicalprocess (e.g., Bussma nn [1998]). Her e, different agents ar e delegat ed th e ta sk of man ipulating a sub-portion of the physical spa ce in which the process ta kesplace. In both cases, however, th e system is closed; all agents are known a pri-ori, they are supposed to be inately cooperative to each other and, therefore,they can trust one another during interactions. The latter class includes mostdistributed systems in which the agents have to make use of services, knowl-edge, and capabili t ies found in other agents spread throughout the network (e.g., agents for information retrieval [Cabri et al. 2000], for work ow ma n-agement in virtu al ent erprises [Ricci et al. 2002], an d for pervasive compu ting[Estrin et al. 2002]), as well as those systems that involve interactions betweenagents that represent different stakeholders (e.g., e-commerce agents [Estevaet al . 2001] and web service agents [Cabri et al . 2002]). In these cases, onemust take into account the possibility of self-interested (competitive) behaviorin t he course of the interactions (preventing a gents from inherently trustingeach other) and the dynamic arrival of unknown agents.

2.2 Objects, Components, and Agents

The distinction between the contemporary view of objects and agents is be-

coming less sharp with time. However, let us rst consider the tradit ional (historical) object-oriented perspective [Booch 1994]. An object, per se, is notautonomous, in that its internal activity can be solicited only by service re-quests coming from a n externa l th read of cont rol. As a consequence, an objectis not capa ble of proactive beha vior a nd is n ot capable of au tonomously decidingwhat to do in a speci c situ at ion (i.e., an object is n ot capable of action selection).Moreover, in traditional object applications, there is not an explicit conceptionof environment : objects either encapsulate resources in terms of internal at-tributes or perceive the world only in terms of other objects names/references.

On the other hand, objects and components in today s distributed and con-cur rent systems ar e somewhat r emoved from t his canonical de nition and theyare start ing to approach our view of agents, at least in terms of observablebehavior. Objects and components may be a ctive and may integrate internalthreads of execution enabling them to perform speci c computa tional tasks.They may also have to serve requests in a concurrent way and have to pre-serve themselves from unauthorized or unsafe requests for services (in otherwords, they can select not to do an action). Finally, the coexistence in such sys-tem s of both active componen ts/objects a nd pass ive objects, pr ovides for a cleardistinction between an active compu tat iona l part of the system an d a world of



6/54


external resources (i.e., of an environment). The fact that objects and compo-nents have to access such external r esources and often have to deal with un-expected situ at ions in so doing (exception and event h an dling) may requ ire anexplicit modeling of situatedness (such as the explicit identi cation of cont ext-dependencies in component-based systems). Similar considerations can alsoapply to modern pervasive compu ter-based systems. When such ent ities enterinto a complex interactive scenario (e.g., a wireless-enabled building for a PDA[Mamei et al . 2003], a wireless network of distributed sensors [Estrin et al .2002] or a network of controllers in an automobile [Leer and Hefferman 2002])their observable behavior, from the viewpoint of the system designer, is that of an autonomous a gent.

In addition to the fact that modern object and component systems exhibitchara cterist ics t hat make them assimilable to a gents, agents themselves ar eoften implem ent ed in ter ms of active objects an d component s (e.g., J ava th rea dswith synchronizat ion, exception ha ndling, and event-handling capabilities).

However, we emphasize the above mean neither that agents add nothing tomodern objects or that the real a dvantages of agent-based computing can beappr eciated only in t he p resence of AI t echn iques. Rather, the fact th at objectsand agents are converging from a technological viewpoint is evidence of thefact t hat , from a softwar e engineering viewpoint, a gent-based a bstra ctions suitthe development of complex software systems. This appears even clearer whenshifting the attention from single object/components to complex systems.

2.3 Software Architectures and Multiagent Systems

Traditional object-based computing promotes a perspective of software compo-nents as functional or service-oriented entities that directly in uences t heway th at softwar e systems are architected. Usually, th e global design relies ona r ath er sta tic architectur e tha t derives from the decomposition (and m odular-isation) of the functionalit ies a nd data required by t he system to achieve i tsglobal goals and on the de nition of their interdependen cies [Bass et al. 2003;Shaw and Garlan 1996; Shaw et al. 1995]. In particular:

objects ar e usua lly considered as service providers, r esponsible for speci cportions of data and in charge of providing services to other objects (thecontractual model of software development explicitly promotes this view);

inter actions between objects ar e usu ally an expres sion of int er-dependen cies;two objects interact to access services and data that are not available locally;

everything in a system tends to be modeled in terms of objects, and anydistinction between active actors and passive resources is typically neglected[Schwabe et al. 2002].

In other words, object-oriented development, while promoting encapsula-tion of data and functionality and a functional-oriented concept of interactions,tends to neglect modeling and encapsulation of execution control. Some sortof global cont rol over the activity of the system is usually assumed (e.g., thepresence of a single execution ow or of a limited set of controllable and glob-ally synchronised execution ows). However, assuming and/or enforcing such



7/54


control may be not feasible in complex systems. Thu s, rath er th an being at r isk of losing control, a better solution would be to explicitly delegate cont rol overthe execution to the system components [Zambonelli and Parunak 2003] asin MASs. In fact:

Delegating cont rol to aut onomous components can be considered a s a n addi-tional dimension of modular ity and encapsulation. When ent ities can encap-sulate contr ol in addition to data and algorithms [Parun ak 1997], they canbett er ha ndle th e dynam ics of a complex environmen t (local contingen cies canbe handled locally by components) and can reduce their interdependencies(limiting the explicit transfer of execution activities). This leads to a sharpersepara tion between the component-level (i.e., int ra -agent) a nd system-level(i.e., inter-agent) design dimensions, in that also the control component is nolonger global.

The dyna mics a nd openn ess of application scenarios can mak e it impossible

to know a priori all potential interdependencies between components (e.g.,what services are needed at a given point of the execution and with whatother components to interact), as a functional-oriented perspective typicallyrequires. Autonomous components delegated of their own control can be en-riched with sophisticated social abilities, tha t is, the capability to mak e de-cisions about the scope an d n atur e of their interactions at run-time and of initiating intera ctions in a exible manner (e.g., by looking for and negotiat-ing for service and data provision).

For complex systems, a clear distinction between the active actors of thesystems (autonomous and in charge of their own control) and the passiveresources (passive objects without aut onomous control) may provide a sim-pl i ed modeling of the problem. In fact, the software components of an ap-plication often have a real-world counterpart that can be either active orpassive and tha t, consequent ly, is better suited t o being m odeled in term s of both active ent ities (agents) a nd passive ones (environment al r esour ces).

Again , we have to emphasize that modern approaches are beginning t orecognize the above l imitations. As outlined in Section 2.2, tradit ional object abstr actions have been enriched by incorporating novel featur es such asintern al t hrea ds of execution, event-handling, exception ha ndling, and context-dependencies and are being substitu ted, in architectura l styles, by the higher-level abstr action of self-conta ined (possibly active) coarse-gra ined ent ities (i.e.,components). These changes fundamentally alter the way software architec-tur es ar e built, in t hat active self-contained components intrinsically intr oducemultiple loci of control ar e m ore nat ura lly considered as repositories of tasks,rather than simply of services. Also, the need to cope with openness and dy-nam ics requ ires application components to intera ct in more exible ways (e.g.,by making use of external directory, lookup, and security services).

However, attempting to enrich more conventional approaches with novel fea-tures and characterist ics to meet the novel needs, in addition to increasingthe complexity of the modeling, is also likely to introduce a dangerous mis-mat ch between th e abstr action level adopted a nd t he conceptual level at which



8/54


application problems have to be solved. Put simply, objects and components aretoo low a level of abst ra ction for dealing wit h th e complexity of today s softwaresystems, and miss importan t concepts such as au tonomy, task -orienta tion, sit-uatedness and exible interactions. For instance, object- and component-basedapproaches have nothing to say on the subject of designing negotiation algo-rithm s to govern int eractions, an d do not offer insights into how to mainta in abala nce between rea ctive an d proactive beha viour in a complex an d dynam ic sit-uations. This forces applications to be built by adopting a functionally orientedperspective and, in turn, this leads to either rather static software architec-tures or to the need for complex middleware support to handle the dynamicsand exible r econ gura tion a nd t o support n egotiation for resources and t asks.Neither of these are particularly desirable.

In summary, we believe agent-based computing promotes an abstractionlevel that is suitable for modern scenarios and that is appropriate for buildingexible, highly modular, and robust systems, what ever the technology adopted

to actually build the agents.

3. THE ORGANIZATIONAL METAPHOR

Given the suitability of a modeling approach based on autonomous, situatedagents that interact in exible ways, th ere is a need to un dersta nd which furt herabstr actions inspired by which meta phor complete th e agent-oriented m indset.

3.1 Motivations

In recent years, researchers in the area of MASs h ave proposed a number of different approaches for modeling systems based on different metaphors, noneof which can reasonably claim to be general purpose. For instance: the ant al-gorithms metaphor [Bonabeau et al . 1999; Babaoglu et al . 2002] has shownto be useful in ef ciently solving complex distributed problems such as rout-ing and distributed sorting; physical metaphors [Abelson et al. 2000; Mameiet al. 2003], focusing on the spont an eous resh apin g of a syst em s structure, mayhave useful applications in pervasive and mobile computing;societal metaphorshave been effectively applied in robotics applications [Moses and Tennenholtz1995; Collinot et al . 1996] and in the understanding and control of highly-decentr alized systems [Hatt ori et al. 1999; Ripeani et al. 2002].

Our appr oach focuses on th e development of medium t o large size systems,possibly dived in open and dynamic environments, and that have to guar-antee predictable and reliable behaviors. For these kinds of systems, we be-lieve th e most a ppropriate metaph or is tha t of a human organization [Handy1976; Fox 1981; Demazeau and Rocha Costa 1996; Zambonelli et al. 2001a], inwhich:

A software system is conceived as the computa tiona l insta nt iation of a (pos-sibly open) group of inter acting a nd au tonomous individua ls (agents).

Each agent can be seen as playing one or more speci c roles: it has a well-de ned set of responsibilities or subgoals in the context of the overall systemand is responsible for pursuing these autonomously. Such subgoals may be



9/54


Environment

Agent Agent

AgentAgent

Agent

Agent

Organization

Inter-agentInteractions

Access to theEnvironment

Fig. 1. Multiagent systems as computational organizations [Jennings 2001].

both a ltru istic (to cont ribut e to a global application goal) or opport un istic (foran agent to pursue i ts own interests).

Interactions are no longer merely an expression of interdependencies, andare rather seen as a means for an agent to accomplish its role in the system.Therefore, interactions are clearly identi ed and localized in the de nitionof the role itself, and they help characterize the overall structure of the or-ganization and the position of the agent in it.

The evolution of the activit ies in the organization, deriving from the au-tonomous execution of agents and from their interactions, determines theachievement of the application goal, whether an a priori identi ed globalgoal (as, e.g., in a work ow mana gement systems where altru istic agents con-tr ibute to th e achievement of a speci c coopera tive pr oject), or a goal relat edto the satisfaction of individual goals (as, for example, in agent-mediatedauctions, whose purpose is to satisfy the needs of buyer and seller agents), orboth (as, for example, in n etwork ent erprises exploiting mar ket mechanismsto improve ef ciency).

The organizational perspective leads to a general architectural characteri-zation of a MAS as depicted in Figure 1. Although some simpler systems can beviewed as a single orga nizat ion, as soon as th e complexity increas es, modula rityand encapsulation pr inciples suggest dividing th e system into different subor-ganizations (the da shed ellipses in Figure 1), with a su bset of the a gents beingpossibly involved in multiple organizations. In each organization, an agent canplay one or more roles, to accomplish which agents typically need to interact with each other to exchange knowledge and coordinate their activities. Theseinteractions occur according to patterns and protocols dictated by the natureof the role itself (i.e., they a re institut iona lized by th e de nition of th e r ole). Inaddition, the MAS is typically immersed in an environment (i.e., an ensembleof resources, represented by the gray ellipse in Figure 1) that the agents mayneed to interact with to accomplish their role. Interactions with the environ-ment occur via some sorts of sensors and effectors (i.e., m echa nisms enabling



10/54


agents to perceive and act upon some par t of the environmen t). That portion of the environment tha t agent s can sen se and effect (represented by the dar ker el-lipses inside the environment in F igure 1) is determined by the a gent s speci crole, as well as by its current status.

The organizational m etaph or oth er tha n being a na tu ral one for hu man de-velopers who are cont inuously immersed in a variety of organ izat ional settingsand opening up the possibility of reusing a variety of studies and experiencesrelated to real-world organizations [Handy 1976; Mintzberg 1979] appears tobe appropriate for a wide ra nge of software systems. On the one hand, somesystems are concerned with controlling and supporting the activities of some(possibly open) real-world organ izat ion (e.g., m an ufacturing control system s,work ow man agement a nd enter prise informa tion systems, and electronic ma r-ketplaces). Therefore, an organization-based design may reduce the conceptualdistance between the software system and the real-world system it has to sup-port. On th e other h and, other softwar e systems, even if they are n ot a ssociated

with a ny pr e-existing rea l-world organization, may h ave to deal with problemsfor which hu ma n orga nizat ions could act as fru itful source ofin spira tion, ha vingalrea dy shown to produ ce effective solutions (e.g., resour ce sha rin g, ta sk as sign-ment, and service negotiation). More generally, whenever a software system iscomplex enough t o war ran t a n a gent-based approach and st ill requires a signif-icant degree of predicta bility and reliability in all its par ts, th e organizationa lmetaphor may be the most appropriate one. In fact, by relying on agents playingwell-de ned roles and interacting according to institutionalized patterns, theorganizational metaphor promotes both micro-level (at the agents level) an dmacro-level (at the system level) cont rol over th e design a nd un dersta nding of the overall system behavior. Other metaphors (e.g., ant colonies and arti cialsocieties) by focusin g on th e achievemen t of an avera ge ma cro-level behavior of the system, often sacri ce th e micro-level asp ects (i.e., individual agen ts m at ter

little or not at all). While this may be acceptable in, say, wide-area le sharingapplications and heuristic allocation systems, it is de nitely not in ma nufactur-ing contr ol systems, enter prise informa tion systems, electronics ma rketplaces,where each agent is important in its own right.

3.2 Example Applications

To illustra te our a rgumen ts, an d to show how they ma p into real-world applica-tions, we will consider t wo sample problems t ha t will act as ru nning examplesthroughout this article.

Manufacturing Pipeline . As an example of th e class of distributed problemsolving (closed) MASs, we consider a system for contr olling a man ufacturingprocess. Speci cally, let us consider a m an ufactu ring pipeline in which items a retransformed or augmented (e.g., a pipeline in which metal items are painted).

Here, different agents may be devoted to the control of different stages of thepipeline (e.g., one agent is devoted to controlling the paint spraying, another tocontrolling the heat treatment of the paint, and yet another to controlling thecooling process). In such an organization, the role of each agent is that of stagecontroller, in charge of ensuring that a speci c portion of the pipeline works



11/54


properly (e.g. , that the oven maintains a constant temperature and that thecooling system does n ot cool items too fast ). To this en d, a gents need to senseand effect that portion of the environment which represents the stage of thepipeline of which they are in charge. Since portions of what an agent senses andeffects may be sensed and effected by neighboring agents in the pipeline, somesort of indirect interaction, mediated via the environment, is likely to occurbetween agents. In a ddition, th e agents m ay need to intera ct directly with eachother to achieve a proper global functioning of the pipeline (for instance, byguaranteeing a uniform ux of items or by guaranteeing that the global ux of items does not exceed the processing capabilities of each of the stages).

Conference Managem ent . As an example of a system raising issues typicalof open systems tha t is, agents exhibiting self-interested behavior, not all of whom may be known at deployment time we consider a n agent-based systemfor supporting the management of an international conference.

Setting u p an d ru nning a conference is a mu ltiphase pr ocess, involving sev-eral individua ls and groups. During th e submission pha se, au th ors send pa pers,and are informed that their papers have been received and have been assigneda su bmission n umber. In the r eview phase, th e progra m committ ee (PC) has t ohan dle the review of the papers: conta cting potential referees and a sking th emto review a n um ber of the pa pers (possibly by bidding on pap ers). Eventua lly,reviews come in and are used to decide about the acceptance or rejection of the submissions. In the nal phase, authors need to be noti ed of th ese deci-sions and, in case of acceptance, must be asked to produce a revised versionof their papers. The publisher has to collect these nal versions and print theproceedings.

The conference mana gement p roblem n atu ra lly leads to a conception of th ewhole system as a num ber of different MAS organizations, one for each pha seof the process. In each organization, the corresponding MAS can be viewedas being made up of agents being associated to the persons involved in theprocess (auth ors, PC chair, PC m embers, reviewers) to support t heir work, an drepresent ing the active part of th e system. The roles played by each a gent re ectthe ones played by the associated person in the conference organization. Thismay require agents to interact both directly with each other and indirectly viaan environmen t composed of (passive) papers an d review forms. 1

The openness of th e conference mana gement system is evidenced in a n um-ber of ways. Clearly, authors submitting a paper are unknown at deploymenttime, and so ar e th e total nu mber of author a gents being involved in the pro-cess. However, this appears as a not very problematic issue, in that authoragents (generally) have simply to send a p aper to the P C chair, and do not n eedto strongly interact with other agents in the system. More problematic is th e

fact th at, since agents are associated t o different sta keholders with competing

1 Such modeling differs considerably from traditional, object-based modeling of the same prob-lem (see, e.g., Schwabe et al. [2002]), where the same application problem is typically modeledwithout mak ing any distinction between t he a ctive entities a nd environmenta l resources (despitetheir being very different in nature) and where interactions are used to express functional inter-dependencies rather than the organizational relationships that actually cause them.



12/54


interests, unpredictable strategic and opportunistic behaviors can emerge inthe application. The tr ivial case being tha t of a reviewer a gent a cting on beh alf of a person which is also an author, and trying (e.g., by bidding for papers) toreview its own paper or possibly competing papers. In addition, we also empha-size that a reviewer (or a PC member) may decide to exploit its own personalagent rath er th an the a gents made a vailable by the conference ma nagementsystem to enter th e organization and interact with the other a gents in i t . Inthis case, even if all the reviewers are known in advance (and we know this isnot th e case in large conferences) the a gents th at will interact in th e systemmay not be.

3.3 Organizational Abstractions

The cha racterization of a MAS of Figure 1 highlights th e most basica bstra ctionsthat characterize a computational organization and that can be appropriately

exploited in t he a na lysis and design ph ases: the environment in which the MASis immersed; the roles to be played by the different agents in th e organization;and the interactions between these roles. In addition, we have identi ed twofur ther abstr actions t ha t a re often implicitly int egrated int o the above ones an dtha t, we believe, need to be considered in their own right: organizational rulesand organizational structures .

3.3.1 The Environm ent. A MAS is always situated in some environmentand we believe this should be considered as a primary abstraction during theanalysis and design phases. Generally speaking, identifying and modeling theenvironment involves determining all the entities and resources that the MAScan exploit, control or consume when it is working towards the achievement of the organizationa l goal. In some cases, th e environment will be a physical one,

including such things as the temperature in a room, the status of a washingmachine or the average speed of cars on a motorway. This is the case in themanu facturing pipeline, where t he agents are intended to control th e correctprocessing and the global ux of th e items in th e pipeline. In other cases, th e en-vironment will be a virtual one, including such things as enterprise informationsystems, web services, and database management systems. This is the case of the conference management system, where agents execute in an environmentpopulated by papers, r eview forms an d digita l librar ies. What ever the case, anexplicit modeling of the environment is very important: not taking it into ac-count (as, e.g., in the previous version of Gaia methodology [Wooldridge et al.2000]) may complicate the overall design and may introduce mismatches be-tween t he MAS design a nd its actua l operat ion. For insta nce, in t he conferencemanagement example, the lack of environmental modeling would imply con-sidering speci c application a gents as repositories of papers an d r eview formsand as being in charge of explicit ly transferring them to other agents. Thisis a more complex solution than that of explicitly modeling an environmentaldata repository, and conceptually farther from the likely operating environ-ment (a world of Websites from which agents can access papers and reviewforms).



13/54


For both ph ysical an d comput at iona l environm ent s, th e following issu es cometo th e fore wh en considering an explicit environment al m odeling ph ase:

What are the environm ental resources that agents can effectively sense and effect? Const raint s ma y exist with r espect to th e possibility of accessing andmanipulating r esources, an d the environment model should th erefore dis-t inguish between the existence and the accessibil i ty of a resource. In themanufacturing pipeline, i t may be the case that no sensors exist to effec-tively evaluate t he quality pa rameters. In conference mana gement, i t maybe the case that a reviewer agent cannot pay to access a particular digitall ibrary (as needed to compare a submitted paper to an already publishedone). Also, since the environmen t may be chara cterised by its own dyn amic,it may be the case tha t some of the r esources are ephemer al in nat ur e or th atar e only intermitt ently available. These dynamics may need to be identi ed ,modeled, and evaluated against technological capabilities to cope with them.

How should the agent perceive the environment? In other words, what rep-resentation of the environment is appropriate in a given situation? Such achoice is naturally dependent on the available technologies and on the pre-existing scenarios. In th e ma nu factur ing pipeline, the choice ma y depend onwhether sensors are passive or active, leading to a char acterization of theenvironment in terms of either a data world or a service world. In confer-ence ma nagement, such a choice m ay depend on the chara cterist ics of theavailable services providing access to papers and review forms.

What in the existing scenario should be characterized as part of the environ-ment? The existence of active entities with which the agents in the MAS willhave to interact (e.g., computerbased sensors in the manufacturing pipelineor active dat aba ses in a Web scena rio), mean s a decision ha s to be tak en aboutwhat should be viewed as a n a gent an d what should be viewed in term s of dy-

na mic environment al resources. In other words, th e distinction between th eagent and the environment is not always clear cut. It is something that mayrequire an accurate analysis and may ult imately depend on the problem scharacteristics.

Summ ar izing, the environment of a MAS should not be implicitly assumed:its characterist ics must be identi ed, modeled, an d possibly shaped to m eetapplication-speci c pur poses.

3.3.2 Roles and Interactions. The role of an agent de nes what i t is ex-pected to do in the organization, both in concert with other agents and in re-spect of the organization itself. Often, an agent s r ole is simply de ned in termsof the speci c task th at it ha s to accomplish in th e cont ext of th e overall orga-nization. However, our notion of a role is much more precise; it gives an agenta well-de ned position in t he organization, with an associated set of expectedbehaviors [Wooldridge et al. 2000; Ferber an d Gu tkn echt 1998; Demazeau andRocha Costa 1996]. Organizational role models precisely describe all the rolesthat constitute the computational organization. They do this in terms of theirfunctionalities, activities, and responsibilities, as well as in terms of their inter-action protocols and patterns. Organizational interaction models describe the



14/54


protocols that govern the interactions between the roles. Moreover, the inter-action model describes the characteristics and dynamics of each protocol (e.g.,when, how, and by whom a protocol has to be executed).

Most a ppr oaches t o MAS m odeling [Lind 2001; Wood et al. 2001], (includingthe rst version of Gaia [Wooldridge et al. 2000]), consider role and interac-tion m odels as t he sole organ izational abst ra ctions upon which to base t he en-tire development process. Consequent ly, th e an alysis and design process sta rtsdirectly with the identi cation and de nition of role and interaction models.However, alth ough role and intera ction models can be useful t o fully describean existing organization, they are of l imited value in building an organiza-tion. In fact, before the design process can de ne an actual organization (to bepossibly described in terms of role and interaction models), there is a need toidentify how th e organization is expected t o work an d which kind of organiza-tion (among several possible ones) best ts the requirements identi ed in theanalysis phase. This observation elaborated below motivates our introduc-

tion of the n otions of organizational r ules an d organizational stru ctures.

3.3.3 Organizational Rules. In the requirements capture phase of MASdevelopment, it is certainly possible to identify the basic skills (functionalitiesan d competences) required by the organization, as well as th e basic intera ctionsthat are required for the exploitation of these skills. In the case of the manu-facturing pipeline, i t is easy to identify the need for agents to act as stagecontrollers ; in the conference management case study, it is easy to recognizethe need for agents to act as authors, reviewers, PC Chair, and so on.

Alth ough su ch a n a na lysis can lead to the identi cat ion of a preliminary ver-sion of the role and interaction models, this identi cation cannot and should not be us ed t o produce complet e models. In fact, before bein g able t o fully char-acterize the organization, the a na lysis of a MAS should ident ify the constr aints

that the actual organization, once de ned, will have t o respect. Typically, su chconstraints: (i) spread horizontally over all the roles and protocols (or, which isthe same in this context, over the identi ed preliminary roles and protocols),or (ii) express relations and constraints between roles, protocols, or betweenroles and protocols [Esteva et al. 2001]. Although, in an actual organization,such constraints are likely to be somehow enacted by some agents playing someroles an d int eracting somehow, th ey can ha rdly be expressed in t erms of indi-vidual roles or individual interaction protocols (in the same way, that socialconventions an d compa ny directives h orizonta lly in uence our social life a ndour work, but cannot be associated with any speci c actor). Thus, the explicitidenti cation of such constraints captured in our concept of organizationalrules is very importan t for the correct u nderstanding of the chara cterist icsthat the organization-to-be must express and for the subsequent de nition of the system structure by the designer.

The explicit identi cation of organizational rules is also important in thecontext of open systems. With the arrival of new, previously unknown, and pos-sibly self-interested agents, the overall organization must be able to enforceits internal coherency despite the dynamic and untrustworthy environment.The identi cat ion of global organizational r ules a llows t he system d esigner to



15/54


explicitly de ne: (i) whether and when to allow new agents to enter the or-ganization, and, once accepted, what their position should be; and (ii) whichbehaviours should be considered as a legitimate expression of self-interest, andwhich among them must be prevented by the organization. In this context, or-ganizational rules may also drive the designer towards the de nition of thespeci c organization structure that most eases the enforcement of the orga-nizational rules and, for instance, can facilitate the prevention of undesirablebehavior on the part of the unknown agents.

In the manufacturing pipeline example, all the different stages must main-tain t he same speed of ow of items in t he pipeline. This requirement is mostsimply expressed in t erms of a global organizational rule, rat her than repli-cat ing it as a r equirement for each an d every role in t he organization (as, e.g.,the previous version of Gaia and any methodology not making explicit use of organ izat ional r ules would have required). In th e conference mana gement sys-tem, there are a number of rules that drive th e proper implementation of the

organ izat ion. As notable examples: an a gent sh ould be prevented from p layingboth the role of author and reviewer of the same paper; PC m embers shouldnot be in charge of collecting the reviews for their own papers. Neither of theseconstraints can easily be expressed in terms of properties or responsibilitiesassociated to single roles or protocols and, if so, they would notably increasethe complexity of roles and protocol description. Instead, they represent globalorgan izat ional rules.

3.3.4 Organizational S tructures. A role model describes a ll the roles of anorganization and their positions in that organization. Therefore, a role modelalso implicitly de nes the topology of the interaction pa tterns and the controlregime of the organization s activities. That is, it implicitly de nes the overallarchitecture of the MAS organization (i.e., its organizational structure ). Forexamp le, a role model describing an orga nizat ion in ter ms of a mast er role andslave r oles where th e former is in cha rge of assigning work to the latt er an dofload balan cing their activities implicitly de nes an organ izat iona l stru cturebased on a hiera rchical topology an d on a load pa rt itioning contr ol regime. Oth erexemplar organizational structures include collectives of peers, multilevel andmultidivisional hierarchies [Fox 1981], as well as more dynamic stru cturesderiving from ma rk et-orien ted m odels [Kolp et al. 2002]. All these organ izationscan be modeled in terms of a role model.

However, while th e role model may de ne the organizational structure in animplicit way, the structure of a MAS is more appropriately derived from theexplicit choice of an appropriate organizational structure, and organizationalstructures should be viewed as rst-class abstractions in their own right. Thisargument (which is conventional in architecture-centered software design [Bass

et a l. 2003, Shaw an d Gar lan 1996]) calls for a speci c design choice not to be(generally) anticipated to the analysis phase, but rather should exploit infor-mat ion collected du ring a na lysis. In t he speci c context of MAS development,the argument is motivated by several considerations:

Although the organizational structure of a MAS may be directly inspiredby the s t ructure of the rea l-world sys tem that the MAS must suppor t ,



16/54


AgentStage 1

AgentStage 2

AgentStage 3

Fig. 2. Manufacturing pipeline: Collective of peers organization.

automate, or monitor (consider, for example, enterprise information systemsand work ow mana gement systems), t his should not automatically implythat the organization of the software system should always mimic that of the real world system. This is so for several r easons. First , the real worldorganization may not be necessarily so well-structured. Second, the issuesthat may have driven a h uman organization towards t he adoption of a par-

ticular stru cture ma y not necessarily apply to th e agent organization. Third,the mere pr esence of software ma y introduce cha nges in t he r ealworld orga-nization. Of course, it may be the case that some speci c sub-structures ina real-world organization are to be necessarily preserved at the MAS leveland, thus, come prede ned from the analysis phase. However, this shouldnot be considered the general case and should not prevent developers fromexplicitly addressing th e organizationa l str ucture issue.

Star ting from t he organizational st ructur e may prevent optimizing th e over-all ef ciency of th e organization and may prevent subsequent optimiza-tions and chan ges. This consideration assum es a particular emphasis indynamic applications scenarios (e.g., virtual enterprises [Ricci et al. 2002]global [Babaoglu et al. 2002] and pervasive computing [Estrin et al. 2002;Tennenhouse 2000]) where a system may need to frequently adapt its orga-nizational structure to the prevailing situation, possibly at run-time and inan unsupervised way [Kephart and Chess 2003]. Although this paper does notexplicitly deal with dynam ic an d un supervised reorganizations, th e meth od-ological approach we propose (by making the de nition of the organizationalstructure an explicit design decision) facilitates off-line reorganization andpaves th e way for supporting dyna mic on-line r eorganization.

The organization, once de ned, has t o respect its organizationa l rules. Star t-ing from a prede ned organizational structure by assuming t o know in ad-vance what it should be or by committing a priori to a given organizationalstructure can make it dif cult to have the organizational rules respectedand enforced. It is more na tu ral for t he choice of the organizational str uctureto follow from the identi cation of the organ izat ional rules.

In the manu facturing pipeline, perha ps th e most n atur al choice is to h avean organizational structure in which all of the stages in the pipeline form acollective of peers. For inst an ce, with reference to F igur e 2, t he various sta gesof the pipeline are controlled by agents speci cally devoted to controlling onestage, and each of these agents may directly interact with all the other stagesto agree on issues requiring global coordination (e.g., regulating the ux of



17/54


AgentStage 1

AgentStage 2

AgentStage 3

CoordinatorAgent

Fig. 3. Manufacturing pipeline: Hierar chical organization.

PC MemberAgent

(reviewer)

PC Chair Agent(assign reviews to

PC Members)

Data Repository (e.g., Web sites)With Papers and Review Forms

Paper XReview

Paper ZReview

Paper YReview Paper ZPaper YPaper X

PC MemberAgent

(reviewer)

PC MemberAgent

(reviewer)

Paper Assignments

Fig. 4. Conference managemen t: Single level hierar chy.

items in the pipeline). In other words, the topology of the interactions is a fullyconnected one an d is su bject to a fully distributed cooperat ive control regime.However, this is neither the only possible choice, nor necessarily the best one.For instance, because of the real-time nature of the pipeline control problem,it may be the case that some problem requiring complex global coordinationbetween all the agents cannot be solved in time because of the high coordina-tion costs associated with peer-to-peer interactions. In such cases, the designercan adopt a different organizational structure. For example, as sketched inFigure 3, a global coordinator agent can be introduced to control and mediatethe interactions for all the other agents. This, in tur n, leads to a hierarchicalorganization.

In t he conference mana gement, th e overall str ucture of the MAS can gener-ally be derived directly from t he st ru ctur e th e conference of cials have explicitlydecided to adopt. A sma ll conferen ce usu ally relies solely on the PC m ember s forthe review process, with the PC chair acting as a global coordinator in a single-level hierarchy to control the reviewing work of the PC members (see Figure 4).The higher workload in a large conference usually requires a different approach(see Figure 5). For instance, the PC chair may partition the papers among thePC members, and the PC members may be in charge of nding reviewers for



18/54


PC Chair Agent(partition papers

among PC Members)

Data Repository (e.g., Web sites)With Papers and Review Forms

Paper XReview

Paper ZReview

Paper YReview Paper Z

Paper YPaper X

PC Member Agent(assign reviews and negotiate

assigned paper with PCmembers)

ReviewerAgent





ReviewerAgent

ReviewerAgent

ReviewerAgent

Bidding forReviews

Paper

Assignment

Fig. 5. Conference management : Multilevel hierar chy.

the papers in their partitions (either by asking a reviewer to review a speci cpaper or, alternatively, by calling for bids on papers in a sort of contract-netprotocol [Smith 1980]). Also, PC members may negotiate with one another forre-allocating papers to different part itions. In other words, the organizationa lstr uctu re can be composed by a hierar chy at t he higher level (ruling inter actionsbetween th e PC Chair a nd t he PC Members), and by a market organizationat th e lower level (to ensur e a pr oper a ssignment of papers to reviewers an d to

enable direct n egotiations between the collective of PC m ember agents). How-ever, the development of a MAS for a conferen ce mu st t ak e into account th e factthat the conference may chan ge i ts dimensions (and its str ucture) from yearto year and that the support of an agent-based system (reducing the work of th e conferen ce of cials) may suggest a different organizational choice than thatoriginally planned. Thus, if the analysis describes the system s requirementswithout committing to a speci c organizational structure (as we suggest), thedesigner can reu se th e an alysis work to produce a new design according to theconference s new needs.

As an additional note related to organizational structures, we believe thatdespite th e hu ge num ber of structur es th at can possibly be conceived, a (com-parat ively) small subset of these structures are l ikely to be used most of thetime. This opens up signi cant opportunities both for re-use and for the ex-ploitation of cata logues of agent-oriented organizational patterns includinguse-cases reporting on ef ciency, r obustn ess, degree of openness, an d ease of enactment of organizational structures to support designers in choosing themost appropriate organizational structure for their problem. For instance, inthe manu facturing example, the collective organization expresses a patternthat is l ikely to reappear in many applications. The same can also be said



19/54


of the hierarchical st ructure. In the conference mana gement example, t hevarious organizational structures that conferences of different sizes tend toadopt are also all fairly typical: single hierarchies, composite ones, contractnets, etc. Currently, in the area of agent-oriented software engineering, mostpattern-related work focuses on detailed design patterns [Tahara et al. 1999;Kendall 2001]. In the near futur e, we expect more research and studies to becarried on in the area of architectural, organization-oriented patterns, to ex-tend the speci c studies a lready performed in t his a rea regard [Fox 1981; Kolpet a l . 2002] and t o adapt those studies performed in th e a rea of organizationman agement [Mintzberg 1979; Han dy 1976] for exploitation in agent-orientedmethodologies.

4. THE GAIA METHODOLOGY

Having introduced and de ned th e var ious organizationa l abstractions th at webelieve ar e necessary for analyzing an d designing MASs, the next st ep is tofashion them into a design process . That is, to produce an ordered sequence of steps, an identi able set of models, and an indication of the int errelationshipsbetween the models, showing how and when to exploit which models and ab-stractions in the development of a MAS. The design process that we proposeuses our previous work on the Gaia methodology [Wooldridge et al. 2000] as apoint of departure. The new, extended version of Gaia (simply called Gaia here-after) exploits the new organizational abstractions we identi ed in Section 3and s igni cant ly extends the range of appl ica t ions to which Gaia can beapplied.

Before going into the details of Gaia, we rst provide an overview of its keystages and models (see Figure 6). The Gaia process starts with the analysisphase, whose aim is to collect and organize the speci cation wh ich is t he ba sis

for the design of the computational organization. This includes the identi ca-tion of:

Th e goals of the organizations th at constitu te the overall system and their expected global behavior . This involves ident ifying h ow to fruitfully decomposethe global organization into loosely coupled suborganizations.

Th e environmental m odel . Intended as an abstract, computational represen-tation of the environment in which the MAS will be situated.

Th e prelim inary roles m odel . Ident ifying the basic skills required by th e or-ganization. This preliminary model contains only those roles, possibly notcompletely de ned, that can be identi ed without committing to the impo-sition of a speci c organizational st ructur e. Also, th e n otion of roles, at thisstage, is abstract from any mapping into agents.

Th e prelimin ary interaction m odel . Identifying the basic interactions re-quired t o accomplish th e preliminary r oles. Again, t his model must abstr actaway from t he organizational str ucture an d can be left incomplete.

The rules that the organization should respect and enforce in its global be-havior . Such rules express constraints on the execution activities of rolesand protocols a nd are of primary importan ce in promoting ef ciency in



20/54


PreliminaryRole Model

PreliminaryInteraction Model

EnvironmentalModel

Requirements

OrganizationalRules

OrganizationalPatterns

Organizational Structure

Interaction ModelRole Model

Services ModelAgent Model

IMPLEMENTATION

ARCHITECTURALDESIGN

ANALYSIS

COLLECTION OFREQUIREMENTS

GAIASCOPE

Subdivide System intoSub-organizations

DETAILEDDESIGN

Fig. 6. Models of the Gaia meth odology and their relat ions in the Ga ia process.

design and in identifying how the developing MAS can support opennessand self-interested behavior.

The output of the analysis phase consisting of an environmental model,a preliminary roles model, a preliminary interactions model, and a set of or-ganizational rules is exploited by the design phase, which can be logicallydecomposed into an architectural design phase and a detailed design phase.The architectural design phase includes:

Th e denition of the system s organizational stru cture in term s of its topologyand control regime . This activity, which could also exploit of catalogues or-ganizationa l pa tter ns, involves considering: (i) th e organ izat ional ef ciency,(ii) the real-world organization (if any) in which the MAS is situated, and

(iii) the need to enforce th e organizational r ules. The com pletion of the prelim inary role an d interaction m odels . Th is is

based upon the adopted organizational structure and involves separating whenever possible the organ izational-independent aspects (detected fromthe ana lysis pha se) and t he organizational-dependent ones (derived from th eadoption of a speci c organizational st ructur e). This dema rcation promotes



21/54


a design-for-change perspective by separating the structure of the system(derived from a contingent choice) from its goals (derived from a generalcharacterization).

Once the overall architecture of the system is identi ed together with i tscompleted roles and interactions model, the detailed design phase can begin.This covers:

The de nition of the agent model . This identi es the agent classes that willmake up the sys tem and the agent instances that will be instantiated fromth ese classes. Ther e m ay be a one-to-one correspondence between roles a ndagent types, although a number of closely related roles can be mapped intoin t he sa me a gent class for the pur poses of convenience or ef ciency.

T h e d e nit ion of the services m odel . This ident i es the main services intended as coherent blocks of activity in which agents will engage t ha tare required to realize the agent s roles, and their properties.

Before detailing the analysis (Section 4.1), the architectural design phase(Section 4.2) and the detailed design phase (Section 4.3), i t is important toexplicitly state the scope and limitations of our methodology:

Gaia does not directly deal with particular modeling techniques . It proposes,but does not commit to, speci c techniques for modeling (e.g., roles, envi-ronment, interactions). At this time, and given the large amount of ongoingresear ch work devoted t o de ning su itable (an d possibly standa rdized) nota-tion techniques for agent systems (as detailed in Section 5), we believe sucha commitment would be premature.

Gaia does not directly deal with implementation issues . The outcome of theGaia process is a detailed but technology-neutral speci cation that shouldbe easily implemented u sing an a ppropriate agent -programm ing fra mework (e.g., a FIPA-compliant agen t syst em) or by using a modern object/component -based framework (i.e., one supporting distributed and concurrent objects). Of course, we are aware t hat speci c technology platforms may introduce con-straints over design decisions (a typical example relates to environmentalmodeling: if the en vironmen tal r esour ces ar e of a passive nat ure, one cannotrely on having agents perceive them in terms of events). However, gener-ally speaking, these situations should be known at the time of requirementscapture.

Gaia d oes not explicitly deal wit h th e activities of th e requirements captu ringand modeling, and speci cally of early requirements engineering [Mylopou-los et al . 1999]. We are aware of the importance of such activit ies and of the ongoing work in this area (see Section 5). In particular, we believe thatGaia could t a nd be ea sily integrat ed with m odern goal-orient ed appr oachesto requiremen ts engineering [Cast ro et al. 2002] whose a bstra ctions closelymatch those of agent-oriented computing. However, the investigation of suchan issue is beyond th e scope of this a rticle.



22/54


4.1 The Analysis Phase

The m ain goal of the ana lysis ph ase is to organize th e collected speci cations

and requirements for the system-to-be into an environmental model, prelimi-na ry role and intera ction models, and a set of organ izat ional r ules, for each of the (suborgan izat ions) composing the overall system .

The basica ssum ption in Gaia is that t he ana lysis phase can rely on the outp utproduced by an ea rly requirements engineering phase, devoted to an alyzing th echaracteristics to be exhibited and the goals to be achieved by the system-to-be,as t hey emerge from th e needs of the st akeh olders and from th e speci c opera-tiona l environment. The increasing acceptan ce of goal-oriented approaches t oearly requirements engineering [Mylopoulos et al. 1999] modeling the speci -cations of systems in terms of the actors involved, their roles, and their goals is well suited to th e organizational a bstra ctions exploited by Gaia. Moreover,it may facilitate the Gaia analysis (which can accordingly be considered as aform of late requ irements engineering phase), as well as the subsequent design

phases.

4.1.1 The Organizations. Th e rst phase in Gaia analysis is concernedwith determ ining whether multiple organizations ha ve to coexist in t he systemand become autonomous interacting MASs. Identifying such organizations isreasonably easy if (i) the system speci cation a lready identi es them or (ii) thesystem mimics the structure of the real world, and this involves multiple,interacting organizations. However, even if neither of these conditions hold,modularity concerns m ay su ggest considering th e system in term s of multipleorganizations, for the sake of splitting the global complexity of a problem intoa set of smaller more m an ageable components [Simon 1957]. Genera lly speak-ing, such su borgan izations can be found when th ere ar e portions of the overallsystem that (i) exhibit a behavior speci cally oriented towards the achieve-

ment of a given subgoal, (ii) interact loosely with other portions of the sys-tem, or (i i i) require competences that are not needed in other parts of thesystem.

Turn ing to our r un ning examples. The agents contr olling the ma nu factur ingpipeline are likely to be conceived as belonging to the same organization: (i)they share the same overall goal (making the pipeline run ef ciently), (ii) theysometimes need to inter act inten sively with each other, while th ey interact lessfrequent ly with those agent s concerned with contr olling other part s of the fac-tory (e.g., the electric plant), and (iii) the required agent skills are very closelyrelated t o that section of the ma nu factur ing process. With r egard t o the confer-ence mana gement example, three suborganizations can be clearly identi ed .First, the organization responsible for the submission process is in charge of distributing the call for papers, collecting the submitted papers, and possiblydoing some preliminary review/control of the papers. Second, the organizationresponsible for the review process. This is in charge of assigning submittedpapers to r eviewers, of collecting a nd rank ing th e reviews, and de ning thetechnical programme. Third, the organization responsible for the publicationof the proceedings. In all cases, there is a clear subgoal to be pursued in eachorganization, the interactions between organizations are loose and scheduled



23/54


at speci c intervals of t ime, and there are enti t ies that participate in someorganizations and not in others.

4.1.2 The Environm ental Model. It is dif cult to provide general modelingabstractions and general modeling techniques because (as already stated inSection 3.1) the environments for different applications can be very different innat ure an d also becase t hey ar e somehow related to the und erlying technology.To develop a reasonably general approach (without the ambition for it to beuniversal), we suggest treating the environment in terms of abstract comput a-tional resources , such as variables or tuples, made available to the agents forsensin g (e.g., rea ding t heir values), for effectin g (e.g., chan ging th eir valu es) orfor consuming (e.g., extracting them from the environment).

Following su ch ident i cation, the environmental model (in its simplest form)can be viewed as a list of resources; each a ssociated w ith a symbolic na me, char-acterized by the t ype of actions t ha t t he a gents can per form on it, and possiblyassociated with additional textual comments and descriptions. A simple wayto represent these is as follows (inspired by the FUSION notation for operationschema ta [Coleman et a l. 1994, pp. 26 31]):

reads Var 1 // readable resource of t he environm ent Var 2 // anoth er readable resource

changes Var 3 // a variable that can be also chan ged by th e agent

Returning to our ru nning examples. In th e ma nufacturing pipeline, and as-sum ing tha t th e MAS is being deployed with t he sole goal ofen sur ing the corr ectow of items in th e pipeline, the resources of inter est a re t he n um ber of itemsbeing produced and ma de ow in ea ch of th e pipeline s n stages (other resourcessuch as tempera tu re, hum idity, position, ma y be relevan t for other speci c ac-tivities of the stages). Thu s, if appr opriate sensors an d a ctu ators a re a vailableto detect and control, respectively, such ux, the en vironment al model reducesto:

changes ux [i ], i = 1, n // number of items owing in each stage of the pipeline

In the conference management, the resources handled by the agents arepapers and review forms. In a minimal (exemplifying) representation, the en-vironmental model can be as follows:

reads papers [i ], i = 1, totalsubmitted // all papers submitted for reviewchanges review [i ][ j ], i = 1, totalsubmitted ;

j = 1, numberofreviewers // reviews for the submitted papers

Clearly, in realistic development scenarios, the analyst would choose to pro-vide a more detailed and structured view of environmental resources. For in-stan ce, a paper would be represented by a dat a st ructur e including informationsuch as authors, title, keywords, and so on. Also, it is worth pointing out thatmore speci c modeling t echn iques may be better adopted depending on speci-cations and technological constraints. For instance, the development of Web-based in form at ion ba sed on XML docum ent s (as may be th e case in a conferen ce



24/54


Manufacturing Pipeline

Stage 3Stage 2Stage 1

Flux[1] Flux[2] Flux[3]

Fig. 7. Graphical representat ion of the ma nufacturing pipeline environmen t.

mana gement system) might pro t from an en vironment al model by preservingthe already available XML data representation and simply enriching i t withannotations related to how the MAS will access these structures.

In a ny case, ther e are other speci c issues relat ed to the modeling oft he envi-ronmental resources that may be required to enrich/complement our proposedbasic notation. In particular:

Often, du e to either th e distributed n atu re of the en vironmen t or to the logi-cal/physical relationships existing between its resources, a graphical (possi-bly an notated) scheme m ay be of help to represent such relationships an d toidentify how and from where a resource can be accessed. In th e ma nufactur-ing pipeline, the various stages are intrinsically distributed in space, and itmay be the case that the data re la ted to the ux of an i tem in a particularstage can only be accessed by the stage itself. In this case, a graphical repre-sentation as per Figure 7 facilitates the capturing and understanding of theenvironmental characteristics. A similar representation can be used for theconference mana gement environment where paper s an d review forms may begrouped either according to some logical relationships (e.g., the type of sub-mission) or their network distribution (e.g., when a multiple track conferenceinvites submissions directly to t he Websites of th e t rack chairs).

The environm ent in wh ich a MAS is immer sed is typically cha ra cterized by itsown dyna mics. On the one ha nd, th e content of the environmen tal r esour cesmay change over time according to patterns that may be of some relevanceand may require some explicit modeling (for the sake of, for example, analyt-ical modeling). These cases can generally be dealt with via annotations to thebasic environment al model. On th e other han d, some of the r esources couldbe intermittently available, of an ephemeral nature, or simply be a prioriunknown. These cases may also require enriching the basic access model toresources to take into account such uncertainties. For instance, an associa-tive access model as per Linda tuple spaces may well suit this purpose [Cabriet al. 2000], as proved by its increasing adoption in open distributed systems[Cabri et al. 2002].

An importa nt issue t ha t should be born e in mind when modeling the environ-ment is the fact tha t t he operational environmen t of a MAS may include a ctivecomponents (i.e., services and computerbased systems) with which agents inthe MAS h ave to inter act. This intr oduces th e problem of how to deal with su chentities: should they be modeled as resources of the environment, or shouldthey instead be agenti ed ? (i.e., modeled in ter ms of additiona l agents in t he



25/54


MAS) Some genera l guidelines can be provided with respect to th is issue:

When the role of these active components is simply that of a data provider(consider, for exam ple, a Web server or a DBMS media tin g access to a da ta set,or a simple computerbased sensor), it is better to abstract away from theirpresence and to model them in terms of resources. The rationale for this isthat their presence in uences only the m echa nisms by which agents r etrieveresources (i .e. , obtaining the data by requesting a service rather than byperforming a sensing opera tion), not t he n atu re of th e resources themselvesor th e inter na l activities of th e agent s. Similar considerat ions may a pply forsimple components capable of event-noti cation services (i.e., upon changeof a resource value).

If the environment cont ains components an d services th at ar e capable of per-forming complex operat ions (e.g., a ctive dat abases, active contr ol systems,humans in-the-loop) then their effects on the agents perception of the en-

vironment can make it ha rd to model them as a simple resource repositorywith identi able patterns of dynamic change to be sensed by agents (or tointeract with based on event-noti cat ion mechanisms). In su ch cases, thesecomponents should n ot be treated a s par t of the environment but, instead,they should be agenti ed .

4.1.3 The Prelimin ary R ole Model. The ana lysis phase is not intended todesign t he actual organization of the MAS (this is th e pu rpose of the subse-quent architectural design phase). However, even without knowing what thestructure of the organization will be, it is possible, in most cases, to identifysome characterist ics of the system that are l ikely to remain the same inde-pendently of the actual organizational structure. In particular, this equates toidentifying th e basic skills that are required by the organization to achieve

its goals, as well as th e basic inter actions t ha t a re r equired for t he exploitationof these skills. Such identi cation activities ma y even be facilitat ed if a goal-oriented early requirements analysis has already modeled the characteristicsof the system in term s of actors involved an d t heir goals.

Given th e ident i cat ion oft he basic skills and oft heir basic intera ction needs,respectively, th e a na lysis pha se can provide a preliminary de nition of the or-ganization s roles and protocols. However, this de nition cannot be completedat this stage. In fact, the basic skills (or preliminary roles ) can only truly be-come organiza tional roles when it is known how and with wh ich other r oles theywill interact. This, in turn, requires the de nition of the global organizationalstructure. Analogously, the basic interaction needs (or prelim inary protocols )can only be fully de ned as organizational protocols when the adoption of anorgan izat ional str uctur e clari es wh ich roles th ese pr otocols will involve, whentheir execution will be triggered, and by whom. In addition, the design phaseis likely to intr oduce additiona l r oles and protocols, directly derived from th eadopted organizational structure and, therefore, not identi ed in th e ana lysisphase.

As anticipated in Section 3.3.3, i t may also be the case that the need toadopt speci c organizational substructures in a system derives from speci c



26/54


requirement s, in wh ich case at least some of th e roles and protocols may assu mean already complete de nition even at this stage.

In t he ma nu factur ing pipeline, the preliminar y roles ( PR ) that can be devisedare those associated with each of the stages in the pipeline:

PR = S TAGE [1], S TAGE [2], . . . , STAGE [N] .

In a ddition, depending on th e global str uctur e of the man ufactu ring process,it is possible to devise other preliminary roles. For example, when the ux of i tems in the pipeline require more power than is currently supplied, an ad-ditional role m ay h ave to be introduced whose ta sk is to coordinate with theelectric plan t (better, the agent organization of the electric plant ) and negotiatefurther supplies of energy. However, unless the design has identi ed whetherthe overall system should be structured as an organization of peers (Figure 2)or a hierarchy (Figure 3) the role speci cation cannot be completed, nor is itpossible to identify all t he roles involved in th e organization. Analogously, itmay be clear from the analysis phase that a protocol should be de ned for en -abling one stage to ask for a slowing down in the ux of items in th e pipeline.However, in this case, it is not certa in wh ich other entity t his pr otocol shouldinvolve (the other stages in the pipeline or a global controller, depending on thechosen organizational str ucture).

In the conference management case, and in par ticular in t he organizationof the review process, it is comparatively easy to devise a number of prelimi-nary roles th at will be played whatever th e organizational structure. For ex-ample, the roles associated with selecting reviewers and assigning papers tothem (R EVIEW C ATCHER ), the role of reviewer in charge of lling review formsfor assigned papers (R EVIEWER ), the role in charge of collecting and ranking thereviews (R EVIEW C OLLECTOR ) and the role of nalizing the technical programme(D OP ROGRAM ). Depending on th e actua l organ izational stru ctu res, different ac-tors (e.g., th e PC Chair, the PC Members or extern al r eviewers) will be calledto play such r oles. However, th e actua l organizational stru ctu re, de ned in thearchitectura l design ph ase, may a lso require a dditiona l roles to be introduced.For exam ple, a big conferen ce ma y opt to subdivide the subm itted pa pers a monga set of co-cha irs a ccording to th eir compet ences. In th is case, an add itional roleis required, for partitioning the submitted papers according to the de ned cri-terion. This is likely to in uence the de nition of th e protocols an d t o requirethe de nition of further protocols (e.g., protocols to achieve some form of loadbalancing on the par titions).

To represent (preliminary) roles, Gaia adopts an abstract, semiformal, de-scription to express th eir capabilities an d expected beha viors. These are repre-sented by two ma in a ttr ibute classes, respectively: (i) permissions a nd (ii) re-

sponsibilities.Permissions . These attributes are mainly aimed at: (i) identifying the r e-

sources that can legit imately be used to carry out the role intu itively, th eysay what can be spent while carr ying out the role; and (ii) stating t he r esour celimits within which the role must operate intuitively, th ey say what can t bespent while carrying out the role. In general, permissions relate agent roles



27/54


Manufacturing Pipeline

Stage 3Stage 2Stage 1

Flux[1] Flux[2] Flux[3]Environment

PreliminaryRoles

Stage[1] Stage[2] Stage[3]

Change ChangeChange ReadRead

Fig. 8. The environment-preliminary roles diagram.

to the environment in which they are situated: in order to carry out a role, anagent will typically ha ve to access environm ent al resources and possibly chan geor consume them. However, they can also be used to represent knowledge t heagent can possibly ha ve or h ave received from commu nications with other r oles.Tor epresent perm issions, Gaia mak es use of the sam e nota tion alrea dy used forrepresenting the environmental resources. However, the attributes associatedwith r esources no longer r epresent what can be done with su ch r esour ces (i.e.,reading, writing, or consu ming) from th e environmenta l perspective, but wh atagents playing the role must be allowed to do to accomplish the role and whatthey m ust not be allowed to do.

In the manufacturing pipeline example, an agent in charge of controlling aspeci c stage of the pipeline may need to sense (read) the abstract resourcerepresenting the ux of items entering its region of responsibility. However,since the previous stage is controlled by a different agent, it cannot control(cha nge) it. Neverth eless, the role requires a n a gent t o sense and effect t he uxof items in its sta ge, represent ing the inpu t ux to the n ext stage. This reducesto the following representation of the permissions for a generic role S TAGE [i ]:

reads ux [i 1] // ux from previous stagechanges ux [i ] // ux t o next stage

In the conference management example, the R EVIEWER role requires the ca-pability to read the papers it has been assigned for review and of writing theassociated review forms:

reads Papers // all t he pap ers it receiveschanges ReviewForms // one for each of the papers

Due to the strict relations between the permission and the environmentalmodels, a graph ical represent ation relating th e preliminary roles and th eir con-nections with t he environment is often a useful outcome of the a na lysis pha

Date post:	07-Apr-2018
Category:	Documents
Upload:	hoangtca
View:	224 times
Download:	0 times

the Gaia Methodology for Agent-Oriented Analysis and Design

Documents