Dounia Boufedji

Zahia Guessoum

Anarosa Brandão

Tewfik Ziadi

Aicha Mokhtari

Towards a MAS Product Line Engineering Approach

Keywords: Software Product Line Engineering, Software Engineering Reuse, Feature Model, Variability

It is our claim that the adoption of software engineering reuse techniques can leverage MAS development, mostly when we consider similar applications belonging to the same domain. MAS-Product Line (MAS-PL) raises as an interesting approach that uses Software Product Line Engineering (SPLE) techniques and AOSE to manage the commonalities (similarities) and variabilities (differences) of such MAS applications. Although MAS present specific characteristics that could be considered when describing the system variability, existing work on MAS-PL is devoted to deal with MAS variability considering only domain-specific issues. Moreover, the adoption of variability models such as feature models should be considered for describing both Generic and Specific MAS variability. We propose a MAS-PL approach to address the aforementioned issues by representing Generic MAS variability according to MAS concepts such as agents, environment, interaction and organization, and Specific MAS variability according to a specific application domain. We evaluate the approach by deriving a family of agents that perform jobs in the Multi-Agent Contest environment.

Introduction

Multi-Agent Systems (MAS) provide an interesting approach for developing software systems in several domains such as resource and information management, process control and simulation of complex systems. Nevertheless, since engineering MAS is a complex task that is not entirely controlled by a process which is accepted by the software industry, MAS are still not part of the mainstream of enterprise application development [START_REF] Guessoum | Roadmap of agent-oriented software engineering[END_REF]. In this paper, we propose to introduce a new MAS-PL approach to improve the reuse during MAS development.

AOSE provides several templates and reuse patterns to facilitate MAS development [START_REF] Cossentino | Introducing pattern reuse in the design of multi-agent systems[END_REF][START_REF] Hara | Reusable software components based on an agent model[END_REF] and speed up the MAS adoption in software industry. However, most existing AOSE approaches are not suited to the development of similar applications (a.k.a MAS families). These kinds of applications present similarities (i.e. commonalities) and differences (i.e. variabilities).

Indeed, managing such applications remains a difficult task because even if the core architecture is reusable, the variability management is mainly achieved by making code changes.

As the facts mentioned above lead to a considerable waste of time, cost and effort, and make the MAS implementation a difficult task, it is important to provide a solution based on the idea of capitalizing the MAS implementation expertise. Thus, managing MAS variability in MAS families is a key solution to such a capitalization, and has become one of the main challenges in AOSE. SPLE comes out as an interesting solution to manage MAS variability at different levels such as in design models, implementation of agents and so on. It provides a solution to speed up industrial adoption of MAS, and leverages such an adoption [START_REF] Peña | Multi-agent system product lines: challenges and benefits[END_REF].

Several MAS-PL approaches have been proposed [START_REF] Ayala | Using models at runtime to adapt self-managed agents for the iot[END_REF][START_REF] Dehlinger | Gaia-PL: A product line engineering approach for efficiently designing multiagent systems[END_REF][START_REF] Nunes | Developing multi-agent system product lines: from requirements to code[END_REF][START_REF] Nunes | Extending PASSI to model multi-agent systems product lines[END_REF] to apply SPL concepts to MAS development. Those MAS-PL approaches introduce the notion of variability for a reuse issue within a MAS family. They are often built as an extension of existing methods, what make them easily adopted. However, most existing approaches introduce different notations and stereotypes to specify variability, what concerns only specific domains.

It is our claim that a MAS-PL approach should address both the variability concerning a specific application domain, and the variability referring to the MAS domain, which concerns MAS concepts that emerge from MAS metamodels and tools.

In addition, we believe that specifying variability by using only variability models (e.g. feature model) is more interesting than using a variety of models (e.g. roles' variation model) or introducing new notations (e.g. extensions of MAS design models) for the same purpose. Example of that is proposed by Peña et al. [START_REF] Peña | Building the core architecture of a nasa multiagent system product line[END_REF], where three kinds of models are used to specify variability: feature model, roles variation model, and plans variation model. In our view, roles and plans variation could be specified using a single variability model, such as a feature model.

We propose a new MAS-PL approach that follows the general SPLE Framework [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF]. This approach relies on two types of features (resp. two types of reusable artifacts): the Generic MAS features (resp. artifacts) and the Specific MAS features (resp. artifacts). This will concretely serve to promote different types of reuse in MAS.

Those features result from a refinement process that is based on a variability analysis of distinct domains. Generic MAS variability analysis scopes the domain of existing MAS methods, meta-models, architectures and tools, while Specific MAS variability analysis scopes a specific application domain.

This paper is organized as follows: Section 2 presents a background, dealing with MAS-PL related work and motivations. Section 3 gives an overview of our MAS-PL approach; while Section 4 and Section 5 give more details about the approach and illustrate it with simple examples of the multi-agent contest case study. Section 6 describes and discusses some results about the evaluation of our approach through the multi-agent contest product line. Finally, Section 7 summarizes the contributions and proposes some perspectives for future work.

2 Background and Related Work Domain Analysis allows to scope the domain (which products should be covered by the product line), and to specify the relevant features that should be implemented as reusable artifacts. The results of domain analysis are usually documented in a Feature Model (FM) [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF]. The FM describes features and their relationships (parent-child) in a hierarchical tree. Features express the commonality and variability among the products within a product line (see examples in Fig. 3).

Domain Implementation allows to develop reusable artifacts that correspond to identified features. There are many kinds of relevant artifacts in SPLE (including implementation, test, and documentation artifacts) [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF].

Requirement Analysis considers a user's requirements to produce a customized configuration, by selecting the desired features.

Product Derivation aims at deriving the product according to the configuration provided by the requirement analysis.

Related Work

MAS-PL approaches emerged from the idea of applying SPLE approaches into AOSE ones. The first efforts on MAS-PL arose on the mid of the 2000's first decade. Peña et al. [START_REF] Peña | Multi-agent system product lines: challenges and benefits[END_REF] argue that both AOSE and SPLE approaches are based on similar concepts in the first activities of domain engineering. For instance, both of them use models in the domain analysis activity: SPLE uses feature models and AOSE uses MAS meta-models. Unlike AOSE, SPLE covers common and variable features analysis of the software family. Most existing AOSE approaches do not consider implementation activity, while SPLE also relies on implementing reusable assets.

MAS-PL approaches differ according to the SPLE phases they cover: Domain and Application Engineering. Most approaches propose to extend AOSE methods by integrating SPLE concepts and techniques.

In this context, Dehlinger et al. [START_REF] Dehlinger | Gaia-PL: A product line engineering approach for efficiently designing multiagent systems[END_REF] propose Gaia-PL to extend GAIA. They provide requirement specification pattern to capture changing design configuration (variation points) in agents and potential reuse of requirement specification; with no detail about the domain implementation activity.

Nunes et al. [START_REF] Nunes | Developing multi-agent system product lines: from requirements to code[END_REF][START_REF] Nunes | Extending PASSI to model multi-agent systems product lines[END_REF] propose to extend PASSI [START_REF] Cossentino | From requirements to code with the passi methodology[END_REF], to cover the whole development process from requirements to code. They endow PASSI's UML models with stereotypes to model and document agent variability, and they propose implementation guidelines to help MAS developers. Moreover, they propose the modularization of the fine-grained variability (agent architecture) allowing a better specificity of the features [START_REF] Nunes | A case for new directions in agent-oriented software engineering[END_REF]. For instance, they introduce decomposition of the goals that gives more specific plans. Although the decomposition of goals ensures alternative or optional features, reuse is only possible for a specific domain application.

Peña et al. [START_REF] Peña | Building the core architecture of a nasa multiagent system product line[END_REF] propose to enrich MaCMAS (Methodology for analyzing Complex Multi-Agent Systems) with software product lines to model and evolve MAS. They use UML to model a MAS-PL and focus on building the core architecture (common features). MaCMAS captures views of the system at different abstraction levels. The core architecture of the system is represented by a traceability model, and a set of role models. The model is evolved with variations and constraints. They specify the commonality and variability in a feature model.

MAS-PL approaches that cover the Application Engineering phase propose mainly MAS derivation approaches that extend derivation tools like in [START_REF] Cirilo | Automating the product derivation process of multi-agent systems product lines[END_REF] where they propose to use multi-level models to support the configuration knowledge specification and automatic product derivation of MAS-PL.

Among MAS-PL approaches that cover both SPLE phases, SelfStarMAS proposes a process for the development of self-adaptive agents in Internet of Things (IoT), and extends it by a Dynamic SPL based approach, that presents the advantage of behaviour agent adaptation at runtime [START_REF] Ayala | Using models at runtime to adapt self-managed agents for the iot[END_REF]. The approach is interesting, but remains specific to IoT domain.

Even though many approaches have been proposed, some limitations can be clearly identified:

-The use of multiple notations and stereotypes in UML diagrams to model variability is more difficult to adopt than using feature modeling notations only, what is more recommended by the SPLE [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF]; -Using colors while introducing crosscutting features and spreading variability specification along different kinds of models may prevent their adoption, since any change on features must be propagated to all models; -Some approaches focus on building the core architecture of MAS families and neglect variabilities. Some others focus on the domain analysis activity and do not give details on the domain implementation; -Reusing feature models and artifacts, when developing a new family of applications, is unfeasible since the specified variability is domain-specific in all approaches.

As a solution to those limitations, we propose a new MAS-PL approach with one category of variability models: feature model; and two kinds of features: generic MAS features and application specific features. In the next section, we introduce our MAS-PL approach.

Overview of our MAS-PL approach

Our approach proposes to develop MAS families by following the general SPLE framework [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF] and reusing MAS concepts (see Fig. 2).

Our approach splits the Domain Analysis (resp. Domain Implementation ) activity of the domain engineering phase into two activities: 1) Generic MAS domain analysis (resp. Generic MAS domain implementation) and 2) Specific MAS domain analysis (resp. Specific MAS domain implementation). This distinction between Generic MAS domain and Specific MAS domain aims at capitalizing the expertise of using MAS methods, models and implementations, by reusing both Generic MAS features and Domain specific ones.

