Amira Dhouib
email: amira.dhouib@fsegs.rnu.tn

Ahlem Assila
email: aassila@cesi.fr

Abdelwaheb Trabelsi
email: atrabelsi@seu.edu.sa

Christophe Kolski
email: christophe.kolski@uphf.fr

Mahmoud Neji
email: mahmoud.neji@fsegs.rnu.tn

Factors Affecting the Choice of Usability Evaluation Methods for Interactive Adaptive Systems

Keywords: Interactive adaptive system, Usability evaluation method, Decision process

Choosing the appropriate usability evaluation methods is a key part of the usability evaluation process of interactive adaptive systems. This step needs the consideration of different factors, leading to a multi-criteria decision analysis problem. In this paper, we present a review of the main factors reported in the literature which can affect the selection of usability evaluation methods for interactive adaptive systems. Three of the most commonly used usability evaluation methods are selected and classified according to these factors. The results of this research are used by applying a decision aid method in order to guide the choice of suitable usability evaluation methods for a given adaptive system in the field of tourism.

Introduction

As for all interactive systems, usability plays an important role in the success of Interactive Adaptive Systems (IAS)1 [START_REF] Benyon | Adaptive systems: a solution to usability problems[END_REF]. The usability evaluation of IAS represents an essential part of their development process. It may be conducted through the use of suitable Usability Evaluation Methods (UEMs). In the IAS literature, several UEMs are available [START_REF] Gena | Usability engineering for the adaptive web[END_REF][START_REF] Dhouib | A classification and comparison of usability evaluation methods for interactive adaptive systems[END_REF]. These methods aim mainly to detect the usability issues. Given this variety, non-specialists and even specialists can encounter difficulties in selecting the most appropriate UEM(s) in particular settings [START_REF] Dhouib | A classification and comparison of usability evaluation methods for interactive adaptive systems[END_REF][START_REF] Xavier | UCD method selection with usability planner[END_REF]. Choosing appropriate usability evaluation method(s) is a crucial task of the IAS evaluation process [START_REF]Maturing Usability: Quality in Software, Interaction and Value[END_REF]. This task depends usually on different factors, such as number of stakeholders, available time, etc. [START_REF] Dhouib | A classification and comparison of usability evaluation methods for interactive adaptive systems[END_REF]. Applying a Multi-Criteria Decision Analysis (MCDA) method for the suitable UEMs choice is one strategy to deal with multiple and conflicting factors. One of the main steps of the decision analysis process is to define the factors that impact the choice of alternatives. In this research, we provide a general overview of the factors affecting the choice of alternative UEMs. We also classify three common usability evaluation methods for IAS according to the considered factors. These include heuristic evaluation, cognitive walkthrough, and usability test. Lastly, we use the finding of this analysis to guide the choice of suitable methods for the usability evaluation of a target adaptive system as a whole using ELECTRE I (Elimination and Choice Translating Reality) method.

It is common to identify in the IAS literature two kinds of evaluation. The first one is named layered evaluation, which aims to separate the adaptation process into its layers and to assess each one individually where necessary and feasible [START_REF] Paramythis | Layered evaluation of interactive adaptive systems: framework and formative methods[END_REF]. The second one is evaluation as a whole (or traditional evaluation), which considers the adaptation as one block. Various UEMs can be applied in conjunction with the layered evaluation as well as the evaluation as a whole. In the IAS field, a limited number of works have been focused on the guidance of the choice of appropriate UEMs. For instance, Paramythis et al. [START_REF] Paramythis | Layered evaluation of interactive adaptive systems: framework and formative methods[END_REF] proposed a layered evaluation framework that breaks the adaptation process into five separate layers. They provided a comprehensive overview of the appropriate evaluation methods and attributes to be applied in individual layers and evaluation as a whole. Regarding the use of MCDA, it has been observed that very few studies exist, apart from the ones in our previous works [START_REF] Dhouib | EvalCHOICE: A Decision Support Approach for the Usability Evaluation of Interactive Adaptive Systems[END_REF][START_REF] Dhouib | Towards the Layered Evaluation of Interactive Adaptive Systems using ELECTRE TRI Method[END_REF]. These studies focus on the choice of suitable evaluation methods for the layered evaluation given particular evaluation settings. While assessing adaptation layers individually allows one to answer questions which are not possible to approach in a "monolithic" entity, there are some assessment questions that require treating the adaptation process as a whole. One example of the questions that can be examined when conducting the evaluation as a whole is "does the adaptive system achieve its goals?" [START_REF] Paramythis | Layered evaluation of interactive adaptive systems: framework and formative methods[END_REF]. To the best of our knowledge, there are no attempts to date that provide a review of the common factors affecting the selection of UEMs and that explore the most potential benefits of MCDA to identify appropriate methods for the usability evaluation as a whole of IAS. For instance, the use of MCDA allows the consideration of a variety of criteria that are important for the decision analysis by considering both quantitative and qualitative aspects.

The present paper is organized as follows. First, we briefly outline the usability evaluation methods for IAS, focusing on three common ones (Section 2). Second, we present the proposed decision process for choosing the appropriate usability evaluation methods for IAS (Section 3). Then, the study investigates the main factors that can affect the choice of usability evaluation methods for IAS and analyzes the considered UEMs in relation to these factors (Section 4). An application of an MCDA method is provided in Section 5. The aim is to guide the selection of the most suitable methods for the usability evaluation of a given adaptive system as a whole. Lastly, we conclude the paper with a summary and some future directions (Section 6).

2

Focus on Three Usability Evaluation Methods for Interactive Adaptive Systems

Heuristic Evaluation

It describes a method in which expert evaluators examine a user interface in order to discover the usability problems [START_REF] Nielsen | Heuristic evaluation[END_REF]. In the IAS field, expert evaluators need to have expertise in heuristic evaluation and they are required to understand the meaning of the particular heuristics applied for adaptive systems [START_REF] Paramythis | Layered evaluation of interactive adaptive systems: framework and formative methods[END_REF].

Usability Test

The main purpose of this method is to give a group of real users well-defined tasks to perform and to ask them to record what happens [START_REF] Dumas | A Practical Guide To Usability Testing[END_REF]. Certain observational methods can be applied in conjunction with this method such as co-discovery, retrospective testing, etc. In the IAS field, certain modifications to observational methods are required. For instance, in contrast to interactive (non-adaptive) systems, an IAS necessitates interrupting the users in order to ask them about the adaptations that occur explicitly.

Cognitive Walkthrough

During this evaluation method, a group of expert evaluators construct typical user tasks in order to detect the difficulties encountered by novice users [START_REF] Mahatody | State of the art on the cognitive walkthrough method, its variants and evolutions[END_REF]. When evaluating adaptive systems, some modifications to this method are needed. For instance, multiple-action sequences per task have to be given to expert evaluators. For each action, the expert evaluators have to examine four main questions: "Will the user expect to be asked to do this?", "Will they notice the control (e.g., button)?", "Will they realize that the control is appropriate for this step?", and "Will progress be apparent once it has been used?" [START_REF] Paramythis | Layered evaluation of interactive adaptive systems: framework and formative methods[END_REF].

Usability Evaluation Methods' Choice Process

