Grégory Nain

Erwan Daubert

Olivier Barais

Jean-Marc Jézéquel

Using MDE to Build a Schizophrenic Middleware for Home/Building Automation

In the personal or corporate spheres, the home/office of tomorrow is soon to be the home/office of today, with a plethora of networked devices embedded in appliances, such as mobile phones, televisions, thermostats, and lamps, making it possible to automate and remotely control many basic household functions with a high degree of accuracy. In this domain, technological standardization is still in its infancy, or remains fragmented. The different functionalities of the various appliances, as well as market factors, imply that the devices that control them communicate via a multitude of different protocols (KNX, LonWorks, InOne). Building a high level middleware to support all the appliances seems to be a reasonable approach. However, market factors has shown that the emergence of a unique and universal middleware is a dream. To solve this issue, we have built a new generation of schizophrenic middleware in which service access can be generated from an abstract services description. EnTiMid, our implementation of schizophrenic middleware, supports various services access models (several personalities): SOAP (Simple Object Access Protocol), UPnP and DPWS (Device Profile for WebServices). In this paper, we describe how these personalities are generated using a Model Driven Engineering approach and discuss the benefits of our approach in the context of a deployment of new services at the city level.

Introduction

Time after time, each building parts manufacturer has developed his own communication protocol, and this for two reasons. The first one is the increasing need of communication between the devices. Then, the belief that a close protocol is more secured, is still present in minds and make the second reason. As a consequence, devices of today are communicating through dozens of protocols, and most of them are private and protected. For example, X2D 1 , InOne 2 or IO-homecontrol 3 are private protocols. Open protocols are emerging such as KNX, LonWorks or BacNet, but interconnections between each other and/or with private protocols are often made 'on demand'. Building a high level middleware to support all the appliances and allow the development of high level services seems to be a reasonable approach. However, building automation market factors has shown that the emergence of a unique and universal middleware is a dream. To solve this issue, we present in this paper a new generation of schizophrenic middleware [START_REF] Vergnaud | Polyorb: A schizophrenic middleware to build versatile reliable distributed applications[END_REF] in which service access can be generated from an abstract services description. EnTiMid, our schizophrenic middleware implementation, supports various services access models (several personalities): SOAP (Simple Object Access Protocol), UPnP [START_REF]The UPnP Forum[END_REF] and DPWS (Device Profile for WebServices) [START_REF] Jammes | Service-oriented device communications using the devices profile for web services[END_REF]. In this paper, we describe how these personalities are generated using an Model Driven Engineering approach and discuss the benefits of our approach in the context of a deployment of new services at the city level.

The remainder of the paper is organized as follows. Section 2 presents an overview of EnTiMid, a middleware for home automation and presents the metamodel embedded into EnTiMid to export devices services at the business level. Section 3 presents the generative tool chain of personalities. Section 4 discusses the usage of EnTiMid in the context of a city deployment. Section 5 highlights some selected related works and Section 6 wraps up with conclusions and outlines some future work.

Overview of EnTiMid

EnTiMid is a middleware implementation developed in a house or building automation context. The aim of this middleware, is to offer a level-sufficient abstraction, making it possible for high level services to interact with physical devices (such as lamps, heater or temperature sensors).

A layered middleware based on services

Based on a service-oriented architecture [START_REF] Jammes | Service-oriented paradigms in industrial automation[END_REF], this middleware incites people to build their software as a set of services working together. Thus, each user can customize the services offered by the software, according to his needs.

The OSGi Alliance [START_REF]Osgi alliance[END_REF], 'consortium of technology innovators', has released a set of specifications which define a service-oriented platform [START_REF] Jézéquel | Osgi service platform core specification[END_REF], and its common services. The OSGi kernel is a standard container-provider to built service-oriented software. It implements a cooperative model where applications can dynamically discover and use services provided by other applications running inside the same kernel. It provides a continuous computing environment. Applications can be installed, started, stopped, updated and uninstalled without a system restart. It offers a remote management model for applications that can operate unattended or under control of a platform operator. Finally it embeds an extensive security model so that applications can run in a shielded environment. According to these specifications, an application is then divided on several bundles. A bundle is a library component in OSGi terms. It packages services that are logically related. It imports and exports Java packages and offers or requires services. Services are implementations of Java interfaces.

Inspired by the CBSE (Component Based Software Engineering) paradigm [START_REF] Szyperski | Component technology: what, where, and how?[END_REF], each bundle is designed to reach the highest level of independence, giving the software enough modularity to allow partial services updates, adds or removes. This programming style allows software-builders, to deploy the same pieces of software for all of their clients, either professionals or private individuals, and then simply adapt the services installed. Moreover, the services running on the system can be changed during execution.

On top of this kernel, EnTiMid is structured around three layers as presented in Figure 1: a low-level layer which manages communication with the physical devices, a middle layer (the kernel), offering a message oriented middleware (MOM), and giving a first abstraction level of low-level layer, a high-level layer which publishes services and enables the device access through standard protocol. The Figure 1 gives an overview on how services are organized. EnTiMid defines a set of interfaces between the services provided by the low level layer and the services required by the middle layer to allow the access to the physical devices.

The low-level offers a common abstraction to the EnTiMid Kernel to access the different devices. It wraps existing library to support some protocols, for example, it wraps the Calimero toolkit to provide an access to KNX devices 4 . It provides also home-made drivers to access protocol such as X2D or X10. The EnTiMid kernel (middle layer) and the high level layer are described more precisely in Sections 2.3 and 3.

A schizophrenic middleware

High-level protocols, such as DPWS, SOAP or UPnP, are going to be more and more present in our everyday life. Each of them offers a different access to devices, according to their main goal. For example, UPnP has been developed to ease media sharing, whereas SOAP is a protocol to programmatically access services such as devices provided services. So, manufacturers choosing to implement a high-level access to their devices, will select the protocol offering the best accordance with the devices applications.

In a few years, new high and low level protocols will probably appear, and some will become useless. Existing protocol will evolve and EnTiMid, which aims to ease the device interconnection, has to support all the new protocols and new protocols versions. An interesting solution to face the need of protocol management flexibility (both low and high level), is the schizophrenic middleware, presented by Laurent Pautet [START_REF] Vergnaud | Polyorb: A schizophrenic middleware to build versatile reliable distributed applications[END_REF]. A schizophrenic middleware offers several personalities to access services. Consequently, in EnTiMid, high-level protocols define application personalities. As the middleware has to support lots of application personalities, we propose in this paper to use a MDE approach to generate these application personalities from an internal representation of devices. This choice is driven by the features provided by a MDE approach (abstraction, transformation language) and by the improvement of the maturity of MDE tools (we use the Eclipse Modelling Framework [START_REF] Ecore | The eclipse modeling framework project home page[END_REF] for the meta-model definition and Kermeta [START_REF] Muller | Weaving executability into object-oriented meta-languages[END_REF] for the transformation). Next subsection presents in depth the internal representation of the device services. Section 3 presents the details of the generative approach used for the UPnP and the DPWS personalities.

EnTiMid kernel

Figure 2 shows a part of the structure of the middle-level layer. Each manufacturer provides a Bundle. This bundle will use a Gateway contained in a Zone in order to access the devices. Each low-level bundle implements a method called getAvail-ableProducts(). This method returns a catalogue of the devices the bundle is able to control/provide. Then, users just have to instantiate the device they need to interact with. According to the type of the device, the actions offered are different. Actuators inform the system about the actions they are able to realise, giving a list of CommonAction (on, off, up, down...). Then, for each CommonAction, they produce a HouseAction containing all necessary information for the action to be done on a device. These HouseActions can be valued to specify light intensity for example. Sensors are divided in different categories, and we focus on ModularSensors. They are composed of Modules, and those modules are only containers. At setup time, a sensor in charge to switch off a light, will ask the light actuator for the House-Action to be sent to switch off the light, and this HouseAction is then stored in a list. Then, at use time, when the push() method is called on a Module of a ModularSensor, all the HouseActions stored in the Module list are published to all HouseActionListeners.

