ADELFE 2.0

Abstract

ADELFE is a French acronym that means “Toolkit for Designing Software with Emergent Functionalities” (“Atelier de DEveloppement de Logiciels à Fonctionnalité Emergente” in French). ADELFE methodology is dedicated to applications characterized by openness and the need of the system adaptation to an environment. Its main goal is to help and guide any designer during the development of an Adaptive Multi-agent System (AMAS). An AMAS is characterized by the following points: it is plunged into an environment and composed of interdependent agents, each agent carries out a partial function and the agents, organization during runtime makes the system realize an emergent function. Actually, an agent is locally cooperative, i.e. it is able to recognize cooperation failures called Non-cooperative Situations (NCS, which could be related to exceptions in classical programs) and treat them.

ADELFE includes five Work Definitions that were initially inspired from the Rational Unified Process (RUP) and gathers 21 activities, producing or refining 12 work products. These products are aggregating modelling diagrams or structured or free text. ADELFE, which is a Model-Driven (model-centred) development method, is not hardly dependent on Domain Specific Modelling Languages (DSML) but currently the recommendation is to use UML2 for general activities and to use AMASML (AMAS Modelling Language) and SpeADL (Species-based Modelling Language) for specific activities appearing in Analysis, Design or Implementation phases.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

ADELFE is a French acronym that means “Toolkit for Designing Software with Emergent Functionalities” (“Atelier de DEveloppement de Logiciels à Fonctionnalité Emergente” in French). The main goal of ADELFE is to help and guide any designer during the development of an Adaptive Multi-agent System (AMAS). Adaptive software is used in situations in which the requirements are incompletely expressed, the environment is unpredictable or the system is open. In these cases, designers cannot implement a global control on the system and cannot list all situations that the system encounters. In these situations, ADELFE guarantees that the software is developed according to the AMAS theory. This theory, based on self-organizing multi-agent systems, enables one to build systems in which agents only pursue a local goal while trying to keep cooperative relations with their neighbouring agents. An AMAS is characterized by the following points: it is plunged into an environment and composed of interdependent agents, each agent carries out a partial function and the agents organization during runtime makes the system realize an emergent function.

In the following, the ADELFE process is described by initially considering its whole process and then its five phases, which gather 21 activities, producing or refining 12 work products.

Since 2003, ADELFE has been used in many academic and industrial projects, for a total of more than 20 AMASs produced. Recently, ADELFE has been slightly modified in order to integrate last research results on Multi-agent Oriented Software Engineering and practical usages related by the industrial ADELFE partners. This chapter presents this up-to-date version of the method.

As it can be seen in the following sections, ADELFE is composed of several activities dedicated to Adaptive Multi-agent Systems. Considering this, it contains junction activities where the designer has to control if their problem requires an MAS solution or, even more, an AMAS solution. In the negative case, the design should be continued with a traditional process or a process dedicated to the problem characteristics. This documentation does not describe such activities and focuses only on the process parts dedicated to AMAS development.

Finally, it is important to notice that ADELFE is a Model-Driven (model-centred) Development method which is still in progress. Works on fragmentation, simulation, formal methods and AMAS patterns are feeding the method every year in order to improve the development of complex systems based on the AMAS. As the maturity of these topics is not sufficient to be included in this chapter, we left their presentation in research papers.

The following are the relevant references for the ADELFE process and the ADELFE extensions:

• Bernon, C.; Gleizes, M.-P.; Peyruqueou, S.; Picard, G.; ADELFE, a Methodology for Adaptive Multi-Agent Systems Engineering International Workshop on Engineering Societies in the Agents World (ESAW), Madrid, Spain, 16/09/2003–17/09/2003, Springer-Verlag, 2003, 156–169

• Bernon, C.; Camps, V.; Gleizes, M.-P.; Picard, G. Designing Agents’ Behaviours within the Framework of ADELFE Methodology International Workshop on Engineering Societies in the Agents World (ESAW), Imperial College London, 29/10/2003–31/10/2003, Springer-Verlag, 2003, 311–327

• Rougemaille, S.; Arcangeli, J.-P.; Gleizes, M.-P.; Migeon, F. ADELFE Design, AMAS-ML in Action International Workshop on Engineering Societies in the Agents World (ESAW), Saint-Etienne, 24/09/2008–26/09/2008, Springer-Verlag, 2008