As shown in Fig. 1, the decision analysis process starts with a preparatory step, where the goal of the decision problem is defined. The aim consists in selecting the appropriate UEMs for interactive adaptive systems. This step also defines the actors involved in the decision process, including a Decision Maker (DM) and an analyst. In this research, a decision maker can be a novice evaluator; s/he can also be an expert evaluator who needs to be assured in the suitable UEMs. Finally, s/he can be a project manager who needs to be aware of the UEMs to be applied given particular evaluation settings. The next step consists in determining the set of alternative UEMs that define the aspects relevant to the decision problem. Then, the factors (or criteria) that can affect the choice of these UEMs are identified. Different criteria should be considered when selecting appropriate UEMs for interactive adaptive systems. Once relevant criteria are retained, the performance table should be established. Each alternative UEM is classified with respect to the considered criteria after a detailed analysis of studies such as [START_REF] Gena | Usability engineering for the adaptive web[END_REF][START_REF] Dhouib | A classification and comparison of usability evaluation methods for interactive adaptive systems[END_REF][START_REF] Paramythis | Layered evaluation of interactive adaptive systems: framework and formative methods[END_REF]. Next, an appropriate MCDA method needs to be selected in order to solve the considered decision problem. The decision maker has then to give information about the evaluation constraints of the target IAS. Usually, some parameters need to be set up in an MCDA method, such as the weight associated to every criterion. The weight refers to the relative importance of each criterion. It can be determined by the DM or estimated using a specific weighting method 2 . The next step consists to establish the outranking relations for the different alternative UEMs. Before proposing the final list of appropriate UEMs, it is essential first to test the robustness of the results by varying the MCDA method's parameters and observing the effect on the results. On the basis of such an analysis, it is possible to study the validity of the results. The results are said to be robust only in the case where they are not modified to any significant extent by varying the parameters [START_REF] Zardari | Weighting Methods and their Effects on Multi-Criteria Decision Making Model Outcomes in Water Resources Management[END_REF]. After an analysis of the results, the DM has to express the satisfaction level s/he obtained from the proposed UEMs. 2 Different weighting methods have been proposed in the MCDA literature to assign weights to decision criteria. One example of these methods is the 'equal weights' method. It consists in distributing weights equally among all criteria and has been used in different problems [START_REF] Zardari | Weighting Methods and their Effects on Multi-Criteria Decision Making Model Outcomes in Water Resources Management[END_REF].

A score is attributed; it may adopt either (1) useful, when the list of UEM(s) satisfies the evaluation constraints, or (2) not useful, when the list of UEM(s) is not suitable due either to the non-satisfaction of the evaluation constraints (e.g., exceed the available number of users, etc.) or to the lack of proposals. In this case, a relaxation of constraints has to be performed by proposing a list of actions to the DM.

Factors Affecting the Choice of Usability Evaluation Methods

One of the main parts of the UEMs' choice process is to define the factors that reflect the impact of each alternative on the decision problem. This step has a great influence on the decision process's success. As already stated, this research seeks to present the common factors that influence the choice of UEMs in the IAS field. As shown in Table 1, three groups of criteria are considered (e.g., situational factors, characteristics of stakeholders, and adaptivity aspects). It is essential to highlight here that this list is not exhaustive and may be completed with other factors.

Situational Factors

The choice of UEMs for interactive adaptive systems depends on different factors related to the evaluation situation. In Table 2, we classify the characteristics of the considered UEMs (cf. Section 2) according to these factors.

Stage of Development Life-Cycle.

The evaluation of IAS can occur at three stages of the development life-cycle of adaptive systems [START_REF] Paramythis | Layered evaluation of interactive adaptive systems: framework and formative methods[END_REF]. These include (1) specification, which refers to the phase taking place before any system implementation, (2) design, which occurs during the IAS' development, and (3) implementation, which occurs after the implementation of a prototype of the system functionality.

Table 1. List of criteria affecting the choice of usability evaluation methods for IAS.

Group of criteria Criteria Situational factors

Stage of the development life cycle [START_REF] Paramythis | Layered evaluation of interactive adaptive systems: framework and formative methods[END_REF] Temporal resources [START_REF] Dhouib | A classification and comparison of usability evaluation methods for interactive adaptive systems[END_REF] Financial resources [START_REF] Dhouib | A classification and comparison of usability evaluation methods for interactive adaptive systems[END_REF] Style of evaluation [START_REF] Dix | Human-Computer Interaction. 2nd Ed[END_REF] Type of data [START_REF] Assila | Integration of Subjective and Objective Usability Evaluation based on ISO/IEC 15939: a Case Study for Traffic Supervision Systems[END_REF] Characteristics of stakeholders Number of users [START_REF] Primož | Adequateness of usability evaluation methods regarding adaptivity. Simpozijum o računarskim naukama i informacionim tehnologijama[END_REF] Number of evaluators [START_REF] Primož | Adequateness of usability evaluation methods regarding adaptivity. Simpozijum o računarskim naukama i informacionim tehnologijama[END_REF] Availability of direct access to users [START_REF] Wixon | The Usability Engineering Framework for Product Design and Evaluation[END_REF] Level of expertise of evaluators [START_REF] Karat | User-centered software evaluation methodologies[END_REF] Adaptivity aspects Intrusiveness of adaptivity [START_REF] Primož | Adequateness of usability evaluation methods regarding adaptivity. Simpozijum o računarskim naukama i informacionim tehnologijama[END_REF] Reusability adaptation rules [START_REF] Primož | Adequateness of usability evaluation methods regarding adaptivity. Simpozijum o računarskim naukama i informacionim tehnologijama[END_REF] Temporal Resources. The application time of a usability evaluation method represents an important factor which affects its choice [START_REF] Dhouib | A classification and comparison of usability evaluation methods for interactive adaptive systems[END_REF]. The duration can be represented by an ordinal scale (i.e., low, medium, or high).

Financial Resources. Another factor distinguishing UEMs is the required budget [START_REF] Dhouib | A classification and comparison of usability evaluation methods for interactive adaptive systems[END_REF]. This criterion can be assessed using a three-level scale (i.e., low, medium, or high).

Style of Evaluation.

Usability evaluation methods may be performed under laboratory conditions, as well as in the work environment [START_REF] Dix | Human-Computer Interaction. 2nd Ed[END_REF]. In order to evaluate this criterion, yes is used to model the evaluation conducted in laboratory conditions, and no otherwise.

Type of Data. Usability evaluation methods can be distinguished according to the type of data they deal with, specifically, whether these data are qualitative or quantitative [START_REF] Assila | Integration of Subjective and Objective Usability Evaluation based on ISO/IEC 15939: a Case Study for Traffic Supervision Systems[END_REF]. In order to evaluate this criterion, yes is used to model that an evaluation method provides qualitative data, and 0 otherwise.

Characteristics of Stakeholders

A crucial consideration when selecting UEMs is the characteristics of the stakeholders involved in the usability evaluation process. In Table 3, we present a classification of the considered UEMs according to the characteristics of stakeholders.

Number of Users.

This concerns the total number of users to be involved to use a specific UEM [START_REF] Primož | Adequateness of usability evaluation methods regarding adaptivity. Simpozijum o računarskim naukama i informacionim tehnologijama[END_REF].

Number of Evaluators.

This refers to the total number of evaluators to be involved to apply a given UEM [START_REF] Primož | Adequateness of usability evaluation methods regarding adaptivity. Simpozijum o računarskim naukama i informacionim tehnologijama[END_REF].

Availability of Direct Access to Users. The evaluation of interactive adaptive systems can be carried out in the presence of real or representative users [START_REF] Wixon | The Usability Engineering Framework for Product Design and Evaluation[END_REF]. Level of Expertise of Evaluators. This refers to the evaluator's expertise and knowledge of UEMs [START_REF] Karat | User-centered software evaluation methodologies[END_REF]. The level of expertise can be: low, medium, or high.

Adaptivity Aspects

One other important consideration when choosing UEMs is the adaptivity aspects (e.g., reusability adaptation rules, and intrusiveness of adaptivity). Table 4 presents a classification of the considered UEMs based on these aspects of adaptivity. [START_REF] Primož | Adequateness of usability evaluation methods regarding adaptivity. Simpozijum o računarskim naukama i informacionim tehnologijama[END_REF]. It may adopt two values either simple or complex. In order to evaluate this criterion, yes is used to model simple reusability adaptation rules, and no otherwise.

Reusability Adaptation Rules. The reusability adaptation rules can influence the choice of UEMs

Intrusiveness of Adaptivity.

This underlines the frequently-given suggestions of the interactive adaptive systems [START_REF] Primož | Adequateness of usability evaluation methods regarding adaptivity. Simpozijum o računarskim naukama i informacionim tehnologijama[END_REF].

Illustrative Example of Using an MCDA Method for Choosing Appropriate UEMs

