Erwan Brottier
email: erwan.brottier@orange-ftgroup.com

Benoit Baudry
email: bbaudry@irisa.fr

Yves Le Traon
email: yves.letraon@enst-bretagne.fr

David Touzet
email: dtouzet@irisa.fr

Bertrand Nicolas
email: bertrand.nicolas@orange-ftgroup.com

Producing a Global Requirements Model from Multiple Requirement Specifications

Requirements documentation is a collection of partial specifications produced by different stakeholders. Obtaining a global specification is a fundamental step of a requirement analysis process. Merging requirement specifications is indeed a way to reveal inconsistencies between them. We propose in this paper a model-driven mechanism for that purpose. It takes as inputs a set of texts or models which conform to input requirement languages and produces a global requirements model. This mechanism is integrated in a platform called R2A which stands for "requirements to analysis". The R2A core element is its core requirement metamodel which has been defined for capturing the global requirements model. We illustrate our approach with requirement specifications expressed in a constrained natural language. This platform and its mechanism have been completely implemented with MDE (Model Driven Engineering) technologies. As such, it is a good example of how MDE technologies can contribute to requirements engineering as a technical solution.

Introduction

Requirements Engineering (RE) is the first step of a software development process. It consists in discussing, modeling, validating and agreeing on the requirements. It is critical since the primary measure of software system success is the degree to which it meets the purpose for which it was intended [START_REF] Nuseibeh | Requirements Engineering: A Roadmap[END_REF]. It is now well-known that the first reason of software project failures is requirement issues such as misunderstanding of the actual needs, requirement inconsistencies or even lack of requirements documentation [START_REF] The_Sandish_Group | Chaos Standish Group Internal Report[END_REF][START_REF] Meta_Group | Research on Requirements Realization and Relevance[END_REF]. Performing a good RE process has a strong impact on the relevance of a software development process and consequently the quality of the system itself.

Requirements capture a wide range of concerns, expressed by a significant number of stakeholders (end users, domain experts, project leaders, business analysts, software and requirement engineers, etc.).

Stakeholders produce a set of specifications according to their viewpoints and expressed using different syntaxes adapted to their domain.

The requirement distribution in heterogeneous documents revealing several partial specifications is a good solution to let all stakeholders express their needs. However, it makes difficult the analysis of the software specification since semantic links between partial specifications remain implicit. Indeed, partial specifications are likely to be semantically interlinked since parts of them can describe the same aspect of the software specification. A robust mechanism is needed for gathering all stakeholders' specifications in a single model in order to validate semantics, completeness and consistency of these viewpoints. This model must capture the global problem space for the system.

Current RE tools allow either a single input global requirement specification or single requirement syntax. In both cases, they are not designed to evolve easily if the input language must be customized to stakeholders' preferences and the kind of software being developed. That is the main reason why these tools are not widely used in an industrial scale.

This paper presents a general model-driven process (and tools) to produce a global requirements model from a set of specifications written in different syntaxes. It does not aim to detect or resolve inconsistencies which may appear in the resulting model. The process is composed of two steps. The first one, required for textual languages, parses each textual requirement specification to produce an abstract syntax model. The second step (i) interprets the semantics of each abstract syntax model in an intermediate requirements model, (ii) merges these models into a global requirements model. These two steps (and included sub-steps) use MDE (Model Driven Engineering) techniques. This process produces a global requirements model on which it is possible to detect underspecified elements or inconsistencies between different specifications. However, the analysis of the global model is out of the scope of this paper.

In the paper, we illustrate this process with the R2A ("requirements to analysis") platform, which provides MDE mechanisms for interpreting, analyzing and simulating requirements. Its core asset is a metamodel that defines the modeling language we use to capture requirements. It captures both business domain and functional concerns of system requirements as use cases guarded with specific business rules represented as pre-and post-conditions. The main R2A input textual language is a constrained natural language called the "Requirement Description Language" (RDL). The result of merging RDL specifications is a model which conforms to the R2A metamodel.

This paper is organized as follows. Section 2 discusses the need of a merge mechanism and outlines by an example its application scope. Section 3 presents the general merge mechanism, and introduces its implementation in the R2A platform. The two following sections detail the relevant parts of the platform that implement this mechanism. Section 4 introduces RDL and the R2A metamodel; section 5 presents the interpretation and fusion transformations involved in the R2A import step. Finally, we discuss the related works in section 6 and conclude in section 7.

Merging as a Basis for Requirements

Engineering Activities

Managing a Set of Requirements Specifications

RE is the part of the software engineering which focuses on development issues at the early stage of a development process. Requirements engineers have to deal with requirements produced by all stakeholders, in order to gather sufficient and consistent information about what the software has to be.

Definition -Requirement and requirement specification:

A requirement is a constraint on the software-to-be. A requirement specification is a set of requirements which describe what the software has to resolve (in other terms a problem) and why the software is required (the goals). Requirements are specified by heterogeneous stakeholders such as end users, domain experts, project leaders, business analysts, software and requirement engineers and so forth. Moreover, stakeholders focus on different aspects of the software and have different needs, expertise and skills. The result of discussions between stakeholders is a collection of partial specifications, also called viewpoints [START_REF] Easterbrook | Using Viewpoints for inconsistency management[END_REF]. We provide below a definition of partial specification:

Definition

-Partial requirement specification or Viewpoint: A partial requirement specification produced by one particular stakeholder or stakeholders group. It is an incomplete viewpoint on the softwareto-be. Partial specifications describe different points of view on the same object that is the software-to-be. As such they are likely to be semantically interlinked [START_REF] Easterbrook | Using Viewpoints for inconsistency management[END_REF]. They must be merged into only one model that reflects the global complexity of the requirements. By this way, implicit semantic links can be expressed so that automatic treatments can be expressed. The result of this process is the global requirement specification.

This merge process is a basis for RE activities. It produces a global requirements model which is necessary for computing automatic treatments. It is a way for analyzing requirements and discovering inconsistencies between partial specifications. It can reveal communication issues between stakeholders.

An Example

Figure 1 gives excerpts from a "Library Management System" called LMS. (a) and (b) textual partial specifications have been produced separately. The first one has been written by the library end users while the second corresponds to the librarian's viewpoint. These two partial specifications must be merged to obtain a more global specification.

These requirements capture functional concerns. They define basic actions provided by the LMS which are an interface between the system and its environment. Each sentence defines one action property which is either an activation condition or an effect if triggered. For instance, the sentences [START_REF] Nuseibeh | Requirements Engineering: A Roadmap[END_REF]6,[START_REF] Sommerville | Integrated Requirements Engineering: A Tutorial[END_REF][START_REF] Lugato | Automated Functionnal Test Case Synthesis from THALES industrial Requirements[END_REF] describe activation conditions for borrow action while the sentence (2) defines one effect: the given book is now borrowed by the customer who triggers the action.

Business domain entities are also described by these partial requirements. It is possible to deduce from them a dictionary of business concepts for the LMS (book, customer and librarian). The two last business concepts could be identify as actors since they are subjects of action verbs. The sentence (2) suggests that book and customer concepts are linked by a dependence called borrowed. The sentence [START_REF] Schmidt | Model-Driven Engineering[END_REF] implies that a book can be in a state called damaged, and so on.

The LMS will be used through the entire paper to illustrate our approach. Its global requirements are described below:

• A library is maintained by a librarian.

• A customer must register in the library to avail the facility of borrowing the books.

(1) The "book" must be not "borrowed" before the "customer" can "borrow" the "book".

(2) The "book" is "borrowed" by the customer after the "customer" did "borrow" the "book".