First, during the Generic MAS domain analysis activity, we analyze the MAS knowledge in terms of generic MAS concepts which are involved in MAS approaches like GAIA [START_REF] Cernuzzi | The gaia methodology[END_REF], and PASSI [START_REF] Cossentino | From requirements to code with the passi methodology[END_REF]. Then, we represent Generic MAS concepts in terms of commonalities (similarities) and variabilities (differences) among MAS approaches, organized so that they refer to Agent, Environment, Interaction and Organization features. Our approach relies on AOSE methods, to enable reusing most common concepts and assets, and to provide flexibility to MAS designers and developers by using the features they need. For instance, the Role concept that is provided by GAIA [START_REF] Cernuzzi | The gaia methodology[END_REF], PASSI [START_REF] Cossentino | From requirements to code with the passi methodology[END_REF] and AGR [START_REF] Ferber | From agents to organizations: an organizational view of multi-agent systems[END_REF] can be placed as a child-feature component of the Organization feature. To illustrate the activity, we analyze the belief-desire-intention (BDI) model [START_REF] Georgeff | The belief-desireintention model of agency[END_REF], some organizational models like Moise+ [START_REF] Hübner | Moise+: towards a structural, functional, and deontic model for mas organization[END_REF], and so on. This activity produces a Generic MAS FM.

Second, Specific MAS domain analysis activity documents similarities and variabilities among the members of a specific MAS family. We illustrate this activity with the multi-agent contest example 1 . This activity produces a Specific Fig. 2. Overview of our MAS-PL approach MAS FM. Unlike existing MAS-PL approaches that build MAS specific FM from scratch, our approach proposes to build it by reusing the Generic MAS FM.

Third, Generic MAS implementation activity involves implementing Generic reusable MAS artifacts, that do not rely on any specific MAS family. They implement Generic MAS features and are composed of Agent, Environment, Interaction and Organization artifacts. Those artifacts often come from existing tools and frameworks.

Finally, Specific MAS implementation activity produces Specific MAS reusable artifacts. Specific MAS implementation relies on Generic MAS implementation. Artifacts are adapted to the specific MAS family.

Application engineering activities concern both MAS requirement analysis and derivation. According to the MAS requirements, MAS variants are specified by selecting a valid configuration from the Specific MAS FM. The specified product that represents the MAS application variant is then derived. As we are interested in Composition-Based implementation approaches [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF] instead of Annotation-Based ones, we need a Composer to derive the product. This derivation activity is done by FeatureHouse composer [START_REF] Apel | Language-independent and automated software composition: The FeatureHouse experience[END_REF] that generates MAS variants automatically by composing reusable artifacts. We illustrate our approach by Contest Agent Variants based on configurations produced during the Application Engineering phase.

MAS Domain Engineering

This section describes the proposed domain engineering phase based on activities and their outputs.

Generic MAS domain analysis

In this first activity, we analyze MAS models' commonalities and variabilities to build the Generic MAS FM which is a compact representation of MAS concepts. We therefore define the features that are often shared by MAS applications.

Our idea is to produce a common FM (see Fig. 3) based on that generic representation and to use the Vowels paradigm [START_REF] Demazeau | From interactions to collective behaviour in agent-based systems[END_REF] to organize these features. The Vowels paradigm considers that MAS are composed of (1) Agents (Vowel A), which refers to the description of internal architectures of the system processing entities; (2) Environment (Vowel E), which refers to domain-dependent elements for structuring external interaction among the system entities; (3) Interaction (Vowel I), which refers to elements for structuring internal interaction among the system entities; and (4) Organization (Vowel O), which refers to elements for structuring entities within the MAS. We do not include the User (Vowel U) dimension that is considered in the Vowels extension to explicitly take into account the user. Agent features: Agent architectures provide solutions to structure agents and define their functionalities in order to enable them to act and to interact in a dynamic environment. Most existing architectures follow the perceptionaction loop. We thus propose three categories of features: Perception, Architecture (Internal Architecture) and Action. For the Internal Architecture, we consider both categories: Reactive and Deliberative [START_REF] Ferber | Multi-agent systems: an introduction to distributed artificial intelligence[END_REF]. While deliberative agents follow Perception-Deliberation-Action cycle, reactive agents follow Perception-Stimulus-"Re"action one. Hybrid architectures can also be defined by combining the previous ones (selecting both Deliberative and Reactive features).

Deliberative agents need a knowledge model to provide them a representation about their environment, and their own knowledge. The Knowledge representation feature represents knowledge representation such as Belief and Ontology.

The BDI model [START_REF] Georgeff | The belief-desireintention model of agency[END_REF] includes three mental attitudes: Beliefs, Desires and Intentions. Whenever the agent has a BDI architecture, all of Belief, Goal, and Plan features are mandatory.

The Utility feature of our Generic MAS FM represents an option used to endow Goal Based agents with an utility measure for evaluating the level of success when reaching the goal, to obtain Utility Based agents.

Environment features: Agents are situated in an environment that used to be domain dependent and generally spatial. That environment represents many aspects that conceptually do not belong to agents themselves such as in a software infrastructure on which the MAS is deployed, or in a representation of physical environment. City maps used for situated agents can be mentioned as an example. We represent the agent Environment product line by two environment features: the Deployment Environment which is mandatory and the optional Physical Environment since the physical world is not always represented in MAS.

Interaction features: Interaction provides a way to ensure coordination of agents' activities. Agents' interaction can be Direct or Indirect. In direct interaction, agents exchange messages to coordinate their behaviour and achieve the global goal. In indirect interaction, agents use the environment to share information and coordinate their actions. For example, ants use the pheromone to coordinate. In this paper, we focus only on direct interaction that is regulated by interaction protocols. The Interaction protocol feature is therefore mandatory. Interaction protocols were introduced into MAS to facilitate the specification and the implementation of interaction between agents. According to FIPA2 definition, an interaction protocol is a common pattern of communication (a predefined sequence of messages). Thus the specification and the implementation of the Protocol could be independent of the scope and of the agent internal architecture. Several interaction protocols have been proposed: request protocol, bargaining, auction and Contract Net Protocol (CNP), among others. Our Generic MAS FM includes some of them with a possible feature selection.

Organization features: In MOISE+ model [START_REF] Hübner | Moise+: towards a structural, functional, and deontic model for mas organization[END_REF], the organization is seen under three points of view: Structural, Functional, and Normative. We propose to model the MAS Organization product line by the root Organization feature that includes two-child features: the norm optional feature; and the mandatory structure feature to represent all possible organization structures.