Let us assume that a DM, who is in this case a novice evaluator, is interested in identifying the appropriate UEMs for the usability evaluation of a given adaptive tourist guide system. The adaptive system adapts the user interface and the content according to the needs and requirements of the tourists. It helps them to easily find the most appropriate itineraries, schedules, etc., according to their requirements and preferences. Furthermore, the system can be adapted based on the device on which it is displayed (i.e., desktop, Smartphone). Many adaptive systems of this type have been studied and proposed in the literature over the last decades [START_REF] Hariri | Context aware business adaptation toward user interface adaptation[END_REF][START_REF] Taktak | Service-oriented application creation process in ubiquitous environments: Travel assistant mobile application[END_REF].

As already presented, the interest of this study is related essentially to choosing the appropriate methods for the usability evaluation as a whole. To support the decision process of the choice of UEMs, the DM has to consider the evaluation constraints of the whole system to be evaluated without separation between its adaptation layers. This situation deals with choosing problem (P.α) 4 , where the goal is to select one or a combination of UEM(s). For this study, one MCDA method is adopted, namely the ELECTRE I method. In the sub-sections that follow, we give a brief overview of the ELECTRE I method and details to justify the choice of this MCDA method as well as an application of the ELECTRE I method.

Brief Description of the ELECTRE I Method

ELECTRE I method is an MCDA method based on an outranking relation (aSb) 5 that aims to increase a set of alternatives in a reduced subset called kernel set [START_REF] Roy | The Outranking Approach and the Foundations of ELECTRE Methods[END_REF]. This latter contains the best alternative(s). The ELECTRE I method is based essentially on the following steps:

Calculating the Concordance Index (C(a,b)). The aim is to test the strength of the criteria coalition in favor of the agreement to the outranking relation. In this step, the discordance index is computed as shown in (eq. ( 1)), where W k represents the weight for each criterion and 𝑓 𝑘 (𝑎) is the score for alternative a under criterion j.

C(a,b) = 1 𝑊 ∑ 𝑊 𝑘 𝑗: 𝑓 𝑘 (𝑎)≤ 𝑓 𝑘 (𝑏) 𝑊ℎ𝑒𝑟𝑒 𝑊 = ∑ 𝑤 𝑘 𝑚 𝑘=1
, 𝑤 𝑘 > 0

Calculating the Discordance Index (D(a,b)). The aim is to measure the rejection against the assertion aSb. In this step, the discordance index is computed as shown in (eq. ( 2)). More details about the ELECTRE I method can be found in [START_REF] Roy | The Outranking Approach and the Foundations of ELECTRE Methods[END_REF].

