Julien Mallet
email: julien.mallet@telecom-bretagne.eu

Siegfried Rouvrais
email: siegfried.rouvrais@telecom-bretagne.eu

Style-Based Model Transformation for Early Extrafunctional Analysis of Distributed Systems

In distributed environments, client-server, publish-subscribe, and peer-to-peer architecture styles are largely employed. However, style selection often remains implicit, relying on the designer's know-how regarding requirements. In this paper, we propose a framework to explicitly specify distributed architectural styles, as independent models of the application functionalities. To justify feasibility and further benefits of our approach, we formally define three classical distributed architectural styles in a process calculus. Our proposal then opens up the way to a systematic composition of functional models with architectural style models as an endogenous transformation. Comparative analysis of extrafunctional properties could then be proposed at the early design stages to guide the architect in stylistic choices.

Introduction

Architectural styles build up conventional structures for designing large systems at a software architecture level. Different architectural styles enforce different quality attributes for a system [START_REF] Bhattacharya | Predicting architectural styles from component specifications[END_REF]. Within distributed systems, an application often relies on an architectural style which defines connections between application components (e.g. simple message interaction models, client-server, publishsubscribe, peer-to-peer). Most often, style selection remains implicit and tacit [START_REF] Kruchten | Building up and exploiting architectural knowledge[END_REF], relying on the architect's know-how regarding requirements. Choosing an inappropriate architectural style can lead to major impacts on the properties of a system or application [START_REF] Shaw | Comparing architectural design styles[END_REF]. Moreover, extrafunctional properties such as security, performance, reliability or scalability are not easily grasped at an abstract description level. Such concerns thus tend to be forwarded to the end of the design process lifecycle, though they are rough to manage once a style has been selected and a system designed. They are however the critical selection criteria to better manage the development process, regarding system's internal and external properties. Specifying a distributed system's software architecture classically requires to model architectural components and connectors, and some of their extrafunctional properties. However connectors, as communication mediums, are parts of distributed styles having their own comprehensive, intrinsic, and emergent properties. To manage extrafunctional properties at early design stages, we propose to specify distributed architectural styles independently of the functional model. By separating concerns in a framework, we then propose a model transformation corresponding to a composition of an abstract functional model with styles predefined in a repository. Functional and especially extrafunctional analysis could then be investigated to compare models and guide the architect faced with several distributed design alternatives. To justify the approach, we restrict to three common distributed styles descriptions in this paper, using structure diagrams and process calculus: client-server [START_REF] Orfali | The essential client/server survival guide[END_REF], publish-subscribe [START_REF] Eugster | The many faces of publish/subscribe[END_REF] and peerto-peer [START_REF] Androutsellis-Theotokis | A survey of peer-to-peer content distribution technologies[END_REF]. A distributed version control system with its functional model is proposed as a case study.

The remainder of this paper is organised as follows. Section 2 introduces our framework and proposes some common distributed architectural styles and their specifications using a process calculus. Section 3 presents an independent functional model and proposes a specification example on the version control system case study. The systematic composition of a functional model with an architecture style model is described in section 4 through the application example. Section 5 addresses extrafunctional properties integration in the framework, while section 6 presents related work. Finally, section 7 concludes this paper with a summary and an outline of further research.

A Framework with Distributed Architectural Styles

The motivation of the proposed framework presented in figure 1 is to guide the architect in choosing the right distributed architecture style in conformance with extrafunctional requirements. It follows a model driven engineering approach [START_REF]Model Driven Architecture Guide, version 1[END_REF] and addresses the quality of the target system's software architecture for early design decisions. First, the designer specifies system functionality using a style-independent model (SIM). This model is purely functional: the services are provided in an ideal structureless-environment. However, application components in a distributed system require some interaction mechanisms for coordination and communication. As early proposed in the software architecture community [START_REF] Garlan | An introduction to software architecture[END_REF], architectural styles provide conventional structures for building large systems [START_REF] Bushmann | Pattern-Oriented Software Architecture: A system of patterns[END_REF][START_REF] Shaw | Toward boxology: preliminary classification of architectural styles[END_REF]. Such structures are the primary models for distributed interactions. Connectors, as interaction mechanisms, are the principal structural elements for a boxology [START_REF] Shaw | Comparing architectural design styles[END_REF] of distributed architectural styles. Within distributed systems, the client-server architectural style [START_REF] Orfali | The essential client/server survival guide[END_REF], based on the request-reply protocol, is still predominant. With Web generalisation, related styles like serviceoriented or Representational State Transfer (REST [START_REF] Fielding | Principled design of the modern web architecture[END_REF]) architectures are now taking a major position. So far, mechanisms for coordination and communication based on push-like models (e.g. message sending) or pull-like models (e.g. request-reply) are structural elements of architectural styles. Thus, we propose to gather distributed architecture styles in a repository of style definition models (SDM). Those models, having their own extrafunctional characteristics, can be early analysed in light of extrafunctional requirements.

Extrafunctional properties (e.g. security, performance, scalability) are key elements to guide the design decisions. Our transformation model consists in composing the required functional services with a given distributed style available in the repository. A distributed architectural style candidate can first be selected in front of quality attributes. The resulting style specific model (SSM) represents a possible system's architecture model which can be compared with other SSMs using functional and extrafunctional analysis. The framework makes it possible to choose, at upper stages, possible styles thanks to the extrafunctional properties. After analysis, if a proposed style specific model does not guarantee the extrafunctional requirements, the architect may modify or weaken some of the requirements until finding an appropriate style, or introduce specific mechanisms (e.g. patterns) in the specified system's software architecture to satisfy requirements.

Three Classical Distributed Architecture Style Models

Client-server, publish-subscribe, and peer-to-peer styles are largely used for distributed applications. Such styles encourage reusability, system comprehension, and analysis by using well-known interaction mechanisms. These mechanisms predominantly rely on push or pull models. Style variants exist, but they share common characteristics at an abstract level. In the classical client-server style, a client component requests a service through a remote invocation to a server component. Often synchronous, this interaction mechanism follows a pull model based on a request-reply protocol. In the publish-subscribe style, components are either announcers or listeners of events. By registering through an event manager, listeners are asynchronously informed of events most often through a push model. In the decentralised peer-to-peer style, where a peer represents a component, overlays, as logical networks, are dynamically constructed or maintained. For instance, by using a pure pull model between peer neighbours or by combining the pull with a push model restricted in depth, this style is much adopted in mobile or ubiquitous environments.

The distributed architecture styles have emergent extrafunctional properties. For example, the publish-subscribe and peer-to-peer styles are mostly known to be scalable and reliable. Moreover, the publish-subscribe style generally guarantees the anonymity of the announcers. However, these intrinsic properties mainly arise from empirical studies and not from systematic evaluations on style models.

Modelling Architectural Styles

Magee and Kramer [START_REF] Magee | Concurrency: State Models and Java Programs[END_REF] provide elements of style specification using the Finite State Processes (FSP) process calculus. For our purpose, we expand their style examples to create a first repository of distributed styles, independent of any application functionalities. Other formal approaches could have been addressed, but FSP process calculus, with its associated LTSA tool (i.e. model-checker), is suitable for a comprehensible demonstrator for a model transformation. For the sake of clarity, the three classical distributed styles addressed in this paper are shown hereafter as structure diagrams of processes (i.e. components as boxes in figures) and ports or events (i.e. bullets in figures). Note that the structure diagrams are only graphical representations of the FSP expressions as defined in [START_REF] Magee | Concurrency: State Models and Java Programs[END_REF] (e.g. the notion of provided/required ports does not exist). Elements of syntactical FSP expressions for client-server and publish-subscribe styles can be found in [START_REF] Magee | Concurrency: State Models and Java Programs[END_REF]. We detail the FSP expression only for the client-server style.