Ferber et al. proposed the first organizational model Agent-Group-Role (AGR) [START_REF] Ferber | From agents to organizations: an organizational view of multi-agent systems[END_REF], to highlight the importance of organizational concepts like 'groups'. The Role concept is used in most existing MAS organizational meta-models while the Group concept is used only in some of them such as AGR and AGRE [START_REF] Ferber | AGRE: Integrating environments with organizations[END_REF]. So, the Group feature is optional while the Role feature is mandatory.

The last mandatory feature that concerns the structure is the Topology, that has two alternative child features: Centralized and Decentralized organizations described with other child features.

Specific MAS domain analysis

During this activity, we analyze MAS commonalities and variabilities of a specific MAS family (e.g. Multi-Agent Contest) to produce a Specific MAS FM to refine the Generic MAS FM. The refinement process is achieved by adding Specific features to solve the problem. These specific features are placed hierarchically under the generic features they are specializing. We propose as an example, the Multi-agent Contest specific domain in order to illustrate the rest of the activities of our approach. We will refer to Specific MAS features as Contest MAS features. Contest agents' teams move around the streets of a realistic city, having the goal of earning money by completing jobs. Teams should then decide how to navigate on the city map, and where to get the resources to assembly, buy and deliver items considering targets like shops, warehouses, charging stations, and storage facilities. Tournament points are distributed according to the amount of the money a team owns at the end of the simulation. For instance, since the provided Contest environment is mandatory, the Contest mandatory feature cityMap should be added to Contest features. After, the corresponding Generic MAS feature is refined. The result is presented in Fig. 4 on (c) where cityMap refines the Physical Environment feature. Another example represented on (a) concerns Agent variability. The specific BuyItem Goal feature refines the Mono Goal for specific items acquisition goal. This first version of the Specific MAS FM represents the simplest one, and considers only agents that achieve one goal. But, as our approach is incremental, this simplest version of the Specific MAS FM can be also refined in turn. The left side of Fig. 5 depicts another version of the Specific MAS FM which refines the simplest one. This refinement allows to support other versions of agents. For example, both of DeliverItem Goal and Charging Goal Contest specific optional Features refine the generic Multi Goal feature by specifying agents that have to achieve items delivering and charging goals. When considering other generic variabilities such as Organization ones, the process remains the same. The last example (see Fig. 4 on (b)) proposes possible roles of the organization of a team in Contest. This aspect considers the structural point of view of the organization, and is relative to the Structure feature. Thus, the Role generic MAS feature is refined by Contest specific roles such as Buyer and Carrier that will take part in all Contest Team Variants. While TruckGroup feature is an option to consider groups' organization.

Generic MAS Implementation

The following activity concerns the Generic MAS reusable artifacts implementation. The MAS implementation is often based on existing frameworks. Artifacts correspond to components provided by those frameworks. In this paper, we consider APLTK (A Toolkit for Agent-Oriented Programming) [START_REF] Behrens | Towards Building Blocks for Agent-Oriented Programming[END_REF] to illustrate the feasibility of the approach in the implementation side. The set of reusable artifacts can be then enriched by considering other frameworks such as JaCaMo [START_REF] Boissier | Multi-agent oriented programming with jacamo[END_REF].

Agent artifacts: Agent reusable artifacts implement Agent features. Although we could not raise variability concerns related to Belief, both Goal and Plan can present variability depending on the choosing BDI algorithms.

The three algorithms we use to illustrate our approach are those proposed by Wooldridge [START_REF] Georgeff | The belief-desireintention model of agency[END_REF]. The variability among these algorithms lies on the cardinality of the sets of B, D and I. The first algorithm represents the simplest version. It corresponds to mono-Goal agents. While the second algorithm concerns agents that have to achieve multiple goals. The last algorithm proposes to enrich the library of plans during the execution.

Goal and Plan variabilities can then be expressed by the following features: Mono Goal, Multi Goal, Mono Plan and Multi Plan.

Most BDI model implementations use brf (belief revision function), ogf (option generation function), filter and asf (action selection function). However, the algorithm variability has an impact on these functions. For instance, if we consider BDI Mono Goal implementation, agents use neither the ogf function nor the filter one. Mono Plan agents do not need a function to select a plan.

We implement the Mono Goal feature with reusable artifacts, composed of the functions proposed in the simplest algorithm of Wooldridge [START_REF] Georgeff | The belief-desireintention model of agency[END_REF] : (i) getting-Percepts(): to execute the get-next percept, (ii)createBeliefsFromPercept(): to create and update the agent beliefs, it represents the brf() function; (iii)checkAll-BeliefsForInsertGoal(): for the agent deliberation to correspond to the deliberate() function, and (iv)performActionGoal(): to select a plan and execute it.

Environment artifacts: The general view of the environment considers that agents are part of the environment, which can provide for example means or resources for agent communication. However, environment standardization should be done by separating both concepts. Behrens et al. [START_REF] Behrens | Towards an environment interface standard for agent platforms[END_REF] proposed a generic approach for connecting agents to environment, and considered reusable environment artifacts that are as much independent of a specific environment structure as possible. For example, we reuse EIS (Environment Interface Standard) API [START_REF] Behrens | Towards an environment interface standard for agent platforms[END_REF], that represents possible reusable environment artifacts, which are mapped to the Physical Environment feature. EIS reduces the implementation effort for connecting to the environments (e.g. Unreal Tournament UT3 and UT2004 gaming environments, and the Multi-Agent Contest).

Interaction artifacts: The reusable Interaction artifacts concern mainly the Interaction protocols. FIPA standard Interaction artifacts are available to the programmer through abstractions to develop FIPA-compliant MAS. Some reusable FIPA implementations are provided by MAS frameworks such as the CNP implementation in JADE. Thus, we reuse JADE API3 that includes role behaviors for FIPA standard protocols. For example, the CNP-Initiator implements the initiator role in a FIPA-Contract-Net or Iterated-FIPA-Contract-Net, while the CNP-Participant corresponds to the responder role. These two implementations are mapped to the CNP feature.

Organization artifacts: Some concepts of the Generic MAS FM which are linked to the organization such as Roles may be implemented by reusable artifacts at the implementation level. For instance, in JADE API, the classes implementing the behaviours can represent roles that are reusable.

Specific MAS Implementation

During the last activity of Domain Engineering, Specific MAS reusable artifacts implement Specific MAS features by reusing Generic MAS artifacts.

MAS Application Engineering

This section will present application engineering activities, and illustrate them with Contest Agent configuration and derivation.

Requirement Analysis

During this activity, to obtain customized MAS, each requirement is analyzed to detect which features have to be selected from the Specific MAS FM, to fill that requirement and constitute a configuration.

Table 1 gives some examples of Contest requirements. The first requirement that corresponds to the Contest Agent Variant CAV1, is fulfilled by the given configuration presented on (a) in Fig. 6. All selected features are represented on (b) through a set of literals. Consequently, the non selected features are excluded from the configuration. The other requirements correspond to Contest Team Variants that consider some organizational aspects. For instance, unlike CTV3, to fill the requirements of CTV1, we must include features such as the Non Hierarchical feature, and exclude others such as the Hierarchical one.

Product Derivation

For a valid configuration, the MAS variant derivation activity is automatically achieved by a composer, such as FeatureHouse.

Fig. 6 gives on (c) the derived code relative to the configuration on (a). For more details, interested readers can access our link 4 . A Car Contest Agent Variant that has to achieve one goal, by executing an acquisition job (buying items in a shop). The agent has no charge utility concerning its battery, and has to execute one Plan (find a shop, move to it, and buy the items) CTV1

A Contest Team Variant (CTV) that looks only for priced jobs. The team is organized according to a non hierarchical topology without including groups structures. CTV2

A Contest Team Variant that looks only for priced jobs. The team is organized according to a non hierarchical topology, with the possibility of structuring into groups of cars and trucks. The groups are supervised by group supervisors. CTV3

A Contest Team Variant that looks for both priced and auctioned jobs, and that is organized according to hierarchical topology without including groups structures. CTV4

A Contest Team Variant that looks for both priced and auctioned jobs, and that is organized according to hierarchical topology, with the possibility of structuring into groups of cars and trucks. The groups are supervised by group supervisors.

Table 1. Examples of multi-agent Contest requirements