(3) The "book" must be "borrowed" by the customer before the customer can "return" the "book". (4) The "book" becomes not "borrowed" after the "customer" did "return" the "book". [START_REF] Schmidt | Model-Driven Engineering[END_REF] The "book" is "damaged" after the "customer" did "damage" the "book". (6) The "customer" must be "registered" before the "customer" can "borrow" the "book". [START_REF] Sommerville | Integrated Requirements Engineering: A Tutorial[END_REF] The "book" must be not "damaged" before the "customer" can "borrow" the "book". [START_REF] Lugato | Automated Functionnal Test Case Synthesis from THALES industrial Requirements[END_REF] The "book" must be "registered" before the "customer" can "borrow" the "book". [START_REF] Nebut | Automatic Test Generation: A Use Case Driven Approach[END_REF] The "customer" becomes "registered" after the "librarian" did "subscribe" the "customer". [START_REF] Saeed | Model Driven Requirements Engineering[END_REF] The "book" becomes "registered" after the "librarian" did "register" the "book". [START_REF] Muller | Model-Driven Analysis and Synthesis of Concrete Syntax[END_REF] The "book" is not "borrowed" after the "librarian" did "register" the "book". [START_REF] Kermeta | The KerMeta Project Home Page[END_REF] The "book" is not "registered" after the "librarian" did "unregister" the "book". [START_REF] Muller | Weaving executability into object-oriented meta-languages[END_REF] Each "book" is not "damaged" after the "librarian" did "make an inventory". • When a customer returns a damaged book, the book is not available for customers, till the librarian performs an inventory check.

Characterization of a Merge Operation

Merging two partial specifications consists of making explicit the semantic links between them. By observing the previous requirements, two distinct types of semantic links can be identified:

• Equivalence link (or explicit link): it means that linked elements represent the same concept. For instance, while the concept of book is unique, the expression "book" surrounded by quote is present 22 times in Figure 1. This redundancy is not a problem if the text is only used as documentation. It is even natural in textual representations. But each reference to a same concept must be represented by only one element in a model dedicated to analysis purpose. However, redundancy is not always a mark of equivalence link. The two words "registered" in requirements [START_REF] Lugato | Automated Functionnal Test Case Synthesis from THALES industrial Requirements[END_REF] and [START_REF] Nebut | Automatic Test Generation: A Use Case Driven Approach[END_REF] do not refer the same meaning. The first one is a state of a book while the other one is a state of a customer. Then, an equivalence link can not be systematically deduced from words equality. It is defined according to the overall specification.

Two elements can represent the same concept even if their types are different. For instance, the customer is an actor since it appears as one subject in requirement (4) while it is considered as a business entity in the requirement [START_REF] Nebut | Automatic Test Generation: A Use Case Driven Approach[END_REF].

• Implicit link: it is a semantic link between elements.

For instance, the guards of the borrow action are defined by requirements [START_REF] Nuseibeh | Requirements Engineering: A Roadmap[END_REF]6,[START_REF] Sommerville | Integrated Requirements Engineering: A Tutorial[END_REF][START_REF] Lugato | Automated Functionnal Test Case Synthesis from THALES industrial Requirements[END_REF]. Semantically, these conditions are logically linked by conjunctions since all of them must be true for triggering the action. These conjunction links must appear in the resulting global requirements model while they are implicit in Figure 1.

A Model-Driven Process for Producing a Global Requirements Model

Merging partial requirement specifications is crucial during a RE process. The concerns that requirements capture are tightly related to the business domain of the software. Companies have their own requirement language, according to their cultures and habits. So a merge process must provide flexibility to support different input languages. Moreover, the global requirements model issued from the merge operation must be easy to manipulate. This section proposes a general process which satisfies these requirements.

The Model-Driven Engineering (MDE) as a Technical Solution

Model-Driven Engineering (MDE) [START_REF] Schmidt | Model-Driven Engineering[END_REF] advocates the systematic use of models for designing and implementing software. The most famous MDE initiative is the MDA (Model Driven Architecture) [6], which has been defined by the OMG for making software system implementations independent to a particular execution platform.

MDE technologies are mainly based on two notions: metamodel and model transformation. A model is structured data which conform to a metamodel in the same way as a source program conforms to a grammar. Model transformations are specific programs which are dedicated to model manipulation.

Requirements are the first models of the software-to-be. Requirement analysis activities consist essentially of the manipulation of these models. Model-driven technologies are thus particularly adapted to implement requirement analysis tools. We propose a MDE process for manipulating a set of partial textual requirements to produce a global requirements model.

A Two Steps Process for Merging Partial Requirement Specifications

The overall process is completely based on a MDE approach. It is build around a core element which is the global requirements model. Its metamodel describes which requirement concerns can be captured. In a requirement analysis context, this metamodel can be for instance the input language of such a formal analysis tool or the conceptual modeling language of an elicitation process. Input languages are chosen so that the union of their expressiveness is sufficient w.r.t. the global requirement metamodel.

Figure 2 depicts an overview of the MDE process with its models, metamodels and transformations. The process is decomposed in two sequential steps. The result of applying these steps on one partial textual specification is the addition of its semantics in the global requirements model. These

Going from the RDL to the R2A

We have implemented the R2A platform that targets the integration of RE solutions into modern software development processes [START_REF] Sommerville | Integrated Requirements Engineering: A Tutorial[END_REF]. It has been designed as a result of our requirement analysis experiences in several industrial projects.

The work around the R2A platform has been initiated in a collaboration with THALES [START_REF] Lugato | Automated Functionnal Test Case Synthesis from THALES industrial Requirements[END_REF]. This project intended to evaluate the MDE approach to simulate requirements, and automate the generation of functional test objectives [START_REF] Nebut | Automatic Test Generation: A Use Case Driven Approach[END_REF] from requirements.

The R2A platform has then been extended for modeling new telecom services in FRANCE TELECOM. This experiment aimed at simulating requirements, producing an analysis model and system test cases. More details are provided on the R2A website [START_REF] Saeed | Model Driven Requirements Engineering[END_REF].

We have implemented a mechanism that follows the principles of the general process previously exposed (section 3.2). It is thus an instance of the generic process (Figure 2) in the R2A context that illustrates the general process. the "customer" must be "registered" before the "customer" can "borrow" the "book". the "book" becomes not "available" after the "customer" did "borrow" the "book". the "book" for the "customer" is "borrowed" after the "customer" did "borrow" the "book". the "book" must be not "damaged" before the "customer" can "borrow" the "book". requirement 1.5 "Return a book" the "book" for the "customer" becomes not "borrowed" after the "customer" did "return" the "customer" must be "registered" before the "customer" can "borrow" the "book". the "book" becomes not "available" after the "customer" did "borrow" the "book". the "book" for the "customer" is "borrowed" after the "customer" did "borrow" the "book". the "book" must be not "damaged" before the "customer" can "borrow" the "book". requirement 1.5 "Return a book" the "book" for the "customer" becomes not "borrowed" after the "customer" did "return" The Requirement Description Language (RDL) is a constrained natural language that has been designed as surface language for the R2A metamodel. Thus, all specification expressed with the RDL can be captured as a model instance of R2A. This language is also well adapted to the industrial contexts where we improve the platform. The sentences in Figure 1 are RDL expressions.

In the following, we focus on the parts of the R2A platform which are relevant for describing and illustrating the mechanism:

• Section 4 presents the metamodels for RDL and R2A

and the parsing step. • Section 5 presents the import step of the R2A platform. It describes the two transformations which perform the interpretation and fusion sub-steps.

4 The RDL Input Language and the R2A Output Metamodel

The RDL/RDM

The RDL is a pseudo-natural language (i.e. a constrained natural language). It has been designed to avoid writing ambiguous, incomplete and incorrect sentences. Its syntax allows writing readable sentences that look like natural language (although it is not intended to address any natural language analysis issues).

A RDL specification consists of a set of requirement sentences in which domain specific words are contained in quoted strings. These domain specific words include: the actors and the business concepts, the actions that actors can activate, the observable properties of business concepts or actors and the values of these observable properties. The textual specifications (a) and (b) in Figure 1 are two RDL expressions.