Figure 2 presents the generic client-server style, through the structure diagram, where several clients call services from the server and obtain the associated result. The clients are introduced by the processes CLIENT (stacked boxes represent identical processes). A given client will always request the same service (introduced by its parameter s). Furthermore, each CLIENT process is statically linked with one distinct SERVER process that responds to its request (there are as many SERVER as CLIENT processes). For model transformation, in order to further compose the style-independent and style definition models, the clients provide a service[s][d] event corresponding to an external call to the service s that returns a result d, and the server offers a process service event corresponding to an external service computation.

call[s] wait[d] call[s] reply[d] request[s] reply[d] process_service[s][d] service[s][d] CLIENT(s) SERVER set Data = {d1,d2,d3,d4} set ServiceId = {s1,s2} set Clients ={c1,c2,c3} CLIENT(S='si) = (call[S] -> wait[d:Data] -> service[S][d] -> CLIENT)+{call[ServiceId]}. SERVER = (request[s:ServiceId] -> process service[s][d:Data] -> reply[d] -> SERVER). ||CS EX = (c1:CLIENT('s1) || c2:CLIENT('s2) || c3:CLIENT('s1) || Clients:SERVER) /{forall [c:Clients]{[c].call/[c].request,[c].reply/[c].wait}}.
In addition, figure 2 presents the corresponding FSP expression and an example of an instanced client-server style (process ||CS EX). Three sets are introduced: Data as the possible results, ServiceId as the service names offered by the server and Clients as the identifiers of the client processes. A CLIENT process calls the service (event call[S]), then awaits synchronously the result (event wait), forwards it through the service event to external components and iterates. Similarly to [START_REF] Magee | Concurrency: State Models and Java Programs[END_REF], the CLIENT process uses the alphabet extension operator (noted +) in order to ensure a suitable synchronisation between the clients and the server and takes the service name as parameter (its default value is si). The SERVER process awaits a service request (event request), then requests the result computation (event process service) and returns the result (event reply). Finally, the ||CS EX client-server style example is the parallel composition of the clients (in our case, three clients: c1, c2 and c3) with as many server processes prefixed by the identifier of the corresponding client (expression Clients:SERVER). Corresponding to architectural attachments, the mapping between client and server events associates, respectively, the call and wait events of the client with the request and reply events of the corresponding server.

Note that the definition of the client-server style is generic : we just have to define the Data, Client and ServiceId specific sets in order to instanciate the style to a client-server application.

Relying on [START_REF] Magee | Concurrency: State Models and Java Programs[END_REF], figure 3 presents the publish-subscribe style where one announcer (process ANNOUNCER) publishes events to zero or more listeners (process LISTENER). The EVENTMANAGER process carries out the event broadcasting. A listener can register his/her interest in a particular pattern p with the event manager through the register[p] event. Each time the announcer produces the pattern, only the registered listener is notified. Finally, a listener can deregister himself through the deregister event. In order to specify this style in FSP, one event manager process is introduced per listener. When an event announcement is produced, the event managers forward it to their associated registered listeners. Finally, figure 4 presents the peer-to-peer style in its flooding version where peers collaborate through a pull model (e.g. like in the Gnutella scheme). Since many variants of peer-to-peer styles exist, we limit our example to the simple flooding version. Each peer is represented by a PEER process taking its number as parameter. It offers two services as interface: service[s][d] for requesting a service s returning the result d and process service[s][d] for requesting external components. A FLOODER process per peer is associated with each link between peers. In the figure 4, the peers of number i and j are neighbouring. The FLOODER sends the requests to the peer neighbours (event call) then awaits the response from the latter (event wait). Therefore, the topology of the considered peer-topeer network is modelled by the FLOODER and PEER links. At the time of a service[s][d] event, the PEER process initiates the flood request to its neighbours with the begin flood event. The FLOODER process carries out the flood, then obtains the result d thanks to the wait[i][d] event. Finally, a PEER process receives the result through the end flood event and transmits it to the requester.

request[p][s] reply[p][d] process_service[s][d] service[s][d] begin_flood[j][s] end_flood[j][d] end_flood[j][d] call[i][s] wait[i][d] begin_flood[j][s] PEER(i) FLOODER(i,j)
The styles presented above and contained in the repository are distributed architecture styles rather than communication ones in the sense that they describe interaction between components. Due to the style transformation (presented section 4), the intended interaction mechanisms will be introduced into the functional model using the selected style model.

Functional Model

In the framework, the designer first specifies his system in a style-independent model, with a pure functional point of view set in an ideal non-constrained environment: extrafunctional properties are not taken into account, and architectural stylistic elements are abstracted.

Thereafter, we exemplify this principle on a version control system as a classical distributed case study. A version control system (e.g. CVS) allows several users/developers to modify a set of shared files concurrently. Each developer has a copy of the files (most often in a repository) which he/she can modify locally, using a write command. The local modifications are spread to other developers with a commit command, using the versioning system. Update command brings local copies up-to-date with the last shared version.

Pure Functional Model of a Versioning System

The style-independent functional model of a distributed application is defined by introducing, for each user, the three following components (defined by one or more processes as the application requires):

-User: operations from the user's point of view (i.e. update, write, and commit in the example). It introduces the available services thanks to shared events; -RemoteState: operations for data information obtained from other users due to distribution (i.e. future components for interaction mechanisms); -Safe: business rules specified through authorised sequences of events in the system, to guarantee application requirements in functional terms.

Our abstract level approach is general and can be applied to other distributed applications as long as they could be decomposed into the three previous components. For our case study, each preceding component is specified by one FSP process (i.e. User, RemoteState, Safe) as presented in the structure diagram of figure 5. Each User process of the system takes a unique user number I as parameter. It holds and updates the state of its local copy of the repository (i.e. either it is identical to the reference repository or it contains some update). Any user can modify the file locally (event write), update his/her local copy with the repository (event update) or update the repository with his/her local copy (event commit). Moreover, the User process offers a service to read its local state thanks to the localState event. In the structure diagram, the User(I) and User(J) are similar except for their number. We distinguish them in order to present the specific shared events between User and RemoteState processes. The RemoteState(I) process abstracts the overall remote state for the i th User process. The remote state is either remotely non modified (other users have not modified the repository since the last local update) or remotely modified (one or more other user has modified the repository). So, when another User(J) process, distinct from User(I), performs a commit, the remote state associated with I becomes remotely modified. When User(I) produces an update event, the remote state becomes remotely non-modified. Furthermore, RemoteState provides a service allowing its state to be read (event remoteState).

Finally, Safe(I) processes ensure the right update policy (i.e. each User(I) process has to obtain a local copy that is consistent with the repository before updating the repository with its changes). These processes define the functional properties that the whole system has to ensure by specifying the authorised sequences of events.

There are several implementations of versioning systems, introducing architectural styles more or less implicitly (e.g. CVS and Subversion rely on the client-server style, SVK uses the peer-to-peer style). As we can see in our case study, the functional model does not imply any style.

Facilitating Functional Model Generation

We propose to formally specify style-independent models at an abstract level using a process calculus. A functional model is a composition of processes having remote states definitions. However, specifying processes could be difficult for the designer unfamiliar with formal methods. Tools supporting functional model elaboration have been designed in the process calculus community. For instance, based on scenarios specified as sequence diagrams or message sequence charts, FSP expressions could be generated to assist the architect [START_REF] Uchitel | LTSA-MSC: Tool support for behaviour model elaboration using implied scenarios[END_REF].

Functional and Style-Based Model Transformation