Figure 3 illustrates what append when push method is called on a Module. A HouseEvent containing a HouseAction is sent for each HouseAction to each House-EventListener. Then, the bundle able to route the information on the destination The Object Management Group (OMG) promotes an approach to achieve adaptability at the application level with the Model-Driven Architecture (MDA) [START_REF] Soley | Model-Driven Architecture[END_REF][START_REF] Fuentes | How mda can help designing component-and aspect-based applications[END_REF]. The concepts involved in MDA are based on the definition of two kinds of model: Platform Independent Models (PIM) and Platform Specific Models (PSM). A PIM provides an abstract representation of an application independently of any standards and aims at capturing only the business concerns. A PSM is the result of the transformation of a PIM to apply it on a particular technology or a particular standard. PIM and PSM are defined by specific meta-models which constrain the expression of the models. The EnTiMid internal device services model can be considered as a PIM, due to the fact that all devices types are specified in the framework, and specifications are common to all technologies. On the opposite, UPnP or DPWS personalities, for example, are to be considered as PSMs, because the device description mode is very specific for each device and dependent of the protocol. UPnP Meta-model UPnP [START_REF]The UPnP Forum[END_REF] is based on a discovery-search mechanism. As an UPnP-Device joins the UPnP network, it sends an XML description file to all UPnP-ControlPoints, presenting itself with information such as manufacturer, device type, device model or uuid. Most of times a UPnP-Device is selfcontained, describing itself and publishing all services it can offer. The UPnP specification allows devices to contain other devices (called embedded devices); if so, the root-Device (the container) have to publish its self-description and the description of each embedded device. Moreover, UPnP-Devices (embedded or not) can offer UPnP-Services, as shown in Figure 4. Each service type provided by an UPnP-Device, must be described in a separated file. The description explicits all the UPnP-Actions the service renders, and all the UPnP-StateVariables, used by these actions, in a UPnP-StateTable. Indeed, UPnP-Actions can be parametered, and sens (in or out), name and related StateVar are specified for each parameter. UPnP-StateVars are used to offer more precise information about parameters, such as value type or allowed value list.

Meta-binding he Figure 5 shows how the binding between EnTiMid-Devices and UPnP-Devices is done. An EnTiMid-Device is exported as a UPnP-RootDevice, beeing Sensor or Actuator. In the case the device is a Sensor, and more precisely, a ModularSensor, all the modules it contains are exported as UPnP-EmbeddedDevices. The RootDevice do In order to allow users to generate actions on actuators, a new UPnP-Device is created and is given as BasicModule as it offers CommonActions. For example, if a simple light actuator offers "on" and "off" CommonAction, a BasicModule will be created for each action, and added to the RootDevice. By this way, it will be presented as a UPnP-Device containing two Modules (one "on" ans one "off") each one offering a push() method. As a consequence, EnTiMid-Devices are mapped to UPnP-RootDevices; the Modules are mapped to UPnP-EmbeddedDevices and CommonActions are specified as ServiceStateVariables.

Files As previously said, each UPnP-RootDevice and each UPnP-Service must be defined in an XML description file. During its life, the UPnP-Device will frequently be asked to send its description file to other UPnP-Devices, and services descriptions are consulted each time a service is likely to be used. In a commercial point of view, those description files are defined once (for a proper device), and embedded in the product. But the dynamics of EnTiMid, its abstraction level and its modularity, implies that information, such as device type or description, about the devices installed on the system, are never known in advance. Moreover, the EnTiMid implementation of a product can offer different services, and those services are implementation dependent. That is why the description files are generated at runtime.

Service description file generation Our choices of implementation has led to the fact that only Modules offer services. UPnP-Actions, offered by a UPnP-Service, are an UPnP-Export of some methods of the module class. Methods to be exported are signaled to be UPnP-Compliant, thanks to the presence of an UPnP-Method annotation. This annotation offers some interesting information. The first information is that the annotated method has to be exported in the service; then, the annotation gives, at runtime, a semantic name to the parameters and the returned value of an action. More precisely, without annotation, the only information one can get on a parameter at runtime is its place on the method signature and its type. In this case, the user can not have the information that the first string parameter is for the name, and the second for the age. The annotation brings these information. So, if the BasicModule service description file does not exist yet, a simple reflexive research on the class's methods make it possible for the system to generate it, and all devices offering this service will then be able to point to this file.

Device description file generation

In order to generate the description file of a device only once, the name of file is the device class name. Device des s. The first one gives general information about the device: manufacturer, description, model type, model number or uuid; some are statically completed by the EnTiMid-System (such as manufacturer), others are retrieved from the device itself (model type, model number). The second part contains the types, identifiers and links of the services offered by the device. For example, the first BasicModule declared will complete its services list with: <serviceType>urn:www.entimid.org:service:BasicModule:1</serviceType> <serviceId>urn:www.entimid.org:serviceId:BasicModule1</serviceId> <SCPDURL>/service/BasicModule/description.xml</SCPDURL> <controlURL>/service/BasicModule/control</controlURL> <eventSubURL>/service/BasicModule/eventSub</eventSubURL>

The last description file part contains the description of each embedded devices. Those descriptions are composed of the two previous part, for each embedded device.

UPnP events management A different listener is created for each service of the device, to simply manage UPnP events. By this way, a listener is linked with a unique module, and side-effects with other modules or devices are avoided. Each listener is then attached to each action of the service. When an action event is received, the first work is to identify the method that has been actionned. Once done, the second work is to cast the UPnP-Action parameters into the real method argument types. Then the method is invoked, and, if necessary, the result is translated into a UPnP-VarType and sent.

DPWS personality generation

The Device Profile for Web Services (DPWS) [START_REF] Jammes | Service-oriented device communications using the devices profile for web services[END_REF] defines a minimal set of implementation constraints to enable secure Web Service messaging, discovery, description, and eventing on resource-constrained devices. Its objectives are similar to those of Universal Plug and Play (UPnP) but, in addition, DPWS is fully aligned with Web Services technology. Moreover, it includes numerous extension points, allowing for seamless integration of device-provided services in enterprise-wide application scenarios. From a conceptual point of view, the DPWS meta-model is closed to the UPnP meta-model described in Figure 4. Consequently, building the abstract model of the service to export, follows the same way: we use the Java annotation in the low level layer to infer the model. However, the generation process is different. To build the DPWS layer, we use the WS4D project [START_REF] Zeeb | Ws4d: Soa-toolkits making embedded systems ready for web services[END_REF]. This project proposes a programming model to create DPWS services. This model is based on the concept of service, device, operation and parameter.

A DPWS service provides an implementation of one or more WS (Web Services) port types to DPWS clients. The messages, a service receives and sends, are specified by its WS port types. The DPWS services definition is different of the standard definition of the term service in the WSDL specification. A device hosts one or more services and provides common functions like messaging or discovery. It is classified by its port types. According to the DPWS specification a device is a target service of the WS-Discovery specification. The basic functionality of a device is implemented by the class HostingService. An Operation/Action is a named message exchange pattern of a port type. It can consist of an input and output message, and multiple fault messages. The appearance and order of the input and output messages in the WSDL determine the type of the operation (requestresponse (in-out), solicit-response (out-in), notification (out), one-way (in)).

For each device, service and operation, a Java class has to be generated. This class must extend respectively HostedService, HostingService and Action. For each parameter, an instance of the class Parameter has to be implemented. Consequently, the generation process can be done automatically. To achieve that we use the JET Framework to create generation template for DPWS. We embed the JDT compiler provided by the eclipse project to compile the generated code. Finally, we programmatically create a new bundle containing all generated classes. Once loaded, this new bundle provides all generated classes, and allow them to be used.

Use case

Context: Application to a city-level project

EnTiMid is currently used in a Brittany project to allow old persons to hold in their home as long as possible. Two associations of the Rennes metropolis, the "CODESPAR" and the "ASSAD", are working together in a project called "Maintiens à domicile et habitat évolutif ". With the support of industrial partners, they are conceiving an environment around health professionals and old people, composed of new information technologies. As previously said, the main goal of the project is to help people to stay at home as long as possible, but this can not be done without helping health professionals in their everyday work.

From March to October 2007, an initial study has permitted to obtain a set of recommendations. The second phase of the project aims to find technical answers to these recommendations. However, technical solutions are often multiples, and the probability to install this technical environment over, or mixed with, an already installed technologies is not null.

Consequently, the software used to manage the technologies and ease the access to the house for health professionals, will have to be fully adaptable to the in-place technology, and require a short development time to reach new technologies or new protocol versions.

Its unified technology management, provided by the middleware abstraction of the underlying protocols, and its multiple access personalities, inherited from its schizophrenic aspect, have led EnTiMid to be a privileged candidate to be deployed as the access point to the equipped houses.

Advantages of a schizophrenic middleware in this context

The schizophrenia of this middleware and its generative capabilities are advantages in two dimensions.

In space The city scale deployment of the project necessarily implies that the technologies used will sometimes be different, due to some physical constraints, or because a technology is already installed, and people do not want to change. EnTiMid will then propose an abstraction of the deployed devices technologies; it will expose different personalities of these devices for high level application developers. Consequently, services provider associated to the project will be able to develop high level services directly on top of DPWS or UPnP. Finally, the management capabilities provided by the OSGI gateway will also help to update and reconfigure the gateway.