D(a,b)= { 0 if 𝑓 𝑘 (𝑎) > 𝑓 𝑘 (𝑏), ∀𝑘 1 𝜕 max [𝑓 𝑘 (𝑎) -𝑓 𝑘 (𝑏)], 𝑂𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒
Where 𝜕 = [𝑓 𝑘 (𝑎) -𝑓 𝑘 (𝑏)] 𝑎,𝑏,𝑘 𝑚𝑎𝑥

(2)

Why Adopt ELECTRE I Method?

Numerous MCDA methods exist in the literature. Each one has some advantages depending on where it is applied. According to [START_REF] Guitouni | A Framework to Choose a Discrete Multicriterion Aggregation Procedure, Defence Research Establishment Valcatier[END_REF], the choice of a suitable MCDA method depends mostly on the type of information available and the nature of the decision problem to be solved. As stated earlier, the decision problem to be treated in this study corresponds to (P.α). A number of MCDA methods are appropriate to decision problems involving choice, such as the ELECTRE I method and its variant ELECTRE IS. Some differences between these methods exist. The main novelty of the ELECTRE IS method, for example, is the use of indifference and preference thresholds [START_REF] Roy | The Outranking Approach and the Foundations of ELECTRE Methods[END_REF]. These discrimination thresholds aim essentially, in this case, to take into account the imperfect knowledge character of the DM with respect to the evaluation of alternatives. Such imperfect knowledge may arise when two alternatives are susceptible to be characterized with the same performance, which disables the DM to clearly express a preference relation for any pair of alternatives. For the problem analyzed in this case, it is presumed that neither indifference nor preference thresholds are necessary to model the preferences of our DM. Then, ELECTRE I method is retained since it seems to be appropriate for this decision problem. The main advantage of this MCDA method consists in using pair-wise comparisons between alternative UEMs, so that one can select the appropriate one or a combination of UEMs according to different criteria [START_REF] Bouyssou | On Some Properties of Outranking Relations Based on a Concordance-Discordance Principle, Multiple Criteria Decision Making[END_REF].

Application of the ELECTRE I Method

The use of ELECTRE I method requires the identification of a set of input data about the given decision problem. Firstly, the DM has to identify the UEMs applicable to the candidate usability attributes to be assessed. Three representative UEMs are considered in this study, namely cognitive walkthrough, heuristic evaluation, and usability test (cf. Section 2). After determining the set of criteria, a performance table should be established which consists of the evaluation of alternative UEMs through the retained criteria (Cf. Table 2, Table 3, and Table 4). Then, the decision maker is asked to answer a questionnaire in order to explore the constraints about the usability evaluation of the given adaptive system. An example of these questions is: "When will the usability evaluation of the given adaptive system be done?". In this study, the evaluation as a whole occurs in laboratory conditions during the implementation stage. As already stated, ELECTRE I is retained. A set of input data has to be determined for this MCDA method such as the relative importance of criteria. In this study, the DM considers that the decision criteria at the same level have equal weights. The outranking relation of ELECTRE I method involves two calculations, including the concordance and the discordance indices (Cf. Section 5.1). The outranking relation is based on the concordance and discordance thresholds. Table 5 presents the concordance matrix, which aims to measure the strength of the criteria coalition in favor of the agreement to the outranking relation. Then, the discordance matrix, which aims to measure the rejection against the assertion (aSb) is calculated (Table 6). In order to interpret the information shown in the concordance and discordance matrices (Table 5, and Table 6), two thresholds (p and q) should be defined. These thresholds aim to establish the outranking relations between alternatives and to define the desired concordance and tolerated discordance. The concordance threshold p refers to the minimum concordance index needed for outranking whereas the discordance threshold q reflects the maximum discordance index required for outranking. The values for both threshold parameters are fixed as follows: p= 0.67 (represents the average of the concordance matrix); q= 0.48 (represents the average of the discordance matrix). Table 7 illustrates the outranking relations between alternative UEMs. The results obtained by the ELECTRE I method may be expressed in the form of a graph, as shown in Fig. 2. The arrows emerging from the nodes represent the outranking relations between alternatives. Each node corresponds to an alternative UEM. Once the analysis of the robustness of results is carried out, the decision maker has to express his/her satisfaction level obtained from the proposed UEMs. In this study, the Usability Test (UT) method has no incoming arrows. It outranks Heuristic evaluation (HE) and Cognitive Walkthrough (CW) method. The latter outranks heuristic evaluation method. Hence, the usability test can be stated to be the most appropriate method for the evaluation as a whole of the given adaptive system. It is essential to highlight that these results depend essentially on the given evaluation context and can change from a situation to another. During the usability evaluation of IAS, a careful selection of UEMs should be performed in order to fit better the situation of the evaluated system. As a contribution to the IAS field, this paper summarizes firstly the most common factors that affect the selection of UEMs for a particular situation. Three of the most commonly used methods for evaluation as a whole are classified then according to the identified factors. Indeed, the knowledge obtained in this research is used in order to support the choice of appropriate methods for the usability evaluation as a whole. Towards this end, the ELECTRE I method is retained. An application of this MCDA method is presented to support the UEMs choice process for a target adaptive system in the field of tourism.

Future work will investigate to apply our proposal in other areas of adaptive systems (e.g., adaptive learning system, adaptive e-commerce system, etc.). We also intend to propose a Multi-Criteria Decision Support System (MCDSS) that integrates ELECTRE I into its model base subsystem. This MCDSS will guide our DM by providing powerful capabilities in the exploration and the comparison of alternative UEMs.

Fig. 1 .

 1 Fig.1. A flowchart illustrating the decision analysis process for the choice of Usability Evaluation Methods (UEMs).

Fig. 2 .

 2 Fig.2. Outranking graph 6 Conclusion and Future Work

Table 2 .

 2 Classification of UEMs according to the situational factors.

		Heuristic evaluation Cognitive walkthrough	Usability test
	Stage of the development lifecycle	Design	Design	Implementation 3
	Temporal resources	Low	Medium	High
	Financial resources	Low	Low	High
	Style of evaluation	Yes	Yes	Yes
	Type of data	Yes	Yes	Yes

Table 3 .

 3 Classification of UEMs with respect to the characteristics of stakeholders.

		Heuristic evaluation	Cognitive walkthrough	Usability test
	Number of users	0	0	15+
	Number of evaluators	3+	3+	1+
	Availability of direct access to users	No	No	Yes
	Level of expertise of evaluators	High	High	Medium

Table 4 .

 4 Classification of UEMs according to the adaptivity aspects.

		Heuristic evaluation Cognitive walkthrough	Usability test
	Reusability adaptation rules	No	No	No
	Intrusiveness of adaptivity Yes	Yes	Yes

Table 5 .

 5 Concordance matrix.

		Heuristic	Cognitive Walkthrough	Usability Test
		Evaluation (HE)	(CW)	(UT)
	Heuristic evaluation (HE) --	0.616	0.4
	Cognitive walkthrough (CW)	0.916	--	0.45
	Usability test (UT)	0.833	0.85	--

Table 6 .

 6 Discordance matrix.

		Heuristic	Cognitive Walkthrough	Usability Test
		Evaluation (HE)	(CW)	(UT)
	Heuristic evaluation (HE)	--	0.266	1
	Cognitive walkthrough (CW)	0.333	--	1
	Usability test (UT)	0.166	0.15	--

Table 7 .

 7 Outranking relations between alternative UEMs

	CUEMi, UEMj	CUEMi, UEMj	DUEMi, UEMj	DUEMi, UEMj	UEMi=>UEMj
		≥ p		≤ q
	CHE,CW = 0.616	No	DHE,CW = 0.266 Yes	--
	CHE,UT = 0.4	No	DHE,UT = 1	No	--
	CCW,HE= 0.916	Yes	DCW,HE= 0.333 Yes	CW=>HE
	CCW,UT = 0.45	No	DCW,UT = 1	No	--
	CUT,HE= 0.833	Yes	DUT,HE= 0.166 Yes	UT=>HE
	CUT,CW = 0.85	Yes	DUT,CW = 0.15 Yes	UT=>CW

According to Jameson and Gajos[START_REF] Jameson | Systems that adapt to their users[END_REF], an interactive adaptive system represents an "Interactive system that adapts its behavior to individual users on the basis of processes of user model acquisition and application that involve some form of learning, inference, or decision making".

It is essential to highlight that it is possible to apply usability test using Wizard-of-Oz when a target system's functionality has not been implemented yet. In the case of this paper, the interest is on using usability test without Wizard-of-Oz technique.

Three types of decision problems can be distinguished according to Roy[START_REF] Roy | Méthodologie Multicritère d'Aide a la Décision[END_REF], namely choosing problem (P.α), ranking problem (P.γ), and (3) sorting problem (P.β).

5Where a and b are two alternatives to compare.


Martin Cronel
email: martin.cronel@gmail.com

Bruno Dumas
email: bruno.dumans@unamur.be

Philippe Palanque
email: palanque@irit.fr

Alexandre Canny
email: canny@irit.fr

MIODMIT: A Generic Architecture for Dynamic Multimodal Interactive Systems

Keywords: Interactive systems engineering, input/ouput devices integration, interaction techniques, software architectures

This paper proposes a generic interactive system architecture describing in a structured way, both hardware and software components of an interactive system. It makes explicit all the components that play a role in the information processing from input devices to the interactive application and back to the output devices. Along with the generic interactive system architecture the paper proposes a process for selecting and connecting those components in order to tune the generic interactive system architecture for a specific interactive application. This select, connect and tune-on-demand approach helps handle complexity of interactive applications featuring innovative interaction techniques by splitting the interactive software into dedicated functional components. It also supports design flexibility by making explicit the components impacted when the interaction design evolves. This interactive system architecture and its related process have been applied to the development of several real-life interactive systems and we illustrate their application on an interactive application offering multi-mice, multi-touch and leap motion interactions in the context of interactive cockpits of large civil aircrafts.

Introduction

The diversification of technological platforms on which interactive systems are designed, developed and deployed significantly increases the complexity of designers' and developers' tasks. At the same time, such an ever-changing context has made it very difficult for researchers belonging to the engineering community on interactive systems, to provide generic approaches to support those tasks. Designers need to go beyond the interactive application design by providing new interaction techniques that encompass new input and output devices which can be very cumbersome to design and evaluate (as for instance fingers clustering in multi-touch interactions [START_REF] Morris | Cooperative Gestures: Multi-user Gestural Interactions for Co-located Groupware[END_REF]). Developers of these systems are repetitively facing the same issues of: i) new devices integration, software redesign (due to device drivers' evolution) and above all poor reliability of the resulting system due to the low level of maturity of the various components to integrate. Such constraints are even stronger in the area of critical systems where a failure may lead to catastrophic consequences. This paper addresses these issues by proposing MIODMIT (Multiple Input and Output Devices and Multiple Interaction Techniques) generic interactive system architecture for integrating new input and output devices, along with their more and more (potentially multimodal) sophisticated interaction techniques. MIODMIT identifies the building components that have to be developed for integrating new devices as well as the building components for merging information from these devices in order to offer multimodal interaction to users. As such, MIODMIT helps developers with the design of systems exploiting advanced interaction technologies. While this interactive system architecture is generic (and can thus be applied to many types of interactive systems) it also comes with a set of attributes and related trade-offs giving freedom to developers using it, while constraining them when necessary. Due to its generic nature, MIODMIT needs to be tuned to and adapted for the interactive system under development, especially to the input and output devices and interaction techniques considered. Two case studies (including a real world critical system application) and two illustrative examples illustrate how the architecture is applied, as well as the benefits it brings.

The remainder of this paper is structured as follows. Next section describes relevant related work and characterizes input and output devices. Section 3 details MIODMIT making explicit how it decomposes interactive systems into connected components within a generic interactive system architecture. Section 4 presents the Tune-on-Demand process and makes explicit how to go from a tuned MIODMIT diagram to the implementation. Section 5 presents a real world case study in the area of interactive cockpits. As this application is rather complex, we also present a simple example of interactive system to demonstrate along the paper the application and functioning of the tune-on-demand process in its entirety. The last section concludes the paper, highlighting benefits and limitations of the contributions and identifying potential extensions.

2

Related work

Software Side of Interactive Systems Architectures

Architectural models for multimodal interactive systems have been presented in research papers [START_REF] Vennelakanti | The picture says it all!: multimodal interactions and interaction metadata[END_REF] and [START_REF] Kousidis | A Multimodal In-Car Dialogue System That Tracks The Driver's Attention[END_REF] as a way of explaining the various components of a given system. More generic ones have also been presented, but they are usually bound to one type of modality such as touch interaction [START_REF] Echtler | A multitouch software architecture[END_REF] or speech interaction [START_REF] Kraleva | On model architecture for a children's speech recognition interactive dialog system[END_REF]. Toolkits and frameworks for supporting the development of prototypes and demonstrations have also been developed such as, for instance, PyMT toolkit [START_REF] Hansen | PyMT: a post-WIMP multi-touch user interface toolkit[END_REF] for interactive applications offering multi-touch interactions. Similarly SensScreen [START_REF] Schneegass | SenScreen: A Toolkit for Supporting Sensor-enabled Multi-Display Networks[END_REF] is dedicated to interactive applications exploiting multimodal management of sensors distributed in the user environment and presents a very high level architecture dedicated to public displays. As far as interaction techniques are concerned, dedicated software architectures have been proposed but focusing on a specific problem raised by a specific kind of interaction technique in an interactive application. For instance [START_REF] Ng | Designing for low-latency directtouch input[END_REF] presents the Accelerated Touch Architecture and [START_REF] Hamon | Multi-Touch Interactions for Control and Display in Interactive Cockpits[END_REF] the Layered Multi-touch Architecture but both only address specific problems related to touch input. MUDRA [START_REF] Hoste | Mudra: a unified multimodal interaction framework[END_REF] is one recent exception proposing a framework embedding a generic architecture for multimodal interaction. The main limitation of MUDRA architecture (in terms of genericity) lies in its hardware part which is restricted to a defined set of input devices and does not provide a generic approach making explicit how new devices can be instantiated.

Despite such architecture-based contributions for engineering systems, empirical studies have demonstrated that, generally, developers are coding from scratch [START_REF] Latoschik | SEARIS: software engineering and architectures for realtime interactive systems[END_REF] as the problem they are facing is only superficially addressed by the existing solutions.

Hardware side of Interactive Systems Architectures: Input and Output Devices

In order to provide generic means to deal with the extent of future input and output devices, there is a need to characterize them and, in addition, to provide means for integrating input devices types (according to their characteristics) rather than their instances. Indeed, integration based on types provides an adequate mean to increase architecture genericity. The HCI community has been proposing several taxonomies of input devices taking into account both their hardware and software aspects.

In [START_REF] Buxton | Developing a Taxonomy of Input, chapter 4[END_REF], the software side is prominent as the classification is more abstract and goes beyond the description of the physical capabilities of the input devices. They introduced the "virtual" and "logical" device concepts, which can be used to produce more versatile interaction techniques. The concept of virtual devices allows reasoning in terms of interaction methods without having to consider the input devices themselves. For instance, instead of designing the interaction techniques with low level mouse events (for instance using dx, dy relative quantity of movement as for a mouse), it is described using generic pointing events such as x, y screen coordinates. This allows replacing mouse input devices easily with other devices as long as they produce similar (compatible) pointing events. In order to support this, MIODMIT proposes the refinement of the virtual device concept into two distinctive components called Virtual Device and Logical Device as presented in the section dedicated to the architecture (see Fig. 3).

From a hardware perspective, we classify devices as in [START_REF] Palanque | Computer Discretized Interaction: From Continuous to Discrete and Back Again[END_REF] as according to the discrete versus continuous nature of events provided. At an abstract level, MIODMIT architecture remains independent and thus generic whatever the category (continuous or discrete) the device belongs to. Nevertheless, the device type will be taken into account at the refinement time (i.e. during the development of the architecture components). This way of dealing with these two types of devices has been identified when integrating different devices such as keyboards, mice, speech recognition, touch input, and more recently gesture input, eye-tracking and speech synthesis. The only constraint (to ensure the correct functioning of the final system) is to make sure that data processing is consistent both in terms of input and output for each component throughout the entire pipe-line of information processing (from input to output) as identified in [START_REF] Nigay | Multifeature Systems: From HCI properties to Software Design[END_REF].

In the literature, much less work has been done on addressing the output side of interactive systems and while a plethora of input devices taxonomies is available, output device taxonomies are seldom. Noticeable exceptions are [START_REF] Hinckley | Input/Output Devices and Interaction Techniques[END_REF] which provides characterization of both input and output devices and [START_REF] Rousseau | Multimodal output specification / simulation platform[END_REF] which is dedicated to multimodal output engineering. MIODMIT encompasses this work using the same decomposition for output devices as the one for input devices presented above.

MIODMIT: A Generic Architecture for Interactive Systems

The Multiple Input and Output Devices and Multiple Interaction Techniques (MIODMIT) generic interactive system architecture explicitly depicts the various components (both hardware and software) of an information pipe-line in modern interactive systems. In that sense, MIODMIT is compatible with the principles and objectives of the Model Driven Architecture approach at OMG (http://www.omg.org/mda). Such systems contain multiple input devices each providing an information flow that are usually fused with other ones to offer multiple (and often multimodal) interaction techniques. This architecture presents input and output flows as well as how they can be integrated altogether. The following sections present an overview of MIODMIT and detail functionalities and responsibilities of each component via an illustrative example.

Illustrative example with a simple JAVA application

In order to illustrate how MIODMIT is structured, we use a simple example application developed with Java Swing, presented in Fig. 1. This application allows users to add, modify and remove elements in a database. An element is composed of three attributes: a text field (the name), an enumerated field (the number of children) and a Boolean value (married or not). The list of elements in the database are displayed in the listbox (called mother list). Once added to the database, elements can be selected in that listbox to be deleted or modified.

In terms of input and output modalities, this application is standard, offering a mouse and a keyboard for input, and a computer screen for display.

MIODMIT Overview

MIODMIT is meant as a thinking and design tool for developers working on the development of advanced interactive systems. It seeks to clearly describe which components are to be designed, built or reused when envisioning such systems, and the interplay between these components. The overview of MIODMIT is presented in Fig. 2 while the full description of the generic architecture is provided in Fig. 3. Fig. 2 is described from top (left to right) and then towards bottom (rigt to left). The overview of the architecture is composed of several components each of them represented by a rounded rectangle. When developing systems using MIODMIT developers have to describe the precise behavior of each component. Due to space constraints, we cannot present it here but the interest reader can access full details in [START_REF] Cronel | Une approche pour l'ingénierie des systèmes interactifs critiques multimodaux et multiutilisateurs : Application à la prochaine génération de cockpit d'aéronefs[END_REF].

The grayed out boxes labeled "Input Device Type" handle events flow for each type of input device used (according to the classification presented in the related work section). For instance, having two mice and a voice-recognition system would require two separate "Input Device Type" boxes as they do not belong to the same type. The same holds for the output processing. Following the normal flow of events (in which the interactive system is idle waiting for input from users) a given "input device" sends events to the "driver & Library". The "input chain device type 1" transforms the raw data into higher-level information (e.g. transformation of the amount of motion of a mouse (dx, dy) into absolute coordinates for the mouse pointer).

Such information is then processed by the "input chains manager" (e.g. picking function connecting the input event to user interface objects) that possibly fuses information from the various input devices types. The input chain manager and its output counterpart are also responsible for managing dynamic reconfiguration of interaction when a failure occurs in the flow of events, thus being compliant with [START_REF] Navarre | A Formal Approach for User Interaction Reconfiguration of Safety Critical Interactive Systems[END_REF]. Fused information is then dispatched either directly to the "Dialog" or to "Global Interaction Technique" which behaves as a transducer as defined in [START_REF] Accot | A Formal Description of Low Level Interaction and its Application to Multimodal Interactive Systems[END_REF] and then dispatch information to the "Dialog". Both the "Dialog" and "Application Core" system have a similar responsibility as in standard interactive architecture models such as Seeheim [START_REF]Proceedings of IFIP/EG Workshop on User Interface Management Systems (November 1983[END_REF] or ARCH [START_REF] Bass | The arch model: Seeheim revisited[END_REF]. The "Functional Adapter" have a similar responsibility as the "Functional Core Adaptor" in ARCH [START_REF] Bass | The arch model: Seeheim revisited[END_REF]. The output part processing is a mirror of the input side. The "rendering system" component in the middle of the diagram includes immediate feedback function and more sophisticated state-based rendering functions.

3.3

Inside the Details of MIODMIT Fig. 3 presents the refinement of Fig. 2 making explicit both the content of each component and the information flow between components. Even in its detailed description, MIODMIT remains abstract on purpose which means that each component may be decomposed into several classes. More details about that aspect are given in the case studies section.

The MIODMIT architecture, presented in Fig. 3, uses the AADL notation [START_REF]SAE-AS5506B: SAE Architecture Analysis and Design Language[END_REF], a standard for describing software architecture which been applied in several domains including automotive and aeronautics. Other notations could have been used but the standard nature of AADL eases its understanding. We do not provide here a description of the elements of AADL but a key is provided at the bottom of Fig. 3.

Input devices

The first layer of this interactive system architecture is composed of the physical input devices directly handled by the users. In Fig. 3, they are defined with a number corresponding to their type and an ID corresponding to their number within a given type. For instance, two input devices (Input Device 1 ID 1 and Input Device n ID n) represent the fact that both input devices are similar (two mice for instance) but with small functionalities that need to differentiate their drivers. If two identical mice were to be connected, ID will then allow to differentiate them. Fig. 3 only details one generic type of device. The addition of a new modality associated with a new input device results in a new set of input devices, new driver(s) and a new input chain, represented within a gray rectangle. In the case of our Java app example, the mouse and keyboard are the input devices.

Drivers

Usually only one device driver is used in an operating system per type of device at a time. This software component is in charge of retrieving (or receiving) raw information from the hardware input device and makes it available for the upper layer. The driver may also allow some control over the hardware components of the physical input device such as the sampling frequency (e.g. of the touch acquisition in [25]) or to provide user identification [START_REF] Vu | Distinguishing users with capacitive touch communication[END_REF]. Drivers are either provided together with the hardware (typically for specific non-standard input devices such as gesture tracking cameras) or by the operating system when the input device is rather standard or has been around for a significant amount of time (typically several years). For instance, mouse and keyboard drivers are handled at the OS level. This component is usually OS dependent and includes the libraries and the API needed for using the device. The API can be a composite object in order to translate information from a low-level language or OS level, to the higher one in the information flow.

Virtual Devices and Logical Devices

Virtual devices are necessary extensions to the logical device concept of Buxton [START_REF] Buxton | Developing a Taxonomy of Input, chapter 4[END_REF] as we take into account explicitly both hardware and software aspects. For instance, as quickly introduced in the related work section, for a mouse, the virtual device will be a software component mirroring the state of each physical button (pressed or released) and the amount of motion (dx, dy), while the logical device handles the cursor pointer positions (x, y). It is important to note that this is independent of the rendering aspect that is handled in a dedicated set of components ("rendering system" and "output device type" in the architecture). Indeed, these (x, y) values are abstract and how they are presented to the user or fused before rendering is a responsibility not belonging to the input chain.

This distinction allows using a single virtual device, with different logical devices in order to propose different interaction techniques. For instance, with a gesture recognition device such as Leap Motion, with one virtual device (a computerized hand), one logical device could be dedicated to two-dimension interactions, as a pointing device, while another could be used in a 3D environment.

Virtual and logical device components are transducers (as defined in [START_REF] Buxton | Developing a Taxonomy of Input, chapter 4[END_REF]) as they provide processed information to a higher level. Virtual devices can be dynamically instantiated as with plug-and-play devices. Logical devices might also be dynamically instantiated at operations time, as for multi-touch input devices where a "logical input device" component is created each time a finger touches the device [START_REF] Hamon | Formal description of multi-touch interactions[END_REF].

Input Manager

The "Input Manager" component manages the availability and instantiation of devices in order to address configuration and dynamic reconfiguration. This layer is composed of several managers, one per configuration of input devices, each of them being responsible for handling the dynamic aspects of input devices of the same type. At initialization time, these managers are responsible for the instantiation of the input devices and inform "Logical Input Devices" components.

Input Configuration Manager (Input Chains Manager)

One of the specificities of MIODMIT is its intrinsic ability to support dynamic reconfiguration of the interaction techniques. It is a functionality of paramount importance for different systems such as: critical systems, systems with a long exploitation life, systems with long start up procedures (such as civil aircrafts), or systems with a high replacement cost. Indeed, if one or several modalities fail at runtime (also called operation time), it may be critical to offer other modalities for allowing operators to perform their tasks even with degraded or less efficient interactions. To this end, MIODMIT includes an "input configuration manager" which is responsible for handling reconfigurations. It is a unique software component, whatever the amount of input devices is. At runtime, the "input configuration manager" component links the (possibly) dynamically instantiated "logical input devices" components to the relevant "interaction transducers" which are in charge of processing users' input.

Beyond that linking aspect, this manager is in charge of verifying the physical input device configurations to ensure that the current configuration still allows users to trigger all the needed events, and thus to produce all the information that the interactive application is expecting. In the case of input devices failure, the manager would reconfigure the interaction in such a way that the remaining physical input devices could compensate the failing ones (provided that this aspect has been addressed at design time). An example of a behavioral description of such a reconfiguration manager can be found in [START_REF] Navarre | A Formal Approach for User Interaction Reconfiguration of Safety Critical Interactive Systems[END_REF] (and is highlighted in the case study section). It is important to note that in critical systems, the failure must have been expected and so the reconfiguration possibilities are predefined (so that operators can be trained) and not dynamically made.

Input Device Type and Output Device Type

The gray boxes labelled Input Device Type and Output Device Type do not represent component of the architecture. They represent the fact that the components "drivers and libraries" and "input/output chain device type 1" have to handle all the input/output devices of the same type. Mouse and keyboard are examples of different input device type. A screen and a loudspeaker are examples of different output device type.

Picking Functions (Input Chains Manager)

This component channels the input event to the intended sensing zones. These functions are generally handled by the OS for standard devices, but for non-standard interaction, recipients of events must be designed and implement a picking function.

Interaction Transducers (Global Interaction Techniques)

The "interaction transducers" are responsible for generating the high level user events used by the application to trigger the various commands it provides. Usually, one "interaction transducer" is associated with one global interaction technique. These "interaction transducers" perform the recognition of a specific interaction technique which is not linked to a sensing zone such as a button (e.g. an interaction technique such as a double click is a composition of 2 simple clicks performed within a pre-defined temporal window and the click is a succession of a "down" event followed by an "up" event on a button). In the case of multi-touch interaction techniques, the transducer receives fingers' (logical devices) movement and triggers the appropriate high level events based on the gesture recognition or the clustering of fingers. A basic transducer description for two mice can be found in [START_REF] Buxton | A three state model of graphical input[END_REF], a more detailed one in [START_REF] Accot | A Formal Description of Low Level Interaction and its Application to Multimodal Interactive Systems[END_REF], one for a keyboard in [START_REF] Accot | Formal transducers: models of devices and building bricks for the design of highly interactive systems[END_REF] and one for a tactile screen in [START_REF] Hamon | Formal description of multi-touch interactions[END_REF]. A detailed behavioral description of such component can be found in [START_REF] Hamon | Multi-Touch Interactions for Control and Display in Interactive Cockpits[END_REF]. The global interaction technique component is thus made of multiple interaction transducers, each of them bringing defining one or several interaction technique. The global interaction techniques are not necessarily linked to a special zone. For example, on a Samsung smartphone with Samsung Experience, a palm swift on the screen will take a snapshot of the screen, whatever the state of the OS is or whatever application is launched.

Sensing Zone (Dialogue and Application Core)

To match the WIMP paradigm, "sensing zone" components include concepts such as interactive widgets (e.g. radio boxes, buttons …). With post-WIMP interaction, those objects are not enough, thus "sensing zones" are to be defined, containing representation parameters (coming from design), their precise behavior as well as how this behavior is triggered (i.e. their local interaction technique). For instance, a "sensing zone" reacts to a specific spoken sentence when highlighted, whereas the rest of the application will not react to the same sentence. The "ok Google" sentence always triggers an event on Android, whichever app is currently active. It is thus a nice example of a global interaction technique whereas a sentence such as "tell me if it's going to rain today" triggers a result only when the Google Now app is active.

Application Dialog

The "Application Dialog" component is a composite component and represents the functional behavior of the application as defined in ARCH [START_REF] Bass | The arch model: Seeheim revisited[END_REF]. The "Activation Function" component activates or disables the "Sensing Zone" depending on the current state of the application.

Functional Adapter and Application Core

The "Functional Adapter" component adapts the flow of information from the "Dialog" to the "Application Core" as defined in ARCH [START_REF] Bass | The arch model: Seeheim revisited[END_REF]. The "Application Core" is the component that is responsible of providing the data and services of the application.

Rendering System

The rendering system is composed of several components of two main types: the "rendering functions" and the "rendering scenes". The "rendering function" describes how to present the information of a specific state which might be distributed information in the other components of MIODMIT. The immediate feedback is an example of such a rendering function depending mainly on the information in components "logical devices" and "global interaction techniques". A "Rendering Scene" component composes all rendering function of a given type (e.g. a graphical scene, a sound scene …). These components prepare the final composition of the information before the output processing. They are thus connected to one or several output devices which can effectively present the information to the users.

Output Chain Manager

The "Output Chain Manager" offers the same functionalities as the "Input Chains Manager" presented above. Nonetheless, the main difference is that while the input is eventbased, the output is state-based, thus, there is no equivalent to the output, of the "Global Interactions Techniques" component.

Fusion and Fission Engines: A Distributed Function

MIODMIT does not include specific components for fusion and fission as other architecture do [START_REF] Vennelakanti | The picture says it all!: multimodal interactions and interaction metadata[END_REF]. Indeed, in that case, only one device was used (a photo browser) and fusion was located by the device. In MIODMIT, fusion can occur at different levels (e.g. low level with two input devices for a CTRL+Click event or high level where merging speech sentences with mouse event for a "Put that there" multimodal command). Fusion and fission mechanism are thus to be specified within components as for example, fusion engines within the "Global Interaction Technique" component to fuse two (or more) high-level events into a multimodal interaction technique. Engineering issues of multimodal input interactions for a single user have been studied and classified in [START_REF] Buxton | Developing a Taxonomy of Input, chapter 4[END_REF] and a taxonomy based on this classification has been proposed in [START_REF] Lalanne | Fusion engines for multimodal input: a survey[END_REF]. Indeed, the various models identified in that survey spread over several components of MIODMIT.

Tune-on-Demand Process

According the type and the number of input and output devices and according to the complexity of the multimodal interaction techniques the generic MIODMIT architecture has to be adapted (tuned) to the specificities of the application under consideration. This section presents a systematic process for tuning MIDOMIT that will be exemplified on case studies in section 5.

Prototyping

Fig. 4 presents a process to tune the generic architecture into a specific one. The top left-hand side (labeled prototyping) represents an abstraction of the user-centered design process of interactive systems. This part is presented in a very abstract way only highlighting the productions that are used as input in the other parts of the process.

Tuning the Generic Interactive System Architecture

The right-hand side of the diagram (labeled tuning) corresponds to the tuning-on-demand part of the proposed approach while the bottom part focuses on the implementation aspects. These three main phases have been highlighted using gray boxes with dashed lines in Fig. 4. The tuning-on-demand step refines the diagram by concretizing each component of MIODMIT making explicit (in the diagram):  where software parts (e.g. API; libraries …) provided by the input device's manufacturer are distributed in the architecture,  if existing code has already been produced where it has to be distributed in the architecture,  which component have to be coded from scratch. It is important to note that due to an absence of standards, provided software packages often require to split or merge functionalities in order to fit in the structure of the generic architecture. For instance, the Leap Motion is provided with three software packages: the driver (for a dedicated OS), the library (making it possible to exploit the driver on a dedicated OS and integrating C and C++ API), and a wrapper for high-level programming language (e.g. Java). The driver corresponds to the component "Driver instance" in MIODMIT while the functions in the Leap Motion library cover the "virtual device" component and several interaction transducers (e.g. detection of a circle called Cir-cleGesture) located in the "Global Interaction Techniques" component. The wrapper provides functions for all the other components of the input flow but only covers a very limited set of functionalities. The provided set of interaction techniques is basic and has to be extended according to the expected use of the Leap Motion in the application. This is a clever design choice made by Motion manufacturers to allow direct exploitation of the Leap within an application by providing standard interaction techniques but making it also possible to easily extend this set according to the designers' needs.

Illustration of the Process with the Java Application Example

The result of the application of the tune-on-demand process described above on the Java Application illustrative example is presented in Fig. 5. The Figure can be split in three sections. The left-hand side represent the physical input and output devices used with the Java Application. The center represents the MIODMIT components that are taken care of by the operating system (surrounded by a grey box named "Black Box: OS Windows"). While no access to the Windows source code is given, it remains possible to describe the OS behavior using MIODMIT. Indeed, drivers for a keyboard, mouse and screen as well as part of the rendering system are an integral part of modern OS. The OS merges input and output aspects at hardware level and thus only one component handling both input and output devices drivers is represented. The input and output chains components are merged handling both abstract input abstraction, immediate feedback (position of the mouse cursor on the screen) and graphical rendering (related to the presentation part of the widgets, e.g. display of items in the list box). The window manager of the OS handles picking function (identification of the widgets which are recipients of user input) thus merging input and output chain managers. The right-hand side describe the four components from the MIODMIT architecture that have to be implemented.

A Real World Case Study: A Weather Radar

This case study demonstrates a more complex tuning of the generic interactive system architecture and addresses the issues of integration of input devices as well as the possibility to reconfigure the interaction techniques dynamically. This case study comes from the field of aeronautical critical systems and thus must follow development processes such as the DO178C [START_REF]/ ED-12C, Software Considerations in Airborne Systems and Equipment Certification[END_REF] and certification specifications as defined in CS-25 [START_REF]CS-25 -Amendment 17 -Certification Specifications and Acceptable Means of Compliance for Large Aeroplanes[END_REF]. In the context of this paper these standards make it impossible to use in critical applications software components for which the code is not available. This prevents using Operating Systems offering integrated handling of devices, drivers… as was the case in the previous example. Indeed, every component of the architecture must be specified and developed from scratch and may be subject to inspection by the certification authorities.

The case study corresponds to a subset of an envisioned weather radar system of civil aircraft providing atmospheric data to the flying crew. This weather radar is controlled by a set of input devices (allowing input from the flying crew) and the processed information is graphically rendered on a computer screen in the cockpit (usually called Navigation Display). This application uses colors and shapes to present information such as dimensions, distance and density of clouds (as visible on the bottom of Fig. 6).

The central lower part of the interface is composed of a map and a custom selector:

 The map displays the aircraft's position and current heading (small numbers from 0 to 360 on the outside circle) as nearby traffic (small blue plane near 40.0 number on the inner circle) and weather information (colored zone on the righthand side of the image).  The custom selector (the small circle at the edge of the biggest circle) controls the heading of the aircraft. When modified, it modifies the information presented in the map display.

2. The upper left part of the interface is composed of three toggle buttons and a custom discrete slider. They provide the following controls:

 The "HEADING" toggle button (top) controls the heading validation and triggers heading changes,  The "ARC" and "ROSE" toggle buttons control the two mutually exclusive display modes of the navigation display,  The custom slider (labeled "RANGE SLIDER") defines the zoom level of the navigation display in nautical miles (10nm, 20nm …). Current selection is 160nm.

3. The right upper part of the interface of Fig. 6 called Weather radar control is composed of two widgets:

 A toggle button "WXR" control the weather visibility on the navigation display,  A custom discrete slider controls the weather radar orientation. The informal description provided below is representative of the potential use of several redundant modalities for such application. It is important to note that design aspects of this application is beyond the scope of this paper both in terms of usability and operational validity. In the proposed case study, operators are able to use multiple input devices, modalities and interaction techniques:  Input devices: interaction can take place using a KCCU (Keyboard Cursor Control Unit) which blends a graphical designator (a track-ball) and a keyboard. Two KCCUs are available in the cockpit (one for each pilot) thus enabling parallel interaction with two mice. Such interactions and input devices are available in most recent large civil aircrafts e.g. Airbus A380, A350 and Boeing 787. In the case study, it is also possible to interact in a tactile way using the multi-touch screen presented in Fig. 6.  Interaction techniques and modalities: on top of these input devices, interaction can take place in various ways. Using the multi-touch screen, operators can perform "Flick 2 fingers", "Tap", "Tap long" and "Drag" which are global interaction techniques (i.e. they can be performed everywhere on the screen). Mice are used for triggering events on the WIMP interactors while multimodal events (e.g. "Flick 2 fingers") are assigned (as defined in CARE properties [START_REF] Coutaz | Four easy pieces for assessing the usability of multimodal interaction: the CARE properties[END_REF]) to the touch screen. In case of a touch screen failure, the mice can be used to trigger high level events previously devoted to the touch screen. In that case the application must be able to switch from one configuration to another. While multiuser interactions with two mice for triggering equivalent multi-touch interactions might be cumbersome, guaranteeing the possibility of events triggering in presence of faulty touch devices was a requirement.

Overview of the Tuned Generic Interactive System Architecture

According to the process in Fig. 4, the first step, from the prototyping phase, is to refine MIODMIT by specifying all the components. During this refinement, it is important to make explicit where the software provided by the input devices manufacturers is located in the diagram. It is important to note that currently, software packages provided by manufacturers often require splitting or merging in order to fit in the structure of the architecture.

As for the description of MIODMIT in previous sections, Fig. 7 presents an overview of the architecture tuned for the weather radar case study. The gray boxes on the left-hand side of the figure correspond to the input and output devices available in the case study. These components will be detailed further in the following sections. The input devices provide input to the "Input chains manager" component. The "input chains manager" component is able to switch between two predetermined input configurations:

 The normal one where touch and mice are available,  The degraded configuration (resulting from a loss of tactile functionality). This behavior is similar to the one proposed in [START_REF] Navarre | A Formal Approach for User Interaction Reconfiguration of Safety Critical Interactive Systems[END_REF] where reconfiguration was performed at the interaction technique level for keyboards and mice.

As there is only one output device in this case study, there cannot be several output configurations. The "output configuration manager" component is therefore not necessary.

The "Global Interaction Techniques" component contains several transducers that produce high-level events such as "flick-2-fingers", "Combined-Click", "Tap", "Drag", etc. Part of the behavior of those transducers consists of fusing input from multiple input devices thus implementing functionalities of fusion engines. As the weather radar application is a real case study in aeronautics, the behavior of the "Core Application", "Functional Adapter", "Dialog" and a part of the "rendering system" has already been coded. The process of tuning the architecture to include touch and mice interactions does not deeply impact the existing application. Those modifications mainly consist of ensuring that the components connect (plug) and function altogether (play).

The remainder of the "rendering system" concerns mostly the immediate feedback that has to be linked to the two input chains and more particularly, to the "abstract cursor" from the mice input chain and to the "finger" from the touch input chain. These aspects, which are at the center of the contribution, are detailed in the following section.

5.3

Application to the Case Study: Tuning MIODMIT Input Device Type 1: Touch Screen Fig. 8 presents the tuning of the gray box "Input Device Type 1" from Fig. 3 for a touch-screen device. Adding a touch screen device requires a touch driver (see [START_REF] Deshayes | A generic framework for executable gestural interaction models[END_REF]). All the components within the "Input Chain Touch Screen" are within the Java Virtual Machine (JVM) via the use of a dedicated Java library (JavaFX). These events are retrieved by the "virtual screen" component while the "Touch Screen Manager" instantiates the various logical input devices (fingers in this case) one each time a finger is detected. The "Touch Screen manager" link Fingers events and data to the registered interaction transducers (within the "Global Interaction Techniques" component) as, for instance, the "Flick 2 Fingers" one detecting the eponym interaction.

Input Touch Screen

Drivers & Librairies

Finger n

Touch driver Finger 1 Touch Screen

Touch Screen Manager

Virtual screen

To Rendering System Fig. 8. Tuning MIODMIT for a touch-screen device

Input Device Type 2: Two Mice

Even though the mouse is a standard input device, as we use multi-mice interactions, we cannot use drivers provided natively by the operating system. The data from mice is accessed by having a thread polling the JInput library information (e.g. JInput.dll for windows). The two mice are then handled by the "mice manager" (Fig. 9) that instantiates two virtual mice and two abstraction of cursors. The "mice manager" links these cursors to "interaction transducers" within "Global Interaction Techniques" that recognize high level events such as Click, DoubleClick, etc. and possibly multimodal ones such as combined clicks as defined in [START_REF] Accot | A Formal Description of Low Level Interaction and its Application to Multimodal Interactive Systems[END_REF]. The Leap Motion is provided with three software packages as explained in section 4.2.

While the wrapper provides functions for several components of the input chain (namely "Virtual Hands", "Leap Manager", "Global Interaction Technique") it only covers a very limited set of expected functionalities for instance only basic interactions (e.g. KeyTap or CircularGesture) are recognized (in the "Global Interaction Technique"), partial transducer for the cursor is provided ...

As the case study uses a non-provided interaction technique named Hand-Flick (corresponding to a mid-air "Flick 2 Fingers") the "Global Interaction Technique" component has to be programmed exploiting the functions of the API. Adding this new device as an equivalent modality does not impact the rest of the implementation as long as it provides the same high level events.

Conclusion and Perspectives

This paper presented a generic interactive system architecture and its associated tuning process for the engineering of interactive systems. It addresses the issue of the complexity of engineering current interactive systems integrating non-standard input and output devices and offering multimodal interactions. Both hardware and software aspects are described within a single framework. The generic interactive system architecture makes explicit the relationships between input devices and interaction techniques. It also makes explicit how such elements are related to implementation considerations involving various software entities such as device drivers, transducers, toolkits and APIs. As such, the integration of novel interaction techniques such as gesture interaction is simplified and better structured, and can be tuned depending on the needs of specific applications. The illustrated development process presented helps demonstrating how the MIODMIT generic interactive system architecture can be applied. An example in the field of critical systems, in our case a weather radar panel for civilian aircrafts, shows a real world application of our approach.

The proposed approach brings multiple benefits including the division of complex interactive systems into generic components loosely coupled and highly coherent thus enforcing the locality of modifications. It also brings research work achieved in the area of critical interactive systems (such as self-checking interactors 35 and reconfigurations) to the broader world of mainstream interactive multimodal systems.

Due to its white box principle (each component of the architecture contributes to the processing of input and the production of output) the approach is particularly suitable for interactive critical systems where each component has to be auditable. However, as demonstrated by the classical interactive application example it is also applicable to the engineering of more mainstream interactive systems. The only difference is that some components are directly managed by the programming environment (Java and Java VM) or the operating system on which they are executed.

Fig. 1 .

 1 Fig. 1. Simple JAVA application

Fig. 2 .

 2 Fig. 2. Overview of MIODMIT

Fig. 3 .

 3 Fig. 3. Multiple Input and Output Devices and Multiple Interaction Techniques expressed in AADL [33]

Fig. 4 .

 4 Fig. 4. Process of tuning-on-demand

Fig. 5 .

 5 Fig. 5. MIODMIT tuned for Java Application: most of the components of the architecture are integrated within the operating system (especially management input and output devices).

Fig. 6 .

 6 Fig. 6. User interface of the weather radar application

Fig. 7 .

 7 Fig. 7. MIODMIT tuned for the Weather Radar Application

Fig. 11 .

 11 Fig. 11. Tuning MIOMIT for a Leap Motion Device

Input Chain Mice

Output Device: Screen

The management of the screen is straightforward as there is no multiplicity of devices. As there are no redundancies of output modalities in this case study, there is no need for an "output chain manager" component (see Fig. 10).

Application to the Case Study: Implementation

Following the process in Figure 4 after MIODMIT tuning, each remaining component has to be implemented. Implementation concerns the definition of the behavior of each component of the tuned architecture. Such implementation can be done using different programming languages being formal or not. In previous work ICO-based descriptions were used for some of the components (e.g. "Global Interaction Technique" component [START_REF] Kraleva | On model architecture for a children's speech recognition interactive dialog system[END_REF], "Dialogue" [START_REF] Hamon | Formal description of multi-touch interactions[END_REF] component…). Work such as [START_REF] Deshayes | A generic framework for executable gestural interaction models[END_REF] has provided C implementation of all the components of the "Input Chain Kinect". In section "Tune on Demand Process" we have detailed the various implementation steps that are thus not duplicated here as they are generic to every type of application.

Application to the Case Study: Adding a Device

One of the most important aspects of MIODMIT is its modularity providing flexibility and modifiability to the applications designed. This section highlights the modifications to be made when an additional input device is added, here a Leap Motion (see Fig. 11).

Once the device is chosen, two processes can be done in parallel. The first one is to prototype the interaction using the new device (design, evaluation … etc.). The other is to tune MIODMIT for the chosen device and integrate the tuning within the existing application. In the following, we describe how to add a Leap Motion hand gestures tracker as well as corresponding gesture-based commands to our case study.