Methodologies for self-organising systems: a SPEM approach

Mariachiara PuvianiDepartment of

Information Engineering,University of Modena

and Reggio Emilia,Modena, Italy

mariachiara.puviani@unimore.it

Giovanna Di Marzo Serugendo,Regina Frei

Computer Science and Information Systems,Birkbeck College,

London, United Kingdomdimarzo@dcs.bbk.ac.uk,regina.frei@uninova.pt

Giacomo CabriDepartment of

Information Engineering,University of Modena

and Reggio Emilia,Modena, Italy

giacomo.cabri@unimore.it

Abstract

This article summarises five relevant methods for devel-oping self-organising multi-agent systems. It identifies theirmost promising aspects and provides a meta-model of eachunder the form of ’SPEM fragments’. These fragments canbe combined and be part of a larger ad hoc methodology.Self-organising traffic lights were chosen as an illustratingexample for the relevant features of the different methodsconsidered.

1. Introduction

A large amount of work has focused on translatingnatural self-organising mechanisms into artificial systems.These developments remain ad hoc solutions, usually highlydependent on finely tuned parameters. To convince potentialindustrial buyers of such a technology, more systematicdevelopment and validation techniques are needed.

This article investigates five software engineering tech-niques (section 4, 5, 6, 7 and 8), which explicitly addressthe development of self-organising systems, applies themto a common self-organisation problem, described in sec-tion 2 and presents them using ’SPEM fragments’. Spem[17] is a meta-modelling language, useful for representingdevelopment methodologies, comparing them and possiblycombining them (see sections 3 and 10). In section 9, wecompare the considered methodologies and in section 10 wegive some guidelines to compose an ad hoc methodology.Conclusions and future work follow in section 11.

2. Case study - Traffic Lights Control

To illustrate how the main aspects of the different methodspresented in sections 4, 5, 6, 7 and 8 apply to a concreteexample, we consider a system composed of cars and trafficlight controllers (TL). The global goal of the system isto optimise traffic throughput. Cars need to reach theirdestination as fast as possible without stopping; TLs need toallow vehicles to travel as fast as possible while mediating

their conflicts for space and time at intersections. Trafficlights are independent from each other, and the global systembehaviour will appear from the traffic flow of the wholesystem.

We consider four traffic lights, disposed in a grid asshown in Figure 1. To simplify the system, cars travel alonghorizontal and vertical lines only. TLs synchronise with eachother (two by two) using the traffic flow information givenby cars that pass by.

Figure 1. Traffic Light Case Study

3. Spem and fragments

To build a multi-agent system, different existing method-ologies can be helpful, but not every methodology providesa solution to any problem in any context. It is thereforeconvenient to join reusable fragments from existing method-ologies. This combines the designer’s need for an individualmethodology with the advantages and the experience ofexisting and documented methodologies.

Methodologies are decomposed into so-called methodfragments, which are pieces of process. With these frag-ments and using SPEM (Software Process EngineeringMetamodel)[17], the FIPA Methodology Technical Commit-tee1 constructed a repository (the method base). In thisarticle, we use the FIPA fragment type. For others see [2],[21] and [8]. Thanks to using a common language, Spem

helps comparing method fragments. A standard language ornotation is the best way to enable the reuse of methodolo-gies. The Spem specification is structured as a UML profile,and provides a complete Meta Object Facility (MOF)2 basedmetamodel [16]. UML diagrams (e.g. use cases diagrams,activity diagrams, sequence diagrams) facilitate the inte-gration of different methodologies. According to the OMGspecification3 [17], a method fragment is a portion of amethodology, which is a set of the following components:

1) A process specification, defined by a Spem diagram.2) Deliverables which permit process reconstruction.3) Preconditions which represent constraints.4) A list of concepts (related to the methodology’s meta-

model) to be defined, designed or refined.5) Guidelines fragment application and best practice.6) A glossary of terms used in the fragment.7) Composition guidelines: descriptions of the con-

text/problem that is behind the source methodology.8) Aspects of fragment: textual descriptions.9) Fragment dependency relationships.A software development process is a collaboration be-

tween abstract active entities (process roles) which performoperations (activities) on concrete entities (work products).The overall goal of a process is to deliver a set of workproducts in a well-defined state [17].

Extracted fragments: The fragments presented are par-ticularly relevant because they cover significant features ofself-organizing system. When presenting the fragments, weuse the following abbreviations: DL for deliverables, PC forpreconditions, and GL for guidelines.

4. Adelfe