• Bernon, C.; Gleizes, M.-P.; Picard, G., Enhancing Self-Organising Emergent Systems Design with Simulation International Workshop on Engineering Societies in the Agents World (ESAW), Dublin, 06/09/2006–08/09/2006, Springer-Verlag, 2007, 4457, 284–299

• Lemouzy, S.; Bernon, C.; Gleizes, M.-P. Living Design: Simulation for Self-Designing Agents European Workshop on Multi-Agent Systems (EUMAS), Hammamet, 13/12/07–14/12/07, Ecole Nationale des Sciences de l’Informatique (ENSI, Tunisie), 2007

• Mefteh, W.; Migeon, F.; Gleizes, M.-P.; Gargouri, F. Simulation Based Design International Conference on Information Technology and e-Services, Sousse, Tunisie, 2012

• Bonjean, N.; Gleizes, M.-P.; Maurel, C.; Migeon, F., Forward Self-Combined Method Fragments. Workshop on Agent Oriented Software Engineering (AOSE 2012), Valencia, Spain, 04/06/2012–08/06/2012, Jorg Muller, Massimo Cossentino (Eds.), IFAAMAS, p. 65–74, June 2012

1.1 The ADELFE Process Life Cycle

ADELFE includes five Work Definitions (WD1–5) (see Fig. 1):

• Preliminary Requirements (WD1): This phase represents a consensus description of specifications between customers, users and designers on what must be and what must give the system its limitations and constraints.

• Final Requirements (WD2): In this work definition, the system achieved with the preliminary requirements is transformed into a use cases model, and the requirements (functional or not) and their priorities are organized and managed.

• Analysis (WD3): The analysis begins with a study or analysis of the domain. Then, identification and definition of agents are processed. The Analysis Phase defines an understanding view of the system, its structure in terms of components, and identifies if the AMAS theory is required.

• Design (WD4): This phase details the system architecture in terms of modules, subsystems, objects and agents. These activities are important from a multi-agent point of view in that a recursive characterization of a multi-agent system is achieved at this point.

• Implementation (WD5): Implementation of the framework and agent behaviours is produced in this work definition.

Fig. 1

The ADELFE process phases

It is important to notice that ADELFE is not a simple waterfall process but includes loops and increments that are not depicted in the graphical representation shown in Fig. 1. For example, at the end of each phase, a validation step is executed, which requires a possible transition towards an activity previously passed.

Each phase produces at least one document that is aggregated from modelling diagrams or from structured or free text. ADELFE is not hardly dependent on Domain Specific Modelling Languages (DSML) but currently the recommendation is to use UML2 for general activities and to use AMAS Modelling Language (AMASML) and Species-bAsed moDelling Language (SpeADL) for specific activities appearing in Analysis, Design or Implementation phases.¹

1.2 The ADELFE MAS Metamodel

1.2.1 Definition of MAS Metamodel Elements

The ADELFE method is composed of various tools based on model-driven development. To support model transformation and DSML editors an ADELFE metamodel has been defined. However, this metamodel is too much based on natural language (precise and complex) to support a designer guidance.

The ADELFE MMM is organized according to the five phases comprising the process. We give in the following a short description of the main elements of this metamodel that is presented in five diagrams to simplify the layout and the discussion.

The Preliminary Requirements Phase (see Fig. 2) focuses on acquiring information about the client and their needs. Therefore, a consensual description of the problem is made in terms of functional and non-functional requirements, keywords, limits and constraints of the system. A business model with business concepts and business activities is defined to complement the documentation.

Fig. 2

The preliminary requirements phase MAS metamodel

Fig. 3

The final requirements phase MAS metamodel

Fig. 4

The analysis phase MAS metamodel

Fig. 5

The design phase MAS metamodel

In the Final Requirements Phase (see Fig. 3), the objective is to validate the requirements and to detail the need through a description of the actors, a use case model and scenarios. The end of the phase is dedicated to the characterization of the system environment and the identification of cooperation failures among the system interactions. This leads to a conclusion on the MAS adequacy to treat the problem of the client.