Once a functional model of the system has been specified by the designer, it can be related to a certain architectural style model taken from the repository. Thanks to process calculus specifications, the transformation is achieved by process composition and event renaming. This model transformation is endogenous, i.e. the source and target models are still FSP processes. The generic transformation process is based on the following steps:

1. Choice of an architectural style in the repository (note that the designer could be egged on a choice due to early analysis on style models); 2. Selection of functional model event(s) in order to introduce the style; 3. Definition of event relabelling between functional model and style.

These above steps are devolved to the designer. Then, based on them, a systematic transformation can be applied in order to obtain the style specific model. The target style specific model is simply a process parallel composition, where events have been relabelled. We detail two generic transformations on our case study, respectively to produce client-server and publish-subscribe style specific models. The transformation will link the external events of a style (e.g. service and process service for the client-server style) with shared events of the functional model (e.g. commit, update and remoteState for the case study). These later events can be seen as join points for the style introduction.

Two Style Specific Models of the Case Study

A Client-Server Versioning System. The client-server style is introduced through the remoteState, update and commit events shared by the User, Safe and RemoteState processes from the functional model detailed in section 3. The events are transformed into a request-reply interaction between clients and a server. The resulting structure diagram is given in figure 6. Three kinds of components are identified: CS GEN, VC CLIENTS, and VC SERVER. CS GEN is the client-server process described in section 2. VC CLIENTS represents the n clients of the distributed versioning system, each one maintaining the state of the local copy of a user and ensuring the access policy to the repository. Finally, VC SERVER is the system server that holds and maintains the remote state of each user.