ADELFE [1] is an agent-based development methodologytargeting self-organising systems with decentralised controland emergent functionality. It is based on UML (UnifiedModelling Language) and AUML (Agent-UML) [18], andproposes a design process based on the RUP (RationalUnified Process). Adelfe is based on the AMAS (AdaptiveMulti-Agent System) theory [3] where cooperation is fun-damental. During cooperation an agent tries to:

• anticipate problems;• detect cooperation failures, called Non Cooperative

Situations (NCS): e.g. a perceived signal is ambiguous.• repair NCS [12].The designer not only needs to describe what an agent has

to do in order to achieve its goal, but also which situationsmust be avoided (NCS), and how to suppress them whenthey are detected.

A cooperative agent in the AMAS theory is autonomousand unaware of the global function of the system; it candetect NCSs and acts to return to a cooperative state; it isnot altruistic but benevolent.

Adelfe is divided into six main phases or Work Defini-tions (WD): Preliminary Requirements, Final Requirements,Analysis, Design, Implementation and Test (see Figure 2,from [19]). Each phase consists of several activities (A),and each activity consists of several steps (S). We focus onhow Adelfe creates self-organising systems [19].

Figure 2. The ADELFE methodology [19]

WD2, Final requirements: A6 supports the identificationof the environment (entities and context). It is characterisedas being accessible or not, deterministic or not, dynamicor static and discrete or continuous. In A7, the designeridentifies the possible cooperation failures (NCS).

WD3, Analysis: an interactive tool helps to decide ifthe use of the AMAS theory is required or not (A11). InA13, entity relationships which are useful for cooperationare studied.

WD4, Design: protocol diagrams serve to study agentinteractions (A15). Adelfe provides a model to design coop-erative agents (A16). A set of generic NCS are suggested,such as: incomprehension, ambiguity, uselessness or conflict.The designer fills in a table for each NCS.

Adelfe and the AMAS theory have been applied to alarge range of cases such as flood forecast, robot transport,manufacturing control or emergent programming [1].

Case study:We used the Adelfe Toolkit4 to produce the documents

and diagrams which are related to the self-organizing partof the methodology, and to simulate the created system inthe end. Here we report only some activities; for furtherdetails see [20].

A1-A3: The stakeholders are TLs or cars. Each actorindividually owns some constraints that must be (best)fulfilled: TLs have constraints about the status of their lights:They cannot be both green and red. TLs have to turn greenif there is traffic flow. If the traffic flow in one direction isbigger than the flow in the other direction, TLs have to turngreen in the direction with the bigger traffic flow. TLs haveto turn red if there is no traffic flow. Cars have constraintsabout their traveling: they have to stop if there is a red lightor another car ahead and must go on if the street ahead is

Name Equal flowState AnyDescription The horizontal traffic flow is equal to the vertical

traffic flowCondition(s) flowhorizontal == flowvertical

Action(s) The TL decides which flow to consider first.Name Too many carsState AnyDescription The number of cars exceeds the chosen threshold θ.Condition(s) flowhorizontal > θ or flowvertical > θAction(s) Prevent cars from entering, let them leave quickly.

Table 1. Equal flow NCS and too many cars NCS

empty and the light is green. Constraints on TLs are moreimportant than constraints on cars.

In A11 the AMAS adequacy are verified by answeringthe AMAS questions. Global (1-8) and local (9-11) level:

1) The global task is not completely specified.2) Cars and TLs are not subject to a fix order of action.3) Several attempts are required to find a solution.4) Dynamic environment: cars can enter/exit the system.5) The system is physically distributed.6) The system can consist of many components.7) The system is non-linear.8) Cars can appear and disappear dynamically.9) A component has limited rationality.

10) TLs can perform various actions.11) TLs and cars adapt to changes in the environment.

We identify the NCS summarised in Table 1.

SPEM:The following fragments describe the most important

steps for self-organizing systems according to [13].Environmental Description Fragment (A6): (Figure 3a).

DL: an environment definition document and UML dia-grams (scenarios) which describe the situation in the en-vironment. PC: a requirement set document that definesthe system requirements. GL: determine entities, define thecontext and characterize the environment.

Figure 3. (a) Environment Description Fragment, (b)Use Cases Description Fragment

Use Cases Description Fragments (A7): (Figure 3b). DL:a functional description model, and the now completed

environment definition document. PC: the preliminary envi-ronment definition document. GL: draw up an inventory ofthe use cases, identify cooperation failures and elaborate onsequence diagrams.