Evaluation

Evaluation objectives: The main objectives of our evaluation are to show the feasibility of our approach to derive MAS variants and to deduct the rate of reuse improvement our approach brings. In order to evaluate our approach, we first derived several Contest Agent Variants and deployed them in the MAS Contest environment. Second, we involved groups of students to derive Contest Agent Variants by following the SPLE framework without relying on the generic MAS features and artifacts that we proposed. After, we compared students' Contest feature models and implementations with ours.

Contest Agent Variants derivation:The implementation of our approach adopted the Feature IDE tool5 to specify the feature models, and to create agent configurations. FeatureHouse composer was used to derive Contest Agent Variants.

The first version of the product line involves neither interaction nor organization aspects of the team, and considers only agents that have to complete their priced jobs. More details are available on the Contest website under the Contest 2016 example 6 .

The case study offers more than 5948 possible configurations, as shown on the upper left side in Fig. 6. We present among them ten [START_REF] Cossentino | Introducing pattern reuse in the design of multi-agent systems[END_REF] CAV1 and CAV2 have the minimal feature configurations that involve a total of six mandatory features. CAV1 corresponds to the simplest agent (see Fig. 6). CAV3 to CAV10 represent variants with a maximum number of eight possible selected features. These variants follow the second BDI algorithm [START_REF] Georgeff | The belief-desireintention model of agency[END_REF]; and differ on their charging utilities. According to those variabilities, more or less methods and lines of code are derived. We calculate them by using eclipse Metrics 7 .

The percentage of reused features and methods show the two main advantages of our approach. Indeed, the originality of our approach is the possibility to reuse Generic MAS features and artifacts. The percentage of reused features ranges from 25% to 33 %, while the percentage of reused implemented methods ranges from 7% to 10.18 %.

The above results correspond to the rate of reuse improvement our approach offers. The results show also the advantage of using software product lines in our approach. There is a development time saving of about 354 lines of code, and 25 methods from CAV1 to CAV10. We can also compare variants according to their strategies using utilities. Indeed, when using our approach, we can compare Contest agents performances easily since the agents are derived automatically and can be deployed faster. For example, through simulations, we could distinguish between the best and the worst charging utilities. We could also make the agents variants play together.

The second version of the product line involves some interaction and organization aspects of the team. Due to space restrictions we did not include the table. The product line includes four variants labeled from CTV1 (Contest Team Variant) to CTV4. Their configurations correspond to the requirements presented in Table 1. The results show a feature reusing rate that ranges from 27.27 % to 30.76%. These variants which consider organization and interaction features presents a higher rate of reused features compared to the agent variants presented above.

Involving students: Groups of students were involved in this activity. None of the groups was familiar with SPL concepts. The students were asked to model, implement and derive Contest multi-agent variants by following the SPLE framework that we use in our approach. However, we did not provide them the starting points proposed by our approach, to compare their results with the ones we obtained by relying on both generic MAS FM and artifacts. As a result, we could distinct three categories of groups: CAT1, CAT2 and CAT3.

CAT1 represents groups that failed on detecting domain-independent variability. The category presents the worst results regarding Contest Agent Variants. Indeed, 44.44 % of the students belong to this category.

The students focused only on domain specific variability, what let them build only domain specific features and artifacts.

CAT2 includes groups that detected domain-independent variability, but did not include it in the feature model. It presents a rate of about 33.33 %. This intermediate category succeeded in detecting reusable generic MAS features, but did not exploit them in the feature model. For example, they thought about MAS organizational variabilities such as centralized or decentralized organizations; but did not consider these aspects in possible configurations.

CAT3 concerns groups that detected domain independent variability and introduced it in the feature model. It was the most successful category, but it represents the lowest rate of 22.22 % of the students.

However, the total number of reusable features does not exceed eight, and include Interaction and Organization features.

The results brings out the advantages of our approach. It can provides CAT1 a starting point to support domain-independent variability. Moreover, it allows CAT2 to exploit the detected features to derive more multi-agent variants. In addition, it provides CAT3 more reusable features and artifacts than those detected. Our approach provides to all categories more possible configurations, which implies more variants.

All these facts lead to increase the number of Contest Agent Variants, save time and effort to the whole categories through the whole process.

Our MAS-PL approach uses of known notations covering both design and implementation aspects, what would facilitate its use and its adoption by MAS developers. Moreover, since it provides a generic MAS FM, MAS designers and developers will not build feature models nor develop the source code from scratch.

However, our approach has some limits. Indeed, it does not consider all organizational artifacts, most variability is specific to contest and the total number of reusable artifacts which should be increased.

But, we prospect to enrich our work with a more refined MAS variability. Currently, we are studying self-organizational aspects of the system. We also prospect to evaluate our approach through other specific domains. We project to evaluate it by students as well.

Conclusion

In this paper, we proposed a first version of a new MAS-PL approach for the automatic derivation of MAS variants according to MAS requirements. Our MAS-PL approach follows the SPLE framework in both domain and application engineering phases. It relies on two types of features (resp. two types of reusable artifacts): the Generic MAS features (resp. artifacts) and the Specific MAS features (resp. artifacts). The features of the Generic MAS feature model and those of Specific MAS feature model are organized according to the Vowels paradigm.

Our MAS-PL approach deals with known notations and covers both the design and implementation aspects. So, it is easy to use by MAS developers. Moreover, it is incremental, the Specific MAS FM can be refined as many times as needed to deal with more specific MAS variability.

We illustrated the different activities of our MAS-PL approach by simple examples issued from the Multi-Agent Contest 2016. We derived a Contest product line of agents that includes variants that have been simulated in the Multi-Agent Contest environment. We compared those variants according to some metrics. The result shows that our approach is promising. We also compared these results to those obtained by students without using the Generic MAS features and arti-facts we proposed. This comparison brought out the value of our Generic MAS features and artifacts in practice.

As for further on-going research work, we are concentrating on an interesting perspective which would allow us to obtain more variability to enrich both Generic MAS FM and artifacts. We intend, for instance, to introduce interaction mechanisms such as ant-based algorithms. We also prospect to evaluate our approach by groups of students to compare their results to those presented in this paper. Another perspective is to suggest to researchers and MAS developers to use our approach when implementing Multi-Agent System Product Lines in different domains. The feedback would help us improve our work to serve the technological development and advances.

2. 1

 1 Software Product Line Engineering framework SPLE represents one of the most interesting paradigms in software reuse and development. It reconciles both production and standardization with customization in software engineering, and it considerably reduces development cost, time and effort. The general SPLE framework proposed by Apel et al. [1] is represented in Fig. 1 with its two levels: Domain and Application Engineering. The framework includes four activities: domain analysis, domain implementation, requirement analysis, and product derivation.

Fig. 1 .

 1 Fig.1. SPLE Framework and its main activities.[START_REF] Apel | Feature-Oriented Software Product Lines[END_REF]

Fig. 3 .

 3 Fig. 3. Generic MAS Feature Model

Fig. 4

 4 depicts three examples of possible Contest MAS FM. The two categories of features are separated by a red line. The examples show what MAS product line designers should do to refine the Generic MAS FM. However, before doing it, Contest MAS features should be detected by the domain variability analysis.

Fig. 4 .

 4 Fig. 4. Examples of the Contest Specific MAS FM that refines the Generic MAS FM: (a) Contest Agent refinement, (b) Contest Organization refinement and (c) Contest Environment refinement

Fig. 5

 5 summarizes the four activities of the Domain Engineering. It illustrates a Contest MAS reusable artifact which is at the right side bottom of the figure. This Contest artifact implements the BuyItem Goal Contest feature, by reusing the PerformActionGoal() function that is mapped to the Mono Goal feature.

Fig. 5 .

 5 Fig. 5. An example of a Contest MAS reusable artifact obtained through the four Domain Engineering activities

Fig. 6 .

 6 Fig. 6. An example of (a) a Contest Agent Configuration (b) its propositional expression and (c) the derived Contest Agent Variant

  of the derived and simulated Contest Agent Variants. The variants are labeled from CAV1 (Contest Agent Variant) to CAV10. Table 2 represents the relative configurations of each variant that includes both Generic and Contest MAS features labeled respectively GMF and CMF.