Figure 7 presents the FSP expression (for simplicity, only the components previously described are given). The processes from the functional model are unchanged (i.e. User, Safe and RemoteSate). In this case, the system is composed of three users identified by u0, u1 and u2. ServiceId is the set of events used as join points in order to introduce the style. The ||CS GEN component contains a CLIENT process per event and user. Thus, for the remoteState event, there are three CLIENT processes, prefixed by u1.remoteState, u2.remoteState and u3.remoteState respectively. The ||VC CLIENTS component is the parallel composition of the User and Safe processes. Events are relabelled in order to match the style events. For instance, the remoteState[0] event of User(0) is relabelled u0.remoteState.service['remoteState] (in FSP, the expression @(Users, j) denotes the j th element of Users). The ||VC SERVER component composes the RemoteState processes and relabels events equally. Finally, the ||VC CS final system is the parallel composition of the three previous components.

A Publish-Subscribe Versioning System. For the publish-subscribe style, we choose the commit event shared by the User and RemoteState processes in order to introduce the style. This event is transformed into a push mode interaction: each User notifies all the others that he/she has modified the repository. The resulting structure diagram is given in figure 8. Three kinds of component are introduced: VC ANNOUNCERS, VC LISTENERS and PS GEN for the style. The first one contains the User processes that act as announcers of commit events. The VC LISTENERS component contains the RemoteState processes acting as listeners of the same events. At commit time, the User(J) process announces the commit[J] event to the event manager, which broadcasts it to all the RemoteState processes. The users communicate through the event manager to notify repository updates.

We have shown throughout this example that a functional model could be systematically composed with different styles provided in a common repository. Nowadays, the transformations are handmade; we have not yet an automatic tool that produces the target style specific model but we plan to describe formally the style transformation as a FSP expression transformation. Indeed, the transformation consists in composing the FSP expression of the functional model with the chosen style one and relabelling the events in order to match the functional model ones with the external events of the style. Further, style variants are also to be considered. In fact, RemoteState could be distributed either locally on a User or within a particular component. A range of style interaction models can then be made available according to the required distribution. After composition, a model checker is the primary tool used to verify conformity with functional requirements. A generated model can be verified through a LTSA model checker (e.g. liveness, progress). For the versioning system example, we can check that the update policy is preserved after the style introduction (i.e. there is no deadlock due to the SAFE processes). But extrafunctional properties should be the key concerns for selection.

Preparing Architecture Quality Analysis

For the moment, our framework focuses mainly on the functional services and properties of the system's software architecture. However, extrafunctional properties are also to be taken into account in the style definition models and in style-specific models so as to compare architectural choices. Some styles are intrinsically known to meet extrafunctional requirements more easily. In particular, peer-to-peer distributed systems are well recognised for scalability and reliability characteristics; publish-subscribe systems support extensibility, anonymity of actors and dynamicity of incoming/outgoing participants; client-server systems are often considered better for flexibility but worst for availability due to single points of failure.

Using our approach, some security properties such as message authenticity, confidentiality and integrity may be early verified, e.g. based on earlier formal work of Schneider [START_REF] Schneider | Security properties and CSP[END_REF]. Pursuant to this proposition, the system is specified in the CSP process calculus (quite similar to FSP) and includes an additional enemy process in order to model potential security attacks (e.g. message leakage, message alteration). The security properties are then introduced as properties on event traces. For example, for message confidentiality, it can be stated that each message received by the enemy process must have been sent to it before. This ensures that the message can only be accessed by the component which was intended to receive it. Security analysis on a style model could then warn anonymity weaknesses in face of strong security requirements. The designer could then have a look at other styles or investigate the introduction of security mechanisms after model transformation. In order to preserve architecture quality after refinement by introducing such mechanisms, cross-cutting concerns between extrafunctional properties need to be addressed. Extrafunctional properties influence each other [START_REF] Chung | Using non-functional requirements to systematically select among alternatives in architectural design[END_REF] and can lead to conflicts in face of requirements (e.g. a security mechanism impacts performance issues).

On the other hand, extensions to process algebras allow to introduce a timed interpretation, i.e. to specify time performance properties as computing time or message transfer time. These existing works seem a good starting point to introduce extrafunctional properties into the framework. Their integration and the extension to other properties (e.g. scalability, dependability) are under investigation.

Related Work

An application can rely on several styles. As an early example, Garlan and Shaw [START_REF] Garlan | An introduction to software architecture[END_REF] have defined a collection of architectural styles showing how different architectural solutions for a same problem offer different benefits. For example, they outline four distinct architectural designs for the Key Word In Context (KWIC) system (i.e. shared data, abstract data types, implicit invocation, and pipes and filters). However, their early proposal does not open up the way to a systematic transformation of functional models with different styles. In a distributed system, selected interaction mechanisms impact locally on extrafunctional properties of a point-to-point interaction. But the choice of the right architectural style also broadly depends on the emergent properties addressed by the overall structure. To guide the selection, a formal specification of common distributed styles is a prerequisite for early analysis. Moreover, styles could be combined [START_REF] Mehta | Composing architectural styles from architectural primitives[END_REF] to meet specific requirements, encouraging analysis assistance. Our proposal tends to go one step further in this direction.

In the last ten years, a number of architecture description languages have been proposed to represent software architectures (e.g. [START_REF] Magee | Modelling distributed software architectures[END_REF][START_REF] Medvidovic | A classification and comparison framework for software architecture description languages[END_REF][START_REF] Zhang | xsadl: An architecture description language to specify component-based systems[END_REF]). More recently, development and deployment of large distributed systems also conduce to rely on component models with dedicated languages (e.g. CCM, Fractal, GCM). Some of those architecture description languages open up the way to analysis by incorporating formal specifications (e.g. CSP or pi-calculus, Z, OCL, types, graph grammars or chemical abstract machine). However, their usage does not directly dissociate styles from system models and therefore limits the definition of a fixed repository of styles independent of the architect's know-how.

To the best of our knowledge, three mature frameworks provide some architecture stylistic guidance. Morisawa and Torii [START_REF] Morisawa | An architectural style of product lines for distributed processing systems, and practical selection method[END_REF] have restricted their exploration to the client-server style alternatives and propose to evaluate them under some of the ISO 9126 quality issues (e.g. data security, reply to user for time performance). Metrics with maximum range are fixed on properties. The target style may be selected thanks to size and distance functions regarding requirement criteria. It is worth noting that several extrafunctional characteristics are not taken into account at the level of early design choices. By separating concerns, the ISO 42010:2007 recommended practice [START_REF]International Organization for Standardization: Systems and Software Engineering -Recommended practice for architectural description of software-intensive systems[END_REF] now provides some elements within a conceptual framework for describing and analysing complex architectures in terms of architectural viewpoints. However, there is still a recognised gap between requirements and architectural description phases.

The NFR framework [START_REF] Chung | Architectural design to meet stakeholder requirements[END_REF] considers extrafunctional goals to guide the designer and cover a far-reaching area of extrafunctional requirements. A nonfunctional requirement is defined in a tree description as a combination of lower level requirements (e.g. security is a combination of confidentiality, integrity and availability) and pattern-mechanisms to meet them (e.g. confidentiality can be ensured by using authentication and access matrix). Informal positive and negative contributions between mechanisms and requirements are elaborated by an expert to guide the selection. Architectural patterns can also be attached to a tree, based on property contributions known by experience. In this case, an architecture guidance is a mechanisms and patterns proposal in conformance with requirements.

After identifying actors and goals for a system, the i * framework [START_REF] Grau | A goal-oriented approach for the generation and evaluation of alternative architectures[END_REF] permits to represent dependencies between components (e.g. tasks, resources) and then elaborates alternative architectures. By selecting predefined architectural patterns corresponding to quality attributes, refined solutions of an instance system are then evaluated through metrics (actor-based and dependency-based). This framework, used for system reengineering (i.e. SARiM and PRiM methods) under quality issues, fruitfully distinguishes functional and extrafunctional aspects. However, its pattern-based approach is flexible but less rigorous than a formal transformation, and stylistic choices remain handmade at a pattern-level rather than at a high structural one.

Conclusion and Perspective

Designing software architecture of good quality, satisfying requirements, is recognised as a complex task. To facilitate construction in the lifecycle, well-known architectural abstractions could be employed at the early design stages. However, a style choice could considerably impact extrafunctional properties in the rest of the design cycle with sometimes large influences at the implementation stages. Requirement specifications do not always impose or promote style models.

Depending on the functional and extrafunctional properties, an architect faced with alternatives could rely on his/her know-how. Thus, alternatives scope and criteria for style selection often remain implicit [START_REF] Kruchten | Building up and exploiting architectural knowledge[END_REF] and tend to be put forward in the design process.

It is critical to better manage extrafunctional properties in the architecture design as an engineering discipline. Architecture analysis at the early stages is crucial to satisfy requirements in the final application or system and limits tacit choices for the architect. By specifying the behaviour of an application only in terms of functional concerns, independently of a style, our conjecture prepares for the separation of distribution concerns. Indeed, some extrafunctional properties [START_REF] Chung | Using non-functional requirements to systematically select among alternatives in architectural design[END_REF] are intrinsic to specific styles [START_REF] Mehta | Composing architectural styles from architectural primitives[END_REF] (e.g. reliability in client-server or scalability in peer-to-peer).

Therefore, we have proposed in this paper a model-driven framework to shed light on the appropriateness of separating functional system concerns from distributed architectural style. Relying on a process calculus, our formal design process enables different architectural solutions to be systematically generated by a transformation model. We tackled style independent and style specific models at an abstract specification level, and have shown through a classical distributed application that functional models could be expressed by a designer independently of interaction mechanisms. Based on an expandable repository of styles, a functional model of an application could be systematically composed with alternative styles for further comparative analysis before development. The applicability of our approach has been justified, through three distributed styles, with a classical distributed version control system case study. For the architect faced with design alternatives, our framework thus provides early formal support and allows to address the software architecture quality at higher design stages.

Following the NFR framework [START_REF] Chung | Architectural design to meet stakeholder requirements[END_REF] proposal for quality attributes, future work will take into consideration other extrafunctional properties for styles and analyse their impact on the composition process. Is a property simply intrinsic or not to a style? How to match the extrafunctional requirements with the results of analysis in our approach? Noting that resulting models are analysable with respect to some extrafunctional properties, they could be extended with patterns of mechanisms to meet requirements. Finally, a process calculus is not ideally suited to all of the extrafunctional concerns. Further, it might restrict the expandableness of the style repository (e.g. in order to address more dynamic notions). Other formalisms could also be considered in our framework to meet requirement specifications and to increase the expressiveness of style description.

Fig. 1 .

 1 Fig. 1. The overall framework

Fig. 2 .

 2 Fig. 2. Structure diagram and FSP expression of a client-server style

Fig. 3 .

 3 Fig. 3. Structure diagram of a publish-subscribe style

Fig. 4 .

 4 Fig. 4. Structure diagram of a pure peer-to-peer style

Fig. 5 .

 5 Fig. 5. Functional structure diagram of a source control management system

Fig. 6 .

 6 Fig. 6. Structure diagram of the client-server specific model

Fig. 7 .

 7 Fig. 7. Case study client-server FSP expression

Fig. 8 .

 8 Fig. 8. Structure diagram of the publish-subscribe specific model


Ahmed Abbadi

Laurent Michel

Bruno Castanié

EXPERIMENTAL ANALYSIS OF DEBONDING OF SKIN/STRINGER INTERFACES UN-DER CYCLIC LOADING AND AGEING

Keywords: Interface, fatigue, Skin/stringer debonding, moisture ageing, Postbuckling

An experimental investigation aiming to characterize the fatigue failure mechanisms and effect of ageing of skin/stringer interfaces is presented. A simplified specimen known as a "stringer foot specimen" is used. The effects of local design, of the angle of plies located at the interface and of moisture ageing are studied. Among other results, it is shown that a quasiinfinite fatigue life can be obtained under 33% of the static damage initiation load for all designs. In the framework of multilevel analysis, this study is a preliminary investigation to study cyclic buckling of composite stiffened structures.

INTRODUCTION

The present study aims to analyse the skin/stiffener behaviour of aeronautic structures under fatigue loadings. A simplified specimen known as "stringer foot specimen" is used. A recent material (T700/M21) is considered and the influence of some design details and ageing are studied. The experiments were conducted to focus on the influence of two types of interfaces, ((0°/0°) or oriented (+45°/-45°)), local design effects (straight edges and tapered edges) and moisture ageing on the onset of fatigue and speed of crack propagation. Globally, these tests demonstrate that the response to cyclic debonding for lower loads is acceptable for stringer foot specimens. The onset of delamination may occur after millions of cycles and the propagation of cracks is stable and slow for loads equal to 50% of Limit Loads. This analysis falls within the framework of multi-level analysis already developed to analyse skin /stiffener debonding [START_REF] Bertolini | Multilevel Experimental and Numerical Analysis of Composite Stiffener Debonding. Part 1: Non-Specific Specimen Level[END_REF][START_REF] Bertolini | Multilevel Experimental and Numerical Analysis of Composite Stiffener Debonding. Part 2: Element and Panel Level[END_REF] or other problems, such as pinned junctions [START_REF] Vasquez | Multi-level analysis of lowcost z-pinned composite junctions. Part 2: Joint Behavior[END_REF] under static loading (see Fig. 1). Although, in practice, the ultimate goal is the analysis of the separation of stiffeners on full-scale panels, the implementation of testing and modelling at these large scales is difficult, even under static loads. So, simplified tests must be conducted on a less complex structure. The choice of the level of analysis using "non-specific" specimens is illustrated in Fig. 1. Such specimens are representative of a technology (materials, design and manufacturing methods) but independent of any particular programme or aircraft zone. Here, the specimen is composed of a laminate (the skin) where an over-thickness (the flange) has been added, as initially proposed by Minguet et al [START_REF] Minguet | Analysis of Test Methods for Characterizing Skin/stringer Debonding Failure in Reinforced Composite panels[END_REF] (see Fig. 2). It is known as a "stringer foot specimen". These specimens are subjected to four-point bending, which leads to interface failure between the flange and the skin. Thus, the phenomenon of skin/stringer debonding can be studied first by means of non-specific specimens. This scale of analysis also gives results closer to the reality of the substructure than DCB or ENF tests. It also allows different design configurations to be analysed more easily and economically.

Composite structures are now widely used in aerospace applications due to their good fatigue resistance when subjected to in-plane loads and their light weight. According to the manufacturers' policy, skin/stiffener interfaces are not designed with fatigue loading in mind and the interface only has to sustain static loads up to ultimate loads [START_REF] Bertolini | Multilevel Experimental and Numerical Analysis of Composite Stiffener Debonding. Part 1: Non-Specific Specimen Level[END_REF][START_REF] Bertolini | Multilevel Experimental and Numerical Analysis of Composite Stiffener Debonding. Part 2: Element and Panel Level[END_REF][START_REF] Vasquez | Multi-level analysis of lowcost z-pinned composite junctions. Part 2: Joint Behavior[END_REF]. However, optimizing the mass of this kind of structure will require postbuckling to occur under limit loads as in the case of a metallic fuselage. So, buckling and unbuckling should occur many times, thus creating cyclic out-of-plane loading of the interface and requiring fatigue of the interface to become a design basis.

Fig. 1: Multi-level analysis applied to skin/stringer debonding (reproduced from ref [START_REF] Bertolini | Multilevel Experimental and Numerical Analysis of Composite Stiffener Debonding. Part 1: Non-Specific Specimen Level[END_REF]).

Numerous studies have been devoted to the fatigue of composites over several decades [START_REF] Harris | Fatigue in Composite[END_REF]6]. However, the authors focused essentially on in-plane responses (for example, single lap shear joints [START_REF] Reeder | Debonding of Stitched Composite Joints under Static and Fatigue Loading[END_REF][START_REF] Lin | An Innovative Fatigue Method in Single-Lapped Mixed Composite Joints[END_REF]). Many studies have also been directly concerned with modes I [9, 10] with DCB specimens, II [START_REF] Fernández | Characterization of composite bonded joints under pure mode II fatigue loading[END_REF][START_REF] Vinciquerra | Determination of the Mode II Fatigue Delamination Toughness of Laminated Composites[END_REF] with an ENF specimen or even III [START_REF] Donaldson | Delamination Growth in Graphite/Epoxy Composites Subjected to Cyclic Mode III Loading[END_REF]. So far, few data exist on the fatigue debonding of skin/stiffener interfaces. Researchers have mainly focused on the difficult modelling of static postbuckling and the debonding of stiffeners by various global/local techniques [1-2, 14-17], on pre-sizing methods based on analytical models [START_REF] Bisagni | Single-mode solution for postbuckling analysis of composite panels with elastic restraints loaded in compression[END_REF][START_REF] Bisagni | Analytical formulation for local buckling and post-buckling analysis of stiffened laminated panels[END_REF] or, more recently, on advanced computational techniques [START_REF] Barrière | An adaptive model reduction strategy for post-buckling analysis of stiffened structures[END_REF]. At the scale of the panel (see Fig. 1), very few results are reported in the literature for cyclic buckling. Weller and Singer [START_REF] Weller | Durability of stiffened composite panels under repeated buckling[END_REF] in the early 90's reported favourable behaviour of stiffened composite panels subjected to repeated buckling under shear and compression.