Adequacy Verification Fragment (A11): (Figure 4a). DL:the final AMAS adequacy synthesis document. PC: thepreliminary software architecture document, described in theAdelfe domain description fragment (see [13] for details).GL: verify the AMAS adequacy at local and global level.

Figure 4. (a) Adequacy Verification Fragment, (b) AgentIdentification Fragment

Agent Identification Fragment (A12): (Figure 4b). DL: thesoftware architecture document, including the agents. PC:the preliminary software architecture document and the finalAMAS adequacy synthesis document. GL: study the entitiesin their context, identify the potentially cooperative entitiesand define the agents.

Interaction Between Entities Identification Fragment(A13): important for the agent relationships step, but alsoother fragments can be used to identify agent interactions.See [13] for further details.

Agent Specification Fragment (A15, A16, A17): (Figure5). DL: the AUML protocol diagrams, which specify theinteraction language, the final interaction language documentand the detailed architecture document, including the agentmodel. PC: the initial detailed architecture document definedin the Adelfe architecture definition fragment. GL: defineand test agent behaviours.

5. The Customised Unified Process

The Customised Unified Process (CUP) [4] is an itera-tive process that provides support for the design of self-organising emergent solutions in the context of an engineer-ing process. It is based on the Unified Process (UP) [14], andis customised to explicitly focus on engineering macroscopicbehaviour of self-organizing systems (see Figure 6).

During the Requirement Analysis phase the problem isstructured into functional and non-functional requirements,using techniques such as use cases, feature lists and a do-main model that reflects the problem domain. Macroscopicrequirements (at the global level) are identified.

The Design phase is split into Architectural Design andDetailed Design addressing microscopic issues. Information

Figure 5. Agent Specification Fragment

Figure 6. Customized Unified Process Methodology [4]

Flow (design abstraction) traverses the system and formsfeedback loops.Locality is ’that limited part of the system forwhich the information located there is directly accessible tothe entity’ [4]. Activity diagrams are used to determine whena certain behaviour starts and what its inputs are. Informationflows are enabled by decentralised coordination mechanisms.Therefore, following the idea of design patterns, a setof patterns of decentralised coordination mechanisms areprovided [5] (e.g. the Gradient Field).

During the Implementation phase, the design is realisedby using a specific language. When implementing, theprogrammer focuses on the microscopic level of the system.

In the Testing and Verification phase, agent-based simu-lations are combined with numerical analysis algorithms fordynamical systems verification at macro-level.

The CUP approach has been applied to autonomousguided vehicles and document clustering [4].Case Study:

The four TLs are defined as agents; cars are consideredas entities. The four circles around the TLs define the fourlocalities (see Figure 1). The main goal can be decomposedinto sub-goals, which consist of flow optimisation for eachTL. The information needed for each TL is the status of its

light, and the horizontal and vertical flow in its area.We chose gradient fields as patterns of decentralised

coordination mechanism [15]. Traffic flow automaticallypropagates information between TLs.

SPEM:The following fragments were extracted from the archi-

tectural design phase of the CUP.The information flow can be developed using two different

fragments, which are suitable to describe the communicationflow between agents.

(1) Locality Identification Fragment: (Figure 7a). DL: anUML diagram (e.g. activity diagram) and a localities model.PC: a system requirement document that defines the systemrequirements given by the users, and an agent model.GL:determine localities for each agent.

(2) Information Flow Definition Fragment: (Figure 7b).DL: an UML diagram (e.g. an activity diagram) and aninformation flow model that describes the information flowin the entire system, starting from each locality. PC: asystem requirement document that defines the system re-quirements given by the users, and the localities model.GL: first decompose the system behaviour in sub-goals, thendetermine the information flow.

Figure 7. (a) Locality Identification Fragment, (b) Infor-mation Flow Definition Fragment

We decided not to create specific fragments for thepatterns of decentralised coordination mechanisms becausethe pattern list is only useful for the developer to choose thecommunication and coordination mechanism. This meansthat it is not possible to define a real fragment. It is,however, important to consider this list while defining a self-organising system. The list is a document (similar to thesystem requirement document) given by the user and can beintegrated into other fragments while building the system.

6. MetaSelf

The MetaSelf approach considers a self-organising sys-tem as a collection of loosely coupled autonomous com-ponents. Metadata describes components’ functional andnon-functional characteristics such as availability levels and

environment-related metadata (e.g. artificial pheromones).The system’s behaviour (e.g. reconfiguration to compen-sate for component failure) is governed by policies whichdescribe the response of system components to detectedconditions and changes in the metadata. When the system isrunning, both the components and the run-time infrastructureexploit updated metadata to support decision-making andadaptation in accordance with the policies.