Table 2 .

 2 Some metrics for ten derived Contest Agents Variants

							MAS-PL Features
			GMF								CMF								Metrics
		F1 F2 F3 F4 F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13
	Contest Agent Variants	Mono Goal	Multi Goal	Mono Plan	Multi Plan	BuyItem Goal	Charging Goal	CallBreakDownService Goal	Item Plan	Charging Plan	CallBreakDownService Plan	No Charge Utility	BreakDown Utility	ClosestStationFromDestination	ClosestStationFromStartingPosition	ClosestStationWhenHalfEmpty	Car	Truck	Total selected features	Lines of code	Number of methods	% of reused features	% of reused methods
	CAV1 x		x		x			x			x					x		6 1506120 33	7
	CAV2 x		x		x			x			x						x 6 1565120 33	7
	CAV3		x		x x		x x		x		x				x		8 1523108 25 10.18
	CAV4		x		x x		x x		x		x					x 8 1654127 25	9
	CAV5		x		x x x		x x				x			x		8 1760130 25 8.46
	CAV6		x		x x x		x x				x				x 8 1799133 25 8.27
	CAV7		x		x x x		x x					x		x		8 1850133 25 8.27
	CAV8		x		x x x		x x					x			x 8 1821130 25 8.46
	CAV9		x		x x x		x x						x x		8 1815133 25 8.27
	CAV10		x		x x x		x x						x		x 8 1860133 25 8.46

https://multiagentcontest.org/

http://fipa.org/

http://jade.tilab.com/doc/api/

https://marketplace.eclipse.org/content/featureide

http://multiagentcontest.org

http://eclipse-metrics.sourceforge.net


Sara Casare
email: sjcasare@uol.com.br

Tewfik Ziadi
email: tewfik.ziadi@lip6.fr

F Brandão

Zahia Guessoum
email: zahia.guessoun@lip6.fr

Anarosa A F Brandão
email: anarosa.brandao@poli.usp.br

An Automated Approach to Manage MAS-Product Line Methods

Keywords: multiagent systems, software product line, variability, method

Introduction

Managing variability in Multiagent systems (MAS) has been identified during the last years as one of the main issues within Agent-Oriented Software Engineering (AOSE) [START_REF] Brandao | Vers une approche d'ingénierie multiagent à base de ligne de produits logiciels[END_REF][10] [18][19]. Indeed, the intrinsic properties of MAS, such as modularity, make them variability-rich systems. The notion of software variability is defined as the ability of a software system to be changed, customized or configured for use in a par-ticular context [START_REF] Van Gurp | On the Notion of Variability in Software Product Lines[END_REF]. Therefore, AOSE approaches should consider this variability to design and develop not only a single MAS, but families of systems at the same time. More than twenty AOSE methods have been proposed by the MAS community to support MAS development [START_REF] Casare | Medee Method Framework: a situational approach for organization-centered MAS[END_REF]. Each of them proposes a set of development activities for analyzing, designing, and implementing the typical MAS components: agents, environment, interaction, and organization [START_REF] Demazeau | From interactions to collective behavior in agent-based systems[END_REF]. Gaia [START_REF] Zambonelli | Developing multiagent systems: The Gaia methodology[END_REF] and Tropos [START_REF] Bresciani | Tropos: An Agent-Oriented Software Development Methodology[END_REF] are among the most popular AOSE methods. However, they only proposed to design and develop a single MAS variant at time. Especially, they do not propose in their initial definition any explicit activity to manage variability and develop families of systems rather than a single system. One promising approach for tackling this limitation has been already identified by the MAS community since the early 2000's through the concept of Multiagent System-Product Line (MAS-PL) [START_REF] Dehlinger | A product-line requirements approach to safe reuse in multiagent systems[END_REF]. Instead of considering a single MAS, MAS-PL aims to organize a family of multiagent systems according to their similarities (i.e., commonalities) and differences (i.e., variabilities) in order to build MAS customized according to specific needs. MAS-PL reuses concepts proposed by Software Product Line Engineering (SPLE), which is a systematic approach for variability management proposed by the Software Engineering community [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF] [START_REF] Clements | Software Product Lines: Practices and Patterns[END_REF].

Although already introduced into the AOSE community, there is still a lack of methodological support to implement MAS-PL. As we will see in Section 2, among the more than twenty AOSE methods, only few of them support the specificities of MAS-PL, e.g. Gaia-PL [START_REF] Dehlinger | Gaia-PL: a product line engineering approach for efficiently designing multiagent systems[END_REF], Peña et al [START_REF] Peña | Designing and managing evolving systems using a MAS product line approach[END_REF], and Nunes et al. [START_REF] Nunes | Developing multi-agent system product lines: from requirements to code[END_REF]. Nevertheless, in these methods the proposed extensions are very light and do not cover all Software Product Line activities. Moreover, they are tailored to develop MAS families in specific domains and may not be suited for MAS families in diverse domains.

This paper tackles the mentioned issues by proposing Meduse for MAS-PL, an automated approach that provides steady methodological support for MAS-PL development by integrating SPLE best practices with several existing AOSE methods. Indeed, this approach results from cooperation between AOSE and SPLE research teams: we capitalize all knowledge on SPLE activities in a way that such activities can be automatically incorporated into AOSE existing methods as a set of SPLE best practices in order to develop MAS families in diverse domains. The proposed approach follows Method Engineering techniques [START_REF] Brinkkemper | Method Engineering: Engineering of Information Systems Development Methods and Tools[END_REF] [START_REF] Harmsen | Situational Method Engineering[END_REF] and is built upon the Meduse framework [START_REF] Casare | Meduse: an Approach for Tailoring Software Development Process[END_REF]. To illustrate our approach we present a case study that shows how we can provide MAS-PL methods that take into account SPLE best practices to extend two popular AOSE methods, Gaia and Tropos.

The paper is organized as follows: Section 2 presents background and motivations. Section 3 presents our approach for dealing with method extensions to develop MAS-PL. Section 4 illustrates such an approach using a case study. Finally, Section 5 concludes this work and discusses future work.

Background and Motivations

In this section we present some basic notions related to SPLE and MAS-PL methods that are essential for understanding the main aspects of our approach, as well as a motivating example based on Tropos.

2.1

Multiagent System Product Line Methods MAS-PL methods reuse concepts of SPLE for MAS families' development. Before discussing existing MAS-PL methods, we will briefly introduce the general SPLE framework. Fig. 1 shows its four main activities -domain analysis, domain implementation, requirement analysis, and product derivation -organized in the Domain and Application Engineering levels, as well as in the Problem and Solution spaces [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF].

Fig. 1. Software Product Line Engineering general framework [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF] Domain analysis: This activity aims to define the scope of the problem to be tackled and explicitly specify commonality and variability between products that are included in the product line. The results of domain analysis are usually documented in a variability model. Several formalisms have been proposed to specify such a variability model. Among them, we distinguish Feature Model [START_REF] Kang | Featureoriented domain analysis (FODA) feasibility study[END_REF] and Decision Model [START_REF] Spc | Software Productivity Consortium Services Corporation[END_REF]. The former derives from the work on Feature Oriented Domain Analysis (FODA) [START_REF] Kang | Featureoriented domain analysis (FODA) feasibility study[END_REF], while the latter has its roots on the Synthesis method [START_REF] Campbell | An introduction to Synthesis[END_REF] [START_REF] Spc | Software Productivity Consortium Services Corporation[END_REF].

A feature consists of a distinctive user-visible characteristic of a software product line, used to represent identifiable functional abstractions that shall be present in the final product [START_REF] Kang | Featureoriented domain analysis (FODA) feasibility study[END_REF]. It usually encompasses commonalities and variabilities. A feature model describes relationships between features, and formally specifies which feature selections are valid. This is made by hierarchically organizing features in a tree, where edges are used to represent parent-child relationships (see next section, Fig. 3). These parent-child relationships could be of the following types: mandatory (the child feature must be present in a product whenever its parent appears); optional (the child feature may be present when its parent appears); alternative (exactly one child feature must be present when the parent feature appears); or (at least one child feature must be present whenever the parent feature appears). Moreover, a set of cross-branch constraints is used to indicate dependencies between features pertaining to different tree branches. Finally, in order to establish their consistency feature models can be described through a set of propositional formulas. Thus, a Satisfiability (SAT) solver tool can be used to determine the feature model consistency, i.e. if it will generate at least one valid product, or whether a given product is valid.