The RDM is a metamodel semantically equivalent to a RDL grammar. It describes the concepts of the RDL abstract syntax tree. A part of the RDM is presented in Figure 3 A requirement is composed of several propositions called Fragment. A fragment can be either a ServiceActivation or an ObservableProperty. Service activation corresponds to an action triggered by an actor of the system. It contains a subject (e.g. the service activator), a verb (determined by the type of the ServiceActivation) and a complement which describe the business concept or the actor impacted by the action (e.g. the service parameters).

The services are categorized according to their occurrence in time. For instance, ServiceActivationCan (of kind ServiceActivationPotential) represents a service whose activation depends on a specified condition (such as an observation on a system property).

ServiceActivationDid (of kind ServiceActivationReal) represents a past service activation that can raise some changes in the system state (typically, the update of some system properties). The model depicted in Figure 4 contains an instance of both of these ServiceActivation types.

ObservablePropertys describe either constraints or assignments of actor or business concept states. For simplicity sake, we only consider here simple observable properties (ObservablePropertyLeaf). An observable property associates an observed property (ObjectReference) with a value (ObservableValue). Observable properties can be used to define conditions for service activations (constraints) as well as effects of these activations (assignments).

A constraint is expressed with an ObservablePropertyStable (ObservablePropertyIs, ObservablePropertyMustBe) while an assignment is represented by an ObservablePropertyChange (ObservablePropertyBecomes,ObservablePropertyCh anges, etc.).

In order to bring RDL texts in the model world, we have used a dedicated MDE tool called Sintaks [START_REF] Muller | Model-Driven Analysis and Synthesis of Concrete Syntax[END_REF]. The resulting model is an instance of the RDM metamodel. It is an abstract syntax tree which corresponds to the semantics of RDL texts. The RDM model shown in Figure 4 is the result of the parsing step for requirements (1) and (2) of Figure 1. This model contains two instances of temporal requirements: RequirementBefore and RequirementAfter.

Sintaks is a model-based generic tool that can build a model representation from a text (parsing), but also pretty print a text from a given model. Sintaks has been built with a model-centric approach: the bridge between an abstract syntax (e.g. a metamodel) and a concrete syntax (e.g. a grammar) is specified by means of a dedicated Sintaks model. This model specifies the relationships between the metaclasses of a metamodel and the representation of their instances in textual files. Such a Sintaks file has been defined for the RDM metamodel. This file defines the concrete textual syntax of RDM models.

The R2A

In requirement specifications that we reviewed in the industrial contexts of THALES and FRANCE TELECOM, the description of system actions generally included conditions of activation which specify when the action is applicable. The description also detailed the effects on the system and the environment if the action is triggered.

Based on this survey, we have defined the R2A metamodel. It captures a state-based formalism where system actions are described as use cases. The activation conditions of use cases and their effects are described by pre-and post-conditions (called contracts as for the design-by-contracts approach). Figure 5 gives a textual representation of a R2A model obtained with the platform from LMS requirements [START_REF] The_Sandish_Group | Chaos Standish Group Internal Report[END_REF]6,[START_REF] Sommerville | Integrated Requirements Engineering: A Tutorial[END_REF][START_REF] Lugato | Automated Functionnal Test Case Synthesis from THALES industrial Requirements[END_REF]. The R2A is structured in two main parts: (i) a description of use cases with their contracts, called FunctionalModel and (ii) a description of entities manipulated by the use case contracts, termed AnalysisModel. We detail them in this section.

Use Case

a

The Functional View As shown by Figure 5, the R2A allows specifying: when the use case is applicable (precondition), and what are the modifications on the system properties after activation of the use case (post-condition). In other words, the precondition guards the execution of the use case while the post condition specifies its impact on the system if triggered. Contracts, represented by EXPRESSION class, are first order logical expressions. We do not present in details the expression part of the metamodel due to space limitation. An expression is a combination of logical operators, boolean comparisons and atomic propositions. Logical operators can be conjunction (and), disjunction (or), negation (not), implication or quantifiers (exists and forall). Atomic propositions are either boolean constants (true and false), or property values of actors and business concepts. The notion of property value is defined below.

b

The Analysis View Use cases involve business concepts and actors (the formal parameters) as well as predicates on a set of object called property values (in the contracts). For example, Customer is an actor; Book is a business concept; registered is a property while registered(b) is a property value. Actors, business concepts and their properties are described by the AnalysisModel part of the metamodel, presented in Figure 7.

Figure 7 -Analysis view of the metamodel

An actor or a business concept is represented by an ENTITY. It is linked to a set of PROPERTY which can be a RELATION between several entities or a value attached to one entity (ATTRIBUTE). An attribute has a primitive data type which is either a BOOLEAN or an ENUMERATION. An enumeration is a finite set of literal values (an integer or an interval is represented by a literal value). Complex data types are not supported since we consider they should not be present in a requirements model.

Instances of attributes and relations are property values of the system. A system state is a set of entity instances and property values. It corresponds to a configuration of the system at a given moment.

Interpretation and Fusion

Transformations: RDM to R2A

Here we show how RDM models are transformed to feed the global R2A requirements model (step 2). We illustrate the interpretation step with LMS requirements (1, 2) and the fusion step by merging two intermediate models obtained from the requirements (1, 2) and (6, 7, 8) (these requirements together describe the "borrow" action).

Interpreting RDM Models as R2A Models

Interpreting a RDM model as a R2A model supposes generating both analysis and functional parts of the R2A model. The interpretation step is performed by a model transformation. In the context of the R2A platform, we implemented this step with a dedicated language called IRL (Interpretation Rule Language).

An IRL program is a set of Interpretation rules (IR) which consist of a pattern and a production. A pattern defines the set of input model elements on which the associated rule matches. This set is defined by the type (pattern_type) of its elements (a metaclass) and a condition (pattern_cond) that each matched element must satisfy. The type is a first filter in order to select the matched elements.

The production describes the model elements created and the way they will be linked if the rule is executed. The produced elements are instances of the output metamodel. The resulting model is then a set of model fragments which are not interlinked. An IR specification uses the following template:

IRnumber (elt : pattern_type ( | pattern_cond)?): informal_production_description.

An IR is identified by a number. Its pattern is outlined by parenthesis where the matched element has a type (a RDM metaclass in the R2A context) and the pattern condition is optional. The production is described informally but contains OCL-like navigation expressions inside the RDM metamodel.

In our case, 17 IRs have been defined: for producing elements relative to the analysis model and 10 for the functional model. The list below gives the interpretation rules which are necessary for producing an R2A analysis model from the RDM model presented in Figure 4 The second example depicts the application of the rule IR2 on the element (b) in the RDM model (Figure 4). In that case, the matched element satisfies the pattern condition (no element connected by a by relation instance). In contrary, element (c) does not satisfy the pattern condition but it does match the pattern type.

Figure 9 presents the intermediate R2A model that we obtain by completely executing these five IRs on the RDM model (Figure 4). The model elements are grouped according to the rule execution which has produced them. Thus, we find the two model fragments whose the production has been described in Figure 8. These model fragments are labeled by the name of the rule which created them and the matched element in Figure 4. For example, "IR1→a" means "created by IR1 by matching element (a)".

In a complex transformation process, it is important to notice that a model does not continuously conform to its metamodel during the execution of a transformation. We can notice that the intermediate model depicted in Figure 9 does not conform to its metamodel. Indeed, the R2A metamodel declares that a TYPEDELEMENT instance is inevitably linked to a TYPE instance in a valid R2A model (the cardinality is one). However, two ATTRIBUTE instances out of three have no type in the intermediate R2A model.

IR4 → f IR4 → h IR5 → e IR5 → g IR1 → a IR1 → d IR2 → b IR3 → c (4) (5)
(3)

(12) (7) (8)
(10) (11) (9)
(1) This non conformance reflects the redundancy of the RDL text. Moreover, producing redundancy during the interpretation step is not a problem since it will be resolved by the fusion sub step. In fact, step 2a and 2b are the two parts of a global model transformation for translating a requirement specification from one language to another. We present in the next section the fusion step.