In the E-U COCOMAT programme, tests conducted under fatigue [START_REF] Bisagni | Cyclic buckling tests of CFRP curved panels[END_REF][START_REF] Cordisco | Cyclic buckling tests under combined loading on predamaged composite stiffened boxes[END_REF] showed very good behaviour of panels in fatigue even after postbuckling. Cyclic tests up to 50,000 cycles were performed without significant damage. Nonspecific specimens have also been used to analyse design effects or environmental effects on static debonding loads [START_REF] Bertolini | Multilevel Experimental and Numerical Analysis of Composite Stiffener Debonding. Part 1: Non-Specific Specimen Level[END_REF] or to validate computational methods [START_REF] Krueger | Analysis of composite skinstiffener debond specimens using a shell/3D modeling technique[END_REF][START_REF] Turon | A damage model for the simulation of delamination in advanced composites under variable-mode loading[END_REF][START_REF] Krueger | Comparison of 2D finite element modeling assumptions with results from 3D analysis for composite skin-stiffener debonding[END_REF] for static loads. Some investigations have also been carried out on these specimens for fatigue analysis. Cvitkovich et al. [START_REF] Cvitkovich | Fatigue Debonding Characterization in Composite Skin/Stringer Configurations[END_REF] investigated the fatigue damage mechanisms and identified the influence of skin lay-up in carbon epoxy composite bonded skin/stringers. In this investigation, fourpoint-bending fatigue tests were performed. Microscopic observation was used to document the initiation of matrix cracking, delamination and fatigue delamination growth. The location of the 90° skin and flange plies relative to the bondline was identified as the dominant lay-up feature controlling the location and onset of matrix cracking and subsequent delamination for the two stacking sequences studied. The study was limited to one material (IM6/3501-6 graphite/epoxy prepreg tape) at room temperature. Krueger et al. [START_REF] Krueger | Fatigue Life Methodology for Bonded Skin/Stringer Configuration[END_REF] developed a new methodology to determine the fatigue life of bonded composite skin/stringer for a tapered configuration based on the same test method.

This short analysis of the literature shows a lack of knowledge in this field. This paper therefore aims to provide additional, recent results on the fatigue debonding of stringer foot specimens which, a priori, should give valuable results for cyclic buckling of larger structures. The next sub-section of this paper will describe the experimental study and its objectives. Then the results will be discussed and some conclusions drawn.

EXPERIMENTAL STUDY 2.1. Description of specimens and test matrix

The geometry of the specimens is illustrated in Fig. 2. Specimens were manufactured by hand lay-up of a unidirectional, 134 g/m 2 , T700/M21 pre-impregnated laminate.

Both the skin and the flange laminates had a multidirectional lay-up, containing 0°, 90°, +45° and -45° plies. Skin and flange thicknesses were 2.08 mm (16 plies) and 1.82 mm (14 plies) respectively. The stacking sequences are given Table 1. In the case of tapered edges, only one type of interface was used, 0°/0°. One objective of the study was to analyse the local design effects by using two kinds of local stacking: straight edges (easy to manufacture and cheap) and tapered edges (more complicated to stack but better under static loading [START_REF] Bertolini | Multilevel Experimental and Numerical Analysis of Composite Stiffener Debonding. Part 1: Non-Specific Specimen Level[END_REF]). For these two configurations, the effect of ageing was analysed. The ageing was carried out at 70°C and 85% humidity for 120 days. These conditions of humidity and temperature were assumed sufficient to saturate the specimens with respect to their thickness. Two ways of assembling the flange were also analysed: co-cured (flange laid up at the same time as the skin) and co-bonded. In the case of co-bonding, the skin was polymerized first and the flange was laid up and placed on the skin with an FM300K.05 adhesive film between the two parts. A second polymerization was thus necessary for these specimens. The 0°/0° interface was chosen to enable comparison for ageing and design effects. The behaviour of two types of interface, 0°/0° and 45°/-45°, was also analysed but only for straight edges. Thus 6 different configurations were analysed. The experiment matrix and the number of specimens tested are given Table 2.