Decision Model is another way of modelling variabilities. In this kind of models, decisions describe the variabilities available in a product line, and specify the set of choices during product derivation. Therefore, taking a decision involves analyzing multiple options and then selecting those that better reflect the customers´ needs.

Domain Implementation: In this activity the commonalities and variabilities previously specified are developed as a set of reusable artifacts (also called assets) and organized according to the specified variability model.

Among the domain implementation approaches we can cite Delta-oriented Programming [START_REF] Schaefer | Delta-oriented programming of software product lines[END_REF][21], a compositional and modular approach to manage variability based on modifications applied to a core product, which is transformed into another variant of the product line by incrementally applying a set of delta modules that propose additions, removals, or alterations of elements. A condition is a propositional constraint attached to every delta module through a when clause and it determines for which features the specified modifications are to be carried out. Therefore, conditions create the connection between the modifications prescribed in delta modules and the features. A list of delta modules and attached conditions determines the modifications required to implement different products of the product line, as well as the order in which such modifications shall be applied. Indeed, such a list groups delta modules in ordered partitions and partitions can be partially ordered, i.e., while the order of partitions is fixed, deltas in the same partition can be applied in any order. Finally, the core product can be an empty product.

Requirement Analysis: During this activity needs of a specific customer are considered in order to select the required variabilities (e.g. feature selection), also called a configuration [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF]. Therefore, the variability model is instantiated according to the customer requirements.

Product Derivation: Once we have a selection of the required variabilities representing customer needs, the product derivation activity aims to generate (or derive) the product itself. As underlined by Apel et al. [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF], depending on the implementation approach this activity can be automated. For compositional approaches as Deltaoriented Programming, the idea is to use what is referred as composer to derive product variants.

Extending AOSE methods to support MAS-PL should consider the integration of the different SPLE activities discussed above. As mentioned early, there are just a few MAS-PL methods. Each of them extends particular AOSE method(s) to integrate SPLE activities. However, this integration is often partial and it only concerns some of the SPLE activities previously presented. For instance, Nunes et al. propose a Domain Engineering method to develop MAS-PL that uses PLUS [START_REF] Gomaa | Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures[END_REF] as the SPLE approach, and PASSI [START_REF] Cossentino | From requirements to code with the PASSI methodology[END_REF] combined with MAS-ML [START_REF] Silva | MAS-ML: A Multi-Agent System Modelling Language[END_REF] as AOSE method.

Peña et. al. propose the use of MaCMAS [START_REF] Peña | Designing and managing evolving systems using a MAS product line approach[END_REF] and UML to define the core architecture of a MAS-PL. Their method only considers the Domain Engineering level and it adopts MaCMAS models in several levels of abstraction to guide the building of the MAS-PL variability model. In the same way as Nunes and colleagues, Pena and colleagues' approach results into a single MAS-PL, instead of a family one. Dehlinger and Lutz [10] [11] propose an approach that combines SPLE techniques and Gaia. The method is called Gaia-PL and it is devoted to the Domain Engineering level of a software product line. Their goal was reusing requirements specifications and a heuristic is provided to guide the building of the feature model. Nevertheless, the proposed MAS-PL approaches may not support different application domains than the ones presented as running example.

Motivating Example

We consider the Tropos method as a running example to discuss the current methodological limitations in the MAS-PL development: MAS-PL methods propose a partial integration of SPLE activities with particular AOSE methods.

Tropos offers a set of development phases to deal with requirements gathering as well as to analyze, design, and code two MAS components: agents and interaction. Fig. 2 depicts the five subsequent phases of Tropos, from requirement to implementation phases. We follow the standard notations of the Software and System Process Engineering Meta-model (SPEM) [START_REF] Omg | Object Management Group[END_REF], which is the de facto standard for representing development methods [15]. As initially proposed, Tropos only considers the phases that are related to the development of a single MAS without any methodological support for MAS-PL development. To be suitable for MAS-PL development, the original phases of Tropos (see Fig. 2) should be extended by integrating the SPLE activities. For instance, we need to add the domain analysis phase to specify variability. In addition, we also need to include activities that are related to domain implementation and product derivation. Many interesting issues can be considered in this context:

• Tropos and SPLE best practices according to project needs? The next section presents how our approach deals with these issues. As we will show, Meduse for MAS-PL can automatically generate variants of MAS-PL method based on Tropos, as well as based on other AOSE methods like Gaia or PASSI. Moreover, it offers a set of activities based on SPLE best practices that are ready to be fully integrated with these AOSE methods. Finally, our approach provides MAS-PL methods for developing MAS families in diverse domains.

From MAS Methods to MAS-PL Methods with Meduse

In this section we present the Meduse for MAS-PL approach. In few words, it is an automated approach to generate methods for developing MAS-Product Lines that provides a steady methodological support following SPLE best practices. Besides, it promotes the reuse of existing AOSE methods, by extending them to explicitly support MAS-PL development according to project needs. Finally, to speed up this extension Meduse for MAS-PL capitalizes all knowledge on SPLE activities proposed in [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF], providing SPLE best practices ready to be used for MAS development.

To achieve such a goal our approach takes advantage of Method Engineering techniques. Moreover, it is based on the Meduse framework, which itself adopts SPLE techniques. Therefore, Meduse for MAS-PL uses SPLE principles in two levels. First, SPLE techniques are used in a meta-level fashion to generate method variants to develop MAS-PL. Second, these method variants are used to develop MAS product lines and then to generate MAS applications, i.e. product variants. Since our approach is based on the Meduse framework, we start presenting it.

Meduse in a nutshell

Meduse Framework is a general approach to generate software development methods. Meduse adopts SPLE techniques to manage method variability, as well as to automatically derive method variants. Moreover, it adopts Method Engineering principles to manage reusable method artifacts, so-called method fragments, which consist of standardized building blocks based on a coherent part of method [START_REF] Harmsen | Situational Method Engineering[END_REF]. Method variants are built upon these fragments. Fig. 3 presents the big picture of the Meduse framework, showing from the method domain analysis to the final method variant, which is automatically generated according to project needs. First, Meduse proposes to represent method domain knowledge in terms of similarities and differences among variants of a same method family by means of a feature model.

Second, during method domain implementation these method´s commonalities and variabilities are developed as a set of method fragments, and organized according to the feature model. In order to do that Meduse proposes reusable method fragments together with a compositional approach based on Delta-oriented programming (see Section 2). Thus, method derivation relies on the application of delta modules over an empty method: the modification proposed by a delta module consists of the additions and/or removals of reusable method fragments from the method variant. Therefore, one can define the partially-ordered sequence in which method fragments will appear in the method variant, since delta modules are grouped in fixed-ordered partitions, and modules in the same partition can be applied in any order.

Third, method variants are specified through a method configuration, which consists of a set of features selected according to project needs. Finally, Meduse proposes a tool -the Meduse Composer -that automatically derives the specified method variant: it takes the empty method as starting point of the work breakdown structure and incrementally adds or removes method fragments according to the modifications specified in the delta modules connected with the selected features through attached conditions. Fig. 3 depicts the final method variant automatically generated by the Method Variant Derivation activity.

Managing MAS-PL Method Family with Meduse

After introducing the Meduse framework we present the Meduse for MAS-PL approach in details. Fig. 4 illustrates how we can implement a family of MAS-PL methods and automatically generate method variants. As previously mentioned, our approach applies SPLE principles in two levels: to develop a family of MAS-PL methods and then to develop MAS product lines themselves. First, a method family for MAS-PL is specified in terms of commonalities and variabilities among methods. Second, method family implementation is speeded up with a set of reusable method fragments offered by the Meduse for MAS-PL approach. Such fragments concern SPLE best practices and are ready to be integrated to AOSE methods. Third, a particular method for developing MAS product lines is configured over the method´s commonalities and vari-abilities available in the method family, and then this final method is automatically generated and used to support the development of MAS product lines.

Specifying commonalities and variabilities for a family of MAS-PL Methods