The Fusion Semantics of the R2A Metamodel

The fusion step aims to merge several intermediate models in order to obtain the global requirements model. It is performed by another model transformation where the input and the output metamodels are the R2A metamodel. It has been implemented using the Kermeta language [START_REF] Kermeta | The KerMeta Project Home Page[END_REF][START_REF] Muller | Weaving executability into object-oriented meta-languages[END_REF] which is an open source meta-modeling environment, developed by the Triskell team at IRISA.

In practice, the fusion transformation is asymmetric in the sense that it distinguishes one particular model as being the core requirements model in which all the intermediate models have to be merged. The first time this fusion is performed, one of the intermediate models is chosen arbitrarily as the core. The fusion consists in adding all elements of the intermediate models in the core and in merging all similar elements (redundancies) in order to obtain a correct and compact representation of the requirements model. Some rules, called implicit rules, aim to normalize the resulting model. We give an example of implicit rule in the following.

The fusion transformation is defined with a set of dedicated rules called fusion rules (FR). As introduced in section 2.3, two kinds of FRs can be defined: equivalence and implicit rules. An equivalence rule targets the resolution of redundancies. Equivalence rules are used to define equivalence range. An equivalence range is a set of elements in the intermediate model which must be represented by only one element in the global requirements model. Implicit rules define fusion treatments which produce specific elements in the global requirements model.

In this paper, FRs are provided as first order logic expressions (except for implicit rules which are generally more complex) extended with specific notations for manipulating models and two specific operators: the equivalence declaration operator ('≡') and the equivalence resolution operator (':≡'). The first one is used for defining equivalence range (a ≡ b and b ≡ c means that {a, b, c} is an equivalence range). The second one describes which element will be chosen in an equivalence range for representing the concept in the global requirements model.