During the Analysis Phase (see Fig. 4), the entities are characterized as passive or active and their interactions are described. The work product obtained enables an AMAS analyst to conclude on the adequacy (or not) of the AMAS to deal with the problem. If the result is positive, all the interactions between the entities are described and cooperation failures are identified. From this information, agents (according to the definition of agent in ADELFE, see Sect. 2.3) are identified and local AMAS adequacy is studied to conclude the phase.

The heaviest phase of ADELFE is the Design Phase (see Fig. 5) which consists in defining the multi-agent oriented architecture of the solution. It starts with the definition of a module view. Then, all the communication acts are defined in order to define precisely the entity interactions and agent interactions that will be useful to complete the module view and to define a component-connector view of the agents with their neighbourhood (agents, active and passive entities). The definition of the structure and behaviour of the agents is made in two steps which lead to the definition of the knowledge module, the action module, the perception module and the decision module. These two steps concern respectively the nominal behaviour of the agent, which enables the agent to reach its goal, and the cooperative behaviour which enables the agent to self-adapt to abnormal situations. Finally, a prototype is defined to validate the result.

Currently the last phase of ADELFE, the Implementation Phase (see Fig. 6), focuses on the definition of the component-oriented architecture that will support the design. It is mainly composed of automated activities for model or code generation. However, in this document, we deliberately describe the process as manual operations in order to give more details on the activities and in order to simplify the metamodel. The implementation of an AMAS is not dependent on any MAS platform. On the contrary, it is recommended to produce a dedicated framework in order to gain in software quality. Actually, this framework is defined in terms of components (with provided and required ports, composite components, assembling) which are specified and implemented. First, the implementation focuses on the components defining entities, action and perception modules. Finally, decision module is implemented with standard behaviour rules and cooperative behaviour rules.

Fig. 6

The implementation phase MAS metamodel

Like in every process, unit testing, integration testing and functional testing are taken into account but not described here.

1.2.2 Definition of MAS Metamodel Elements

The table below gives a set of concepts definitions related to AMAS theory and ADELFE method. It covers the entire MAS metamodel used during Requirements, Analysis and Design.

Table 1

1.3 Guidelines and Techniques

ADELFE is based on object-oriented methodology, inspired from the Rational Unified Process (RUP). Some steps have been added in the classical workflow fitting with the adaptive MAS.

ADELFE is based on UML2 notation with the complementary use of DSML AMASML (AMAS Modelling Language) and SpeADL (Species-based Architecture Description Language), a design methodology, several model-driven tools and a library of components that can be used to facilitate the application development.

Guidance of the development process is supported by AdelfeToolkit (Fig. 7a). The general idea is to help the designer to follow the process, with descriptions, examples and presents a summary of works and artifacts already performed and those remaining.

As mentioned in A11 and A13 activities of the ADELFE process, the analyst must verify whether the problem needs the AMAS or not. For this, a tool (Fig. 7b) is provided to answer the questions at the macro-level (eight criteria) and the micro-level (three criteria). Answers to questions are graded from 0 to 20.

Fig. 7

Tool for monitoring the ADELFE process: AdelfeToolkit (a); tool for AMAS adequacy (b)

2 Phases of the ADELFE Process

ADELFE defines its five phases from the RUP definition. They are respectively dedicated to Preliminary Requirements, Final Requirements, Analysis, Design and Implementation.

2.1 Preliminary Requirements Phase (WD1)

The Preliminary Requirements Phase involves traditional software development stakeholders which are assigned classical activities. The goal of this phase is to obtain a precise and consensual description of the problem as well as the client’s business. No specific modelling language is used. The process flow at the level of activities is depicted in Fig. 8, and Fig. 9 depicts this phase according to documents, roles and work products involved.

2.1.1 Process Roles

Four roles are involved in the Preliminary Requirements Phase: the End-user, the Client, the Software analyst and the Business analyst.

• End-User: The end-user is responsible for the list of functional and non-functional requirements during the Define Users Requirements activity. These requirements are used to define the system and its environment.

• Client: The main role of a client is to validate product documents drawn up by other experts. The client is responsible for approving the set of requirements during the Define Users Requirements activity and during the Define Consensual Requirements activity.

• Software Analyst: Actually the software analyst gives a definition for the main concepts used to describe the system and its environment. He/she is responsible for: consensual requirements list during the Define Consensual Requirements activity, keywords during the Establish Keywords activity and limits and constraints of the system during the Extract Limits and Constraints activity.