The MetaSelf approach proposes both a system archi-tecture and a development process. The MetaSelf systemarchitecture involves autonomous components, repositoriesof metadata and executable policies, and reasoning serviceswhich dynamically enforce the policies on the basis ofmetadata values. Metadata may be stored, published andupdated at run-time by the run-time infrastructure and bythe components themselves, both of which can also accesspolicies at run-time (Figure 8).

Guiding policies are high-level goals (e.g. starting orstopping a swarm of robots); bounding policies define en-vironmental limitations; sensing/monitoring policies definereflex behaviour for the components (e.g. if a metadata valuereaches a threshold, an action must be taken). Policies maybe generic, e.g. replacing a current (slow) component with ahigher-performance equivalent. By accessing metadata aboutcurrent performance, the reasoning engine can determinewhich of the available components must replace the failingone. Policies can change dynamically.

Self-* properties

Metadata

Metadata Acquisition

Enforcement of PoliciesService

Apply policy

Application Components(Services)

Run-time Infrastructure

Self-description of

Components Coordination/Adaptation

Service

Coordination SpaceEnvironment

Metadata

Guiding Policies

Coordination Policies

Bounding Policies

Policies

Sensing/MonitoringActing/Adapting

Policies

Apply coordination

Sensing / Acting Acquisition of

policies

Figure 8. MetaSelf - Run-time infrastructure [7]

Figure 9 shows the MetaSelf development method. TheRequirement and Analysis phase identifies the functional-ity of the system along with self-* requirements specifyingwhere and when self-organisation is needed or desired.

The Design phase consists of two steps: (a) the pat-

terns and mechanisms decision step: choice of architecturalpatterns (e.g. autonomic manager or observer/controller ar-chitecture) and adaptation mechanism (e.g. trust, gossip, orstigmergy) (b) the application system design step: instantiatethe chosen patterns for the specific application, architectureand policies, design the individual components (agents),select and describe the necessary metadata.

The implementation phase produces the run-time infras-tructure (Figure 8).

Figure 9. MetaSelf - Development Process

MetaSelf development process has been applied todynamically resilient Web services [6] and to self-organising industrial assembly systems [9].

Case Study:We determine the following: Components: The four

TLs are active, and the cars are passive entities (theycan change their state only due to environmental change).Self-* requirements: Traffic flow is optimised as a resultof self-organisation. Architectural Pattern: The genericobserver/controller is chosen. Each TL comes with itsobserver and controller components. Self-organizationmechanism: Gradient Fields (traffic flows) created by carsmovement. Cars follow gradients, TL react to gradientsby changing lights. Coordination mechanism: TL knowscolour of light in both lanes backwards. Guiding Policies:Optimise traffic flow on each direction. Coordinationpolicies for TLs: Green Wave: ’Keep green light if TLbackwards also has green light’. Bounding policies: Nocars are allowed at the intersections (to avoid blockage):’If distance to car in outgoing lane is too small, switchto red light’. Sensing/Monitoring policies: ’If horizontalflow is bigger than vertical flow (gradients fields), switchthe horizontal TL to green and the vertical TL to red.’ ’Ifvertical flow is bigger than horizontal flow, switch verticalTL to green and horizontal TL to red.’ Metadata: Trafficflow on each incoming lane for each TL; distance to car ineach outgoing lane for each TL.

SPEM:The most relevant MetaSelf fragments are:Identification of Pattern and Mechanism fragment: (Figure

10a). DL: the architectural design pattern and the adaptationand coordination mechanism. PC: a list of self-* require-ments which represents the required system proprieties. GL:define the self-organisation / self-adaptation architectural de-sign pattern and the adaptation and coordination mechanism.

Figure 10. (a) Identification of Pattern and MechanismFragment, (b) Identification of Software ArchitectureFragment

Identification of Software Architecture Fragment: (Figure10b). DL: the metadata model, the agent model and thepolicies model. PC: the self-* requirements document, thearchitectural design patterns document and the adaptationand coordination mechanism document, which describes thenecessary conditions to build the system. GL: define designphase entities.

Run Time Infrastructure Definition Fragment: (Figure11). DL: the final version of the agent model, the exe-cution policies, the metadata repository, and adaptation /coordination services repository. PC: the adaptation andcoordination mechanism document, the architectural designpattern document, as well as the agent model, the policiesmodel and the metadata model. GL: define everything whichis needed to build the run time infrastructure.

Figure 11. Run Time Infrastructure Definition Fragment