In time Software, technologies and protocols constantly evolves and versions change with, sometimes, some compatibilities problems. That is to say that during its life, the OSGi gateway will have to implement new protocols, or different versions of a given protocol. Moreover, protocols can be used in different versions, at a given time, in different places of the city. Once again, the different personalities make it possible for EnTiMid to gain multiple version compliance, for different protocols.

Related work

Xie Li [START_REF] Li | The design and implementation of home network system using osgi compliant middleware[END_REF] has developed a residential service gateway, which aim is to rely "insideof-house" system to a "outside-of-house" system, allowing users to connect their residential gateway from a centralized point "outside-of-house". The connection is recommended to be done by a VPN solution, and offers an HTTP interface to control devices through the Lonworks PLC technology and they have planned in future work to export their services to UPnP. The "inside-of-house" system, developed on an OSGi platform, implements algorithm giving Plug&Play facilities to the system for "pre-defined devices". Compared to this system, our implementation is designed to be Plug&Play. Our system also eases the interoperability and can access several technologies.

The paper [START_REF] Uribarren | Service oriented pervasive applications based on interoperable middleware[END_REF] presents a "Service Oriented Pervasive Applications Based On Interoperable Middleware". As EnTiMid, the described middleware is composed of three layers: a drivers layer, in charge of the connexion between the devices and the "Unified Service" layer. Then a bridges layer links the Unified Service instances to diverse "service technologies (UPnP, WS,...)". The solution is similar, but they do not use the OSGi technology. Besides, we made the choice in this paper to use an MDE based generative approach to propose several personalities for the diverse "service technologies (UPnP, WS,...)".

Valtchev et al. [START_REF] Valtchev | Service gateway architecture for a smart home[END_REF] have developed a gateway to control a smart house. This gateway defines an abstract layer to manage the hardware protocol used to communicate with physical devices. Moreover it is defined to manage many services gateways. But it does not define a high level abstraction to offer services through protocols like DPWS or UPnP. This abstraction could be done using their gateway but for practical reason we have choosen to define our own implementation, because their implementation offers many things like we don't want to use now. Even if, later, EnTiMid could be bigger and need to manage many gateways for examples.

Bottaro et al. have developed a service platform [START_REF] Seyvoz | Dynamic web services on a home service platform[END_REF] to offer service abstraction like DPWS over device communication. Into this platform, each device has to register on the OSGi context, for each high level protocol it implements. At runtime, the high level protocol 'manager' gets all registered devices and publishes them on the network. The main difference between this platform and EnTiMid comes from the service registration. Indeed, for each high level protocol a device want to offer, it has to implement a set of specific interfaces(API) and register to the OSGi context. The generative approach used in EnTiMid simplifies the development of devices. All installed devices are natively exported toward high level protocols, thanks to their EnTiMid-Device implementation.

Conclusions and perspectives

The plethora of networked devices embedded in appliances, such as mobile phones, televisions, thermostats, and lamps, makes possible to automate and remotely control many basic household functions with a high degree of accuracy. Consequently, a new breed of technologies is needed to address the challenges of the development and deployment of building automation applications over an evolving, large-scale distributed computing infrastructure. The approach and the tools, provided by EnTiMid, and described in this paper, are an example of such a technology.

EnTiMid offers a first solution to manage the multiplicity and the evolution of communication protocols through a layered schizophrenic middleware. This solution consists of offering a common abstraction of the home device topology and provides a generative approach to offer an access to the devices through different personalities. To improve the flexibility of this middleware, the high level protocols are generated and loaded at runtime. It enables a dynamic reconfiguration of the application and the high-level protocol bundle without any system restart.

EnTiMid have been implemented to form a complete middleware for home automation 5 . Future work includes technical improvement and new scientific investigations. As a technical improvement of the platform, the AMIGO European project designed a 3D application called VantagePoint, in order to model a room with objects and devices. Moreover, the JDT compiler embedded to compile the DPWS personalities is heavyweight for implementation in small commodity set-top box. The DPWS generation tool chain has to be technically improved. This could be a really good way to generate the configuration file of a house, or to provide a 3D device management application. As a scientific future work, we will work on the definition of a context-aware service composition operator in order to provide users the relevant high level services. In this context, we will follow the work of the S-Cube project in particular the work on the adaptation of service-oriented applications.

Fig. 1 .

 1 Fig. 1. EnTiMid architecture

Fig. 2 .

 2 Fig. 2. Simple EnTiMid model

Fig. 3 .

 3 Fig. 3. Message transmission on action detection

Fig. 4 .

 4 Fig. 4. UPnP-Device structure

Fig. 5 .

 5 Fig. 5. UPnP mapping examplenot offer any services: only modules are offering such a thing. But, actuators do not contain any Module, and so, can not be exported as simply as sensors. In order to allow users to generate actions on actuators, a new UPnP-Device is created and is given as BasicModule as it offers CommonActions. For example, if a simple light actuator offers "on" and "off" CommonAction, a BasicModule will be created for each action, and added to the RootDevice. By this way, it will be presented as a UPnP-Device containing two Modules (one "on" ans one "off") each one offering a push() method. As a consequence, EnTiMid-Devices are mapped to UPnP-RootDevices; the Modules are mapped to UPnP-EmbeddedDevices and CommonActions are specified as ServiceStateVariables.

http://house-manager.gforge.inria.fr

Acknowledgments

The research leading to these results has received funding from the European Community's Seventh Framework Programme FP7/2007-2013 under grant agreement 215483 (S-Cube). (http://www.s-cube-network.eu).


Jacques Simonin
email: jacques.simonin@orange-ftgroup.com

Francis Alizon
email: francis.alizon@orange-ftgroup.com

Jean-Pierre Deschrevel
email: jeanpierre.deschrevel@orange-ftgroup.com

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

Jean-Marc Jézéquel
email: jezequel@irisa.fr

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

EA4UP: an Enterprise Architecture-Assisted Telecom Service Development Method

Keywords: Unified Process, Enterprise Architecture, telecom service development

The cost of a telecom service development is correlated to the discontinuity and the complexity of the process. To solve this problem, we propose a method dedicated to telecom service development, called EA4UP method. The first EA4UP characteristic is the use of the Enterprise Architecture (EA) for the design activity. The EA promotes component reusing, and improves development process continuity thanks to a Model Driven Engineering approach. In this new method, EA enforces the transformation of an analysis model into a design model. The second EA4UP characteristic is to place functions in the core of the method (instead of data). The assessments of eleven projects allow to measure profits of this EA4UP method with regard to the previous ones.

Introduction

A telecom service is a service provided to an enduser by a telecommunication operator. For example, a messaging service enables an end-user to create an email, to send it to another user and to receive emails. This service is decomposed in three functions: message creation, message sending and message receipt. In France Telecom, architects develop new telecom services based on such decompositions which are instantiated into components. For decreasing development costs, components reuse becomes the rule and not the exception. Such reuse requires identifying and sharing service components. Besides, telecom service development processes follow the standards of system development [START_REF]Information technology --Process assessment[END_REF], for instance they use a development process such as the Unified Process (UP) [START_REF] Jacobson | The Unified Software Development Process[END_REF], well-known incremental, iterative use-case driven process.

One of the major requirements of telecom service development is that they should leverage existing building blocks called enablers, as defined by Open Mobile Alliance (OMA) [START_REF] Oma | OMA Service Environment[END_REF]. An enabler dedicated to messaging functions could be used for the architecture design of the previous messaging service. It would indeed make no sense to redevelop an enabler implementing basic messaging functions with a specific protocol as POP [START_REF]Post Office Protocol (POP)[END_REF]. More generally, the current Information System (IS) infrastructure must be optimized to allow the smooth integration of new telecom services. This reusing means also a telecom service architecture rationalization with a sharing of functions and technologies. The telecom services IS evolution should then benefit of this rationalization.

A dynamic approach is intrinsic to service design. Consider for example a simple electronic message sending service that can be described as a sequence of: (i) a successful user authentication; and (ii) a message sending by the user. For business IS applications, the static aspect description is often the main point of view with the study of the data model. The Orange Labs experience is that the data driven approach fails in capturing the telecom service dynamics. With a data model, the architect has to design data from entities specified during the requirements workflow [START_REF] Simonin | An Enterprise Architecture Alignment Measure for Telecom Service Development[END_REF]. For example, a messaging service scenario could be:

1. a message is sent by a user identified by name 2. the message is stored in the messaging box of the user Data could be User's identity, Message and Messaging box. Then, the architect must design dependencies between these data according to the telecom service scenario. The scenario becomes:

a dependency between data extracted from

Message and User's identity a dependency between data extracted from Message and Messaging box A telecom service is less complex to understand with a function sequence description than with a data model description. For example, a messaging service scenario could be:

1. Identify the messaging user 2. Send a message 3. Store a message in a messaging box This paper presents a new method, called EA4UP (Enterprise Architecture for Unified Process), which is a customization of UP to deal explicitly with dynamic aspects of telecom service architecture. Used by France Telecom, its specificity lies in the design step which is primarily seen as a composition of enablers. The enabler definition and production are the goals of the Enterprise Architecture (EA) [START_REF] Zachman | A Framework for Information Systems Architecture[END_REF] of the telecom services Information System (IS).

To be able to reuse enablers, the principle of our solution is based on the dynamic aspect of a telecom service. This re-use objective requires the precise study of all steps of every telecom service scenario, and in particular, to cater for all messages exchanged between enablers.

Section 2 presents how the EA is used in a UP development of a telecom service. This section focuses on the description of the EA4UP method for functional and technical designs. Requirements and analysis workflows are consistent with the previous France Telecom approach [START_REF] Nicolas | MetYs", OMG Information Days[END_REF], and design, implementation and test workflows are not specific in our approach. Section 3 presents related works. The EA4UP method has been evaluated in the field at both France Télécom and Telekomunikacja Polska, and experimental results are reported in Section 4, as well as the perspectives deduced from these results.

EA4UP method

The main characteristic of the EA4UP method is to involve the functional telecom services EA. The functional architecture defines the generic functional elements for telecom services. These elements can be specialized according to each telecom service. In the same way, the technical EA defines a set of recommendations of technical elements which are used in the design phase; for example, the protocols on which the service will be deployed.

The outcome of each activity in the workflow is captured in an abstract way through a model, expressed using the Unified Modeling Language (UML) [START_REF] Booch | The Unified Modeling Language -User Guide[END_REF].

The EA4UP method for telecom service design is an iterative sequence of tasks. Each task is characterized by its input and output elements. Every input element is the result of an upstream task. This paper details only the functional and technical designs enforced by, respectively, functional and technical EA.

The messaging telecom service outlined in the introduction will serve as a running example to illustrate our EA4UP method.

Method overview

The EA is the solution at the core of the EA4UP method to solve the development cost problem. The functional and technical EAs provide the functional and technical frameworks useful for component sharing. The EA allows the re-use of the enablers, hence making it possible to decrease the development costs.

The MDE approach [START_REF] Frankel | Model Driven Architecture -Applying MDA to Enterprise Computing[END_REF] where an analysis model is transformed into a functional design model or into a technical design model will be used to address the problem of development discontinuity. Telecom service architects have to enforce the EA of telecom services IS. The EA playing the role of transformation enforcing, enables thus the improvement of the development continuity.

To decrease the telecom service development complexity, data are deduced from function interactions which illustrate the telecom service usage. The data design is thus a consequence of the design of the dynamic aspects of the functional architecture, and it is not an independent design.

The 5 core workflows defined in an iterative UP development process are: Requirements, Analysis, Design, Implementation and Test [START_REF]Information technology --Process assessment[END_REF]. Within the framework of a service telecom development described in Fig. 1, the core Design workflow is split along architectural views [START_REF] Longépé | The Enterprise Architecture IT project -The Urbanisation paradigm[END_REF]:

-Functional Design for the functional view which contains the IS functions carrying out the telecom service analysis ; -Technical Design for the technical view which describes the set of technologies used for the telecom service deployment ;

-Applicative Design for the applicative view which describes the set of telecom service applicative elements. The functional EA impact takes place between Analysis and Functional Design. Functional EA is designed by enterprise architects who are experts of the telecom services IS areas. They design a functional view which corresponds to the strategy of the company. In the case of France Télécom, the telecom services IS functional view is composed of several tens of functional components.

The architects who design the target functional view of the telecom services IS also add functional interfaces to these functional components. These interfaces must be compliant with the strategy of the company. For example, the enterprise architects may consider that, strategically, a mailbox has to refer to the user's identity of a messaging service. In that case, in the target functional view, they would design a functional interface provided by the identity management functional component and used by the messaging box management functional component.

The impact of the technical EA also takes place between Analysis and Technical Design. Technical EA provides to telecom service architects a target technical view of their IS. It is designed by enterprise architects who are experts of technologies used in the IS areas of telecom services. They design a technical view which corresponds to the strategy of the company. For example, the technical strategy may target a telecom service enabler, e.g. a messaging enabler, a network protocol, e.g. SIP (Session Initiation Protocol).

The technical architect of a service telecom has to respect these recommendations. In the case of telecom service, Applicative Design is concerned because the applicative view of an enabler is deployed on its technical view.

Functional Design

The Functional Design workflow which comes from the Design workflow is central in the EA4UP method. It is the workflow where the telecom service architect takes into account the target functional architecture of the IS. Every task concerned by the functional EA is qualified as generic. When a task is only concerned by the current telecom service, it becomes specific to this service. The Functional Design workflow is split into 3 tasks:

-Static and generic functional design of functional components ; -Dynamic and generic functional design of functional interfaces ; -Specific functional design of output parameters of functional interfaces.

Static and generic functional design

The rule associated with this task is represented in Figure 1: each telecom service functional component is deduced from at least one entity or one link between entities specified during the "Static functional analysis" task and is constrained by functional components designed in the functional EA. Functional components are captured in a UML component diagram.

The functional components are selected in the functional EA of telecom services IS described in the Introduction. The goal of this task is to select among the functional components of the functional EA, those participating in the implementation of the use described in the Requirements workflow. To make this selection easier, the functional architects of company detail each component by its functions.

It may happen that a functional component needed for the implementation of the use case does not yet exist in the functional EA. A negotiation is then recommended between the architects of the telecom service and the enterprise functional architects of company to validate, or not, the creation of this new component in the target functional view of the IS. This recommendation is used for the enhancement of the functional EA.

Figure 1. Static and generic functional design task

In the illustration, the entities specified during the "Static functional analysis" task are represented in Figure 2.

Message

User's identity Messaging box is sent by owns

Figure 2. Analysis model (entity) illustration

The functional components designed during the "Static and generic functional design" task deduced from this entity model and extracted from the functional EA are represented in Fig. 3: -

Dynamic and generic functional design

The rule associated with this task is represented in Figure 4: each functional interface designed during the "Static and generic functional design task" (see Section 2.2.1) carries out at least an interaction between entity instances specified during the "Dynamic functional analysis" task and is constrained by functional interfaces designed in the functional EA. During this task, each step of the scenario is transformed into a sequence of interfaces provided by functional components selected in Section 2.2.1. As for functional components, it is possible that a required functional interface does not yet exist in the functional EA. A negotiation is also recommended between the architects of the service telecom and the enterprise functional architects of company to validate, or not, the creation of this new interface in the target functional view of the IS.

The interactions between entity instances specified during the "Dynamic functional analysis" task are represented in Figure 5.

Figure 5. Analysis model (entity instances interaction) illustration

The functional interfaces designed during the "Dynamic and generic functional design" task are deduced from this model of the interactions between entity instances and extracted from the functional EA as represented in Figure 6.

The link between provided functional interfaces and the scenario is the following one:

the functional interface sendMessage provided by the component Message Sending carries out the interaction message sending request, the functional interface getIdentity provided by the component Identity Management carries out the interaction user's identification request, the functional interface storeMessage provided by the component Message Storage carries out the interaction message store request.

Specific functional design

The rule associated with this task is represented in Figure 8: each functional interface output parameter is extracted from at least one entity specified during the "Static functional analysis" task and is constrained by a functional interface designed during the "Dynamic and generic functional design" task (see Section 2.2.2). A UML sequence diagram captures each interaction between functional component instances of a scenario defined during the Requirements workflow and its output parameters resulting from the interaction. The telecom service specificity of the functional design task is captured by the following rule: each output parameter is extracted from an entity participating to a telecom service use case. An output parameter of a functional interface is obviously produced by the functional component providing the interface.

Figure 9 represents output parameters of each functional interface required to realize the message sending scenario:

-

Technical Design

Technical Design workflow is extracted in a similar way from the Design workflow. Nodes and protocols connecting nodes are the only concepts of the Technical Design workflow, which is split into 3 tasks:

-Static technical design of the nodes of the deployment infrastructure -Dynamic technical design of the protocols of the deployment infrastructure -Detailed technical design of nodes and protocols

Static technical design

The rule associated with this task is represented in Figure 11: each node fulfils a static technical property specified during the "Static technical analysis" task and is constrained by a technical EA recommendation, especially for the technical choice of enabler. The telecom service architect must check this choice with non-functional requirements of the developed telecom service. A UML deployment diagram can be used to capture this.

Dynamic technical design