• Business Analyst: A business analyst is responsible for the business model during the Determine Business Model activity. He/she defines the business concept and the relationships between them. He/she also describes formally what are the business activities involved, what are the products provided or required and who are the persons responsible for these activities.

Fig. 8

The preliminary requirements phase flow of activities

Fig. 9

The preliminary requirements phase described in terms of activities and work products

2.1.2 Activities Details

The flow of activities inside this phase is depicted in Fig. 8 and detailed in the following.

A01: Define Users Requirements This first activity concerns the description of the system and the environment in which it will be deployed. This activity consists in defining what to build or what is the most appropriate system for end-users. End-users and clients have to list, check and approve the requirements. The context in which the system will be deployed must be understood. The functional and non-functional requirements must be established. The flow of tasks inside this activity is depicted in Fig. 10, and the tasks are detailed in the following table.

Fig. 10

Flow of tasks of the Define Users Requirements activity

Fig. 11

Flow of tasks of the Define Consensual Requirements activity

Table 2

A02: Define Consensual Requirements This activity consists in defining what conditions or capabilities the system has to conform. The consensual requirements set is defined by the software analyst. The flow of tasks inside this activity is depicted in Fig. 11, and the tasks are detailed in the following table.

Table 3

Fig. 12

Flow of tasks of the Determine Business Model activity

Fig. 13

Flow of tasks of the Establish Keywords activity

A03: Determine Business Model This activity provides an overview of the problem, the related concepts and the activities linked to it. The flow of tasks inside this activity is depicted in Fig. 12, and the tasks are detailed in the following table.

Table 4

A04: Establish Keywords The main concepts used to describe the application and its business model are listed. This activity, carried out by the software analyst, is composed of one task giving the definition of each keyword. These definitions will be stored in the glossary. The flow of this activity is depicted in Fig. 13.

A05: Extract Limits and Constraints

In this activity, the limits and constraints of the system are defined by a software analyst. They can be found in the expression of non-functional requirements and in the definition of the context in which the system will be deployed. This information will be defined mainly from the consensual requirements set documents. The flow of this activity is depicted in Fig. 14.

Fig. 14

Flow of tasks of the Extract Limits and Constraints activity

2.1.3 Work Products

The Preliminary Requirements Phase generates five work products (text document including textual description and/or diagrams). Their relationships with the MAS metamodel elements are depicted in Fig. 15.

Work Products Kind

Table 5

Fig. 15

The preliminary requirements documents structure

Fig. 16

Business concepts

Example: Conference Management Study

The description of the system has already been provided in the introductory chapter. As the requirements are common to all methods and because ADELFE is not really dedicated to preliminary requirements, only the business model is shown in this phase. Figure 16 shows the business concepts and Fig. 17 shows the business process.

2.2 Final Requirements Phase (WD2)

The Final Requirements Phase is a classical requirement-oriented phase where the Business Analyst gives a detailed description of the system environment. It also embeds MAS-oriented tasks. The analysis, done by an MAS specialist, must add sufficient details to the description of the system environment in order to conclude if an MAS approach is needed to solve the problem with gains. The process flow at the level of activities is depicted in Fig. 18, and Fig. 19 depicts this phase according to documents, roles and work products involved.

Fig. 17

Business process

Fig. 18

The final requirements phase flow of activities

2.2.1 Process Roles

Four roles are involved in the Final Requirements Phase: the Business Process Analyst, the Client, the MAS Analyst and the Ergonomist.

• Business Process Analyst: A business process analyst is responsible for use cases identification during the Determine Use Case activity, drawing diagrams that represent the interactions between actors and the system.

• Client: The main role of a client is to validate product documents drawn up by other experts. He/she is responsible for approving the use cases defined during the Determine Use Case activity. Besides, the client agrees the UI prototype during the Elaborate UI Prototype activity.

• MAS Analyst: An MAS analyst is responsible for verifying the MAS adequacy during the Verify MAS Adequacy activity. It consists in (1) the characterization of the system environment according to Russel and Norvig definition, (2) the identification of the possible “bad” interactions between the actors and the system, and (3) the analysis of the previous results to justify the MAS use.