7. A General Methodology

The General Methodology [11] provides guidelines forsystem development. Particular attention is given to thevocabulary used to describe self-organising systems. For thefive iterative steps or phases see Figure 12 from [11].

In the Representation phase, according to given con-straints and requirements, the designer chooses an appro-priate vocabulary, the abstractions level, granularity, vari-ables, and interactions that have to be taken into account

Figure 12. Methodology steps

during system development. Then the system is divided intoelements by identifying semi-independent modules, withinternal goals and dynamics, and with interactions with theenvironment. Similar interacting variables are grouped, asan increasing number of interaction increases complexity.The representation of the system should consider at leasttwo different level of abstractions: agents are referred to asx-agents, where x denotes the level of abstraction relative tothe simplest agent in the group. Each of them has goals thatcan be described and interrelated.

In the Modeling phase, a control mechanism is defined.This mechanism should be internal and distributed. It willensure the proper interaction between the elements of thesystem, and produce the desired performance. However, themechanism cannot have strict control over a self-organizingsystem; it can only steer it. To develop such a controlmechanism, the designer should find aspects or constraintsthat will prevent the negative interferences between elements(reduce friction) and promote positive interferences (promotesynergy). The control mechanism needs to be adaptive, ableto cope with changes within and outside the system (i.e.be robust) and active in the search of solutions. It willnot necessarily maximize the satisfaction of the agents, butrather of the system. It can also act on a system by boundingor promoting randomness, noise, and variability. A mediatorshould synchronize the agents to minimize waiting times.

In the Simulation phase, the model(s) developed in themodeling phase are implemented and different scenariosand mediator strategies are tested. Simulation developmentshould proceed in stages: from abstract to particular. Basedon the simulation results, the modeling and representationphases can be improved.

The Application phase is used to develop and testmodel(s) in a real system. Finally, in the Evaluation phase,the performances of the new system are measured andcompared with the performances of the previous ones.

This methodology was applied to traffic lights, self-organising bureaucracies and self-organising artefacts [11].

Case Study:We define the following: Requirements: The main goal is

to develop a feasible and efficient traffic light control system.Representation phase: The system can be modelled

on two levels: car level and TL level. The cars’ goal isto maximise their satisfaction σ. This is the case whentravelling freely and without stopping at intersections. Theminimal value of σ = 0 corresponds to a car stopping indef-

initely. The TL system’s goal is to maximise the system’ssatisfaction σsystem. This is the case when all cars travel asfast as possible, and are able to flow through the city withoutstopping. The minimal value of σsystem = 0 corresponds toa traffic jam where all cars stop indefinitely.

Modeling phase (1): Find a mechanism that will coor-dinate TLs so that these mediates between cars, to reducetheir friction. This will maximize the satisfactions of the carsand the TLs. As all vehicles contribute equally to σsystem,frictions are minimised through compromise.

Simulation phase (1): The simulation consists of anabstract traffic grid with intersections between cyclic single-lane arteries of two types: vertical or horizontal.

Modeling phase (2): Each TL keeps a count (κi) of thenumber of cars time steps (c ∗ ts) approaching only the redlight, from a distance ρ. κi can be seen as the integralof waiting/approaching cars over time. When it reaches athreshold θ, the opposing green light turns yellow, and inthe following time step it turns red with κi = 0, while thered light turns green.

Simulation phase (2): Performance measurementsshowed that this algorithm achieves very good results forlow traffic densities, but very poor results for high trafficdensities. This is because depending on the value of θ,high traffic densities can cause the traffic lights to changeinstantly, which obstructs traffic flow.

Modeling (3): The following constraints were added toprevent fast changing: a traffic light will not be changedif the time passed since the last light change is less thana minimum phase ψmin. Once ψi ≥ ψmin, the lights willchange when κi ≥ θ.

Simulation (3): For very low traffic densities, the newalgorithm performed less effectively than the previous, butstill much better than classic methods. For high densities, thenew algorithm outperformed. For certain traffic densities,full synchronization was achieved: no car stopped. Thus,satisfaction was maximal for vehicles, traffic lights, and thecity as a whole.

For the complete result of these simulations and othertraffic light control models with more constraints, see [11].

SPEM:Control Mechanism Definition Fragment: (Figure 13).

Creates a communication model based on how to optimizethe system, which is relevant for self-organising systems.DL: an UML diagram which describes the communicationprotocol of the control mechanism. PC: an agent modeland a list of constraints. GL: divide the labour, to promotesynergies and reduce friction. The two produced documentsdefine the model of the specified system and help during thecreation of the communication and control model. All thesesteps can have feedback (not shown in Figure 13).