Three load levels were fixed: 66%, 47% and 33% of the 1st static damage initiation load (F ini ) found by Bertolini et al. [START_REF] Bertolini | Multilevel Experimental and Numerical Analysis of Composite Stiffener Debonding. Part 1: Non-Specific Specimen Level[END_REF] under static four point bending. These values represent respectively 1.LL, 0.7.LL and 0.5 LL. The limit loads (LL) are the maximum loads that any aircraft can be subjected to during its life. Below the limit loads (LL), the structure must be calculated for use under fatigue loading and this is the reason why absence of crack growth is mandatory for composite parts. The ultimate loads (UL) are equal to 1.5 LL and the structure must sustain these loads only statically. This ability is validated by static certification tests, which are required before the aircraft is allowed to fly. The average value of Fini for the static tests was found to be 567 N and 932 N for the straight and tapered edge configurations respectively, for 0°/0° interfaces at room temperature without ageing. For +45°/-45 interfaces, the static value was lower (505 N, [START_REF] Bertolini | Multilevel Experimental and Numerical Analysis of Composite Stiffener Debonding. Part 1: Non-Specific Specimen Level[END_REF]) but the same fatigue load levels were applied to enable a direct comparison. Two more tests at 333 N (i.e. 0.66 x 505 N) were also integrated in the test results. The static strengths for aged specimens were found to be slightly different [START_REF] Bertolini | Multilevel Experimental and Numerical Analysis of Composite Stiffener Debonding. Part 1: Non-Specific Specimen Level[END_REF] but, for practical reasons and also to enable a direct comparison, the same fatigue load values were applied. A total of 61 specimens were tested.

Description of tests and monitoring conditions

A four-point bending fatigue test was preferred to threepoint bending in order to limit the risk of breaking the skin as done in the static study [START_REF] Bertolini | Multilevel Experimental and Numerical Analysis of Composite Stiffener Debonding. Part 1: Non-Specific Specimen Level[END_REF]. Moreover, no transverse shear occurred at the debonding location. The upper supports were mobile and placed 72 mm apart, and the lower supports were fixed 110 mm apart (see Fig. 2).

For each configuration, fatigue tests were run under a sinusoidal waveform. The test frequency was set at only 4 Hz (to avoid temperature effects and due to the flexibility of the specimen under bending, which affects the PID of the machine) with a load ratio, R = F min /F max , of 0.1 (F min and F max are, respectively, the minimum and maximum loads applied during a fatigue cycle). 4 Hz is very slow and is the reason why some experiments that required a long testing time were limited to only one specimen (see Table 2). The minimum and maximum displacements during fatigue tests were recorded as a function of the number of cycles.

The cyclic loading was stopped depending on the load level and a camera was used every 100, 1000 and 10000 cycles to document the occurrence, delamination onset and propagation of cracks.

At the higher load levels (66% and 47% of the static damage initiation load) the start of cracking was detected visu-ally by taking a photograph of the side of the specimen, locally painted white. At lower load levels (33% of the static damage initiation load) the test was stopped and the specimen was placed in a three-point bending rig as shown in Fig. 3. Then a small load was applied to open the crack delaminations slightly, by hand tightening a screw, to increase the visibility of the damage and the crack length with the specimen and rig placed under a microscope. This procedure was almost the same as in Cvitkovich et al. [START_REF] Cvitkovich | Fatigue Debonding Characterization in Composite Skin/Stringer Configurations[END_REF].

Interface effect (straight edges)

In Fig. 4, the number of cycles to the onset of delamination is given versus the applied load. Tentative curve fitting is also provided to highlight the difference between the three interfaces. In the case of static behaviour, the onset of delamination is globally the same for 0°/0° and 45°/-45° interfaces despite discrepancies in the results [START_REF] Bertolini | Multilevel Experimental and Numerical Analysis of Composite Stiffener Debonding. Part 1: Non-Specific Specimen Level[END_REF]. In fatigue, the curve fitting shows that the 45°/-45° interfaces seem to delay the onset of delamination. This phenomenon is clearly visible at ratios of 47% and 33%. For the 66% ratio, the onset of delamination occurred at a low number of cycles, about one thousand, although, for lower loads, it started after more than one million. These results demonstrate the possibility of cyclic out-of plane loading for such structures. In the case of co-bonded 0°/0° interface, the gain is significant in static loading (+56%) but the results show clearly that this gain is lost under cyclic loadings.

Even though it was not a key feature of the analysis, the speed of propagation was also monitored. For the first two interfaces (not bonded), the crack propagated very slowly with the number of cycles (see Fig. 5). The same observation was made for the 33% ratio. This figure shows that, for a number of cycles six times greater, the 45°/-45° interface had slower crack propagation speed than the 0°/0° interface. Furthermore, the tests showed that this interface slowed down the crack propagation significantly. This observation is consistent with static DCB experiments [START_REF] Bertolini | Contribution à l'analyse expérimentale et théorique des ruptures de structures composites en postflambement par décollement de raidisseurs[END_REF] reported in the literature.

Geometry effect (comparison between straight and tapered edges)

For this analysis, the interfaces were the same (0°/0°) for all specimens. The tapered edged specimens were cycled under a high load condition, of the order of 620 N (representing 66% of the monotonic static tests, see Table 2) compared to the cyclic loading of 378 N used for straight edged specimens (which also represented the same percentage, 66%, of the monotonic static tests). It was confirmed that in fatigue also, the tapered edges significantly delayed the initiation of delamination compared to straight edges (Fig. 6). For the second test at 33%, the test was stopped at 2.2 million cycles, i.e. after more than one week of testing. Nevertheless, this configuration (tapered edges), exhibited faster crack propagation speed than the straight one. Fig. 7 gives some pictures of the fast crack propagation for 66% of the static load. In Fig. 8, for a load of 440 N, corresponding to 47% of the monotonic load, the delamination lengths are plotted versus the number of cycles. The positive role of tapered edges in delaying the initiation of delamination seems to be reduced by this faster, and thus more critical, crack propagation. However, it is important to note that the load level is always significantly higher in comparison to straight edges (378 N) and, since the length of the crack does not increase the critical energy release rate as shown in [START_REF] Bertolini | Contribution à l'analyse expérimentale et théorique des ruptures de structures composites en postflambement par décollement de raidisseurs[END_REF] for this interface, it is not surprising that the crack propagation is very quick at this load level.

Effect of ageing (straight and tapered edges)

The onsets of delamination of pristine and aged specimens are shown in Figures 9 and 10 for straight and tapered edges respectively. Fatigue tests on aged specimens showed that the crack was initiated earlier than in unaged specimens, for both configurations. This result is in good agreement with static test data obtained by [START_REF] Bertolini | Multilevel Experimental and Numerical Analysis of Composite Stiffener Debonding. Part 1: Non-Specific Specimen Level[END_REF]. Ageing of samples has little influence on the propagation of the crack once initiated but, in the case of straight edges, the fatigue onset threshold of aged samples showed a decrease of 33% compared to unaged specimens (for a load of 400 N). In the case of tapered edges, this decrease was about 34% for the same load (400 N). This shows that the ageing phenomenon should be taken into account when sizing composite structures subject to repeated out-of-plane loading.

CONCLUSIONS