• Ergonomist: An ergonomist is responsible for graphic user interfaces prototype during the Elaborate UI Prototype activity. He/she understands the interactions among humans and the system, and designs a prototype which optimizes human well-being and overall system performance.

Fig. 19

The preliminary requirements phase described in terms of activities and work products

2.2.2 Activities Details

The flow of activities inside this phase is depicted in Fig. 18 and is detailed in the following.

A06: Characterize System Environment

The main objective of this activity is to define the system environment in the system environment description document. This activity enables one to identify and to describe briefly actors interacting with the system. The possible encountered constraints are also explained. The flow of tasks inside this activity is depicted in Fig. 20.

Fig. 20

Flow of tasks of the Characterize System Environment activity

A07: Determine Use Cases

The main objective of this activity is to clarify the different functionalities that the studied system must provide. The flow of tasks inside this activity is depicted in Fig. 21, and the tasks are detailed in the following table.

Table 6

Fig. 21

Flow of tasks of the Determine Use Cases activity

A08: Verify MAS Adequacy

In this activity, one must verify that a Multi-agent System (MAS) approach is needed to realize the system to be built. The question to answer is “Is a traditional (Object-Oriented) approach sufficient to solve the problem or has the problem some characteristics which implies an MAS approach for the solving?”. The flow of tasks inside this activity is depicted in Fig. 22, and the tasks are detailed in the following table.

Table 7

Fig. 22

Flow of tasks of the Verify MAS Adequacy activity

Fig. 23

Flow of tasks of the Elaborate UI Prototypes activity

A09: Elaborate UI Prototypes

The GUIs described in the UI Prototype document have to be defined, judged and validated from functional or non-functional (ergonomic, design, etc.) points of view. The flow of tasks inside this activity is depicted in Fig. 23, and the tasks are detailed in the following table.

Table 8

2.2.3 Work Products

The Final Requirements Phase generates four work products (text document including textual description and/or diagrams). Their relationships with the MAS meta-model elements are depicted in Fig. 24.

Work Products Kind

Table 9

Fig. 24

The final requirements documents structure

Fig. 25

Use cases diagram

Example: Conference Management Study

From the business model and the requirements previously established, four actors are defined. For each of them, the functionalities are detailed and depicted in a use cases diagram (see Fig. 25).

Moreover the interactions between the system and the actors are studied and shown in Fig. 26. From these diagrams, the following cooperative failures have been identified:

• at least one paper is not allocated

• not enough papers are accepted for the conference

• the chair committee disagrees with the paper allocation

• a reviewer does not have a paper to review

• the reviewer disagrees with the paper allocation

Fig. 26

System sequence diagrams

Besides, according to Russel and Norvig’s definition, the environment of the system is described as

• inaccessible because knowing all about the environment (papers, keywords, etc.) is difficult

• discrete because the number of distinct percepts and actions is limited

• non-deterministic because the actions have multiple unpredictable outcomes

• dynamic because the state of the environment depends upon actions of the system that is within this environment

2.3 Analysis Phase (WD3)

The Analysis Phase aims at identifying the system structure and justifying the AMAS adequacy. This phase is composed of four activities enabling one to analyse the domain characteristics, determine the agents and validate an AMAS approach at the global and local level. The process flow at the level of activities is depicted in Fig. 27, and Fig. 28 depicts this phase according to documents, roles and work products involved.

Fig. 27

The analysis phase flow of activities

Fig. 28

The analysis phase described in terms of activities and work products

2.3.1 Process Roles

Two roles are involved in the Analysis Phase: the MAS Analyst and AMAS Analyst.

• MAS Analyst: An MAS analyst is responsible for detailing the MAS Environment in Analysis Domain Characteristics activity. It consists in (1) the identification of what are the entities which are active and the ones which are not (passive), (2) the identification of the interactions between the entities. An MAS analyst is also responsible for Identify agent of the step which consists in defining autonomy, goal and negotiation abilities of active entities.

• AMAS Analyst: An AMAS analyst is responsible for every activity dealing with the specificities of AMAS principles. They can be found in Verify the global level AMAS adequacy activity, in Identify agent activity and in Verify the local level AMAS adequacy activity. The identification of (cooperative) agents needs to determine the cooperation failures that can occur between entities and then to define the agents regarding the results of previous steps.