The fusion transformation of the R2A platform is composed of 30 rules: 10 rules for merging elements relative to the analysis model and 20 for the functional model. The FRs below are an excerpt of this FR set. They manipulate instances of the R2A metamodel presented in section 5. Rules FR1 to FR5 are equivalence rules specific to the analysis model. Rule FR6 is an implicit rule specific to the functional model. FR1: ∀ a 1 , a 2 : ATTRIBUTE ∧ a 1 .name = a 2 .name ∧ a 1 .attributes -1 = a 2 .attributes -1 ⇒ a 1 ≡ a 2 . FR2: ∀ r 1 , r 2 : RELATION ∧ r 1 .name = r 2 .name ⇒ r 1 ≡ r 2 . FR3: ∀ r : RELATION ∧ ∀ a : ATTRIBUTE, a.name = r.name ⇒ r :≡ a. Figure 10 shows a global requirements model obtained from two intermediate models produced from requirements (1, 2) (an excerpt is given in Figure 9) on the one hand and from requirements (6,[START_REF] Sommerville | Integrated Requirements Engineering: A Tutorial[END_REF][START_REF] Lugato | Automated Functionnal Test Case Synthesis from THALES industrial Requirements[END_REF] on the other. The gray elements have been produced by the FRs (1-5) above. Figure 10 gives an overall specification of the "borrow" action of the LMS since this action is described by requirements [START_REF] Nuseibeh | Requirements Engineering: A Roadmap[END_REF][START_REF] The_Sandish_Group | Chaos Standish Group Internal Report[END_REF]6,[START_REF] Sommerville | Integrated Requirements Engineering: A Tutorial[END_REF][START_REF] Lugato | Automated Functionnal Test Case Synthesis from THALES industrial Requirements[END_REF].

Fusion rule 3 (FR3) defines that RELATION and ATTRIBUTE instances which have the same name in the model are equivalent. This rule is applied on the elements [START_REF] Meta_Group | Research on Requirements Realization and Relevance[END_REF][START_REF] Easterbrook | Using Viewpoints for inconsistency management[END_REF][START_REF] Schmidt | Model-Driven Engineering[END_REF][START_REF] Kermeta | The KerMeta Project Home Page[END_REF] in the intermediate model presented in Figure 9. As a result, only one instance of the RELATION R2A metaclass with the name "borrowed" appears in the global requirements model provided by Figure 10. We can notice that an equivalence rule execution reduces the number of elements which will be present in the model.

When equivalent use cases are merged, the relationship precondition in the analysis part of the R2A metamodel is likely to be instantiated more than one time for the resulting use case. A use case with several pre-condition is semantically correct: the precondition is conjunction of them. However, it is not correctly expressed w.r.t. the metamodel. The precondition must be a logical tree (as in the Figure 10). Implicit rule FR6 aims to normalize this kind of situation. It creates the conjunction links between the preconditions of a particular use case. Its condition of activation (outlined in parenthesis) specifies that it is applied on each pair of USECASE instances that have been declared as equivalent. A conjunction is represented by an instance of the ANDEXPRESSION R2A metaclass (this metaclass is included in the expression part of the R2A metamodel). A similar rule exists in the R2A platform for the postconditions.

In Figure 10, a BOOLEANPROPERTY instance represents an instance of a property for one particular parameter of a use case (indeed, it is possible to have two instances of the same entity involved as parameters of one use case). While we specify the link to the property with the attribute name, another solution could be to have a link to the targeted property instead.

Related Work

The issue of managing several partial requirement specifications or viewpoints has received a lot of attention in the RE domain. In [START_REF] Easterbrook | Using Viewpoints for inconsistency management[END_REF], Easterbrook defines a framework for managing inconsistencies between viewpoints and a formalism for expressing these inconsistencies. This framework aims at revealing the assumptions made by the stakeholders during the requirement elicitation stage. An inconsistency is detected if two viewpoints define in a different way a same part of the global specification. The inconsistency is resolved when the authors of the two viewpoints agree on a common description, taking into account the concerns of each author in their respective viewpoints. In our approach, each viewpoint is initially considered as correct. Inconsistencies are detected by confronting stakeholders with the model obtained by merging their viewpoints. Both approaches are in fact complementary: The Easterbrook's framework allows to detect conceptual disagreements. Once they are resolved, our approach can merge models in one language, depending of the targeted analysis method.

The viewpoint framework allows checking a wide range of syntactical inconsistencies in terms of relations between abstract syntax of viewpoints languages (notations in [START_REF] Easterbrook | Using Viewpoints for inconsistency management[END_REF]). However, one significant limitation is that semantic inconsistencies such as logical contradictions between viewpoints can not be detected. As stated by the authors [START_REF] Easterbrook | Using Viewpoints for inconsistency management[END_REF], semantic consistency checking necessitates a formal model representing the semantics of the overall requirements specification. This model is obtained by merging the viewpoints together. Our approach allows obtaining such a global semantic model. It is thus possible to implement mechanisms for verifying the semantic correctness of the global specification.

Several works present viewpoints merge mechanism (also called amalgamation or composition) [START_REF] Ainsworth | [END_REF][START_REF] Zave | Conjunction as Composition[END_REF]. In [START_REF] Ainsworth | [END_REF], the authors propose an amalgamation mechanism for producing a global Z specification from several Z specifications. The relations between elements of different viewpoints are described with functional invariants. By using the Z language, they are able to provide proof obligation for verifying the amalgamation. Although our approach is less formal, it is more general since input languages as well as the core requirements metamodel are flexible.

The composition proposed in [START_REF] Zave | Conjunction as Composition[END_REF] is based on a core formalism called "semantic domain" and each input language comes with a function for assigning it a semantics in the semantic domain (as the interpretation step). The result of such a function is a set of "specificands" (an intermediate model for us) expressed in the semantic domain. The authors focus in the paper on the description of a semantic domain which can take into account a wide range of input languages. This semantic domain is the set of standard models of one-sorted first-order predicate logic with equality, enhanced with the notion of event, sequences, time intervals and markers. In that context, the composition of partial specifications is the conjunction of the corresponding sets of specificands.

The formalism of the R2A platform (the R2A metamodel) is based on first-order predicate logic where actions are the events. It is less expressive than the semantic domain described in [START_REF] Zave | Conjunction as Composition[END_REF]. However, it is sufficient for capturing the requirements of the projects we studied in FRANCE TELECOM and THALES. While the approach proposed in [START_REF] Zave | Conjunction as Composition[END_REF] is closed to our work, the authors do not focus on how to implement the composition of viewpoints. Our process decomposes the composition treatment in order to make it flexible. Furthermore, it has been designed for capturing requirements expressed with different textual syntaxes. The process can be used also for non-textual input languages (in that case, one has to skip the parsing step).

MDE is an approach that can help in the task of keeping generated software development artifacts up to date in response to requirement changes. It advocates the use of tools for generating features (parsers, editors, etc.) which are dedicated to a particular metamodel. In [START_REF] Nissen | Managing Multiple Requirements Perspectives with Metamodels[END_REF], the authors advocate, like us, the use of the meta-modeling approach, so that the input languages can be customized to the user needs. Our process is completely based on a model-driven approach. Sintaks is a good example of MDE tools. It allows defining easily a concrete syntax and a parser for a metamodel. Similar tools are also available for graphic languages.

The general process proposed in this paper is a basis for performing requirement analysis activities, such as detecting inconsistencies. It is a necessary step in addressing the issue of integrating requirements in modern development processes. Requirements engineering and software development remain indeed two very distinct tasks in the current software developments. Sommerville gives four reasons [START_REF] Sommerville | Integrated Requirements Engineering: A Tutorial[END_REF] for which this lack of continuity between requirements and software development becomes a crucial issue.

Recent tools for requirements analysis tend to bridge the gap between requirements engineering and software development by defining, like us, a core model that represents the captured requirements. Several inputs are used to populate the core model, like constrained natural languages and graphical languages (UML etc.). The core model is then transformed into one or several output models suitable for propertychecking tools. For instance, [START_REF] Konrad | Automated Analysis of Natural Language Properties for UML Models[END_REF] presents an integrated tool suite called SPIDER. It provides analysis of temporal behavioral properties on UML models with the SPIN model-checker. The tool is used to analyze systems whose implementation follows the MDA principles [6] (separation business and application logic from the underlying technological platform). The properties are expressed in a constrained natural language whose accepted sentences match well the Dwyer temporal logic patterns [START_REF] Dwyer | Patterns in Property Specifications for Finite-State Verification[END_REF].

In the same way, we define a constrained language (RDL) for capturing business and functional concerns. The SPIDER input languages are UML class and state diagrams which are parts of the analysis model in a current development process. Instead of assuming that requirements are directly expressed with UML models, the R2A platform captures information from textual requirement specifications. Furthermore, SPIDER and other tools are not flexible w.r.t. their input language.

Figure 1 -

 1 Figure 1 -A piece of textual requirement specifications of a library management system • Books must be registered before being available to the customers. • A Customer can borrow and return books.• When a customer returns a damaged book, the book is not available for customers, till the librarian performs an inventory check.

steps are: 1 -

 1 Parsing. This step brings partial requirement textual specifications into the model world. It produces a partial requirement specification model equivalent to the textual specification. The parsing step is specific to the input requirement language. 2 -Import. This step is performed by a model transformation. It aims to import the information of the partial requirement specification models into the global requirements model. It is composed of two sub-steps. The first one, called interpretation, expresses specification models in terms of the core requirement metamodel. Its result for one partial requirement specification model is one intermediate model. An intermediate model is a set of model fragments which are instances of the core requirement metamodel. The second sub-step is called fusion. It performs the merge between intermediate models in order to obtain the core requirements model. It resolves the redundancies and expresses clearly the links between the intermediate models.

1 Requirement 1 . 4 "

 114 Borrow a book"

4 "

 4 Borrow a book"

2 Figure 2 -

 22 Figure 2 -Overview of the generic process

Figure 3 Figure 4 -

 34 Figure 3 -The RDM metamodel

Figure 5 -

 5 Figure 5 -A R2A model in a textual form

FunctionalModel 1 Figure 6 -Figure 6

 166 Figure 6 -Functional view of the R2A metamodel Figure 6 details the FunctionalModel part of the metamodel. A use case is represented as an instance of the class USECASE and has exactly one pre-condition and one post-condition. It contains a set of formal parameters (PARAMETER class). A formal parameter type can be either an actor or a business concept (ex: Customer and Book) which are both represented by the class ENTITY.Contracts, represented by EXPRESSION class, are first order logical expressions. We do not present in details the expression part of the metamodel due to space limitation. An expression is a combination of logical operators, boolean comparisons and atomic propositions. Logical operators can be conjunction

An

  IR execution computes a relation between two model fragments: the set of classes and relation instances from the input model which match the pattern condition or are navigated by the production; the set of class and relation instances from the output model which are created by the production.

Figure 8 Figure 8 -

 88 Figure 8 -Illustration of IR executions

Figure 9 -

 9 Figure 9 -The analysis part of the intermediate model obtained from requirements (1) and (2)

FR4: ∀ c 1 , c 2 :

 12 CONCEPT ∧ c 1 .name = c 2 .name ⇒ ((c 1 is an ACTOR ⇒ c 1 :≡ c 2 ) ∨ c 2 :≡ c 1 ) FR5: ∀ b 1 , b 2 : BOOLEANTYPE, b 1 .type -1 = b 2 .type -1 ⇒ b 1 ≡ b 2 FR6: (uc 1 , uc 2 : USECASE | uc 1 ≡ uc 2 ): For npreconditions, creation of n-1 ANDEXPRESSION instances. Creation of links between preconditions.

Figure 10 -

 10 Figure 10 -A core R2A model generated by the platform for LMS requirements (1, 2, 6, 7, 8)

In a context where requirements are quickly changing and are described by several stakeholders, it is crucial to have a global requirements model to automatically compare the ways the stakeholders think the software-to-be or to analyze the impact of requirements changes. In this way, appropriate and rapid decisions can be taken quickly for avoiding common software development pitfalls.

In this paper, we have presented a general process which aims to facilitate the production of a global requirements model from multiple partial requirements specifications. This model is a semantic merge of the input requirements specifications where implicit links between them are clearly expressed. The process is based on a model-driven approach and has been designed to be highly flexible.

We have described an implementation of this mechanism in the R2A platform. It takes as inputs a set of RDL texts and produces an R2A model. The RDL allows expressing a wide range of functional requirements. The R2A metamodel was designed with two industrial partners for incrementally defining requirements by simulation, generating test objectives and analysis models.

The presented mechanism is an incomplete solution for involving more deeply RE activities into modern software development process. But it is at least one step towards this purpose. Beside a formalization of the process, our future work will address activities both upstream and downstream in the software development process. Upstream, we will focus on the detection and the localization of requirements inconsistencies between requirement specifications written in several input languages. Downstream, we will be interested in mechanisms for propagating easily requirements changes to software artifacts.


Franck Chauvel

Olivier Barais

Modelling Adaptation Policies for Self-Adaptive Component Architectures

In most of software systems, designers try to include some self-adaptation facilities to increase the reliability of their systems. However, despite of the new methods and technologies in software engineering such as CBSE, or AOP, it is still difficult to talk about adaptation since adaptation policies might impact the architecture, the configuration data, and some extra-functional features as well. We suggest in this paper a rule-based approach to model adaptation policies that enables the description of both architectural and functional adaptation and to relate them with extra-functional properties.

Introduction

Self-adaptations facilities are more and more used to fulfil some extra-functional requirements. In embedded systems, designers often use self-adaptation in order to maximize the reliability by adapting the system with respect to the available resources. However self-adaptation procedures are mostly designed and hardcoded in the same time when the initial design choices do not match with the extra-functional requirements. Two main reasons can explain this failure in the development process. On one hand, adaptation policies involved the description of both high level and low level extra-functional properties (such as reliability and memory consumption). For instance, it might be interesting to adjust the system in respect with the amount of available memory in order to adjust the reliability. These extra-functional properties are not easily handled on the design level and it makes difficult the expression of adaptation policies that are based on them. On the other hand, adaptation policies can impact both the architecture and the data configuration of the system. For example, in order to maintain the reliability of a web server, more data servers can be deployed, or the cache management policy can be changed to a more efficient one.

The contribution of our work is to enable a precise description of adaptation policies where both the architecture of the system and the configuration of particular components are impacted to involve extra-functional properties. An adaptation policy is thus described at two levels: at the architectural level using some imperative actions and at the functional level where the modifications of the configuration of a component are described using a rule-based approach.

The remainder of this paper starts with the introduction of a web server example to motivate the modelling of adaptation policies. Then, Section 3 shows how software architectures are modelled in order to enables the description of adaptation policies. Section 4 focuses on this particular point Finally, after having presented the main related works in Section 5, we sum up our contribution before discussing some future works in the conclusion.

Motivating Example

Let's consider a simple web server architecture that processes HTTP requests such as the Apache Web Server or the Microsoft IIS solution. One of the typical need of people who design such architectures, is to make it scalable. From the architectural point of view, it means that the architecture needs to self-adapt with respect to the load of the web server.

Because of the reliability requirements, we suggest a first solution of architecture that included a optional cache component and a set of data servers as shown on Figure 1. The incoming requests are handled by the Proxy component which can use the Cache component to solve the request or transfer it to the Load Balancer component. The request is then transferred to a data server and the answer is sent back to the Proxy component which deliver the related HTML page to the user. The designer adds the following requirements about the adaptation of its web server's architecture:

1. The cache must be used only if the number of similar requests is very high 2. The amount of memory devoted to the cache component must be automatically adjusted to the load of web server. 3. The validity duration of the data put in the cache must be adjusted with respect to the load of the web server. 4. More data server have to be deployed if the average load of the data servers is high. 5. The algorithm used to perform the load balancing must be changed according to load of the web server.

Here, requirements 1 and 4 are related to some architectural adaptations since it is required to update the architecture by adding (or removing) components. The others requirements are based on reconfiguration if we consider for instance that the data validity duration is a part of the configuration of the cache component. The approach presented in the following section allows designers to model adaptation policies which correspond to these requirements.

Modelling Component Architectures

This section presents briefly the component model used to described componentbased architectures. In this component model, a component is an entity which interacts with its environment (other components) through well defined connection points named ports. A component is also an instance of a component class which defines the various features included in the component.

Modelling Primitive Components

A primitive component is a "basic" component: one which does not contain any other component. A component might interact with its environment in two ways: it can provide or require some services. Provided and required services are grouped into interfaces which are used to describe the different ports of a component. Figure 2 (left part) models the component class Proxy introduced in the web server example. This component class defines three ports, namely the user port, the cache port and the data port. Each port requires or provides interfaces.

Modelling Extra-Functional Properties

In order to include extra-functional properties in the architecture design our approach claims to reify in the architecture the sensor and the actuator (if they exist) related to these properties. For instance, to include the memory consumption of a component, we need to add a service which measures the memory consumption and another service which frees memory such as a garbage collector service.

In the example of the web server, since the designer needs to adapt the architecture with respect to the average load of the proxy, he has to define a sensor which is able to measure the average load. This sensor is thus reified as a service that can be added on any port of this component. Figure 2 (right part) shows the Proxy component class where a new port devoted to the quality of service purpose has been added. The service which measures the average load is defined in the interface named IQoS.

Modelling Component Collaboration

Primitive components can be put together to build more complex systems. A simple collaboration between two components is realized thanks to a connector that links one port of each of the two components. Connectors enables the description of complex collaborations which might be encapsulated into a composite component. For instance, the architecture shown by Figure 1 can be seen as a collaboration between a proxy component, a load balancer, a cache, and a collection of data servers.

In Self-adaptive architectures, the structure of the collaboration might change and the composite component has to handle this modification in order to keep the collaboration in a consistent state. To enable this, the interaction between the composite component and every sub components involved in the collaboration has to be described as all the others possible interactions: that is to say by using a specific port. In Figure 2 (right part) the port load will be used by a composite component which contains a proxy component to configure it.

Modelling Adaptation Policies

As shown in the motivating example, both architectural adaptation and reconfiguration might be needed. This section describes how to model this two types of adaptation in the component model previously described.

Architectural Adaptation

The first requirement of the motivation example sets that the cache component should be used only if the number of similar requests rises above a specific threshold. In our approach we suggest to add a sensor which measures the number of similar requests and to define an adaptation policy which adds (or removes) the cache component from the architecture with respect to the sensor's measurement. Since composite components are the entities which know all the participants of a collaboration, we suggest to make them responsible for the adaptation policy.

In order to describe such architectural adaptations we suggest to use an imperative language based on a set of architectural actions. -Fill slot instance During the life of a composite component, the containedslot might be updated with a more efficient component. So we need to be able to fill slots. -Connect/disconnect port from connector The most important aspects in component architecture is the composability of component that is reified by the notion of connector. So we need to connect (or disconnect) port instances form connectors.

Figure 3 shows the two operations required to describe the addition and the removal of the cache component. The addCache operation creates a new instance of the cache component class, put it into the devoted slot of the collaboration, and connects the two ad-hoc ports. The RemoveCache operation just breaks the connector that links the cache to the proxy component.

Modelling Functional Data Reconfiguration

The requirements 2 and 3 of the motivating example are related to component data configuration. In these two examples, it is required to update the configuration of the cache component with respect to the load of the web server. Since this kind of reconfiguration is mostly expressed as rules, we suggest to use a rule-based notation to stay as closed as possible of the requirements set by the designers.

The rules that are used to describe data reconfiguration are based on facts. Each rule links the state of a sensor to the state of an actuator. The left part of Figure 4 shows the two rules required to model the data reconfiguration of the cache component with respect to the load of the proxy component. The first rule set up that when the average load of the proxy component is "high" then the size of the cache is "big" and the validity duration is "long". The other rule set up that when the average load of the proxy component is lower then the size of the cache is smaller and the validity duration is shorter.

To enable the use of terms such as "high", "low", "small" or "big", we consider that the sensor and the actuator used to reify every extra-functional properties (such as the size of cache, or the validity duration) offer services that define these terms. For instance, the cache component can offer a port that enables the configuration of the size of its memory with two services such as setLowMemory and setHighMemory. The mapping between these services and the rules can be ensured thanks to naming rules for such services.

Mixing Architectural Adaptations and Reconfigurations

In order to mix these two kinds of requirements in a single notation, the whole adaptation policy has to be defined in terms of modes. Each mode reflects one state of the architecture and includes all the rules which manage the functional data configuration.

Each mode refers to the architectural reconfigurations needed to switch (and to switch back) to this particular architectural mode. It defines also the rules that manage the functional data configuration of the components involved in this architectural mode. The right side of Figure 4 shows the mode that is defined to control the addition and the removal of a cache component into the web server architecture.

In this example, to enter the WithCache mode, the web server component (the composite component that manage the whole collaboration) has to run the addCache operation. The shift from the normal mode to the WithCache mode is triggered by a rule which set that the shift is performed when the number of similar requests detected on the proxy is "High". This information comes to the composite component thanks to the service which reifies the sensor. This service must be available on the port which connect the web server composite component to proxy component.

Related Work

Many tools have been developed in recent years to manage architectural adaptation or re-configuration at run time in component-based software [START_REF] Batista | Dynamic reconfiguration of component-based applications[END_REF][START_REF] Batista | Managing dynamic reconfiguration in component-based systems[END_REF] . However, there is still a gap between the modelling level (where designers specify component, data, and behaviour) and the implementation level where component are running.

Various Architecture Description Languages (ADLs) have been developed in the past as shown in [START_REF] Medvidovic | A classification and comparison framework for software architecture description languages[END_REF]. However, most of them only describe software architecture in a static way. Recently several works have shown the interest of describing the software architecture dynamic [START_REF] Bradbury | A survey of selfmanagement in dynamic software architecture specifications[END_REF]. For example, AADL [START_REF] Sae | Architecture Analysis & Design Language[END_REF] allows designers to model different modes of the same system, where each mode represents a particular state of the architecture evolution but there is no way to describe how the system switches between two modes.

In [START_REF] Allen | Specifying and analyzing dynamic software architectures[END_REF], Allen and al. suggest a first way to manage architectural re-configuration in component-based model. They extend the Wright component model to design component assemblies and perform consistency and verifications. This extension reuses the behaviour notation of Wright to model the reconfiguration. It allows the architect to view the architecture in terms of a set of possible architectural snapshots, each with its own steady-state behaviour. Transitions between these snapshots are accounted by special reconfiguration-triggering events. To introduce the dynamism in an architecture description, the architect has to modify the component's alphabet, and allow new messages to occur in port descriptions. Through this approach, the interface of a component is extended to describe when reconfigurations are permitted in each protocol in which it participates. Thanks to these new events, a "reconfiguration view" consumes these events to trigger reconfigurations. Contrary to our approach, they mainly work to represent some events that trigger the reconfiguration. In our work, we consider that any event can trigger the reconfiguration and we specify the reconfiguration policy at the composite level with a set of predefined modes. Some component models have also been developed to describe component architectures. As seen in [START_REF] Lau | A survey of software component models[END_REF] most of them only deal with the structure of the component architecture. For instance, SOFA [START_REF] Plásil | SOFA/DCUP: Architecture for component trading and dynamic updating[END_REF][START_REF] Plasil | Behavior protocols for software components[END_REF] use CSP to describe behaviour protocols on ports and enables static verification. But the behavioural description only deals with signal emissions and signal receptions and no syntax is related to the architecture reconfiguration.

Rainbow [START_REF] Garlan | Rainbow: Architecture-based self-adaptation with reusable infrastructure[END_REF] provides another appraoch to talk with component-based selfadaptation. This approach is very closed to our but has not been designed to support architectural reconfiguration and data reconfiguration in the same time.

In Fractal [START_REF] Bruneton | An open component model and its support in java[END_REF] user can defined some specific controllers on composite components to manage the internal of the component. Thus, adaptation policies can be described thanks to these controllers. However, controllers are a very low-level mechanism and they are related to the implementation. Our approach allows designers to express adaptation policies in the early stages of the design process.

Conclusion

In this paper, we introduce a way to model adaptation policies into componentbased architecture. The contribution of our approach is to take into account both the architectural adaptation and the functional data reconfiguration. To do this, the description of adaptation policies is based on the definition of several modes for the architecture. Each mode corresponds to a particular state of the architecture and can be related to some extra-functional properties measured in the architecture. The designer specifies a trigger condition for each mode which specifies when the system have to switch from one mode to this one. He specifies also the rules that manage the functional data adaptation inside each mode. This work is a first step in order to manage adaptation policies in early design steps in component-based architectures. However, it is still difficult to design the modes. From the same architecture state, a different order of the adaptation modes can lead to different architectures. We plan to express the whole behaviour of each component in order to simulate the architecture and to predict performance for self-adaptive architectures such as memory consumption.

Fig. 1 .

 1 Fig. 1. The web server architecture modelled as UML2.0 component diagram

Fig. 2 .

 2 Fig. 2. The Proxy and Proxy Updated primitive components

  o p e r a t i o n addCache ( ) i s do s e l f . c a c h e := Cache . new c o n n e c t ( s e l f . p r o x y . c a c h e , s e l f . c a c h e . u s e r ) end o p e r a t i o n removeCache ( ) i s do d i s c o n n e c t ( s e l f . p r o x y , s e l f . c a c h e . u s e r ) s e l f . c a c h e . s e t E m p t y end

Fig. 3 .

 3 Fig. 3. An architectural adaptation described using architectural primitives

  p r o x y . a v e r a g e L o a d i s ' High ' => c a c h e . s i z e i s b i g and c a c h e . v a l i d i t y T i m e i s ' Long ' p r o x y . a v e r a g e L o a d i s 'Low ' => c a c h e . s i z e i s ' Small ' c a c h e . v a l i d i t y T i m e i s ' Short ' mode WithCache i s t r i g g e r i s p r o x y . S i m i l a r R e q u e s t N u m b e r i s ' High ' e n t r y i s addCache ( ) e x i t i s removeCache ( ) p r o x y . a v e r a g e L o a d i s ' High ' => c a c h e . s i z e i s ' Large ' and c a c h e . v a l i d i t y T i m e i s 'Long ' p r o x y . a v e r a g e L o a d i s Low => c a c h e . s i z e i s ' Small ' c a c h e . v a l i d i t y T i m e i s ' Short ' end

Fig. 4 .

 4 Fig. 4. An reconfiguration-based adaptation described using rules

  These architectural actions are: -Create/Remove component instance As we defined both component types and instances, we need to instantiate component types to get new instance and to remove old ones. -Create/Remove port instance we defined also port types (with multiplicity) and so users need to create new port instances to support a new customer connection for instance. -Create/Remove slot instance we also defined slot into composite components. Composite component types do not directly contain sub-component type, but a reference to another component type (called a slot) on which one can specify some multiplicity. So, we need a notation to create (or remove) slot instances into composite components.


Olivier Hugues
email: o.hugues@net.estia.fr

Jean-Marc Cieutat
email: j.cieutat@estia.fr

Pascal Guitton
email: guitton@labri.fr

An Experimental Augmented Reality Platform for Assisted Maritime Navigation

Keywords: H.5.1 [Information Interfaces and Presentation]: Multimedia Information Systems -Artificial, augmented and virtual realities; I.3.7 [Computer Graphics]: Three-Dimensional Graphics and Realism-Virtual reality Experimentation, Human Factor, Security Augmented Reality, Mixed Environment, Image Processing, Human Factor, Combining exteroceptive data

published or not. The documents may come   L'archive ouverte pluridisciplinaire

INTRODUCTION

The continuous progress of new technologies has led to a proliferation of increasingly smart and powerful portable devices. The capabilities of devices on board a ship now enable crews to be offered a processing quality and volume of information until now unrivalled. In a hostile environment such as the sea, users need a relevant flow of information. Computer assisted vessel management is therefore increasingly widespread and digitalisation is an inescapable development. The three main aims are as follows:

1. Improved safety (property, environment and people) 2. Increased gains from productivity (fishing, etc) 3. The representations required for environmental control (orientation, location and direction)

These aims have led maritime software publishers to develop increasingly sophisticated platforms, offering very rich virtual environments and real time information updates. There are many companies on the embedded maritime navigation software market.

They can be separated into two categories. The first part includes those, which develop applications enabling embedded sensors to be taken advantage of (radar, depth-finder, GPS, etc.), such as Rose Point [4], publisher of Coastal Explorer software (Figure 3) and MaxSea International [14], publisher of the MaxSea TimeZero software (Figure 2). Other companies offer hardware platforms in addition to their software applications, like Furuno [10] (Figure 4) and Garmin [11] (Figure 1).

Figure

  Figure 1. Garmin Figure 2. MaxSea


S Yu Grachev

C Cuminatto

E Søndergård

E Barthel

High-Throughput Optimization of Adhesion in Multilayers by Superlayer Gradient

We used thickness gradients for high throughput optimization of adhesion in film stacks. The idea is based on the so-called superlayer test where a top layer under high compression exerts a load onto the lower interfaces and may cause delamination and buckling. Thus, on one hand, the thickness gradient of the superlayer results in the gradient of the load. On the other hand, the adhesion gradient can be realized by changing the thickness of an adhesion enhancer (or an adhesion reducer). When applied in two perpendicular directions (cross-gradient), the gradient of the superlayer in one direction and of the adhesion enhancer in the other, the plane of the sample represents a map where the line of delamination relates the interfacial toughness to the thickness of the enhancer.

In our tests we used Mo superlayers under compressive stress of the order of ~1.5 GPa on a Si wafer with a native oxide. The adhesion reduction was observed with this methodology when Ag layer up to 10 nm thick was deposited onto the substrate prior to Mo deposition. The delamination occurred at Ag thicknesses starting from ~6 nm. This thickness of Ag corresponds to the islands coalescence and formation of a continuous film which immediately results in adhesion reduction. The other test was performed with a step gradient of Ti enhancer placed under a 10 nm thick Ag layer in otherwise the same arrangement. A single test showed that 2.8 Å of Ti was sufficient to improve the adhesion between Ag and SiO x by several times.

INTRODUCTION

Film stacks are widely used in industrial applications such as optical filters, thermal insulators, hard protective coatings, and in microelectronics. One of the requirements for applied use of thin films is their mechanical stability. However, weak interfacial toughness is often responsible for failures of products. In this context, a reliable and easily applicable test of adhesion is a highly wanted tool for mechanical optimization studies.

The superlayer adhesion test has been used both in adhesion estimation and in fundamental research [1][2][3][4][5]. In this test a superlayer under high compression is deposited directly onto a stack. In this case, there is a tendency for the superlayer to relax the internal stress by breaking a weak interface of the stack and buckling. The load on the interface increases with increase of the elastic energy stored in the stressed layer. Since the elastic energy is proportional to the layer thickness (E elastic = σ 2 h E/(1-ν); σ is the stress, h is the thickness, E is the Young modulus and ν is the Poisson's ratio), a gradient of the thickness of the stressed layer provides a gradient of load. When the thickness of the superlayer is large enough, the delamination may occur.

The use of gradients of the superlayer can give a quantitative value of the threshold thickness for delamination. In this way, the adhesion of interfaces can be compared, although the absolute value of the interfacial toughness is difficult to obtain [START_REF] Yu | Thin Solid Films[END_REF]. Using the same gradient method, a gradient of adhesion can also be obtained. Indeed adhesion may depend upon film thickness because an interlayer can either promote or reduce adhesion. Here we demonstrate that cross gradient samples can be obtained where a thickness gradients of the superlayer and an adhesion gradient are applied in orthogonal directions simultaneously in one sample. We show that cross-gradients provide a fast test of the impact of an interlayer thickness on adhesion,

EXPERIMENT

2 inch (50 mm) wafers of Si(100) with a native oxide were used as substrates. All the films were obtained by dc sputter-deposition technique at room temperature. A high vacuum deposition chamber with a base pressure of 1x10 -5 Pa was used. We applied Mo films under ~1.5 GPa compressive stress as superlayers. For nominally homogeneous Mo layers the thickness varied by less than 10~% across the sample, which insured the control over thickness of the films. More details on experimental conditions are given elsewhere [START_REF] Yu | Thin Solid Films[END_REF].

Thickness gradients were obtained by gradually shading the substrate by a metallic shutter during deposition. The plate was moved either continuously with a constant speed or by discrete steps resulting in the continuous gradient or in a series of stripes of homogeneous thickness, respectively. After rotating the sample by 90° around its normal another gradient was applied (cross-gradient). We realized a gradient of an adhesion modifier (Ti or Ag) in one direction and a gradient of the Mo superlayer in the perpendicular direction.

RESULTS AND DISCUSSION

Figure 1 shows a photo of a sample with a continuous cross-gradient of Ag vs. Mo in the stack Mo/Ag/Si(100). The thickness of Ag is constant along vertical lines and continuously increases from 0 at the lefthand side to 10 nm at the righthand side of the wafer. The thickness of the Mo superlayer increases from 150 nm at the bottow, below the horizontal line, to 450 nm at the upper end of the wafer. The adhesion between Ag and oxides is known to be weak [START_REF] Barthel | [END_REF]. This is why the addition of Ag reduces the mechanical stability of the stack. At a certain threshold of ~ 6 nm of Ag (the right vertical line) the adhesion became weak enough and delamination and buckling of the layer has occurred. The delamination started in the area with thicker Mo and thicker Ag layers and propagated towards smaller thickness areas before stopping at some threshold thickness which is found to depend upon Ag thickness. Therefore at each thickness of Ag, a threshold thickness of the superlayer can be determined, which reflects the strength of the weak interface or the interfacial toughness. Remarkably, the toughness of the Ag/SiO x interface decreased rapidly as the thickness of Ag reached the critical value of ~ 6 nm. As the thickness of Ag increased further, the threshold thickness of the superlayer for delamination decreased to ~200 nm. This must be connected to the fact that at room temperature Ag first forms islands which coalesce and form a continuous film at about 5-8 nm of Ag [8,9]. After coalescence a continuous Ag film forms resulting in the loss of direct Mo/SiO x coupling and lower adhesion. Although the adhesion between Ag and SiO x is weak, it can be improved by adding to this interface an adhesion enhancer, for example, Ti. The effect of Ti is demonstrated in our second experiment. We have prepared a cross-gradient Ti vs. Mo in a stack Mo/Ag(10 nm)/Ti/Si(100). In this experiment, the thicknesses were changed in steps. The thickness of Ti was 0, 1.4, 2.8 and 4.2 Å. The thickness of Mo was chosen to be 206, 412, 618 and 824 nm. The delamination pattern is shown in figure 2.

When no Ti was present at the Ag/SiO x interface the application of Mo superlayer resulted in delamination all through the Mo thickness. This means that the threshold thickness for delamination was below 206 nm. As 1.4 Å of Ti was added to the weak interface, the threshold thickness had increased to 412 nm. Deposition of 2.8 Å of Ti enhanced the adhesion dramatically and the threshold thickness for delamination elevated to ~824 nm. The adhesion with thicker Ti enhancer was out of range of the superlayer test.

Note that the blisters in both these experiments were of the telephone-cord shape [5]. This shape allows for relaxation of the biaxial stress in both in-plane directions. However the mechanics of the telephone-cord blisters is not well understood and is currently under investigation [5]. In addition to the adhesion optimization, the present tests give access to the morphologies of the telephone-cords for a wide range of thicknesses and adhesions.

CONCLUSIONS

The high throughput approach to the adhesion optimization based on the superlayer test of adhesion has been developed. We used a thickness gradient of Mo superlayer in one direction and a thickness gradient of the adhesion modifier in the perpendicular one. The first gradient provided a range of load onto tested interface and the second one resulted in the gradient of interfacial toughness. This geometry allowed for comparative studies of adhesion versus the thickness of an adhesion modifier.

With this test we found that the adhesion between an Ag layer and the native silicon oxide on a Si wafer dramatically decreases at ~ 6 nm of Ag. At this thickness the Ag islands coalesce and start forming a continuous film. The test was also used with the gradient of Ti interlayer between Ag and SiOx. The increase of thickness of Ti resulted in the increased adhesion in this system. A change of Ti thickness with a step of 1.4 Å immediately resulted in the interfacial toughness, which was detected by the superlayer test.

Figure 1 .

 1 Figure 1. The delamination pattern due to a continuous cross-gradient Ag vs. Mo in a stack Mo/Ag/Si(100). The Ag thickness was changed from 0 at the left red line to 10 nm at the right end of the sample. The thickness of Mo superlayer was changed from 150 nm at the blue line and below to 450 nm at the upper end of the sample. The buckling of the sample was observed in the area with thicker Mo and thicker Ag layer.

Figure 2 .

 2 Figure 2. The delamination pattern due to the step cross-gradient Ti vs. Mo in a stack Mo/Ag (10 nm)/Ti/Si(100). The thicknesses are given in the picture. Addition of Ti improved adhesion between Ag and Si(100) systematically and the threshold for delamination increased with Ti thickness.

ACKNOWLEDGMENTS

This project is partly funded by the ANR project MatetPro07_247145.