MAS-PL method variants are generated through method families where the MAS-PL methodological knowledge is represented as method commonalities and variabilities by means of a feature model. Thus, on one hand features represent the various AOSE methods that may be extended, like Tropos, Gaia, or PASSI. On the other hand, features represent a large set of SPLE activities and related techniques that may be chosen as best practices to develop MAS-PL. Examples of such activities are those described by the general SPLE framework proposed in [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF] (see Section 2). One of the main advantages of using feature models to specify a MAS-PL method family is that we can use SAT solver tools to determine whether such a feature model is consistent, i.e. if at least one valid method configuration exists, and whether or not a given configuration is valid. Therefore, a valid MAS-PL method variant is guaranteed.

Reusing/Building & Organizing Method Fragments for MAS-PL method family

The first step of the MAS-PL Domain Implementation consists of reusing and/or building a set of method fragments that implements the commonalities and variabilities encompassed by a family of MAS-PL methods. In order to speed up this implementation, we have capitalized all knowledge on SPLE activities proposed in [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF] as a set of reusable method fragments. Therefore, Meduse for MAS-PL offers several reusable fragments that provide detailed guidance to develop MAS-PL based on SPLE best practices. These fragments were sourced from FODA, Synthesis, and the Apel et al. approach, and are ready to be integrated to existing AOSE methods. For instance, some of these reusable fragments deal with feature and decision models, while others deal with the analysis of a particular MAS application over a MAS product line, and the generation of the final code of this MAS application. All of these method fragments encompass fine-grained elements, like tasks, work products, and roles. Fig. 5 On the other hand, fragments related to AOSE may be provided by existing method fragment´s libraries, like the Medee framework [START_REF] Casare | Medee Method Framework: a situational approach for organization-centered MAS[END_REF] that offers more than a hundred fragments sourced from popular AOSE methods. Moreover, method fragments may be also built from scratch whenever the method domain analysis identifies a new feature not yet implemented as reusable asset, related both to AOSE or SPLE.

The second step of the MAS-PL Domain Implementation consists of specifying delta modules that describe the modification to be applied to a method variant by incrementally adding or removing method fragments. These delta modules are then associated with the conditions in which they should be applied. As explained in Section 2, these conditions create the connection between the modifications prescribed in delta modules and the feature model. Finally, delta modules are put together in an ordered list and then are ready to be applied during the generation of a particular MAS-PL method variant. Nevertheless, before such a generation we have to configure this method.

Configuring a Particular MAS-PL Method

To configure a particular MAS-PL method we should analyze the the project at hand needs and express them through a selection of the AOSE and SPLE development activities among those provided by the MAS-PL method family. In order to result in a valid method configuration such a selection must take into account the relationships specified in the feature model. As previously explained, Meduse for MAS-PL proposes the use of SAT solver tools to determine whether a given configuration is valid.

For instance, we may select Tropos as the AOSE method to be extended by integrating SPLE activities to guide the analysis, design, and implementation of a MAS product line concerning the development of several agents, their roles and interactions. Moreover, these SPLE activities may also guide the requirement analysis and derivation of the final MAS application.

Generating a MAS-PL Method Variant

Finally, the final MAS-PL method is automatically generated by the Meduse Composer and can be used to support the development of MAS product lines.

The following steps are performed by the Meduse Composer tool. First, it finds all delta modules that shall be applied to the MAS-PL method variant, i.e., those delta modules attached to a condition evaluated to true for the configuration. For instance, a condition defined as the propositional formula Tropos and Decision Model is evaluated to true whenever a method configuration includes these two features, and therefore all delta modules attached to this condition are taken into account during method derivation. Second, that tool generates an empty MAS-PL method variant and then adds and/or removes reusable method fragments from that variant according to the modification proposed by the selected delta modules, always respecting the order defined by the list of modules.

We have developed a prototype implementation of Meduse for MAS-PL, in which we adopted FeatureIDE [START_REF] Thüm | FeatureIDE: An extensible framework for feature-oriented software development[END_REF] as tool to specify the feature model and to create method configurations, as well as SPEM and Eclipse Process Framework (EPF) 1 to manage method fragments, delta modules, and the derived method variants. Interested readers may access the Meduse for MAS-PL website2 to see available reusable method fragments sourced from several SPLE approaches, and method variants for MAS-PL development automatically derived during the case study presented in the next section.

Creating MAS-PL Method Family: a Case Study

In this section we present a case study that shows how we can use our approach to extend two AOSE methods -Gaia and Tropos -to support MAS-PL development following SPLE best practices. It consists of creating a MAS-PL method family and then deriving several method variants.

The scope of this method family is defined as follows. It aims at providing methods to develop MAS product lines based on Gaia or Tropos. Moreover, such method family would offer two techniques for modeling MAS variabilities -feature model and decision model -as well as it would deal with the development of four MAS components: Agent, Environment, Interaction, and Organization. Finally, this method family would involve both Domain and Application Engineering levels to provide a full SPLE development cycle: from MAS-PL Domain Analysis to the MAS-PL Product Derivation. It should be noted that another scope definition, for instance involving different MAS components or other AOSE methods, like PASSI, is also possible and would give rise to a different MAS-PL method family.

The resulting feature model contains eighteen features, where eleven of them represent the similarities among the method variants pertaining to such a family, while the remainder seven features represent how such method variants may vary. To implement the method family we reused a set of method fragments sourced from Gaia and Tropos, as well as those provided by the Meduse for MAS-PL approach concerning FODA, Synthesis, and Apel et al. Finally, the Meduse Composer was used to derive the twenty possible variants. The remainder of this section describes this case study in detail.

Feature Model for a MAS-PL Method Family

As aforementioned, similarities and differences among the method variants of our MAS-PL method family were specified through the feature model presented in Fig. 6. This feature model is composed of eighteen features and one constraint (environment v organization => Gaia). The root of that diagram is labelled with MAS_PL_Method to represent a MAS-PL development method. It has three mandatory child features: MAS-Component, MASMethod, and SPLEngineering. MASComponent has two mandatory and two optional child features -Agent and Interaction, Environment and Organization -respectively, because in this case study we consider that a MAS-PL method must cover at least the development of agents and their interaction, and may cover also environment and organization development. Thanks to the unique constraint defined in this model, whenever a method variant includes the features Environment or Organization it must include Gaia as MASMethod, because Gaia deals with the development of the four MAS components, while Tropos, the optional MAS-Method child feature, takes into account only the development of Agent and Interaction.

Moreover, SPLEngineering has the two SPLE levels as child features: DomainEngineering and ApplicationEngineering. The former is a mandatory feature while the latter is an optional one because in this case study we consider that a MAS-PL method must propose at least the Domain Engineering level. The DomainEngineering feature has three mandatory child features -Analysis, Design, Implementation -which correspond to the three domain development phases proposed by Apel et al. Additionally, Analysis offers two alternative child features -FeatureModel and DecisionModelthat represent the choice of SPLE techniques to model MAS variability. Therefore, exactly one of these techniques must be present in a MAS-PL method variant.

Finally, whenever a MAS-PL method includes the ApplicationEngineering feature it must include its two child features: ProductAnalysis and ProductDerivation. It should be observed that such a feature model corresponds to the previously described scope. A diverse scope would give rise to a different feature model.

Domain Implementation for a MAS-PL method family

While similarities and differences among the method variants of the MAS-PL method family were specified through a feature model, we used reusable fragments and Deltaoriented programming to implement such features. Therefore, the implementation of that MAS-PL method family comprised a set of reusable method fragments organized in a list of delta modules. Method fragments were sourced from the two AOSE methods considered in our scope, Gaia and Tropos. Concerning SPLE approaches, we have reused those reusable fragments provided by the Meduse for MAS-PL approach. The rest of this section describes how we reused method fragments and implemented delta modules, starting with method fragments.

Method Fragments for MAS-PL Family

In order to deal with SPLE activities and techniques we reused ten of the set of fragments provided by Meduse for MAS-PL. These fragments were sourced from FODA (for feature model), Synthesis (for decision model), and Apel et al. (for SPLE domain and application activities). Besides, method fragments sourced from Gaia and Tropos were provided by the Medee Framework: (i) six fragments sourced from Gaia were used to guide the analysis and design of agents, environment, interaction, and organizations; (ii) five fragments sourced from Tropos were used to analyze and design agents and interaction. Summing up, this case study involved twenty-one method fragments.

Fig. 7 shows two examples of these method fragments, one sourced from Tropos (Gather MAS-PL Requirement with Tropos) and other sourced from Synthesis (Define MAS-PL Decision Model).

Delta Modules for MAS-PL Method Family