2.3.2 Activity Details

The flow of activities inside this phase is depicted in Fig. 27 and detailed in the following.

A10: Analyse Domain Characteristics The main goal of this activity is to analyse the Business Domain and the System Environment Description in order to detail the entities of the domain and their interactions. The flow of tasks inside this activity is depicted in Fig. 29, and the tasks are detailed in the following table.

Table 10

Fig. 29

Flow of tasks of the Analyse Domain Characteristics activity

A11: Verify the Global Level AMAS Adequacy

In this activity, the AMAS analyst must verify that an AMAS approach is needed to realize the system to be built. For example, having a system which is able to adapt itself is sometimes completely useless if the algorithm required to solve the task is already known, if the task is not complex or if the system is closed and nothing unexpected can occur. In this activity, the adequacy at the global level is studied to answer the question “is an AMAS required to implement the system?”. This is done throw several simple questions related to the global level. The flow of this activity is depicted in Fig. 30.

Fig. 30

Flow of tasks of the Verify the Global Level AMAS Adequacy activity

A12: Identify Agent

This activity aims at finding what will be considered as agents in the desired system. These agents are defined among the previously defined entities. The flow of tasks inside this activity is depicted in Fig. 31, and the tasks are detailed in the following table.

Table 11

Fig. 31

Flow of tasks of the Identify Agent activity

A13: Verify the Local Level AMAS Adequacy In this activity, the AMAS adequacy is studied at the local level in order to determine if some agents are needed to be implemented as an AMAS i.e. if a certain kind of decomposition or recursion is required during the building of the system. The flow of this activity is depicted in Fig. 32.

2.3.3 Work Products

The Analysis Phase generates four work products (text document including textual description and/or diagrams). Their relationships with the MAS metamodel elements are depicted in Fig. 33.

Fig. 32

Flow of tasks of the Verify the Local Level AMAS Adequacy activity

Work Products Kind

Table 12

Example: Conference Management Study

From the business concepts model, we define the active and passive entities. In our case, we define six active entities and the other concepts as passive entities. The entities system structure is depicted in Fig. 34. Broadly speaking, entities which are linked to users are considered as active because users may change their mind, which implies a change in the state of the related entity. Moreover, papers and sessions are considered as active because they will need negotiation while finding a review or a session organization.

Fig. 33

The analysis documents structure

Fig. 34

Entities structure system diagram

The following step is the interactions study between entities shown in Figs. 35 and 36. The started interactions and the other one show the interaction after the paper notification, they are represented in Fig. 35.

Fig. 35

Entities interactions system structure (beginning)

Fig. 36

Entities interactions system structure (ending)

Verifying the AMAS adequacy consists in studying some specific features of AMAS with respect to the target application. The designer is provided with a tool which helps him to answer some questions. Here are the eight questions that are asked and some answers for our case study:

• Is the global task incompletely specified? Is an algorithm a priori unknown? YES: the CMS is precisely defined and some algorithms may be found to solve this kind of problem.

• If several entities are required to solve the global task, do they need to act in a certain order? YES: there are dependencies in the interactions needed between entities.

• Is the solution generally obtained by repetitive tests? Are different attempts required before finding a solution? NO: no need for that.

• Can the system environment evolve? Is it dynamic? YES: it is highly dynamic. Authors, reviewers and papers may appear or disappear while a solution is calculated.

• Is the system process functionally or physically distributed? Are several physically distributed entities needed to solve the global task? Or is a conceptual distribution needed? YES/NO: people is physically distributed but there is no need for a distributed solving of the problem.

• Are a great number of entities needed? YES: depending on the conference, but potentially, in conferences like AAMAS, there are a great number of entities.

• Is the studied system non-linear? RATHER YES: in the nominal case, it can be rather easy to find a linear decomposition of the problem, but with the openness described earlier, the great number of interactions may lead to a complex system.

• Is the system evolutionary or open? Can new entities appear or disappear dynamically? YES: it is highly dynamic. Authors, reviewers and papers may appear or disappear while a solution is calculated.

In the “Identify Agents” activity, the active entities previously defined are studied. The following table depicts the autonomy, the goal and the negotiation abilities of each of them.

Table 13