Figure 13. Control Mechanism Definition Fragment

8. A Simulation Driven Approach

The Simulation Driven Approach (SDA) to build self-organising systems [10] is not a complete methodology, butrather a way of integrating a middle phase into existingmethodologies. To describe the environment, suitable ab-stractions for environmental entities are necessary: the Agent& Artefact metamodel [22] considers agents as autonomousand proactive entities driven by their internal goal/task.Artefacts are passive and reactive entities providing servicesand functionalities to be exploited by agents through a usageinterface.

To overcome many methodologies’ limitations regardingthe environment, the notion of environmental agents isintroduced. They are responsible for managing artefacts toachieve the targeted self-* properties. Environmental agentsare different form standard agents (user agents). Theseexploit artefact services to achieve individual and socialgoals.

SDA is situated between the analysis and the design phase,as an Early design phase (Figure 14). It assumes that systemrequirements have just been collected and the analysis hasbeen performed, identifying the services to be performed byenvironmental agents.

Figure 14. Design phases. Adapted from [10].

To design environmental agents, a model of agents andenvironmental resources has to be provided. This model isanalysed using simulation, with the goal to describe thedesired environmental agent behaviour and a set of workingparameters. These are calibrated in a tuning process.

SDA consists of three iterative phases. During the Mod-elling phase, strategies are formulated to make the systembehaviours explicit. These behaviours should form an ab-stract model for possible architectural solutions. To enablefurther automatic elaborations and reduce ambiguity, thesedescriptions should be provided in a formal language (notspecified in [10]). The model is expected to provide a

characterisation of user agents, artefacts and environmentalagents. Feedback loops are necessary in the entire system.

In the Simulation phase, the created specifications areused in combination with simulation tools, to generatesimulation traces. These will provide feedback about thesuitability of the created solution.

As self-organising systems tend to display different quali-tative dynamics depending on initial conditions, it may hap-pen that simulations do not exhibit interesting behaviours.In this case, in the Tuning phase, the model has to betuned until the desired qualitative dynamics is reached. Thetuning process may provide unrealistic parameter values, ormay not reach the required behaviour. This means that thechosen model cannot be implemented in a real scenario. Thedesigner then needs to return to the modelling phase and startagain with a new model.

This methodology was applied to collective sorting [10].

Case Study:This approach is very similar to the one described in

section 7. They are both based on modeling, simulationand testing. We therefore did not implement the case studywith SDA.

SPEM:An important fragment which can be extracted from this

methodology is the Describe the Environment Fragment(Figure 15), as the main innovations of this methodologyare the introduction of environmental agents and the per-spective on resources as artefacts. This fragment can be veryuseful in systems where the environment plays an importantrole, but it may be difficult to combine with fragmentsfrom other methods which do not share this view on theenvironment. DL: UML diagrams, the agent model, theartefact model and the environmental agent model. PC: thesystem requirements. GL: first describe the environment byextracting agent and artefacts, then create the environmentalagents which manage artefacts to achieve the system’s self-*properties.

Figure 15. Environment Fragment

9. Methodologies comparisons

Figure 16 shows the main characteristics of each method-ology as identified by the SPEM fragments above.

Figure 16. Methodologies comparison

After studying methodologies for creating self-organisingsystems and their fragmentation using SPEM, we shed lighton advantages and weaknesses of these methodologies.

AMAS and Adelfe: If the AMAS adequacy verificationfails, the Adelfe process cannot be applied. Additionally,this verification strongly depends on the user, who has toanswer by giving his/her opinion. It is for instance difficultto determine if the system is linear or not (question 9,local level). It is also difficult to determine and select theessential NCS. Furthermore, in Adelfe, the global propertiesof the system are not guaranteed. Adelfe forces the use ofcooperation between the agents, which may be beneficial formany systems, but not for all. Several supporting tools helpdevelopers build their system.

The Customized Unified Process: An important inno-vation of CUP is the information flow diagram. It is usefulfor understanding how a system works and how informationcan be exchanged between agents. The information flowdiagram can be integrated in a communication protocol.This methodology also provides a formal technique forevaluation macroscopic properties. Patterns of decentralisedcoordination mechanisms are important to help the developerfind the best mechanism. However, no indications for theactual application of these patterns are given.

MetaSelf: High-level and low-level control and pre-dictability are supported through the dynamic enforcementof policies. MetaSelf relies on loosely coupled components,metadata and executable dynamically changing policies. Nosupport for the use of conflicting policies is provided.