A list of eleven delta modules were implemented to specify the modifications to be applied during the derivation of MAS-PL method variants according to a given method configuration. Moreover, the list of delta modules determines the order in which such delta modules must be applied during method derivation (see Fig. 8 right). As explained before, delta modules were attached to conditions which allow their connection with combi-nations of features. For instance, a MAS-PL method variant would include the four method fragments defined in the D-TroposFMAnalysis delta module whenever the Tropos and FeatureModel features were selected to configure the MAS-PL method variant.

Method Configuration and Derivation of MAS-PL Method Variants

After implementation, the MAS-PL method family is ready to give rise to method variants according to a given method configuration. As shown in Table 1 (left), the eighteen features proposed in this case study offered twenty possible MAS-PL method configurations, four of them based on Tropos and sixteen based on Gaia. For instance, Configuration 1 is among the smallest MAS-PL method configurations and encompasses eleven features: MAS component, Agent, Iteration, MAS Method, Tropos, SPL Engineering, Domain Engineering, Analysis, Feature Model, Design, Implementation. On the other hand, Configurations 19 and 20 encompass sixteen features and therefore are among the largest ones. The remaining possible configurations encompass sets ranging from twelve to fifteen features.

The derivation of a MAS-PL method variant consists of incrementally applying to an empty method the modifications specified by the delta modules attached to valid (i) Finding all delta modules that shall be applied to the MAS-PL method variant, i.e. those modules attached to a condition evaluated to true for the given configuration. For example, for Configuration 1 the delta module D-TroposFMAnalysis (see Fig. 8 right) shall be selected, since its attached condition (Tropos and FeatureModel) is evaluated to true.

(ii) Generating the method variant by applying the modification proposed by the selected delta modules respecting the order defined by the list of delta modules.

All the twenty MAS-PL method variants presented in Table 1 (right) have been derived and are available in the Meduse for MAS-PL website. Two of these method variants are depicted in Fig. 9: Tropos-PL Variant 1 and Gaia-PL Variant 16. The similarities among these variants are highlighted in red: the two method fragments belonging to Domain Design phase and the entire Domain Implementation phase. It should be observed that our approach can generate several extensions for the same AOSE method. For instance, the SPLE domain analysis may vary according to the formalism adopted to specify the variability model: feature model or decision model. Therefore, Fig. 10 illustrates two Tropos based MAS-PL method variants generated by our approach. In addition to the Tropos-PL Variant 1, we also generated the Tropos-PL Variant 4 that uses the decision model instead of feature model and also covers all activities of the SPLE application engineering level.

Conclusion

This paper introduced Meduse for MAS-PL, an automated approach that aims at providing steady methodological support for MAS-PL development. This approach results from a close collaboration between MAS and SPLE researchers and applies SPLE principles in two levels: to develop a family of MAS-PL methods and then to develop MAS product lines. Meduse for MAS-PL automatically generates methods for MAS-PL based on existing AOSE methods, by extending them to explicitly support MAS-PL development according to project needs. Moreover, to speed up this extension Meduse for MAS-PL capitalizes all knowledge on SPLE activities proposed in [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF], providing SPLE best practices ready to be used for MAS-PL development. Therefore, it promotes the reuse of both AOSE methods and SPLE best practices. Indeed, and as illustrated by the presented case study, our approach provides a set of reusable method fragments sourced from several SPLE development approaches that are ready to be automatically incorporated to AOSE methods.

We validate our approach by the generation of twenty MAS-PL methods that extend Gaia and Tropos. However, its principals can be applied to all AOSE methods. Some of the method variants generated during the case study were used by Master students in the University Pierre et Marie Curie (Paris 6). Those students apply these MAS-PL methods to support the development of teams to the multiagent contest 3 . They consider the use of the proposed MAS-PL methods to generate several multiagent teams. This experience shows that the generated methods are promising. We plan to propose to several groups of students another project and some criteria to measure the quality of those methods.

6

Fig. 2 .

 2 Fig. 2. The Tropos phases using the SPEM notations.

  How can we integrate the different SPLE activities with the Tropos method of Fig. 2, concerning both MAS-PL domain and application engineering levels? • How can we provide MAS-PL methods based on Tropos for developing MAS families in diverse domains? • As early discussed in Section 2.1, there are two kinds of formalisms to specify the variability model during SPLE domain analysis: Feature Mod-el and Decision Model. Then, how can we manage these different integration possibilities into Tropos? • How can we automatically generate a new MAS-PL method based on

Fig. 3 .

 3 Fig. 3. A big picture of Meduse framework

Fig. 4 .

 4 Fig. 4. Generating method variants for developing MAS product lines

  illustrates four of them: Define MAS-PL Decision Model, Define MAS-PL Feature Model, Perform MAS Application Requirement Analysis, and Generate MAS Product Code. For instance, the first is sourced from Synthesis and encompasses two tasks: Define Domain Scope and Define Decision Model. Such tasks are performed by the System Analyst role and produce Domain Definition and Decision Model as work products, respectively.

Fig. 5 .

 5 Fig. 5. Example of four method fragments provided by Meduse for MAS-PL

Fig. 6 .

 6 Fig. 6. A feature model diagram for a MAS-PL method family

Fig. 7 .

 7 Fig. 7. Examples of two method fragments for a MAS-PL method family, sourced from Tropos (left) and Synthesis (right).

Fig. 8 (

 8 left) illustrates four of these delta modules, D-TroposFMAnalysis, D-GaiaDMAnalysis, D-TroposDMAnalysis, and D-GaiaFMAnalysis, as well as the comprised method fragments of the first two delta modules. Note that two of these fragments correspond to those depicted in Fig.7, namely Gather MAS-PL Requirement with Tropos and Define MAS-PL Decision Model fragments.

Fig. 8 .

 8 Fig. 8. A partial representation of the List of Delta modules containing method fragments (left), and the list of Delta modules and attached conditions (right)

F1 12 V6:x x x 14 V10:

 1214 Eng. w/ FM & A.I. 2 * * _ * _ * _ x * * * _ x * * 11 V2: Domain Eng. w/ DM & A.I. 3 * * _ * _ * _ x * * * x _ * * x x x 14 V3: Domain&Application Eng. w/ FM & A.I. 4 * * _ * _ * _ x * * * _ x * * x x x 14 V4: Domain&Application Eng. w/ DM & A.I. Domain Eng. w/ DM & A.I.O. 11 * * x * x * x _ * * * x _ * * 13 V7: Domain Eng. w/ FM & A.E.I.O. 12 * * x * x * x _ * * * _ x * * 13 V8: Domain Eng. w/ DM & A.E.I.O. Domain&Application Eng. w/ DM & A.I. 15 * * x * * x _ * * * x _ * * x x x 15 V11: Domain&Application Eng. w/ FM & A.E.I. 16 * * x * * x _ * * * _ x * * x x x 15 V12: Domain&Application Eng. w/ DM & A.E.I. 17 * * * x * x _ * * * x _ * * x x x 15 V13: Domain&Application Eng. w/ FM & A.I.O. 18 * * * x * x _ * * * _ x * * x x x 15 V14: Domain&Application Eng. w/ DM & A.I.O. 19 * * x * x * x _ * * * x _ * * x x x 16 V15: Domain&Application Eng. w/ FM & A.I.E.O. 20 * * x * x * x _ * * * _ x * * x x x 16 V16: Domain&Application Eng. w/ DM & A.I.E.O. FM = Feature Model DM = Decision Model A = Agent I = Interaction E = Environment O = Organization (*) mandatory feature (x) optional selected featured (-) optional disable feature ( ) optional unselected feature conditions in a given configuration. Such a derivation was automatically achieved by the Meduse Composer as follows:

Fig. 9 .

 9 Fig. 9. Two MAS-PL method variants based on Tropos (left) and Gaia (right), highlighting in red the common fragments among them.

Fig. 10 .

 10 Fig. 10. Two MAS-PL method variants based on Tropos -the smallest (left) and the largest (right) -highlighting in green the variability among them.

Table 1 .

 1 MAS-PL Method Configurations and Derived MAS-PL method variants.

https://eclipse.org/epf/

https://pages.lip6.fr/Tewfik.Ziadi/EMAS17/

https://multiagentcontest.org/

Acknowledgement

Sara Casare was supported by CNPq (grant #233828/2014-1), Brazil.