From the interactions between entities which have been previously identified, three other cooperative failure interactions are identified: (1) a paper does not find a review; (2) several papers want to rise to the same rank; (3) sessions select the same paper. Two kinds of agent are therefore deduced: the paper agent and the session agent. The resulting AMAS is represented in Fig. 37.

Fig. 37

AMAS system diagram

2.4 Design Phase (WD4)

The Design Phase aims at providing a detailed architecture of the system. During this phase, the definition of a module view is proposed, the communication acts are studied and the different behaviours are determined. The process flow at the level of activities is depicted in Fig. 38, and Fig. 39 depicts this phase according to documents, roles and work products involved.

Fig. 38

The design phase flow of activities

Fig. 39

The design phase described in terms of activities and work products

2.4.1 Process Roles

Three roles are involved in the Design Phase: the architectural designer, the MAS designer and the AMAS designer.

• Architectural Designer: An architectural designer is responsible for module organization during the Define Module View activity. He/she defines the detailed architecture of the system in terms of modules.

• MAS Designer: An MAS designer is responsible for communication acts during the Study Communication Acts activity and the definition of the entities behaviour during the Define Entity Behaviour activity. He/she defines how the entities and the agents interact together or with their own environment.

• AMAS Designer: An AMAS designer is responsible for nominal behaviour of agents during the Define Nominal Behaviour activity, cooperative behaviour of agents in the Define Cooperative Behaviour activity and fast prototyping during the Validate Design Phase activity. Indeed, from the structure analysis and the communication acts previously detailed, an AMAS designer defines skills, aptitudes, an interaction language, a world representation, a criticality and the characteristics of an agent. He/she fulfils the agent behaviour by adding a cooperative attitude i.e. giving rules which enable anticipating or detecting and repair of the non-cooperative situations. For that, skills, aptitudes, an interaction language, a world representation, a criticality and the characteristics are filled out. Finally, an AMAS designer tests the behaviour of agents i.e. the protocols, the methods and the general behaviour of agents.

2.4.2 Activity Details

The flow of activities inside this phase is depicted in Fig. 38 and detailed in the following.

A14: Define Module View

This activity shows how the architectural designer maps the key elements of the software to the modules. Their organization and dependencies are defined. The following kinds of dependencies can be used: use, allowToUse, include/decompose, CrossCut, EnvModel. The flow of this activity is depicted in Fig. 40.

Fig. 40

Flow of tasks of the Define Module View activity

A15: Study Communication Acts

This activity aims at making clear interactions between the entities and/or the agents previously identified. The flow of tasks inside this activity is depicted in Fig. 41, and the tasks are detailed in the following table.

Table 14

A16: Define Entity Behaviour

The aim of this activity is to define the entity behaviour. It can be illustrated by an inner state related to its current role. This activity is performed by an MAS analyst. The flow of this activity is depicted in Fig. 42.

Fig. 41

Flow of tasks of the Study Communication Acts activity

A17: Define Nominal Behaviour

The purpose of this activity is to define the nominal behaviour. The AMAS designer has to define skills, aptitudes, an interaction language, a world representation and a criticality, which compose the nominal behaviour. Agents may also have physical characteristics such as weight, colour, etc. which may be necessarily found during this activity. The structural diagrams of agents are drawn and the structural rules are described. In addition, an agent can be defined by an inner state related to its current role in the MAS organization. The flow of tasks inside this activity is depicted in Fig. 43, and the tasks are detailed in the following table.

Table 15

Fig. 42

Flow of tasks of the Define Entity Behaviour activity

Fig. 43

Flow of tasks of the Define Nominal Behavior activity

Fig. 44

Flow of tasks of the Define Cooperative Behavior activity

A18: Define Cooperative Behaviour

This activity is a key step. Indeed, the AMAS designer defines the cooperative behaviour by the allocation of cooperation rules. These rules enable an agent to have a cooperative attitude i.e. anticipate or detect and repair the non-cooperative situations. During this activity, the structural diagram is completed by appropriated skills, representations, the attitudes or any other agent characteristic. The flow of tasks inside this activity is depicted in Fig. 44, and the tasks are detailed in the following table.

Table 16

Fig. 45

Flow of tasks of the Validate Design Phase activity

A19: Validate Design Phase