Fatigue tests were performed on stringer foot specimens with two design options (straight edges and tapered edges), two manufacturing procedures (co-cured and co-bonded) and two other parameters: the orientation of the plies located at the interface, and ageing. The fatigue test results were presented in standard S/N diagrams. The onset of delamination occurred between the skin and the flange for all configurations thus also validating the use of the stringer foot specimen to analyse skin/stiffener debonding in fatigue. The design with tapered edges significantly delayed delamination initiation compared to straight edges. For 33% of the Ultimate Load, representing 50% of the Limit Load, the onset of delamination occurred only after 106 cycles and one test had to be stopped after 2.2 mil- lion cycles. It is also noteworthy that these results were obtained for applied loads significantly higher than those used with straight edges (310 N vs 189 N). The only drawback of this design is that crack propagation was significantly faster because of the higher loads. For the analysis of straight edges with different interfaces (0°/0°, 45°/-45° or 0°/0°bonded), unlike in static conditions, it seems that the 45/-45° delays the onset of delamination. Then, with straight edges, the crack propagates slowly with the number of cycles but crack propagation is slower for the 45°/-45° interface than the 0°/0° interface. For co-bonded specimens, the marked gain under static conditions is not found in fatigue tests. Thus this manufacturing procedure has to be avoided in cases of cyclic buckling. The fatigue test results on aged specimens for both configurations (straight and tapered edges) showed that the crack was initiated earlier than in unaged specimens, while ageing had little influence on the propagation of the crack once initiated. Tests should also be performed at low (-50° C) and high (70° C) temperatures to check the response of the structure. Nevertheless, some preliminary but incomplete results show that the temperature has little influence on debonding in this case [START_REF] Bertolini | Contribution à l'analyse expérimentale et théorique des ruptures de structures composites en postflambement par décollement de raidisseurs[END_REF]. Globally, these tests demonstrate that the response to cyclic debonding for lower loads is acceptable for stringer foot specimens. The onset of delamination may occur after millions of cycles and the propagation of cracks is stable and slow for loads equal to 50% of limit loads. So the preliminary results presented in this paper should encourage the design and testing of large stiffened composite structures under repeated buckling to validate the conclusions and trends at larger scales.

Fig. 2 :

 2 Fig. 2: Specimen geometry and configuration, unit: mm and Four-point bending test principle

Fig. 3 :

 3 Fig. 3: Three-point-bending rig with specimen in place

Fig. 4 :Fig. 5 :

 45 Fig. 4: Maximum cyclic load as a function of the number of cycles to delamination onset for straight edges

Fig. 6 :

 6 Fig. 6: Comparison to onset delamination between straight and tapered configuration

Fig. 7 :Fig. 8 :

 78 Fig. 7: Behaviour of co-cured specimens with tapered edge configuration, interface 0°/0°, at load level of 66%

Fig. 9 :Fig. 10 :

 910 Fig. 9: Number of cycles to delamination onset for aged and unaged specimens (straight edges)

Table 1 :

 1 Stacking sequences of the flanges and skins Experimental Analysis of Debonding of Skin/Stringer Interfaces Under Cyclic Loading and Ageing

	Interfaces	Stacking Sequence	Thickness(mm)
	Skin	[90/+45/0/-45/-45/0/45/0] S	2.08
	0°/0°
	Flange	[90/+45/0/0/-45/0/0] S	1.82
	Skin	[+45/90/-45/0/-45/0/45/0] S	2.08
	45°/-45°
	Flange	[-45/0/-45/0/90/0/0] S	1.82

Table 2 :

 2 Test Matrix

Acknowledgement