A General Methodology: The designer receives assis-tance for understanding how to develop a system, but noinformation about actual development. The system modelneeds to be chosen, and simulation attempts realised. Noguidance for simulation program choice is given. This canbe negative because a methodology is supposed to giveguidelines to users. Besides, the author states that the noveltyof this methodology lies in the vocabulary used to describeself-organising systems, but then the vocabulary is not reallydefined. The choice of appropriate vocabulary for the actualsystem is left to the user.

A Simulation Driven Approach: SDA considers theenvironment and agents as first class entities (artefacts). It

is not a complete methodology per se, it must be com-bined with other methodologies. Elements like environmen-tal agents and artefacts are not necessarily supported by otherexisting methodologies.

10. Building a methodology

We sketch a possible methodology for self-organisation,using the prioritisation algorithm by [23]. In Figure 17 wesuggest where to position the method fragments within thefive development phases. A stands for Adelfe, S for the sim-ulation driven approach, M for MetaSelf, G for the generalmethodology and C for the customised unified process. Greybullets refer to fragments which are not defined here.

Figure 17. Fragments positioning

Figure 18 shows an attempt to integrate the fragments.Solid lines indicate a connection that does not need anychange, while dashed lines indicate connections which re-quire modifications in one of the concerned fragments be-cause the used concepts are not perfectly equal. The numbersin the following text refer to the numbers in Figure 18.

Notice that there are no direct connections between thefirst, second and third fragment; they are connected viagoals (some connecting fragments or entities are needed).As these three fragments come from the same methodology(Adelfe), their connection can be verified. For our purpose,we do not need the complete fragment that Adelfe uses(domain description fragment). Only environment definition(1) needs to be adapted in order to get a document that canbe used to identify the AMAS adequacy. This can be donecreating an ad hoc fragment. In the second fragment, usecase description (2), the NCS are identified, but afterwards,there is no specific fragment that will use them. Thereforethey need to be integrated when identifying the agents and

Figure 18. Composed methodology

the coordination mechanism, as the NCS will interfere withthe agents’ behaviours. The goals of the system are definedwith the help of existing scenarios. The goals, along withthe requirement set and the AMAS adequacy synthesis (3),are useful to build the self-* requirements document, neededfor the identification of pattern and mechanism fragment(4). The role concept may be useful for the identification ofagents and how they satisfy their goals: software architecturefragment (5). The self-* requirements can be used insteadof the system requirements for the locality identificationfragment (6), because they are very similar and they donot need to be adjusted. What needs to be changed are theinput models for the information flow definition fragment(7). The policies model was inserted because it is composedby the communication policies which must be taken intoaccount while building the information flow model. For therun time infrastructure fragment (8), data coming from theinformation flow model are necessary in order to definethe adaptation and coordination services. Notice that themethodology is not complete (missing implementation andsimulation), but can be a useful guideline.

11. Conclusions

Developers of self-organising systems need the supportof customised design methodologies. Most of the existingmethodologies focus on specific characteristics, such as thecommunication process, collaboration between the agents,and the environment. They can therefore never be suffi-ciently generic to cover all the existing problems. This is

why we have studied how these methodologies create therequired features of self-organisation. With the help of theSPEM approach, we suggest that designers could extractmethod fragments and reuse them. To create customisedmethodologies, the readily available fragments can be usedin combination with ad hoc created application-specificfragments.

1http://www.fipa.org/activities/methodology.html2http://www.omg.org/spec/MOF/2.0/3http://www.omg.org/spec/SPEM/4http://www.irit.fr/ADELFE/Download.html

References

[1] C. Bernon, V. Camps, M.-P. Gleizes, and G. Picard. Engineer-ing adaptive multi-agent systems: The adelfe methodology. InB. Henderson-Sellers and P. Giorgini, editors, Agent-orientedMethodologies,, pages 172–202. Idea Group Pub., Hershey,PA, USA, 2005.

[2] S. Brinkkemper, M. Saeki, and F. Harmsen. Assembly tech-niques for method engineering. Lecture Notes in ComputerScience, 1413:381–400, 1998.

[3] D. Capera, J.-P. Georg, M.-P. Gleizes, and P. Glize. The amastheory for complex problem solving based on self-organizingcooperative agents. In 1st Int. TAPOCS Workshop at IEEE12th Workshop on Enabling Technologies: Infrastructure forCollaborative Enterprises (WETICE), pages 383–388, Linz,Austria, 2003. IEEE.