The rule associated with this task is represented in Figure 13: each protocol connecting nodes (see Section 2.3.1) is deduced from at least one dynamic technical property specified during the "Dynamic technical analysis" task and is constrained by a technical EA recommendation. The telecom service architect must choose protocols according to non-functional requirements of the developed telecom service. This is captured in a UML deployment diagram. In our example, the FTP protocol fulfils the dynamic technical properties specified during the "Dynamic technical analysis" task:

the link between the interaction user's identification request (from Message to User's Identity) and the non-functional requirement for an average user are 10 sent messages per day, the link between the interaction message store request (from User's Identity to Messaging box) and the non-functional requirement user messaging box is stored 1 time per day.

A protocol must then exist between the enablers; whatever may be the enabler associated with the entity User's Identity:

the FTP protocol is recommended by technical EA and fulfils the non-functional requirements (see Figure 14).

Detailed technical design

This task allows detailing of operational environments, physical nodes making up each node (see Section 2.3.1) and each communication link (see Section 2.3.2). This task is not discussed here because there is no specificity about it in this method.

Experimental validation

The EA4UP method prototyping ended in June 2007. Eleven new telecom services development projects from France Télécom and from Telekomunikacja Polska have been involved in this field test.

For the analysis framework, on average these projects specified:

-20 entities -50 interactions between entity instances -20 technical properties It is not possible to detail here these numbers by project for a reason of data privacy.

A questionnaire with nine questions has been sent to project architects. Answers to these questions are detailed in Table 1. Four themes emerge in this questionnaire:

the EA4UP approach itself (Q1: approach very complicated "--", complicated "-", simple "+", very simple "++"; Q2: approach without interest "--", not very useful "-", useful "+", essential "++"), the EA4UP approach compared to previous ones (Q3: component reusability definitely worse "--", worse "-", better "+", definitely better: "++"; Q4: quality definitely worse "--", worse "-", better "+", definitely better "++"), the EA4UP cost compared to previous approaches (Q5: designing time definitely longer "--", longer "-", shorter "+", definitely shorter "++"), the EA4UP communication capabilities (Q6: approach does not help "--", helps a little "-", give sounds background "+", is essential "++"; Q7: to work with marketing team approach is without interest "--", not very useful "-", useful "+", essential "++"; Q8: to work with architects approach is without interest "--", not very useful "-", useful "+", essential "++"; Q9: to work with decision makers approach is without interest "--", not very useful "-", useful "+", essential "++"). The last column representing the EA skill of the architect is added to this results table. This skill is closely connected with favourable answers of the project architect about the method simplicity and the cost of this approach. The size of the project architecture is on the other hand not explicitly connected with architect answers. The best result of the assessment of our method synthesized in Figure 15 is for the comparison between EA4UP method and the previous approaches of the telecom service architects. The result is close to ++ for the component reusability.

Approach

Assessment of telecom service design

The worst result is about the EA4UP cost. The reason is the cost of the functional EA suitability. Project noticing about designing time depends on projects (from definitely shorter to definitely longer). The functional EA knowledge is the main parameter for this noticing. This functional EA consists of several ten of functional components and functional interfaces.

EA4UP approach in spite of its complexity has a good evaluation (+) thanks to its interest for the telecom service architecture design but architects need support. For all projects, this approach is very useful for their architecture design.

With EA4UP method, the communication about the telecom service architecture is easier with other architects (between + and ++). The result is also good (+) for the communication with marketing teams and decision makers, but it is however variable (from -to ++).

Related work

Telecom service development is considered as an object oriented development as defined by the Unified Process (UP). UP is moreover adapted for telecom service development because of its iterative feature. In our approach, the design workflow is split into 3 workflows: functional design, technical design and applicative workflows. It makes easier to involve EA constraints during telecom services development.

EA and its framework are suitable to improve telecom service component reuse. EA involved in the development process helps business, functional or technical framework sharing. For example, the SEAM approach [START_REF] Wegmann | On the Systemic Enterprise Architecture Methodology (SEAM)[END_REF] makes easier business and IT alignment. This approach is IS cartography centric but does not deal with the whole telecom service development process. Enterprise Unified Process (EUP) [START_REF] Ambler | Enterprise Unified Process -Extending the Rational Unified Process[END_REF] enables an integration of UP in EA design. ODP [START_REF] Omg | Reference Model of Open Distributed Processing[END_REF] is a welladapted framework for telecommunications only if view points and concepts are taken into account. Nevertheless it is difficult to use it for development processes because of the lack of link between the technical and information view points.

From a Service Oriented Architecture perspective (SOA) [START_REF] Burlton | Business Process Management -Profiting from Process[END_REF], a telecom service is defined as an orchestration of service components. The component orchestration implements the enterprise business processes. The components defined by EA provide an accurate definition of SOA components [START_REF] Grigoriu | An Enterprise Architecture Development Framework[END_REF]. Using EA components, the SOA objective of components reuse can be reached easier. However, if the development of SOA components highly benefits from EA, it is not the case with orchestration that does not take advantage from functional or applicative dependencies between components.

The main contribution of this paper is the use of functional and technical EA frameworks during UP development process. To allow a well EA integration, we choose the framework described in [START_REF] Longépé | The Enterprise Architecture IT project -The Urbanisation paradigm[END_REF] with its 4 views: business, functional, technical and applicative. A benefit of this approach is to take into account the links between these views all along the development process. Moreover, the design of the dependencies between functional or applicative components brings richer component interfaces and introduces interface optimization.

MDA [START_REF] Omg | MDA Guide[END_REF] and MDE [START_REF] Frankel | Model Driven Architecture -Applying MDA to Enterprise Computing[END_REF] approaches allow applicative design frameworks integration during development process [START_REF] Burlton | Business Process Management -Profiting from Process[END_REF]. EA4UP takes so benefits of the MDA approach. In an unusual way, functional or technical EA define indeed the Platform Definition Model (PDM) which enforces respectively generic functional and technical design tasks.

Conclusion

Experimentation results show that the EA4UP method allows an easier reuse of enablers. Thanks to the functional and technical EAs, this reuse implies a telecom service architecture rationalization, with a sharing of functions and technologies.

Telecom services IS evolutions may then benefit from this rationalization. The main need for architects who have been involved in the EA4UP method prototyping is a functional EA skill improvement. Decisions have been taken in Orange Labs to extend this approach.

Future works will try to address the concerns raised on the field experiment mostly the need for support during the design workflow and the high cost for some projects. To address these issues, we are designing and implementing tools for:

assisting in the functional design workflow according to the functional EA model; helping telecom service architects in all their design tasks; making the communication about the architecture results easier. These tools will use MDE techniques, such as model transformations (SmartQVT [START_REF] Smartqvt | [END_REF]).

  Telecom service functional component (Static and generic functional design) EA functional component (Enterprise functional Architecture) Entity (Static functional analysis)

Figure 3 .

 3 Figure 3. Functional design model (component) illustration

  EA functional interface (Enterprise functional Architecture) Telecom service functional interface (Dynamic and generic functional design) Telecom service functional component (Static and generic functional design) Interaction between entity instances (Dynamic functional analysis)

Figure 4 .

 4 Figure 4. Dynamic and generic functional design task

Figure 6 .Figure 7 .

 67 Figure 6. Functional design model (components interaction) illustrationThe chain of interfaces is deduced from their dependency in the scenario. The resulting functional component diagram is illustrated in Figure7.

FunctionalFigure 8 .

 8 Figure 8. Specific functional design task

Figure 9 .Figure 10 .

 910 Figure 9. Functional design model (output parameter) illustration Figure 10 represents the data model deduced from the designed output parameters. Each interaction involves a dependency between output parameters seen

Figure 11 .Figure 12 .

 1112 Figure 11. Static technical design task In our example, during the "Static technical analysis" task, the specified static technical property is the link between the non-functional requirement of Storage maximum capacity of the messaging box per user and the Messaging box entity. The choice of the Storage enabler during the "Static technical design" task represented in Fig. 12 fulfils this requirement and is consistent with technical EA recommendations: the node Storage enabler fulfils static technical property associated with the entity Messaging box, the node Messaging enabler is associated with the entity Message, -Messaging enabler and Storage enabler may be every one of them associated with the entity User's identity.

Figure 13 .

 13 Figure 13. Dynamic technical design task

FTPFigure 14 .

 14 Figure 14. Technical design model (protocol) illustration

Figure 15 .

 15 Figure 15. Advantages (+ or ++) and drawbacks (-or --) of the EA4UP method

  the output parameter Message -Message Sending of the functional interface sendMessage is extracted from the entity Message and produced by the component Message Sending, the output parameter User's identity -Identity Management of the functional interface getIdentity is extracted from the entity User's identity and produced by the component Identity Management, the output parameter Messaging box -Message Storage of the functional interface storeMessage is extracted from the entity Messaging box and produced by the component Message Storage.

	scenario:Message sending	:Message Sending	:Identity Management	:Message Storage
	sendMessage(out: Message-Message Sending)
		getIdentity(out: User's identity-Identity Management)
			storeMessage(Messaging box-Message Storage)

Table 1 . Detailed project architect answers to the questionnaire about EA4UP method prototyping from the smallest project P1 to the greatest P11 in terms of number of designed components

 1

	Projec			Architecture Cost		Communication		EA
	t	Q1	Q2	Q3	Q4	Q5	Q6	Q7	Q8	Q9	skill
	P1	-	++	++	+	+	--		++	++	N
	P2	-	++	+		--			++		N
	P3	+	++	++	+	+	+	-	+	-	Y
	P4	-	+	+	+	-	+	-	+	+	N
	P5	-	+				+	-	-	--	N
	P6	+	++	+	++	++	++	++	++	++	Y
	P7	-	+	++	++	-	++	+	+	+	N
	P8	+	+	++	+	-	+		+	+	N
	P9	-	+				+		+	+	N
	P10	+	++	+	+	++	++	+	++	+	Y
	P11	-	++	++	++	-	+	+	++		N


Gilles Perrouin
email: gilles.perrouin@irisa.fr

Franck Chauvel
email: franck.chauvel@univ-ubs.fr

Julien Deantoni
email: julien.deantoni@irisa.fr

Jean-Marc Jézéquel
email: jezequel@irisa.fr

Modeling the Variability Space of Self-Adaptive Applications *

Modeling self-adaptive applications is a difficult task due to the complex relationships they have with their environments. Designers of such applications strive to model accurately a few (re)-configuration possibilities deemed to be the most relevant with respect to environmental changes. This deliberate restriction of the variability space is cumbersome and may unnecessarily reject interesting (re)configuration possibilities. We employ software productline techniques to properly cover the whole variability space of a self-adaptive application. This variability space is partitioned across three dimensions. Functional variability is modeled through a feature diagram whose features are realized by a set of components to be deployed on a platform. Topological variability is modeled via an UML collaboration excluding irrelevant configurations. Platform variability is modeled through constraints to be satisfied by configurations. For each dimension, we exhibit properties capturing the environment. Our modeling approach is illustrated on a web-server example.

Introduction

The fast emergence of dynamic environments (such as mobile systems, web-services, peer-to-peer networks) requires more flexibility from software systems running in these environments. This specificity raises new development challenges. One emerging possibility to address these * This work has been partially supported by the DiVA STREP project. challenges consists in including self-adaptation capabilities into the application. So-called self-adaptive systems observe their environment and accordingly adapt their internal configuration in order to reach some quality objectives [START_REF] Garlan | Rainbow: architecture-based self-adaptation with reusable infrastructure[END_REF][START_REF] Valetto | A Case Study in Software Adaptation[END_REF][START_REF] Real | Mode change protocols for real-time systems: A survey and a new proposal[END_REF].

However, due to the lack of specific methods and tools, engineers often have to design a set of possible architectural configurations and associate to each of them a possible state of the environment. To do so, they restrict the variability space of the self-adaptive application in a drastic way. However, a self-adaptive application has a complex relationship with its environment which impacts application functionalities, performances and depends on the abilities of the platform on which the application is running. Trying to capture this relationship directly in a few architectural configurations is inherently difficult and exposes engineers to the risk of overlooking important environmental states and thus missing interesting architectural configurations.

We believe that designers should properly model the variability space of a self-adaptive application first. This enables designers to hold all cards before modeling architectural configurations of the application. The contribution of this paper is a modeling process supporting the definition of variability spaces. Each variability space is defined with respect to one of the following dimensions: functional, platform and topological. The first dimension is defined via a feature model that defines variability across application functionalities. These functionalities are then related to a set of components gathered in a repository. It is important to notice that rather than modeling exhaustively architectural configurations in the topological space, we only constrain them via a UML collaboration so that irrelevant configurations can be excluded during the design process. Finally, we illustrate how platform variability can be modeled through non-functional properties.

The remainder of the paper is organized as follows. Section 2 introduces the web-server that will be used as a running example. Section 3 defines our modeling process while Section 4 formalizes the models offered. Section 5 highlights some related work. Finally, Section 6 wraps up with conclusions and outlines future research directions.

Motivating Example

Let us consider a simple web server architecture that processes HTTP requests such as the Apache Web Server or the Microsoft IIS solution. In such architectures, various quality properties can be identified: security level, response time, memory footprint, relevance of the response, etc. Objectives that must be reached for each of these properties depend on the environment state and can depend on each other. For instance, reaching a good security level is important but the required filters increases the web server response time. Classical non adaptive approaches make tradeoffs between these properties. In some cases, it could be better to increase the security level according to the number of malicious requests detected in the environment whereas in other cases, decreasing it in order to achieve a minimum response time is preferable. From an architectural perspective, one emerging solution is to allow the architecture to be adapted with respect to the environment state. Nowadays, to describe self-adaptive applications, designers define an arbitrary number of possible architectural configurations and associate each of them to a particular state of the environment [START_REF] Garlan | Rainbow: architecture-based self-adaptation with reusable infrastructure[END_REF][START_REF] Valetto | A Case Study in Software Adaptation[END_REF][START_REF] Real | Mode change protocols for real-time systems: A survey and a new proposal[END_REF].

For instance, considering the aforementioned security level issue, the solution consists in choosing a threshold on the number of malicious requests that triggers a specific adaptation. This adaptation is often a configuration switch or a hardcoded number of configuration adaptations. Considering all the environment variables influencing the system, this can lead us to specify a large number of configurations or adaptations. To highlight this, we identified some architectural modifications linked with specific environment states in our HTTP web server:

1. Filter such as SQL code detectors, or undesired URL detectors can be deployed when the number of malicious requests increases, or when the kind of retrieved content change. The introduction of such Filter in the architecture increases the web server security level, but also increases its response time and the system used memory. Different kinds of filters can be identified, for instance, it exists URL filters, SQL filters, ...

It can be decided to use secured or unsecured

Receiver depending on the number of malicious request. The use of secured receiver increases the security level but also the response time. • A basic load balancing algorithm may be used to dispatch requests fairly among the various data servers. • Performance hints might also be used to dispatch requests to the best server, such as the one with the shorter response time for instance. • The data contained in requests may be also used as a criteria to dispatch requests to servers. A server which stores all the large video files, could receive all the request referring to video files.

From a designer point of view, we intuitively extract a primary configuration as well as a number of adaptation rules from the previously identified architectural variations. The primary configuration, suitable the majority of the time (i.e. linked to the environment state assumed to be the most frequent one) uses at the same time one unsecured receiver two dataServers, an URL filter and a MRU cache (see figure 1).

When the load of the server is increasing with non malicious requests beyond a specific threshold, the size of the cache is replaced with a bigger one and a SQL filter is added to the application. This adaptation leads to better response time. Aside, when there is not enough free memory, then the new configuration can decide to use at most one StorageServer.

This example highlights the fact that a designer identifies a finite number of configurations from a number of adaptation rules (or configuration switching rules). In the above scenarios, we have overviewed three configurations, each linked to a specific environment state defined through human-chosen thresholds. However, in the above example, the identified architectural variation points and their related variants define more than 72 possible architectural configurations. Naturally, if we consider an arbitrary number of servers, filters, receivers, etc, the number of induced configurations may become quickly very high. As a result, the designer may overlook one particular configuration which may be optimal for some environment state.

Our approach proposes to avoid enumerating configurations with respect to the environment states, by modeling first the variability space of a self-adaptive application. Our approach also takes into account the various architecture topologies which can be built from a given selection of components. We outline our approach in the next section.

Approach Overview

As explained, most of self-adaptive systems are currently designed in an ad-hoc manner using low-level and scripts or APIs. We claim that a systematic identification of variation points and of their related variants helps to cope with the complexity of self-adaptive systems. We identify three distinct spaces of variability in the development process of self-adaptive systems, which must be clearly defined to get an efficient description of self-adaptation. Figure 2 depicts these three variability spaces.

Functional Variability Space

First, the designer must identify the set of features which are used in the system and their related variants. The key point of self-adaptive systems is that they might involve several variants of the same feature and the final system must use the relevant variants with respect to changes in its environment. Organizing and reasoning about features must be achieved using features diagrams since they aim to express variability points and their related variants. Figure 2 shows a possible feature diagram for a Web server and the associated variability space (depicted as a question mark). Reasoning on those diagrams enable the computation of the Functional variability Space that is to say the set of possible feature configurations.

Platform Variability Space

A single feature diagram is not enough to be efficiently used to design self-adaptive software. Features are only abstractions of software pieces: A single component (i.e.. a runnable artefact) commonly implements a set of abstract features and a single feature might be implemented by several components. In Figure 2, the component which implements a feature are shown thank to an arrow which connects a feature to a component. Thus, in order to fill the gap between the abstract feature diagram and the set of legacy components, the designer must describe the relationship between each feature and the legacy components which implement it. The relationship builds the second space of variability, so-called Platform variability Space and is shown as the second question mark on Figure 2. Moreover, a specific execution platform cannot only be described by a set of available components. It might also entail some specific constraints on ressources: memory, CPU, bandwidth, etc. Those constraints must be taken into account to compute and define the platform variability space.

Topological Variability Space

The topological variability space relates to a set of particular configurations which might be deployed at runtime, that is to say the set of bindings between the selected components (See Figure 2). In the web server example, a SQL Filter can be inserted after the receiver, after the analyzer, after the dispatcher, etc ... In existing literature [START_REF] Van Gurp | On the Notion of Variability in Software Product Lines[END_REF][START_REF] Gomaa | Feature Dependent Coordination and Adaptation of Component-Based Software Architectures[END_REF][START_REF] Gomaa | Model-based software design and adaptation[END_REF], such configurations are fixed and are not computed at runtime. Contradictorily, we do not describe any configuration. However, we offer the possibility to the self-adaptive application architect to express some constraints on the topology of the configuration. These constraints may concern the relationships between elements (i.e. a receiver should be connected to a storage server) or to enforce specific architectural patterns to take into account during design. We call topological invariants this kind of constraints.

Models

Overview

Functional space. To model the functional space of a self-adaptive architecture, we use a feature diagram [START_REF] Kang | Feature-Oriented Domain Analysis (FODA) Feasibility Study[END_REF] which is a popular technique to represent variability in product-lines. As noted by Schobbens et al [START_REF] Schobbens | Generic semantics of feature diagrams[END_REF], there are many variants of feature modeling notations. We chose to use the notation proposed by Czarnecki et al. [START_REF] Czarnecki | Formalizing Cardinality-based Feature Models and their Specialization[END_REF] because it offers to model variability in terms of cardinality amongst features. They distinguish two kinds of cardinality; the first kind, called feature cardinality relates to how many in-stances of a feature are allowed in a product. We use feature cardinality to set how many components realizing this particular feature can be involved in a configuration. The second kind of cardinality, called group cardinality, enables to specify how many children can be selected for a given feature. As demonstrated by Schobbens et al [START_REF] Schobbens | Generic semantics of feature diagrams[END_REF] it is rather a concise way to model variability operators; for example the alternative (xor) operator is represented by group cardinality [1..1], or operator by [0..1] etc.

In this space, we mainly focus on functionality. This means that we do not model variations of feature that would actually corresponds to variations in non-functional properties of a component. For example, the size of a cache (big, small, medium) will not be modeled but variations in their functionality (such as the algorithm they implement) have to be modeled in the feature diagram. Figure 3 shows the resulting feature diagram for HTTPServer. The root feature identifies the modeled application. Our application is mandatorily constituted by at least a one component implementing the Receiver feature which may support security or not. There is at least one storage server which can persist their data using RDBMS or files. Other features are optional.

Platform space. In order to model our components, we used an high abstraction ADL (Architecture Description Language) express in terms of components, ports and interfaces. This way, models expressed in this ADL can be easily translated in terms of UML 2.0 components [START_REF] Omg | Unified Modeling Language Superstructure (version 2.1.1)[END_REF] but also in terms of other component models. Since we are mainly concerned by the overall topology of the architecture and not internal component properties, components are considered as black-boxes. Connection between components are made through their ports. To each component is associated a sequence of costs which help the designer to determine if they can fit to a particular platform when defining the topological space. They take the form of non-functional properties covering issues such as bandwidth, memory or CPU usage. These properties are expressed in the same terms that platform-specific constraint to ease the allocation.

Topological space. Topological invariants are modeled via a UML collaboration. When N components are in a same collaboration, it signifies that there exists at least one path in the configuration that links together one instance of each of the N participants. Figure 4 depicts the topological invariant for our example. It specifies the following constraint: "For each StorageServer Component, there must exist a path 1 to a Receiver Component". Mapping features onto components. We do not seek to establish a one-to-one mapping between feature and components. This is due to the strict separation between the functional and platform spaces. Therefore several components can implement the same feature but with possibly different 1 By "path", one should understand a connection with possibly intercalated Components sequence of costs. We have defined the following rules for the mapping:

• Mappings can only be established from leaf features (i.e. features having no child) to components defined in the the platform space,

• A given component cannot implement two features.

Although it is technically possible to do so, this raises the issue of assigning costs to a given component. For example, in Figure 2, considering C3 both as an unsecured receiver and a MRU cache prevent the assignment of the memory attribute globally: is the memory value concerns one feature, all ? This would force components' designers to set those values for each feature therefore taking into account components' internals which contradicts our "black box" approach on components (see above).

Mappings are given in the form of tuples in which the first element represents the feature name and the second the set of components implementing it. For example, the Analyzer feature will be mapped as follows: <Analyzer,{C4,C5}>.

Formalization

In order to safely use the proposed models, it is important to ensure that the topological space is bounded. If the topological space is bounded, it signifies that the number of solutions that can be inferred from the models is finite. To prove that the topological space is bounded, a formal proof is given below.

First, we start by formally defining the notion of configuration, component and port. A component is noted Comp and corresponds to a finite number of ports, each noted P (Cf definition [START_REF] Czarnecki | Mapping Features to Models: A Template Approach based on Superimposed Variants[END_REF].

Comp = {P 1 , P 2 , ..., P p }, ∀p ∈ N * -{∞} (1)
To each port is associated a cardinality specifying the number of possible connectors that can be attached to it. So a port is defined in (2) by a couple of positive or null integers.

P = {Cmin, Cmax}, ∀Cmin, Cmax ∈ N -{∞} (2)
A connector (noted Con) is a bidirectional link between two ports and is so defined in (3) as a couple of ports:

Con = {P 1 , P 2 } (3)
A configuration Cf is a couple of sets. The first one is a set of components and the second one is a set of connectors.

We define a configuration Cf as stated below: (see 4):

Cf = { (4a) {Comp 1 , Comp 2 , ..., Comp n }, (4b) {Con 1 , Con 2 , ..., Con q } (4c) } ∀n ∈ N + * , q ∈ N + (4d) ∧ ∀i ∈ [1; q], Con i = {pi 1 , pi 2 } where pi 1 = pi 2 (4e) ∧ pj 1 ∈ Cj1 ∧ Cj1 ∈ {Comp 1 , ..., Comp n } (4f) ∧ pj 2 ∈ Cj2 ∧ Cj2 ∈ {Comp 1 , ..., Comp n } (4g) ∧ ∀j ∈ [1, n], k ∈ [1, p], l ∈ [1, q], (4h) ∀P k ∈ Comp j , ∃P k ∈ Con l (4i) ∧ ∀c ∈ [1, p], d ∈ [1, q], (4j) ∃ ( Set(Con) ≤ (Cmax ∈ P c ) (4k) ∧ Set(Con) ≥ (Cmax ∈ P c ) ) (4l)
where Set(Con) = d=q d=0

(Con j ∧ (P c ∈ Con d )) (4m) ∧ ∀a, b ∈ [1, q], a = b ⇒ Con a = Con b (4n)
Informally, a configuration is the union of a non-empty set of components ((4b) and (4d)) and a possibly empty set of connectors (((4c) and (4d))) where each connector is a couple of nonidentical Ports ((4e)) belonging to a component of the configuration ((4f) and (4g)). Moreover, there are not two identical connectors in a configuration ((4n)) and each port of each component is connected ((4h) and (4i)).

Finally, the number of connectors referencing a given port depends on the port's cardinality ((4j) to (4m)).

We now define a component repository, Rc, as a set of nonidentical components:

Rc = {Comp 1 , Comp 2 , ...Comp m }, ∀m ∈ N * ∧ ∀i, j ∈ N * , i = j ⇒ Comp i = Comp j (5)
By considering our modeling of the system, a configuration is a set of components where each Component belongs to a component repository. Consequently, a set of all possible configurations noted Set(Cf ) is made up of components from a specific component repository. Considering a component repository noted Rc1, we define the set of all possi-ble configurations as follows:

Set(Cf ) = { {α 1 .Comp 1 , α 2 .Comp 2 , ..., α n .Comp m } {Con 1 , Con 2 , ..., Con q } } ∀m ∈ N * , q ∈ N ∧ ∀i ∈ [1; q], ∃Con i = {pi 1 , pi 2 } where pi 1 = pj 2 ∧ pi 1 ∈ Comp i1 ∧ α i1 = 0 ∧ pi 2 ∈ Comp i2 ∧ α i1 = 0 ∧ ∀j ∈ [1, n], k ∈ [1, p], l ∈ [1, q], ∀P k ∈ Comp j , ∃P k ∈ Con l ∧ ∀c ∈ [1, p], d ∈ [1, q], ∃ ( Set(Con) ≤ (Cmax ∈ P c ) ∧ Set(Con) ≥ (Cmax ∈ P c ) )
where Set(Con) = d=q d=0

(Con j ∧ (P c ∈ Con d )) ∧ ∀a, b ∈ [1, q], a = b ⇒ Con a = Con b ∧ α i ∈ N∀i ∈ [1, m] ∧ ∀k ∈ [1, m], Comp k ∈ Rc1 (6)
Informally, a possible configuration is made up with the set of all available components in the component repository Rc1. Each of these components can be used 0 or more times depending on the associated value of α. Moreover, a possible configuration must conform to the definition given in (4). Consequently, the set of possible configurations is the binomial combination of K possible components in a component repository that contains M components. Since alpha can be greater than 1, the number of possible sets of components is a combination where repetition are allowed and order is discarded. For each set of components, there exists various possible sets of connectors. In the following definition, N bP (Comp) is the number of ports of the component Comp. Consequently, the number of possible configurations denoted Size(Set(Cf )) is given by [START_REF] Gomaa | Model-based software design and adaptation[END_REF]:

Size(Set(Cf )) = M +K-1 C K * N bP Cf -1 i=1 (N bP Cf -i) 2 where N bP Cf = K j=0 (N bP (Comp j )) ∧ ∀j, Comp j ∈ Cf (7)
From definition (6), it appears that the configuration can be composed of an infinite number of components if the value of a given α tends to ∞. Moreover, it can yield an infinite number of possibilities if m tends to ∞. In these cases, the set of possible configurations can also be infinite. To avoid working on an unbounded number of configurations, we have to add a constraint such that both m and α i ∀i ∈ [1, m] can not tend to infinity. for this purpose, we make the assumption that the size of a configuration is limited (this assumption fits a great majority of self-adaptive systems). Formally, the size of a configuration Cf is noted Size(Cf ) and the size of a component is noted Size(Comp) and is strictly greater than 0. We consider here that a connector does not use memory space. From definition (6) we obtain:

Size(Cf ) = m i=1 (α i .Size(Comp i )) ∧ ∀i ∈ [1, m], Size(Comp i ) > 0 (8)
The constraint on the size of the configuration is then:

m i=1 (α i .Size(Comp i )) ≤ S (9)
In ( 9), because Size(Comp) > 0, if m i=1 (α i ) increases, then Size(Cf ) increases. Consequently, bounding the size of the configuration bounds the number of component involved in a configuration. Regarding to the number of possible configurations defined by [START_REF] Gomaa | Model-based software design and adaptation[END_REF], it implies that the number of possible components noted K is bounded. For a constant K, Size(Set(Cf )) increase when M increase. Consequently, M must be bounded to ensure that the first term of (7), i.e. M +K-1 C K , is bounded. Moreover, because the number of ports in a component is strictly finite, N bP Cf defined in [START_REF] Gomaa | Model-based software design and adaptation[END_REF] is bounded. Consequently, considering that there are not two identical connectors in a unique configuration and because all ports in the configuration must be connected, the second term of (7), i.e.

N bP Cf -1 i=0

(N bP Cfi) 2 is also bounded. As a result, this formalization ensures that, if the number of components in the component repository is bounded, if the number of ports for each component is also bounded, and if we restrict the configuration to use a finite amount of memory, then the number of possible configurations is finite.

Related Work

The general problem of mapping feature to the architecture have been addressed by several works. Kang et al [START_REF] Kang | FORM: A Feature-Oriented Reuse Method with Domain-Specific Reference Architectures[END_REF] extends the FODA [START_REF] Kang | Feature-Oriented Domain Analysis (FODA) Feasibility Study[END_REF] approach with general guidelines to model the architecture. Sochos et al [START_REF] Sochos | Feature-Oriented Development of Software Product Lines: Mapping Feature Models to the Architecture[END_REF] provides a two-step approach in order to map architectural elements (implemented as plugins) with features. From one feature model, a sequence of transformations is performed in oder to ease the mapping by ordering and defining dependencies between features. Then, a one-to-one mapping between features and plugins is made. Czarnecki et al [START_REF] Czarnecki | Mapping Features to Models: A Template Approach based on Superimposed Variants[END_REF] propose a detailed approach to map features on various model including UML class and activity diagrams. However, the above works were not meant to build Dynamic Software Product Lines (DSPLs), therefore the barely provides means to consider environmental properties and platform variability. Van Gurp et al [START_REF] Van Gurp | On the Notion of Variability in Software Product Lines[END_REF] early discussed the notion of variability at various levels of abstraction (from requirements to runtime) motivating the need to define and organize variability mechanisms across these levels. However they do not provide specific modeling solutions in the case of DSPLs.

Gomaa et al [START_REF] Gomaa | Feature Dependent Coordination and Adaptation of Component-Based Software Architectures[END_REF][START_REF] Gomaa | Model-based software design and adaptation[END_REF] proposed a UML-based profile and a process to model DSPLs. In particular they handle reconfiguration as a sequence of patterns on a fully designed architecture. Our approach differs in that we do not seek to determine all the possible configurations. Therefore, we need to separate variability definition from architectural models.

Trinidad et al [START_REF] Trinidad | Mapping feature models onto component models to build dynamic software product lines[END_REF] present a modeling approach to build DSPLs. They also base the variability description on a feature model which is mapped on UML 2.0 component architecture. Each feature is mapped to a component and variation points are ensured by relationship components whose main role is to propagate reconfiguration decisions performed by a general configurator component. However, they make the supposition that the feature model is built while thinking about the DSPL architecture (e.g. one-toone relationship between feature and component) which is not a clear separation of concerns between functional and architectural dimensions. Furthermore, they do not provide any means to model platform/environment properties which trigger reconfiguration decisions.

Lee and Kang [START_REF] Lee | A feature-oriented approach to developing dynamically reconfigurable products in product line engineering[END_REF] propose a global approach for the engineering of dynamically reconfigurable products in a product-line fashion. In particular they introduce the notion of binding unit, a grouping of features which are used to identify architectural components. They also give several guidelines to build dynamically reconfigurable architectures, some hints about environment modeling (context) and considerations about how a configurator should work. However they remain at the general level with respect to the models employed and did not provide a formalization of the models as we did.

Hallsteinsen et al [START_REF] Hallsteinsen | Using product line techniques to build adaptive systems[END_REF][START_REF] Floch | Using architecture models for runtime adaptability[END_REF][START_REF] Geihs | Modeling of component-based adaptive distributed applications[END_REF] also provide an holistic view of the engineering of DSPLs. They define variability directly in the reference architecture via a dedicated UML profile. This architecture comprises components which realize component types (variation points) via plans (variants) modeling a particular reconfiguration scenario. Reconfiguration is modeled through the composition of plans. Consequently these approaches are based on a specific topology called composition plan whereas our approach take into ac-count the possible variability within this composition plan. It becomes possible to dynamically change the composition plan at design time.

Montero et al [START_REF] Montero | Representing Runtime Variability in Business-Driven Development Systems[END_REF] focused on managing variability in business processes. In specific, they model how a process evolves (denoting a reconfiguration of the system) with respect to timing/scheduling constraints. We will integrate timing issues in future research while validating our approach on concrete case-studies.

Conclusion

Accurately modeling the variation space of self-adaptive applications requires to properly identify the dimensions (functional, platform and topological) in which this space can be described. By combining software product line techniques with separation of concerns, we are able to provide a clear separation between these dimensions, and to propose models for each of those dimensions; functional dimension is modeled via cardinality-based feature diagrams which defines constraints on the set of components which are available to form a particular self-adaptive application architectural configuration and its possible reconfigurations. The platform space concerned with the definitions of the individual components in terms of costs as well as the definition of restrictions related to the platform on which they run. Finally, the topological dimension aim at defining the possible bindings configurations for given set of components. We also formally demonstrated that our variation space is bounded which opens the way to decision algorithms able to extract intersting configurations from this variation space. Future research will concentrate on the definition of such a decision procedure as well as its validation in concrete situations. We also plan to refine our approach with respect to the complex mapping from features to components and to provide an integrated tool support for the whole approach.

Figure 1 .

 1 Figure 1. One possible configuration for the Web server

Figure 2 .Figure 3 .

 23 Figure 2. Defining the variability space of self-adaptive systems

  Figure 4. Topological Invariant for HTTPServer