The authors wish to thank the RTRA STAE (http://www. fondation-stae.net/) and Airbus France for their support for this study.


H Si-Mohammed
email: hakim.si-mohammed@inria.frgery.casiez@univ-lille.fr

G Casiez

F Argelaguet

N Roussel

A Lécuyer

DEFINING BRAIN-COMPUTER INTERFACES: A HUMAN-COMPUTER INTERACTION PERSPECTIVE

Regardless of the term used to designate them, Brain-Computer Interfaces are "Interfaces" between a user and a computer in the broad sense of the term. This paper aims to discuss how BCIs have been defined in the literature from the day the term was introduced by Jacques Vidal. From a Human-Computer Interaction perspective, we propose a new definition of Brain-Computer Interfaces as "any artificial system that transforms brain activity into input of a computer process". As they are interfaces, their definition should not include the finality and objective of the system they are used to interact with. To illustrate this, we compare BCIs with other widely used Human-Computer Interfaces, and draw analogies in their conception and purpose.

INTRODUCTION

In 1973 Jacques Vidal introduced the term Brain-Computer Interface [START_REF] Vidal | Toward direct brain-computer communication[END_REF]. The "BCI" project as it was imagined back then, was meant to exploit the electrical activity arising from the brain to control a computer program. Even though other terms can be found in the literature to designate BCIs: Brain-Machine Interfaces (BMI), Direct Brain Interfaces (DBI), Direct Neural Interfaces (DNI) or Brain-Interfaces (BI). It is admitted that they all designate the same thing [START_REF] Mason | A comprehensive survey of brain interface technology designs[END_REF]: an interface between a brain and a computer (in the broad sense of the term). This is even noticeable from the fact that most of them share the "I" of "Interface", a term commonly used in Human-Computer Interaction, the field that aims to design, evaluate and implement interactive systems [START_REF] Hewett | ACM SIGCHI curricula for human-computer interaction[END_REF]. The main goal of this paper is to stimulate discussion around the terminology of BCIs from a Human-Computer Interaction point of view by discussing the current definitions of BCIs, by highlighting the definition of an "interface" and by setting up an analogy between BCIs and other popular computer interfaces, leading to a new definition of BCI.

CURRENT DEFINITIONS OF BRAIN-COMPUTER INTERFACES

The most widely recognized definition of a BCI was proposed by [START_REF] Wolpaw | Braincomputer interfaces for communication and control[END_REF]: "A Brain-Computer Interface is a communication system in which messages or commands that an individual sends to the external world do not pass through the brain's normal output pathways of peripheral nerves and muscles" [START_REF] Wolpaw | Braincomputer interfaces for communication and control[END_REF]. The main goal of a BCI would be then, to allow users who may be suffering from "locked in" syndrome or "paralysis" to communicate and to express their wishes to caregivers, or to operate word processing programs and neuroprostheses. The very core idea of a BCI would thus be to provide the brain with "a new, non-muscular communication and control channel for conveying messages and commands to the external world". This brings up a core element of a BCI which is the "nonmuscular" nature. A BCI derives its input solely from the brain activity. A few years later, Blankertz stated that a BCI is "a new augmented communication system that translates human intentions reflected by suitable brain signals, into a control signal for an output device such as a computer application or a neuroprosthesis" [START_REF] Blankertz | The Berlin Brain-Computer Interface: EEG-based communication without subject training[END_REF]. An interesting feature of this definition is the concept of translation. In order to interact using a BCI, the brain activity has to be transformed into commands or messages. According to Daly and Wolpaw [START_REF] Daly | Brain-computer interfaces in neurological rehabilitation[END_REF], a BCI system "enables a new real-time interaction between the user and the outside world" specifying that the signals extracted from brain activity "are translated into an output" from which the user receives feedback that affects his brain activity. This definition highlights the real-time component of a BCI system and introduces the notion of closed-loop between the user and the system through the feedback. Aggregating the previously mentioned features, Grainmann et al. [START_REF] Graimann | Brain-computer interfaces: A gentle introduction[END_REF] stated 4 criteria under which a system can be called a BCI: (1) A BCI system has to acquire its inputs directly from the brain activity; [START_REF] Mason | A comprehensive survey of brain interface technology designs[END_REF] The signal has to be processed and translated in realtime; [START_REF] Hewett | ACM SIGCHI curricula for human-computer interaction[END_REF] The user must obtain feedback from his activity; (4) The user has to send intentional commands to the system. The last criterion though, has been qualified by a newer classification of BCIs proposed by Zander and Kothe [START_REF] Zander | Towards passive brain-computer interfaces: applying braincomputer interface technology to humanmachine systems in general[END_REF] who distinguish between active, reactive and passive BCIs depending on the endogenous and intentional nature of the interaction. Today, passive BCIs should also be considered as BCIs. All these definitions across time have helped better understand and better design Brain-Computer Interfaces. They are remarkably complementary and perfectly describe what most of the BCI systems are able to achieve today, in terms of communication and control. However, most of these definitions go beyond what can etymologically fall into the definition of an interface. From an HCI perspective, considering the usage of the term "interface", strictly speaking, the term Brain-Computer Interface should only be applied to describe the intermediary hardware and software components between the brain and the interactive system.

A NEW DEFINITION OF A BRAIN-COMPUTER INTERFACE

In the Oxford dictionary, the word "interface" defines "A point where two systems, subjects, organizations, etc. meet and interact" [9]. In the context of computing, it defines "A device or program enabling a user to communicate with a computer". From both of these definitions, it clearly appears that the notion of interface only makes sense when considering the items it helps to bridge. In HCI, these two items are the "user" and the "interactive system". A system is said to be interactive if it depends on unpredictable inputs incoming from an external environment that it does not control [START_REF] Goldin | Interactive computation: The new paradigm[END_REF]. In HCI, the unpredictable inputs are the user commands. In this context, an interface is the set of hardware and software means by which the user communicates with the interactive system. The interface comprises the input device (the hardware), the algorithms and methods to process the outcomes of the input device, and the presentation mechanisms to render the feedback. The final objective of the system though, does not belong in the boundaries of the interface. A computer mouse for example, is made of hardware parts, comprising the plastic box, the motion sensor and the microcontroller, for measuring the user movements. It also requires a transfer function for translating these movements into the motion of a pointer displayed on screen, and the presentation of graphical elements (i.e. buttons) so that the user can designate elements to interact with. We believe that any BCI comprises the same set of components as any user-computer interface. Hence, arising from an HCI perspective, we propose to define a Brain-Computer Interface as: "any artificial system that transforms brain activity into input of a computer process".

COMPARATIVE STUDY: A COMPUTER MOUSE VS. AN SSVEP-BASED BCI

Brain-Computer Interfaces have a lot in common with other Human-Computer Interfaces. Both aim to allow the communication between a user and a computer system. Moreover, even in terms of design and components, BCIs and HCI interfaces often share the same high-level architecture. In this section, in order to explain our point of view, we choose to illustrate the similarities between a Steady-State Visual Evoked Potential (SSVEP) based BCI, based on EEG, and a computer mouse. SSVEP is a reactive paradigm based on the property that the brain, when the subject is focused on a periodic visual stimuli of frequency f, reacts with an increase in its activity at the same frequency f. In other words, it means it is possible to determine the frequency of periodic stimulation the user is focused on. Interested readers may refer to [START_REF] Vialatte | Steady-state visually evoked potentials: focus on essential paradigms and future perspectives[END_REF] for more details. The choice of the SSVEP and a computer mouse is arbitrary, and the same analogy could be drawn with other instances. Figure 1 illustrates the different components of this analogy.

Hardware components: The first thing that comes to users' mind when they hear "computer mouse", is the plastic-made body. Similarly, the first thing that comes to mind when evoking a BCI is the EEG cap itself with its electrodes. In fact, both of them correspond to the entry point of the interface for the user. The second component of the mouse is usually a digital camera, the microcontroller and the LED lens embedded in the body which are responsible of acquiring the user's hand movements. In the case of an EEG BCI, it is the amplifier that provides one time-dependent signal per measured electrode.

Software components: In both of the computer mouse and the BCI, the software components hold an important part. In the mouse, the direction, amplitude and speed of the hand movement are translated into new coordinates for the cursor on the screen using a transfer function. These movements can typically be predicted by Fitts' law [START_REF] Fitts | The information capacity of the human motor system in controlling the amplitude of movement[END_REF]. In a BCI, the amplified EEG signal is processed and classified into a mental state. Depending on the mental state, and depending of the position of the cursor when clicking, a particular command is determined from the interface and sent to the interactive system.

Presentation: In the cases of the mouse and an SSVEP BCI, a graphical presentation is primordial. For the SSVEP BCI, it is essential to have external stimuli under the form of flickering targets, in order to infer different commands from the BCI. This is what makes SSVEP a reactive paradigm. For the mouse, on the other hand, it is necessary to present buttons or specific areas on the screen so that the user knows where to click. In the same way as clicking on different buttons generate different commands, focusing on targets flickering at different frequencies will generate different commands. This analogy between a mouse and a SSVEP BCI do apply to other reactive paradigms. Yet, it is possible to draw the same kind of comparison for active or passive BCIs. In the case of Motor Imagery for instance, we can easily make an analogy with a joystick or a game controller. When the subject imagines left or right-hand movement, the appropriate command is sent to the interactive system, without the need for a graphical presentation, even though a feedback mechanism can help. For passive BCIs, it is possible to draw a comparison with proactive and transparent interfaces. A good example of this would be a smart-home interface, where the user's behaviors and locations are transparently monitored to infer commands to send to the smarthome. Adapting a system to the user's mental state can somehow be seen as automatically turning on the light when the user moves into the room. Instead, we consider "any" system, that unlike muscles is "artificial" and falls in the proposed definition as a BCI. The purpose of this system is to "transform" the brain activity into "inputs" that a "computer process" can exploit. A similar reflection has been conducted by Jeunet et al. [START_REF] Jeunet | Using recent BCI literature to deepen our understanding of clinical neurofeedback: A short review[END_REF] when comparing Neurofeedback and Motor Imagery. They highlighted that both Neurofeedback (NF) and MI-BCI users have to learn how to regulate their neurophysiological activity, sometimes with similar features, through given feedback but the final objective is different. While MI-BCI consists in producing a specific EEG pattern to send a command, the goal of NF is to learn how to generate the specific pattern. If one wants to designate the whole interaction between a user and an interactive system using a BCI to achieve a particular role, one should use the term Brain-Computer Interaction. With our new definition of Brain-Computer Interfaces (BCI), any artificial system that involves the exploitation of brain signal, can be considered as using a BCI, instead of being the BCI itself.

CONCLUSION

In this discussion paper, our goal was to explore the different definitions of Brain-Computer Interfaces. All these definitions are very complementary, reflect the transversality of the field, and illustrate what it is possible to achieve with BCIs today. In an attempt to aggregate these definitions, in order to be as inclusive of new and incoming types of BCIs as possible, we proposed a new definition motivated by the etymology of the term, and with our perspective from the Human- Computer Interaction domain. We illustrated and grounded our point of view through an analogy between BCIs and more widely used interfaces. We believe that this new definition could support the future discussion about what BCIs are, and that it could constitute a first step towards the design of Brain-Computer Interfaces as interaction medias.

  These comparisons and analogies have to be seen as what they are meant to be: illustrative examples. They are not intended to be exhaustive nor universal truth, but they serve to illustrate that a Brain-Computer Interface can fundamentally be seen as a Human-Computer Interface. DISCUSSION There have been several definitions of Brain-Computer Interfaces since Jacques Vidal introduced the name. Today, research and innovation in the field of BCIs is very transversal. Neuroscientists, computer-scientists, medical doctors and engineers have different perspectives on what Brain-Computer Interfaces are. The definition we proposed, present the advantage of being very inclusive because it does not comprise the finality of the interactive system.

Figure 1 :

 1 Figure 1: Illustration of the components comprised in a user interface. (Top) A Brain-Computer Interface comprises an acquisition equipment, a signal amplifier and all the methods used to transform the signal into a computer input. (Bottom) A computer mouse is made of a hardware body, a microcontroller and a transfer function.