During this activity, the AMAS designer may test the behaviour of the agents. This test can lead to improve an agent’s behaviour if it is not adequate. The flow of tasks inside this activity is depicted in Fig. 45, and the tasks are detailed in the following table.

Table 17

2.4.3 Work Products

The Design Phase generates six work products. Their relationships with the MAS metamodel elements are depicted in Fig. 46.

Work Products Kind

Table 18

Fig. 46

The design documents structure

Fig. 47

Paper agent structural diagram

Example: Conference Management Study

In this section where the phase settles the design of the software architecture of each agent and entity, we only describe the paper agent behaviour. Actually, its skills, its aptitudes, its interaction language and its representations are depicted in Fig. 47. Figure 48 represents an inner state related to the current state of the paper agent. The nominal behaviour of a paper agent starts in a Submitted state which corresponds to the creation of a paper agent. In this state, the paper agent is looking for reviews. It is in IsReviewing state when it finds all reviews it needs. It becomes Reviewed when all its reviews are complete. In order to reach the following state, Accepted or Rejected, the paper agent self-evaluates the reviews’ results and changes its state. If the paper agent is Accepted, it informs the session of its state and becomes IsImproving. Finally, the paper agent is Printed when the proceedings are published.

Moreover, this cooperative agent can meet some non-cooperative situations. For a paper agent, two situations are detected: (1) a review can be linked to a limited number of papers; it can happen that several paper agents want the same review; (2) when the paper agents have to deal with the acceptance, they can be put in concurrence or competition.

Fig. 48

Inner state related to paper agent behaviour

2.5 Implementation Phase (WD5)

The Implementation Phase aims at providing the desired system. Actually, the aspects of the detailed architecture are first described using SpeADL, then implemented using the Java programming language by relying on code generated from the ADL, and finally executed to deliver the desired system. The process flow at the level of activities is depicted in Fig. 49, and Fig. 50 depicts this phase according to documents, roles and work products involved.

2.5.1 Process Roles

Two roles are involved in the Implementation Phase: the AMAS Framework Developer, and the AMAS Developer.

• AMAS Framework Developer: An AMAS framework developer is responsible for the description of the system architecture in the SpeAD (Species-based Architecture Description) model language during the Implement Framework activity and the implementation of everything that is not an agent. Actually, the AMAS framework developer implements the passive entities, the active entities and all programs required by the system such as a scheduler.

• AMAS Developer: An AMAS developer is responsible for the agent behaviour implementation during the Implement Agent Behaviour activity. He/she implements the nominal and cooperative behaviour according to the designed software architecture.

2.5.2 Activities Details

The flow of activities inside this phase is depicted in Fig. 49, and the tasks are detailed in the following table.

A20: Implement Framework

During this activity, the mechanisms are software components with provided and required services that can be composed together to form the architecture of the system. Entities and agents’ architecture is therefore described in terms of components. The architecture is described using the textual architecture description language SpeADL (Species-based Architecture Description Language). Then the architectural elements which are not a cooperative agent are implemented. The flow of tasks inside this activity is depicted in Fig. 51, and the tasks are detailed in the following table.

Table 19

Fig. 49

The implementation phase flow of activities

Fig. 50

The implementation phase described in terms of activities and work products

Fig. 51

Flow of tasks of the Implement Framework activity

A21: Implement Agent Behaviour

During this activity, the behaviour of the cooperative agent is implemented. The flow of tasks inside this activity is depicted in Fig. 52, and the tasks are detailed in the following table.

Table 20

Fig. 52

Flow of tasks of the Implement Agent Behaviour activity

2.5.3 Work Products

The Implementation Phase generates two work products. Their relationships with the MAS metamodel elements are depicted in Fig. 53.

Work Products Kind

Table 21

Fig. 53

The implementation documents structure

Example: Conference Management Study

Figure 54 is a graphic description of an SpeADL. This architecture defined with SpeAD is made of components connected together with simple connectors. The components externally provide ports, for which they have an implementation, and require ports that they can use in their implementation. Note that the description of components made with SpeADL will then be translated to Java.

Fig. 54

Architectural description of paper agent

Fig. 55

The work products dependencies

3 Work Product Dependencies

Figure 55 depicts the dependencies among the different work products produced by the process. A dashed arrow is used to relate two of them if one is an input document to the other. Its direction points from the consumer document to the input one.