[4] T. De Wolf. Analysing and engineering self-organisingemergent applications. PhD thesis, Department of ComputerScience, Katholieke Universiteit Leuven, Belgium, 2007.

[5] T. De Wolf and T. Holvoet. A catalogue of decentralisedcoordination mechanisms for designing self-organising emer-gent applications. Technical report, Department of ComputerScience, Katholieke Universiteit Leuven, 2006.

[6] G. Di Marzo Serugendo, J. Fitzgerald, A. Romanovsky,and N. Guelfi. A metadata-based architectural model fordynamically resilient systems. In ACM Symposium on AppliedComputing (SAC), pages 566–573, Seoul, Korea, 2007. ACM.

[7] G. Di Marzo Serugendo, J. Fitzgerald, A. Romanovsky, andN. Guelfi. Metaself - a framework for designing and con-trolling self-adaptive and self-organising systems. Technicalreport, School of Computer Science and Information Systems,Birkbeck College, London, UK, 2008.

[8] D. Firesmith and B. Henderson-Sellers. The OPEN ProcessFramework. An Introduction. Harlow, UK: Addison-Wesley,2002.

[9] R. Frei, G. Di Marzo Serugendo, and J. Barata. Design-ing self-organization for evolvable assembly systems. InIEEE Int. Conf. on Self-Adaptive and Self-Organizing Systems(SASO), pages 97–106, Venice, Italy, 2008.

[10] L. Gardelli, M. Viroli, M. Casadei, and A. Omicini. Designingself-organising environments with agents and artifacts: Asimulation-driven approach. Int. Journal of Agent-OrientedSoftware Engineering, 2(2):171–195, 2008.

[11] C. Gershenson. Design and control of self-organizing systems.PhD thesis, Faculty of Science and Center Leo Apostel for In-terdisciplinary Studies, Vrije Universiteit, Brussels, Belgium,2007.

[12] M.-P. Gleizes, V. Camps, J.-P. Georg, and D. Capera. En-gineering systems which generate emergent functionalities.In Engineering Environment-Mediated Multiagent Systems- Satellite Conf. held at The European Conf. on ComplexSystems (EEMMAS 2007), Dresden, Germany, 2007.

[13] M.-P. Gleizes, T. Millan, and G. Picard. Adelfe: Using spemnotation to unify agent engineering processes and methodol-ogy. Technical report, Intitut de Recherche en Informatiquede Toulouse, 2003.

[14] I. Jacobson, G. Booch, and J. Rumbaugh. The unified softwaredevelopment process. Addison Wesley, 1999.

[15] M. Mamei, F. Zambonelli, and L. Leonardi. Cofields: aphysically inspired approach to motion coordination. IEEEPervasive Computing, 3(2):52–61, 2004.

[16] (OMG) Object Management Group. Meta object facility(mof), specification, 2002.

[17] (OMG) Object Management Group. Software & systemsprocess engineering metamodel (spem), 2008.

[18] J. Odell, H.V.D. Parunak, and B. Bauer. Representingagent interaction protocols in uml. In P. Ciancarini andM. Wooldridge, editors, Agent-Oriented Software Engineer-ing, pages 121–140. Springer-Verlag, Berlin, 2001.

[19] G. Picard and M.-P. Gleizes. The adelfe methodology-designing adaptive cooperative multi-agent systems. InF. Bergenti, M.-P. Gleizes, and F. Zambonelli, editors,Methodologies and Software Engineering for Agent Systems,pages 157–175. Springer US, 2004.

[20] Mariachiara Puviani and Giovanna Di Marzo Serugendo.Methodologies for Self-Organising Systems: a SPEM Ap-proach - preliminary draft. Technical Report DII-AG-2008-2,Dipartimento di Ingegneria dell’Informazione University ofModena and Reggio Emilia, 2008.

[21] J. Ralyte and C. Rolland. An approach for method reengi-neering. Lecture Notes in Computer Science, pages 471–484,2001.

[22] A. Ricci, M. Viroli, and A. Omicini. Programming maswith artefacts. In R. P. Bordini, M. Dastani, J. Dix, andA. El Fallah Seghrouchni, editors, Programming Multi-AgentSystems, volume LNAI 3862, pages 206–221. Springer, BerlinHeidelberg, 2005.

[23] V. Seidita, M. Cossentino, and S. Gaglio. Using and extendingthe SPEM specifications to represent agent oriented method-ologies. In M. Luck and J. Gomez-Sanz, editors, 9th Int.Workshop on Agent Oriented Software Engineering (AOSE),Estoril, Portugal, 2008.