Gabriel Tamura
email: gabriel.tamura@inria.fr

Laurenceduchien
email: laurence.duchien@inria.fr

QoS Contract Preservation through Dynamic Reconfiguration: AFormalSemanticsApproach

The increasing pervasiveness of computing services in everyday life, combined with the dynamic nature of their execution contexts, constitutes a major challenge in guaranteeing the expected quality of such services at runtime. Quality of Service (QoS) contracts haveb e e np r o p o s e dt os p e c i f ye x p e c t e dq u a l i t y levels (QoS levels) on different context conditions, with different enforcing mechanisms. In this paper we present a definition for QoS contracts as a high-level policy for governing the behavior of software systems that self-adapt at runtime in response to context changes. Tor e a l i z et h i sc o n t r a c td e fi n i t i o n ,w es p e c i f y its formal semantics and implement it in a software frameworka b l et oe x e c u t ea n dr e c o n fi g u r es o f t w a r e applications, in order to maintain fulfilled their associated QoS contracts. The contribution of this paper is threefold. First, we extend typed-attributed graph transformation systems and finite-state machines, and use them as denotations to specify the semantics of QoS contracts. Second, this semantics makes it possible to systematically exploit design patterns at runtime by dynamically deploying them in the managed software application. Third, our semantics guarantees self-adaptive properties such as reliability and robustness in the contract satisfaction. Finally, we evaluate the applicability of our semantics implementation by integrating and executing it in FraSCAti,amulti-scalecomponent-basedmiddleware,inthreecasestudies.

Introduction

Over the last years, software services have pervaded all aspects of our everyday life. The subsequent proliferation and massive use of these services through ubiquitous computing devices, individually or in combination with traditional systems, challenges the preservation of the associated Quality of Service (QoS) contracts. Moreover, the highly dynamic requirements that appear for these services when confronted with the dynamic nature oft he i re x e c ut i onc ont e xt sf ur t he r exacerbate the problem of maintaining their expected quality levels (QoS levels) fulfilled under these varying execution conditions. Additionally, these dynamic capabilities are also expected to be reliable and robust to be acceptable.

QoS contracts constitute a natural and effective means for capturing this kind of contextdependent requirements, such as those on performance, availability and confidentiality [START_REF] Beugnard | Making components contract aware[END_REF][START_REF] Tran | A Survey and Analysis on Semantics in QoS for Web Services[END_REF]. Several specifications [START_REF] Frølund | Quality of services specification in distributed object systems design[END_REF][START_REF] Keller | The wsla framework: Specifying and monitoring service level agreements for web services[END_REF], languages [START_REF] Röttger | CQML+:E n h a n c e m e n t st oC Q M L ,i n :P r o c s .o f1 s tI n t l .W o r k s h o po nQ u ality of Service in Component-Based Software Engineering[END_REF][START_REF] Becker | Quality of Service Modeling Language[END_REF], formal semantics [START_REF] Braga | A formal semantics foraqualityofservicecontractlanguage[END_REF][START_REF] Cansado | A formal framework for structural reconfiguration of components under behavioural adaptation, Procs. of the 6th Intl. Workshop FACS[END_REF] and models [START_REF] Collet | A Contracting System for Hierarchical Components[END_REF][START_REF] Chang | Patterns for integrating and exploiting some non-functional properties in hierarchical software components[END_REF][START_REF] Lee | A Quality Model for Evaluating Software-as-a-Service in Cloud Computing[END_REF][START_REF] Comuzzi | A framework for QoS-based Web service contracting[END_REF], among others, have been proposed to specify, model and support the QoS contracts elements, the relationship among QoS provisions and requirements, and enforcement mechanisms. However, despite these many advances, the development of a sound theory to preserve QoS contracts in component-based systems still remains an open problem with at least two important challenges. On the one hand, from the components perspective and following its foundations [START_REF] Szyperski | Component Software: Beyond Object-Oriented Programming[END_REF][START_REF]Component-Based Software Engineering: Putting the Pieces Together[END_REF], the strategies for contract fulfillment are based on a per component basis, depending only on the attributes of the individual components, and then acting on components selected with ad hoc strategies [START_REF] Collet | A Contracting System for Hierarchical Components[END_REF][START_REF] Léger | Reliable Dynamic Reconfigurations in a Reflective Component Model[END_REF][START_REF] Delaval | Reactive Model-Based Control of Reconfiguration in the Fractal Component-Based Model[END_REF][START_REF] Zeng | QoS-Aware Middleware for Web Services Composition[END_REF]. However, as software services result from the interaction of sets of components in a shared computing infrastructure, their QoS properties depend also on the components joint work and their context of execution (e.g., amount of concurrent users and underlying computing infrastructure load). Hence, a first challenge is to preserve QoS contracts with context-aware strategies that dynamically and reliably consider the behavior of sets of components chosen systematically and consistently, and act upon them as a whole.

On the other hand, the treatment of QoS contracts have traditionally focused on what contracts must specify, that is, on guaranteeing QoS obligations. Nonetheless, given the unpredictable nature of context and that QoS attributes depend on it, a second challenge is to fulfill QoS contracts robustly. Robustness is required to maintain the consistency between the contract states and the states of the software subject to the contract conditions over time, especially if the system state deviates from the desired state (e.g., what to do and in which state to leave the system when facing unspecified context situations affecting it?).

In a previous work presented in [START_REF] Tamura | QoS Contract-Aware Reconfiguration of Component Architectures Using E-Graphs[END_REF], we proposed a definition of QoS contracts as a static mechanism to specify how to reconfigure component-based software systems. In this approach, the QoS contract semantics had to be hard-coded in the reconfiguration system, restricting its applicability and making it impossible to guarantee properties such as robustness. In this paper we formalize the semantics of our QoS contract definition, andimplementitinasoftwareframework called QoS-CARE (QoS ContrAct-preserving Reconfiguration systEm). In our definition, a QoS contract establishes the different QoS levels expected to be fulfilled under different context situations, together with respective guaranteeing reconfiguration rules. Thus, to formalize the semantics of QoS contracts, we extend finite-state machines (FSMs) and typed-attributed graph (TAGs) transformation systems, and use them as mathematicaldenotationsfortheQoScontract elements and software structures respectively, in two layers. In the governing layer, we interpret aQoScontractasanFSM,withexpectedQoS-levelsasstates,and reconfiguration rules as transitions. In the operating layer, FSM states are mapped to software structures denoted as TAGs, and transitions to software re-configurations via TAG transformations.

The QoS contract semantics formalization allows QoS-CARE to automatically process a contract as the high-level policy that governs the behavior of a self-adaptive system to maintain fulfilled the contracted QoS levels. Moreover, this automation guarantees 5 of the 10 selfadaptation properties that we defined in [START_REF] Villegas | A Framework for Evaluating Quality-Driven Self-Adaptive Software Systems[END_REF]. Of these 5 properties, short settling-time is related to the practical feasibility of our formal-based approach, whereas atomicity, termination, robustness to context unpredictability, and consistency, to its reliability and robustness. Guaranteeing the remaining 5 properties (i.e., stability, accuracy, small overshoot, scalability and security) is part of our ongoing research work. It is worth noting that, to the best of our knowledge and based on the survey performed in [START_REF] Villegas | A Framework for Evaluating Quality-Driven Self-Adaptive Software Systems[END_REF], no other approach guaranteesmorethan4ofthe10properties.

Concerning the aforementioned challenges, the novelty of our contribution is as follows. For the first challenge, our extension of TAG transformation systems as denotation for software structures and reconfiguration rules makes it possible to exploit design patterns (i.e., sets of components consistently considered as a whole with specific goals) at runtime. Despite these patterns have been applied until now at design-time to determine quality attributes in software systems [START_REF] Shaw | Software Architecture: Perspectives on an Emerging Discipline[END_REF][START_REF] Bass | Software Architecture in Practice[END_REF][START_REF] Kruchten | The Past, Present, and Future for Software Architecture[END_REF][START_REF] Buschmann | Pattern-Oriented Software Architecture: A Pattern Language for Distributed Computing[END_REF][START_REF] Clements | The Golden Age of Software Architecture Revisited[END_REF], we encode them in reconfiguration rules toreplacethemdynamically in the running system to fulfill specific QoS levels. For the second challenge, our FSM extension as denotation for QoS contracts guarantees robustness with respect to context unpredictability. Concerning the methodology, our approach introduces the use of two-layered denotational semantics to the specification of QoS contract semantics. Previously, similar methods have been used, nonetheless, for programming languages [START_REF] Gunter | Semantics of Programming Languages: Structures and Techniques[END_REF]. In our case, this semantics bridges the abstract and actual running-software worlds, and generalizes the applicability of QoS-CARE.

This paper is organized as follows. Section 2 introduces a motivating application scenario. Section 3 presents an overview of our semantic specification approach. Sections 4 and 5 present the formal definitions for the two layers of denotations used.S e c t i on6a na l yz e st heprope rt i e sof QoS-CARE, and Section 7 shows its applicability. Section 8 compares our approach with similar ones, and Section 9 concludes the paper.

Application Scenario

To better understand the requirements for preserving the satisfaction of QoS contracts, we use a simplified version of a reliable video conference system( R V C S ) .F ort heus e r ,t hevi de o conference services are provided through a software application subject to a QoS contract. This contract, negotiated with the user and provided by a softwareevolutionarchitect,specifiesQoSlevel obligations for the confidentiality and availability of the RVCS services under different context conditions. In this example, confidentiality and availability are QoS properties interpreted according to Barbacci et al. [START_REF] Barbacci | Q u a l i t yA t t r i b u t e s ,T e c h n i c a lR[END_REF]. That is, the RVCS must ensure (i) the confidentiality on video conference transmissions, and (ii) the continued service of active video conferences, with the expected quality levels under their respective context conditions, as illustrated in Table 1. Thus, this contract implies that RVCS software clients are responsible for maintaining the application services to their users with the expected quality levels, in a "smart" way. For instance, in the confidentiality case, whenever a software client connects to the application services from an extranet-serviced area (cf. CC1 in the table), the communication channel is expected to be configured with ciphering/deciphering components between client and server. As this isknown as having a "confidential channel" structure, the respectiveexpectedQoSlevelisnamed"Con-fidentChannel". Whenever the user moves into an intranet-serviced area, presumably not requiring securing mechanisms in the middle between client and server, a so called "clear channel" structure is expected to be configured in the communication channel (cf. CC2). In case of no network connection, the RVCS client-server communication is expected to be configured with alocal/remote cache structure with automatic synchronization capabilities upon communication resumption (cf. CC3), putting the call on hold (respective QoS levels named accordingly).

It is worth noting that addressing these requirements statically (e.g., with if-then clauses on context conditions) would not be satisfactory. First, QoS levels can be renegotiated at runtime, for instance introducing new ones (i.e., new states), thus implying the deployment of additional functionalities (i.e., new software components). Second, as the video conference requires bidirectionality between client and server, this would introduce undesirable synchronization problems between the client's and server's code in their maintainability and also in their execution consistency. For instance, lets consider simple conditionsofaQoScontractthatdependoncontext situations such as the current bandwidth of the network interface, or the throughput of service requests. Concerning the maintainability, every of these context conditions should be managed explicitly in both the client and the server code to process them accordingly to the responsibilities on each side. Each new condition to be considered in a contractwouldrequireamodificationof the source code of both sides. Concerning the execution consistency, the question is that context conditions depend on where they are sensed, at runtime: for the example on network bandwidth, different clients located in different places and connected from different network access points sense different values, and these values are different than the sensed values by the server, for the same context condition. If these conditions are managed in the code of both client and server, they must synchronize and agree on the behavior of the response to changes on these conditions, at runtime.

In the next section we present an overview of our approach, highlighting the challenges that we address in this paper.

Layered Denotational Semantics for QoS Contracts: An Overview of QoS-CARE

Informally, the semantics of QoS contracts can be globally approached with a finite-state machine (FSM) with the expected QoS levels as states, and the events on context condition changes as transitions. For instance, the confidentiality contract of our application scenario specified in Table 1a can be represented as in Figure 1.

Figure 1: FSM for the confidentiality contract. States represent expected QoS-levels to be fulfilled by the RVCS application under different context situations. On each state, monitor probes in the RVCS software clients notify changes on these situations such as moving into areas with network access fromIntranet, fromExtranet,orhavingnoNetwork.

Nonetheless, even though this tentative approach is plausible and resembles others (e.g., those based on statecharts [START_REF] Harel | Statecharts: A visual formalism for complex systems[END_REF]), it presents two fundamental challenges to achieve the goal of preserving autonomously QoS levels as the corresponding contract semantics. The first challenge is that this approach is "nominal" in the sense that the transitions it performs are confined to the state-machine, that is, they operate only at an abstract level, lacking an explicit and concrete mechanism to achieve the objective of the transitions at the actual software level. Thus, these transitions have no enforcing means for the associated running system to fulfill the expected QoS levels under changing context situations. The second challenge is that this approach does not guarantee contract robustness with respect to context unpredictability. In this sense, robustness implies to manage both, context events notified by context monitors but unforeseen by the user, as well as the inefficacy or absence of reconfiguration rules in a given contract tofulfillforeseen QoS levels.

We address these challenges with two layers of denotations asdescribedinthenextsections.

Context-Aware Reconfiguration Mechanism

To address the first challenge, our strategy to fulfill QoS levels under different context conditions is to use design patterns.T h e s ea r es p e c i fi cs e t so fc o m p o n e n t sc o n s i d e r e da sc o n s i s t ent constructs that determine quality attributes in software systems. For instance, in the confidentiality case of our application scenario we identify three oft h e s es e t so fc o m p o n e n t s ,n a m e l y the corresponding to (i) the confidential-channel components structure, (ii) the clear-channel components structure, and (iii) the local/remote-cache components structure. In fact, these structures correspond to design patterns for distributed components and secure communications as presented in [START_REF] Ramachandran | Designing Security Architecture Solutions[END_REF][START_REF] Buschmann | Pattern-Oriented Software Architecture: A Pattern Language for Distributed Computing[END_REF][START_REF] Dougherty | Secure Design Patterns[END_REF]. Other design patterns proposed to be used at design-time for addressing quality attributes such as performance and availability also exist in the literature (e.g., [START_REF] Kircher | Pattern-Oriented Software Architecture: Patterns for Resource Management[END_REF][START_REF] Mattson | Patterns for Parallel Programming[END_REF][START_REF] Zeng | Network friendly media security: Rationales, solutions, and open issues[END_REF][START_REF] Krakowiak | Middleware architecture with patterns and frameworks[END_REF]).

However, our strategy is to use these design patterns not at design-time, as they have been used until now, but at runtime, by encoding them in the left-and right-hand sides (LHS and RHS respectively) of reconfiguration rules to replace them dynamically when the running system transition between states. This replacement is performed through pattern matching of a given rule's LHS on the actual running system, and the dynamic deployment of the modifications implied by the differences between this LHS and its corresponding RHS on the system components and relationships. Nonetheless, instead of performing these operations at the running system level, we use typed-attributed graphs (TAGs) as denotations for thecomponent-basedstructure(CBS) of the system, and for the LHS and RHS (i.e., design patterns) of reconfiguration rules. Thus, the system reconfiguration operation (CBS 1 → CBS 2 )isabstractedasagraphtransformationoperation (TAG 1 → TAG 2 )usinggraph-basedpattern-matching.Ofcourse,thebenefitofusingTAGs as denotations for CBSs is that we can define f : CBS → TAG such that, for every pair of vertices (CBS 1 , CBS 2 )and(TAG 1 , TAG 2 )withTAG 1 = f (CBS 1 )andpathsq = q 1 ,...,q m between TAG 1 and TAG 2 ,f r o mt h e s ep a t h sq 1 ,...,q m we can synthesize respective paths p = p 1 ,...,p n between CBS 1 and CBS 2 ,suchthatq• f = f • p and TAG 2 = f (CBS 2 ). That is, we have found a systematic way to obtain p,thecomponent-basedreconfigurationplan,fromanabstracted model of the running system (i.e., from the graph transformation q between its formal denotations), an important problem in the software engineering for self-adaptive software systems community [START_REF] De Lemos | Software Engineering for Self-Adaptive Systems: AS e c o n dR e se a r c hR o a d ma p[END_REF]. In denotational semantics this is illustrated with thecommutativediagram:

CBS 1 p ------→ CBS 2 f           f TAG 1 ------→ q TAG 2
In other words, we use design patterns not only as a systematicwaytofulfillexpectedQoS levels under their respective context conditions by modifying the system architecture at the abstract level, but also provide the means to automatically synthesize the reconfiguration plans to instrument these modifications in the actual running system.W ec a l lt h i sfi r s td e n o t a t i o nt h e operational layer of our semantic specification.

Guaranteeing Contract Robustness

To address the second challenge, guaranteeing contract robustness, the strategy has to consider all of the plausible situations that the system can facei ni t se x e c u t i o nc o n c e r n i n gt h e QoS contract definition. To achieve this, we characterize thed i fferent types of context conditions that determine not only states and transitions of contract fulfillment, but also of unfulfillment. Therefore, we redefine the usual 5-tuple FSM as a contract-driven tuple FSM, thus called QoSC FSM (QoS Contract-driven FSM), which incorporates both fulfillment and unfulfillment contract super-states and transitions. To guarantee contract robustness, the fulfillment superstate groups all of the expected QoS levels to be fulfilled, which are associated with the specific component-based structure (CBS) configurations (e.g.,R VCSwithconfidentchannel,clear channel or local/remote cache). Then, the contract denotation is completed with two other superstates that comprise the states of contract unfulfillment, which result from the aforementioned characterization of context conditions. Transitions are associated with TAG reconfiguration rules (i.e., LHS-RHS encoding design patterns) triggered by context events. We call this second layer of denotations the governing layer of our semantic specification.

In other words, we have a two-layered semantics in which the denotations of the second layer are parameterized with denotations of the first one. Thus, our semantic specification of QoS contracts results from a semantic elaboration that combines the semantics of TAGs and FSMs.

QoS Contract Semantics in Practice

In the application scenario introduced previously, assume initially that a mobile user joins a video conference from her office at the corporate building from an intranet-serviced WiFi accesspoint. In this initial state, the RVCS application is configured satisfying the respective condition CC2inT able1a,thatis,withaclearchannelconfiguration(cf. R1 in Figure 2).

As e c o n da p p l i c a t i o ns t a t es h o u l db er e a c h e dw h e nt h eu s e rm o ves from her office to outside of the company building, accessing the RVCS services from any of the available extranetserviced access-points, such as GSM or UMTS, thus changing tot h ec o n t e x tc o n d i t i o nCC1. This context change, notified by the context event labeled E in Figure 2, signals an imminent violation of the confidentiality contract, which is being fulfilled by the current application state. Being in effect the new condition (CC1) in the execution context, the respective QoS level (a confident channel) is expected to be fulfilled. Thus, the expected system response is to reconfigure itself to deploy a confidential channel design-pattern, in a transparent way to the user to obtain the R2 system configuration. However, QoS-CARE performs this reconfiguration by (i) obtaining the TAG denotation G1 of the actual running-application state; (ii) applying graph pattern-matching and transformation G* using the design patterns encoded in the LHS and RHS of reconfiguration rules; (iii) obtaining a new graph representation G2 ;a n dfi n a l l y ,( i v )i n s t r umenting the graph-based reconfiguration operation back intotherunningapplication,obtaining R2 .T h i sn e wc o n fi g u r a t i o n ,w i t hac o n fi d e n t i a lc h a n n e l ,s h o u l dfulfill the expected QoS level CC1.

In the following sections we present the details of the TAG andQ o S C FSM definitions and elaborate on how we use them to build our two-layered semantics for QoS contracts.

Denotation of Component-Based Structures and Design Patterns

The denotations we use for component-based software structures and design patterns correspond to refinements of our formal definitions presented in [START_REF] Tamura | QoS Contract-Aware Reconfiguration of Component Architectures Using E-Graphs[END_REF]. In this section we recall them. Built on the typed and attributed graph transformation systems by Taentzer [START_REF] Taentzer | AGG: A Graph Transformation Environment for Modeling and Validation of Software[END_REF] and Ehrig [START_REF] Ehrig | Fundamentalso fA l g e b r a i cG r a p hT r a n s f o r m a t i o n ,S p r i n g e r -V e r l a g[END_REF], our approach defines an abstract syntax for Components-based (CBD1 )t y p i n gs t r u c t u r e , system's reflection representation, QoS contracts, and design patterns in reconfiguration rules2 . Our choice of graphs to denote software structure configurations and its runtime re-configuration has three motivations. First, the expressiveness of graphs to model software structures and design patterns, and to encode them in left and right hand sides of graph transformation rules. Second, the determining relationship between design patterns and specific quality attributes (i.e., QoS levels) [START_REF] Shaw | Software Architecture: Perspectives on an Emerging Discipline[END_REF][START_REF] Bass | Software Architecture in Practice[END_REF][START_REF] Kruchten | The Past, Present, and Future for Software Architecture[END_REF][START_REF] Buschmann | Pattern-Oriented Software Architecture: A Pattern Language for Distributed Computing[END_REF][START_REF] Clements | The Golden Age of Software Architecture Revisited[END_REF][START_REF] Ramachandran | Designing Security Architecture Solutions[END_REF][START_REF] Zeng | Network friendly media security: Rationales, solutions, and open issues[END_REF][START_REF] Kircher | Pattern-Oriented Software Architecture: Patterns for Resource Management[END_REF][START_REF] Krakowiak | Middleware architecture with patterns and frameworks[END_REF][START_REF] Dougherty | Secure Design Patterns[END_REF]. Third, the benefits granted by graph transformation properties.

System Reflection

The system reflection structure of managed component-based applications is denoted by a set of definitions in terms of typed-attributed graphs (TAGs), which comprise the usual CBD's component, interface, interface type and binding elements.C o m p o s i t e s ,w h i c ha l l o wt os c a l e system complexity by grouping components, are naturally abstracted as components, given that we address structural reconfiguration at the system level. Asa l lo fo u rd e fi n i t i o n so fs o f t w a r e structures are given in terms of TAGs, we start with the TAG definition.

Definition 1 (TAG, TAG morphism). AT AGisantuple

(V 1 , V 2 , E 1 , E 2 , E 3 , (source i , target i ) i=1,2,3 ), where • V 1 , V 2 are
sets of graph and data nodes, respectively;

• E 1 , E 2 , E 3 are sets of edges (graph, node-attribution and edge-attribution, respectively);

• source 1 : E 1 → V 1 ; source 2 : E 2 → V 1 ; source 3 : E 3 → E 1
are the source functions for the edges; and

• target 1 : E 1 → V 1 ; target 2 : E 2 → V 2 ; target 3 : E 3 → V 2 are
the target functions for the edges. AT A Gm o r p h i s mt between TAGs G and H, t

: G → H,i sat u p l e( t V 1 , t V 2 , t E 1 , t E 2 , t E 3 )w h e r e t V i : G V i → H V i and t E j : G E j → H E j for i = 1, 2, j = 1, 2, 3
, such that t commutes with all source and target functions 3 .

As depicted in Figure 3, a TAG adds the usual definition of graph(V 1 , E 1 , source 1 , target 1 ), with (i) V 2 ,thesetofdata-attributionnodes;(ii)E 2 and E 3 ,thesetsofdata-attributionedges;and (iii) the corresponding source and target functions for E 2 and E 3 ,usedtoassociatetheattributes for V 1 and E 1 ,respecti vely ,toV 2 .T A Gm o r p h i s m sc a nb eu s e dt od e fi n er e l a t i o n s h i p s( s u c ha s typing conformity) between TAGs. • DS ig is a data signature over the disjoint union Integer + String + Inter faceS ignature + Inter faceRole, Inter faceRole = {Provided, Required},withtheusualCBDinterpretations; 4 The component-based structure type is a TAG where graph-nodes represent the usual CBD elements. Graph-edges correspond to the relationships among these elements. Data-nodes represent types of attributes, and data-edges, the typing relationships. QoSProvision is a special attribute to annotate components, interfaces and bindings to express their provision of particular QoS capabilities, such as secure network connections or scalable processing possibilities. Naturally, the purpose of CBSTYPE TAG is to serve as a type for the actual CBS instances denoted as TAGs (thus written CBS TAG ). CBS TAG ,typedwithCBSTYPE TAG ,iscalledtheapplication reflection of the respective managed system because weuseitasaninternalrepresentation of the system as an indirect means to modify its structure and quality attributes at runtime.

• G is the TAG (V 1 , V 2 , E 1 , E 2 , E 3 , (source i , target i ) i=1,2,3 )suchthatV 1 = {Component,

Definition 3 (Component-Based Structure Application Reflection-CBSAR).

Given CBS the computational state of the managed component-based software application at runtime, its corresponding reflection state is defined as CBSAR = (CBS TAG , t), where CBS TAG is the TAG that denotes CBS through the one-to-one function f :C B S→ CBS TAG ,a n dt is the TAG morphism t :C B S TAG → CBSTYPE TAG ensuring that CBS TAG conforms to the typing structure CBSTYPE TAG .

That is, being CBS the representation of the managed system state in terms of its components, services, interfaces and bindings, as maintained in runtime component platforms, CBSAR encapsulates its corresponding TAG denotation. Recalling the commutative diagram presented in Section 3.1, the purpose of f is to map the component-based system structure to the TAG domain, in which the system reconfiguration is to be operated.T h ed e fi n i t i o no ff is crucial for the applicability of our model, given that it bridges the running software world with its corresponding abstract (TAG) world. We use CBS TAG .Component as an abbreviation for the set of the graph elements in CBS TAG typed as components by the typing morphism t,t h a ti s ,

CBS TAG .Component = {c | c ∈ G V 1 ∧ t V 1 (c) = Component} (

analogously for the other elements).

Example 1 (Video Conference Component-Based Structure Application Reflection). Figure 5i l l u s t r a t e st h er u n t i m ec o m p

o n e n t -b a s e ds t r u c t u r eo fo u rvideo conference example (i.e., its CBS) when connected from an intranet-serviced area (i.e., with a clear-channel connection).

Figure 6 illustrates the corresponding CBS TAG denotation of the system reflection (CBSAR) state, which conforms to CBSTYPE TAG .T h ec o m p o n e n t sa r er e p r e s e n t e da se x a c t l yt h ev i d e o conference client (the leftmost highlighted component nodewithc_name="VCClient") with its network connection ("NetAdapter") and the server ("VCS erver"). The other elements represent the interfaces of these components ("vccS end", "vccReceive"andsoon),andtheirbindings.The component "NetAdapter"isprovisionedforprovidinga"ClearChannel" network connection, as expressed by its c_QoSProvision attribute.

QoS Contracts

AQoScontractspecifiesobligationsasexpectedQoSle velsfor a given functionality under specific context conditions. These obligations can be seen astheguaranteesoffered by a system or service provider to any of its potential clients ( [START_REF] Beugnard | Making components contract aware[END_REF][START_REF] Keller | The wsla framework: Specifying and monitoring service level agreements for web services[END_REF][START_REF] Collet | A Contracting System for Hierarchical Components[END_REF][START_REF] Krakowiak | Middleware architecture with patterns and frameworks[END_REF][START_REF] Tran | A Survey and Analysis on Semantics in QoS for Web Services[END_REF]). Thus, a QoS contract is an invariant to be preserved by a system, for instance, by restoring it in case of its violation. The evaluation of the invariant validity must be performed atr u n t i m e ,g i v e nt h a ti td e p e n d s on measurements from the actual context of execution, such asr e s p o n s et i m e ,t h r o u g h p u t ,a n d security level on network access location. Therefore, the QoS levels must be monitored and the system must act upon their (imminent) violation in order to have the possibility of maintaining them fulfilled.

Definition 4 (QoS Contract -QoSC). Given QoS DS ig the usual data signature over the disjoint union Integer + String+ Boolean + Predicate,aQoScontractisatuple(C, ct), where

• C is the TAG that denotes the contract instance, subject to • ct,t heT A Gmorphi s mct : C → QoSCTYPE TAG ,whereQoSCTYPE TAG is the TAG typing definition for QoS contract instances, This definition involves the assignment of responsibilitiesf o rt h ec o o r d i n a t e do p e r a t i o no ft h e elements required to perform a software reconfiguration, as established by the autonomic computing vision [START_REF] Kephart | The Vision of Autonomic Computing[END_REF]. That is, a QoS contract is specified referring to a set of QoSProperties, each of which has:

QoSCTYPE TAG = (V 1 , V 2 , E 1 , E 2 , E 3 , (source i , target i ) i=1,2,3 )suchthatV 1 = {QoS Contract,
• asetofobligations(SLOObligation), each with its expected QoS level to be fulfilled (SLO-Predicate)underacorrespondingcontextcondition(contextCondition)signaledbycontextevents of a given type (contextEvType); a guaranteeing reconfiguration rule-set (QoSRuleSet) to apply upon notification of these events. This rule-set is used to perform the reconfiguration of the component-based structure application reflection state (CBSAR) of the actual running system. • asetofmonitoringelements(QoSMonitor)thatnotifytherespectivecontextevents;and

• as e to fQoSGuarantors, system elements distinguished as being the most directly related with the functionalities that determine the fulfillment of the expected QoS levels.

As in the case of CBS instances, QoS contract instances, denoted as TAGs, must have conformance with their typing TAG QoSCTYPE TAG .

Component-Based Structure Reconfiguration System

Having defined the denotations for the structural parts of a system in terms of TAGs, we define the runtime software structure reconfiguration as a TAGtransformationsystem.Thedefinition of this reconfiguration system is based on the definition of reconfiguration rule. Conceptually, a reconfiguration rule encodes a strategy to fulfill a particular QoS level under ag i v e nc o n t e x tc o n d i t i o n . I no u rs t r a t e g y ,s o f t w a r ee v o l u t ion architects can take advantage of known design patterns that determine these QoS levels by encoding these patterns in the left and right hand sides of reconfiguration rules. We group all rules to fulfill a given QoS level in the same rule-set to be associated with the respective attribute(ruleSet)inaQoScontractinstance. 2 specifies the guaranteeing rule-sets for the QoS contract example on confidentiality for our video conferencee xample. Thiscontracthasthree QoS levels corresponding to context conditions defined by network access types. Thus, these conditions determine the communications structure of the managed application to guarantee the confidentiality of the transmitted information, following the corresponding design patterns defined in [START_REF] Ramachandran | Designing Security Architecture Solutions[END_REF][START_REF] Buschmann | Pattern-Oriented Software Architecture: A Pattern Language for Distributed Computing[END_REF][START_REF] Dougherty | Secure Design Patterns[END_REF]: a clear channel when connected from the intranet; a ciphered channel when from the extranet; and a local cache when having no network access. These reconfiguration rule-sets are defined as follows. Rule-set for Changing to Intranet-Serviced Areas (R_clearChannel). Given that the user can move freely among locations with any of the enunciated context conditions, the reconfiguration rules specified to configure a clear channel (i.e., when movingtoanintranet-servicedarea)must consider the transitions from any of the two other configurations. Thus, in Figure 8 we present the rule-set to apply when the user moves to an intranet-serviced area from either, an extranetserviced area (cf. extra2intra rule in the top of the figure), or an area having no network access at all (cf. nonet2intra rule in the bottom of the figure). The left-hand side (LHS) of the extra2intra TAG reconfiguration rule is used by patternmatching to find the components that are providing a ClearChannel connection, thus fulfilling the current QoS level (by the c_QoSProvision attribute). The right-hand side (RHS) specifies that (i) the matched components by the LHS must be kept with their corresponding bindings as they are, except bindings indexed with 4 and 5; (ii) RHS elements not in the LHS must be removed and undeployed to configure a clear channel; (iii) the existing interfaces indexed with 2 and 3 must be re-bound to bindings indexed with 4 and 5, respectively; finally, (iv) the c_QoSProvision attribute of component 1 (i.e., the NetAdapter)i su p d a t e da sp r o v i s i o n i n ga ClearChannel.F o rr e a s o n so fl e g i b i l i t y ,t h el e f t -r i g h tg l u i n gKCBS TAG and graph morphisms l, r, lt, kt, rt are omitted; KCBS TAG , l, r correlate the corresponding LHS-RHS elements, while lt, kt, rt map LCBS TAG , KCBS TAG and RCBS TAG ,r e s p e c t i v e l y ,t ot h eC B S T Y P E TAG structure. The interpretation is similar for the nonet2intra rule.

Example 2 (Reconfiguration rules). Table

The local-cache design pattern we use in this rule specifies two main components (cf. Local-Cache in the client-side and UserCache in the server-side, bottom rule of the figure) to cope with communication interruptions. The first provides the asynchronous resume service to be used by the second, once the communication is re-established. In complement, the second provides the synch service to be used by the resume service to synchronize the interactions from both sides, which were saved locally upon the communication interruption, for post-processing. Even though the client-and server-side components must be labeled accordingly in the reconfiguration rules, we have omitted them in this figure for legibility reasons.

Rules for Changing to Extranet-Serviced and Unreachable-Network Areas (R_con f identChannel and R_localCache). From the previously illustrated rules, it is worth noting that in each rule we can invert its LHS and RHS to obtain the rule that specifies the opposite transition between the same pair of states. Moreover, it is easy to observe that we have chosen carefully the same key elements in the LHSs and RHSs (i.e., the 2:Interface, 3:Interface, 4:Binding and 5:Binding)aspivotsforthesereconfigurationrules. Thus,thereconfiguration rule-sets to be applied for changing to extranet-serviced areas (R_confidentChannel rule-set) and unreachablenetwork areas (R_localCache rule-set) can be specified from the previously specified rule-set, by inverting and exchanging their LHSs and RHSs, that is, with LHS = RHS = {intranet, extranet,noNetwork},a sa r r a n g e di nF i g u r e9( e . g . ,t h er u l eextranet-to-intranet is formed with LHS = extranet and RHS = intranet). Similar to the illustrated reconfiguration rule-set for configuring a clear channel, the corresponding rule-sets to apply when the user moves into an extranet-serviced area, and into an area with no network access, are composed of two reconfiguration rules. These rules correspond to each of the two other possible configurations, as evidenced int h efi g u r e ,t h a ti s ,a l lt h es t a t e s have two incoming transitions.

Definition 6 (Component-Based Structure Reconfiguration System -CBSRS).

The componentbased structure reconfiguration system, CBSRS, is the tuple (DS ig, CBSTYPE TAG , CBSAR, P), where DS ig is the data type signature from Def. 2 (CBSTYPE TAG ); CBSTYPE TAG the componentbased structure typing definition; CBSAR the reflection structure of the managed application to reconfigure in its current running state; and P asetofreconfigurationrules,withCBSTYPE TAG , CBSAR, and P according to Def. 2, 3, and 5, respectively, for:

= G 0 ⇒ G 1 ⇒ ... ⇒ G n = CBS TAG ′ ,
written CBS TAG * ⇒ CBS TAG ′ ,whichfinisheswhennomorerulesinP can be applied, obtaining a new managed application reflection structure CBSAR ′ .F r o mt h es e q u e n c eo ft r a n sformation operations, a correct by construction plan is synthesized to reconfigure the actual running system (i.e., to perform CBS → CBS ′ in the commutative diagram of Section 3.1).

That is, a CBS reconfiguration system reconfigure component-based structure applications. However, as mentioned before, it performs this operation indirectly, by using the guaranteeing reconfiguration rule-sets specified in the QoS contract in the running system denotation, CBSAR, and synthesizing a reconfiguration plan from the graph transformation operations. This reconfiguration plan is finally instrumented in the actual running software system.

Example 3 (System reconfiguration).

In Example 1 we presented the component-based structure of the RVCS application when the client is connected froma ni nt r a ne t -s e r vi c e da r e a( i . e . , with a clear channel). Whenever the user moves into an extranet-serviced area, the reconfiguration rule intra2extra,illustratedinExample2(i.e.,theinverseofextra2intra)isapplied on the RVCS's component-based structure application reflection state, CBSAR. Figure 10 illustrates the CBS TAG denotation of the reconfigured RVCS application, whose structure fulfills the QoS level for the new context condition (i.e., confidentChannel for a network connection fromExtranet)asspecifiedintheconfidentialitycontract.Correspondingly, Figure 11 illustrates the reconfigured runtime application structure in component-based notation.

Separation of Concerns

In the previous sections we have presented the formal definitions to build our system for reconfiguring component-based applications. In this section we analyze the implications of these definitions.

The most important point to highlight corresponds to the indirect relationships between QoSProvision attributes and reconfiguration rules (Def. 2, 3 and 5). QoSProvision attributes are used to identify the managed application elements considered as potential reconfiguration objectives. These elements refer to components, interfacesandbindingsinboth,themanaged application reflection structure, as well as left and right hand sides of reconfiguration rules. Thus, the relationships between them are to be discovered at runtime by pattern-matching operations. As a result, these indirect relationships introduce a level of indirection that allows the decoupling of the managed application (to be reconfigured) from the mechanism that actually performs the reconfiguration. In turn, this decoupling allows our model tomanagetheclearseparationofconcerns between the contractual QoS properties on the managed application and the properties of our reconfiguration mechanism.

The second point is the central role of the contract definitionastheconsistencyenforcerof our approach with respect to the QoS properties of interest (Def. 4 and 6). This consistency supports the collaborative and coordinated work not only among our denotational elements, but also between them and the elements of the actual running system that participate in the reconfiguration loop, namely the system component monitors and guarantors. In this way, our contract definition serves several objectives: (i) it specifies expected QoS levels of a managed application to its users; (ii) it establishes the responsibilities for the internal components of our approach to fulfill these obligations; and (iii) it declares the responsibilities for the monitor and guarantor elements that would be required to complete a reconfigurationloopinafinaldeployment.

Denotation of QoS Contracts

In Section 3 we introduced the global idea of specifying the semantics of QoS contracts in terms of FSMs, and identified two main challenges for realizing it appropriately. First, the execution of an FSM transition must enforce that the software system subject to a QoS contract fulfills the QoS-level associated to the transition's FSM target state. Second, the FSM representation must guarantee contract robustness with respect to context unpredictability. In Section 4 we specified the TAG-based denotations for component-based software structures, design-patterns and reconfiguration systems, which define the operational layer of our denotational semantics. This operational layer constitutes the base to solve the firstofthetwoaforementionedchallenges. In this section we present the formal definition of the governing layer of our semantics. This layer extends FSMs and we use its elements as denotations for QoS contract elements (i.e., specifically the QoS levels as extended states, context conditions as transition triggers, and guaranteeing rules as transition actions). By parameterizing this second layerw i t ht heope r a t i ona lone ,w eobt a i n the two-layered denotational semantics for QoS contracts asawhole,whichs olv esbothofthe two aforementioned challenges in an integrated way.

QoSC FSM :Q oSC ont r ac tD r i v e nR e de fini t i onofF SM s

The definition of the governing layer of our denotational semantics is based on a redefinition of finite-state machines (FSMs). Even though most of the elements of a QoS contract can be represented with the conventional definition of FSM [START_REF] Hopcroft | Introduction toA u t o m a t aT h e o r y ,L a n g u a g e s ,a n dC o m p u t a t i o n[END_REF], as illustrated in Section 3, a detailed analysis of the FSM definition allows us to identify several problems with this representation. First, context events must be specified explicitly to label each transition between states. This imposes very strict constraints for the identification and specification of transition triggers-and the transition function (δ)itself-thatcanleadtoaconsiderablenumberoftransitions [START_REF] Harel | Statecharts: A visual formalism for complex systems[END_REF]. Second, the reconfiguration rules, aimed at guaranteeing QoS levels when triggered by context events, are not considered in FSM transitions. Thus, an explicit invocation mechanism is needed for their execution. Even modifying the FSM to support entry/exit actions as in the event-conditionaction strategies [START_REF] Colombo | SCENE: A Service Composition Execution Environment Supporting Dynamic Changes Disciplined Through Rules[END_REF], the application of our reconfiguration rule-sets would require additional mechanisms, as event-condition-actions specify only one action per event-condition. Third, the purpose of QoS contracts is to specify expected QoS levels to be fulfilled under different context conditions. Thus, QoS contracts specify only states of fulfillment.H o w e v e r ,t oc o p ew i t h robustness, we need to consider also the possible unexpectedandundesirablestatesthatcould be reached by the managed application when facing context conditions that were not foreseen by the user (e.g., a software evolution architect). Nonetheless, solving these problems is a challenging task as some of the improvements depend on the others, and even more, the improvement of some may imply to worsen the others. For instance, adding unexpected and undesirable states would imply to specify all of the exact context events and conditions that may cause the system to transition into these states, which is of course contradictory to the problem of controlling the transitions explosion.

In this subsection and the following we present our solution to the aforementioned problems by taking advantage of the operational layer of denotations defined in section 4. This layer is based on our TAG-based reconfiguration system (CBSRS, Def. 6)a sam or epo w e r f ulw a yof specifying the FSM states and transitions. To achieve this, we modify the conventional FSM definition in three ways. First, parameterizing it with our CBSRS denotations. Second, adding it with two new elements, and six auxiliary functions. Third, redefining its transition function (δ). The new definition of FSM, QoSC FSM ,isasfollows.

Definition 7 (QoS-Contract FSM -QoSC FSM ). AQoSC FSM is the tuple STATES, ACCEPT, Σ, Γ, Ψ,κ,η,ρ,ℜ,π,CBSRS,δ ,where

• STATES is the finite set of expected QoS levels to fulfill. As these levels are expressed as predicates, we label each state with the corresponding indexed predicate.

• ACCEPT ⊆ STATES is the set of states of contract fulfillment. The final managed application state, once finished its execution, should correspond to one of these states. • Σ (the controlled context events alphabet) is the finite set of context events specified by the user to notify changes of QoS levels, thus requiring the managed application to be reconfigured. In contrast, we distinguish this set from Σ U ,t h es e to fa l lp o s s i b l ec o n t e x t events that can be reported from context monitors.

• Γ is the set of guaranteeing rules, specified according to our definition of CBS reconfiguration rules (Def. 5). These rules specify how to perform reconfigurations (i.e., transitions) between the graph representations of running-software states. • Ψ : STATES → PREDICAT E maps each target state with the predicate (i.e., QoS level)

to be fulfilled on it. PREDICAT E is the set of well-formed first-order logic formulae. • κ : STATES → PREDICAT E maps each target state with the corresponding context condition that holds on it.

• η : STATES →P(Σ)mapseachtargetstatewiththetypeofthecontexteventsthat trigger transitions to it. P(Σ)isthepowerset(i.e.,thesetofallsubsets)ofΣ.

• ρ : STATES →P (Γ)mapseachtargetstatetotheguaranteeingreconfigurationrule-set to fulfill its QoS-level objective.

•ℜ: STATES → CBS AR maps the actual contract state to the corresponding runningsoftware state (i.e., the Component-Based Software Application Reflection structure, CB-SAR, Def. 3). As the managed application may evolve dynamically from state to state, its structure is not necessarily the same for a same state. Thus, this mapping is not statically defined, but computed at runtime only for the current state.

• π : STATES → QoS Property maps each target state to the QoS property in which it is defined. QoS Property is the finite set of QoS properties for which the user specifies context events, QoS levels, and reconfiguration rules.

• CBSRS is the component-based structure reconfiguration system (from Def. 6).

• δ : Σ × ∆ U →{ Fulfilled, Unstable, Exception} is the transition function,w h e r e" F u lfilled", "Unstable", and "Exception" are super-states grouping the respective states, and ∆ U is a reference to the universal execution context space of software applications. This space is left unspecified intentionally, given the practicali mpos s i bi l i t yofformal i zi ngi t , even in an abstract form. Any abstraction would imply a partial representation, which, at some point would turn to be incomplete and formally unsound. Instead of that, managing it as a reference to an external construct allows us to refer toitsparticularinstanceswhen evaluating the managed application by sensing the actual context of execution, which is more realistic and feasible than formalizing it.

In the following subsections we illustrate the elements of this FSM redefinition and how it solves the aforementioned problems.

The QoSC FSM Auxiliary Functions

Given that transitions in QoSC FSM are driven by context events and system reconfiguration rules, we encode this information in five of the added auxiliary functions: Ψ,κ,η,ρ and π. ℜ, the sixth function, is used to map the current QoSC FSM state with the running application state. According to their definitions, η : STATES →P(Σ)canbeusedtoidentifythesetoftriggering events that cause a transition to a given state; and vice versa, given a context event, to identify the target state to which this event triggers a transition; Ψ : STATES → PREDICAT E to identify the predicate expressing the QoS level that must be fulfilled in a given state; and ρ : STATES →P(Γ)toretrievethesetofreconfigurationrulestobeappliedforfulfillingtheQoS level associated to a given state. κ : STATES → PREDICAT E is used to obtain the context condition associated with a target state, for instance to confirm if it is still in force in the current context situation, and π : STATES → QoS Property to determine the QoS property to which a given state belongs to.

The mappings for Ψ,κ,η, ρ,andπ can be automatically obtained from QoS contract instances. For the contract example on confidentiality, corresponding to the QoS level to be fulfilled when moving into an extranet-serviced area, these mappings are the following4 :

• Ψ(con f identChannel) → "con f identChannel" • η(con f identChannel) → from_extranet,with from_extranet = {FromExtranet} • ρ(con f identChannel) → R_con f identChannel,withR_con f identChannel the set of two reconfiguration rules {intranet-to-extranet, noNetwork-to-extranet} (cf. rules from Example 2)

Here we present the values of Ψ,whichrepresentpredicates,asstrings.Thesepredicatesare evaluated in the execution of the reconfigured managed application under the current context of execution by the function evalInContext.Thevaluesreturnedbythisfunctionare(F)ulfilledand (U)nfulfilled. The purpose of evalInContext is to verify, by sensing the execution context at its invocation time, whether the predicate that corresponds to agivenQoSlevelissatisfied(returning F), or not (returning U). In this example, Ψ(con f identChannel), which is mapped to the predicate "con f identChannel", would be evaluated by sensing if the (re)configured application fulfills the predicate confidentChannel (i.e., the transmitted data is wrapped in a ciphered packet). In the case of a contract on throughput, Ψ(T 100/min)c oul dbem a ppe dt ot hepr e di c a t e" T 100/min", which would be evaluated by sensing if the application is performing 100 transactions per minute at invocation time. This function is fundamental in self-adaptive systems, given that it is not obvious that the condition will hold after performing a reconfiguration. Of course, to cope with this problem, the user must provide relevant corresponding reconfiguration rules.

In the case of the confidentiality example, assume that we haveaQoSC FSM with the function mappings defined as above. We would also have Σ={FromIntranet, FromExtranet, NoNetwork} and Γ={R_clearChannel, R_con f identChannel, R_localCache}.W h e nt h ec u r r e n ts t a t eo ft h e managed application is connected from the intranet and changes to an extranet-serviced area, it receives the event e = FromExtranet,and,ofcourse,e ∈ Σ holds. Thus, we have:

• e = FromExtranet ∈ η(con f identChannel)h o l d s ,g i v e nt h a tη(con f identChannel) → {FromExtranet}. • The target state s,intowhichtheFSMmustmakeatransitionhavingoccurredtheevente,
is obtained with the formula ∃s : s ∈ STATES | e ∈ η(s), that is, s = con f identChannel. • The QoS level to fulfill in this target state s is Ψ(∃s : s ∈ STATES | e ∈ η(s)), that is, Ψ(con f identChannel) → "con f identChannel". • The rule-set that must be applied to fulfill the QoS level implied by this target state s is ρ(∃s : s ∈ STATES | e ∈ η(s)), that is, ρ(con f identChannel) → {intranet-to-extranet, noNetwork-to-extranet}.

Managing Exception and Unstable States of Contract Unfulfillment

So far, our interpretation of QoS contracts is based on the expected QoS levels to fulfill, as specified in QoS contract instances. This implies that up to this point our model considers only the states of contract fulfillment. However, from the analysis of the auxiliary functions it is clear that to address contract robustness facing situations unforeseen by the user and derived from unexpected context conditions, contract unfulfillment states must be also managed. These states, to be added to the states of contract fulfillment in their automatic derivation from QoS contract instances, are the following:

• The exception state, modeling the specific situations in which the user specifies either:

an incomplete set of reconfiguration rules (i.e., no rule matches a given managed application state or context condition); or asetofreconfigurationruleswhoseapplicationresultsinamanaged application that violates the component-based integrity constraints; or asetofcontexte ventsexcludingothersthatactuallyoccurin the application execution context. • The unstable state, which models the situation in which the specified rulesarenotrelevant or not enough to achieve the fulfillment of a given QoS level. The value of these states, besides the user not having to worryaboutrobustnessissuessuch as specifying undesirable states and transitions, is that wec a nd e fi n et h ef o r m a ls e m a n t i c so f these states and transitions systematically. In this way, different types of operational actions to warn the user at runtime about the corresponding anomalous situations can be associated to these states, for instance after a repeated number of occurrences.

Generalizing Conditions for the QoSC FSM Transitions

Based on the definition and analysis of the QoSC FSM structure and its auxiliary functions, we can notably generalize the conditions for all of the transitions to the states of contract fulfillment. To achieve this, besides the evalInContext function, we recall the CBSRS boolean functions match and reconfig that we defined with it (cf. Section 4.3). match(r, CBSAR) returns true if there exists a match of the LHS of rule r in CBSAR, and false otherwise. Having a reconfiguration rule-set γ such that r ∈ γ and match(r, CBSAR) holds, recon f ig(CBSAR,γ)usesγ to reconfigure CBSAR, the managed application reflection structure. If the reconfiguration succeeds, that is, the application of the rule-set produces a managed application reflection structure that conforms to the component-based structural constraints, the function returns true; otherwise, it returns false.

Thus, the general condition for all of the transitions to contract fulfillment states given the context event e,undertheexecutioncontext∆,is:

e ∈ Σ ⊼ ∃s, r : s ∈ STATES, r ∈ Γ | r ∈ ρ(s | e ∈ η(s)) match(r, ℜ(s | e ∈ η(s)))⊼ recon f ig(ℜ(s | e ∈ η(s)),ρ(s | e ∈ η(s))) ⊼ evalInContext(Ψ(s | e ∈ η(s)), ∆) = F (1)
We read this condition as follows:

• given the occurrence of event e (i.e., a new context situation is present), considered among the set of valid context events Σ,and • atargetstates to be reached in the new context signaled by e (i.e., s | e ∈ η(s)), and 20

• areconfigurationruler in the rule-set to guarantee the fulfillment of the QoS level associated to s (i.e., r ∈ ρ(s | e ∈ η(s))) such that we can find a match of r in the current graph structure of the managed application ℜ(s | e ∈ η(s))), and • after reconfiguring the application reflection structure with the respective rule-set (recon f ig(ℜ(s | e ∈ η(s)),ρ(s | e ∈ η(s)))), the QoS level associated to the target state is F (Fulfilled). That is, evalInContext(Ψ(s | e ∈ η(s)), ∆) = F. It is worth noting that the occurrence of matching rules in thema na ge da ppl i c a t i onupona change in context conditions necessarily implies a reconfiguration. We use the symbols ⊼ and ⊻ for the consecutive logical conjunction and disjunction, respectively. Consecutive expressions operated with the ⊼ (⊻)ope r a t ora r ee v a l ua t e df r oml e f tt or i ghta nds t opsi nt hefi r st one that evaluates to false (true), if any, being it an operational version of logical conjunction (disjunction) used in the theory of abstract syntax-directed translation [START_REF] Aho | The Theory of Parsing, Translation, and Compiling[END_REF].

In condition [START_REF] Beugnard | Making components contract aware[END_REF] we highlight the predominance of target states over source states that results from the context-driven nature of these transitions. Thus, for each of the target states, which correspond to the QoS levels to be fulfilled, we only need to specify the conditions required by the respective incoming transitions. The justification for this is that we use the LHSso f reconfiguration rule-sets as part of the condition for the incoming transition to be satisfied in the match operation. In this way, in the generalized condition (1) we capture the transitions that the user may specify coming from any of the possible source states (i.e., all other QoS levels specified in the contract). That is, the LHSs determine which reconfiguration rules apply.

Furthermore, we follow this same strategy for the added states of contract unfulfillment (Unstable and Exception). For the transitions into these two states we need similar conditions, keeping in mind that those states result from anomalous situations encountered when trying to reach fulfillment states. These conditions correspond to the robustness requirements given in Section 5.1.2. Hence, the condition to reach the unstable state is the same as [START_REF] Beugnard | Making components contract aware[END_REF], except that the QoS level to be fulfilled in the target state is not achieved (i.e, the QoS-level predicate is evaluated as (U)nfulfilled), meaning that the rules given by the user are not relevant or not sufficient to achieve the fulfillment of the QoS level: 5e ∈ Σ ⊼ ∃s, r :

s ∈ STATES, r ∈ Γ | r ∈ ρ(s | e ∈ η(s)) match(r, ℜ(s | e ∈ η(s)))⊼ recon f ig(ℜ(s | e ∈ η(s)),ρ(s | e ∈ η(s))) ⊼ evalInContext(Ψ(s | e ∈ η(s)), ∆) = U (2)
For the exception state we have three disjoint conditions. The first expresses that the user specified an incomplete set of reconfiguration rules (i.e., no rule matches a given application state or context condition: ∀r : r ∈ ρ(s | e ∈ η(s)) ¬match(r, ℜ(s | e ∈ η(s))) ); the second, that an event occured but it is not in the set of context events specified by the user as valid (e ∈ Σ U \Σ); whereas the third, that the application of some of the rules given by the user violate the structural integrity constraints of component-based software (i.e., ¬recon

f ig(ℜ(s | e ∈ η(s)),ρ(s | e ∈ η(s)))): e ∈ Σ ⊼ ∃s : s ∈ STATES |∀r : r ∈ ρ(s | e ∈ η(s)) ¬match(r, ℜ(s | e ∈ η(s))) ∨ (e ∈ Σ U \ Σ)∨ e ∈ Σ ⊼ ∃s, r : s ∈ STATES, r ∈ Γ | r ∈ ρ(s | e ∈ η(s)) match(r, ℜ(s | e ∈ η(s)))⊼ ¬recon f ig(ℜ(s | e ∈ η(s)),ρ(s | e ∈ η(s))) (3)
Figure 12: State machine for the QoS contract-preserving reconfiguration system.

The Transition Function

From the previous analysis, it is easy to observe that the samec o n d i t i o n( 1 )e x p r e s s e sc o rrectly the transition requirements that target the three states of contract fulfillment of the confidentiality example. Moreover, based on this observation, we can abstract all the FSM fulfillment states as one "Contract Fulfillment" super-state to simplify the presentation of QoSC FSM s without loss of generality. 6 In this way, our semantic denotation for QoS contracts preservation becomes the state-machine depicted in Figure 12. In thisfigure,threepos s ibletrans itions , corresponding to the generalized transition conditions (1), ( 2) and ( 3), may occur: A RECONF-FULFILL: if the QoSC FSM finds a matching reconfiguration rule and performs a reconfiguration on the application, verifying that the reconfigured application fulfills its obligations; B RECONF-UNFULFILL: this transition operates as in [START_REF] Beugnard | Making components contract aware[END_REF], except that after the reconfiguration, the QoSC FSM verifies that the reconfigured managed application is not yet fulfilling the respective QoS level, thus reaching an unstable yet contract-unfulfillment state; C EXCEPTION: being unable to find a matching rule to apply, or finding and applying am a t c h i n gr u l et h a tp r o d u c e s an invalid reconfiguration, or facing an unspecified context event, the QoSC FSM is left in an exception state.

Based on the three target super-states, Fulfilled, Unstable,andException,andtheirgeneralized transition conditions, we define our QoSC FSM transition function as follows.

Definition 8 (QoSC FSM Transition Function). The transition function δ : Σ×∆ U →{Fulfilled, Unstable, Exception} (cf. Def. 7) defines output states depending on the context event (e)r eceived from context monitors, and the execution context (∆):

δ(e, ∆) =                                                  Fulfilled * if e ∈ Σ ⊼ ∃s, r : s ∈ STATES, r ∈ Γ | r ∈ ρ(s | e ∈ η(s)) match(r, ℜ(s | e ∈ η(s)))⊼ recon f ig(ℜ(s | e ∈ η(s)),ρ(s | e ∈ η(s))) ⊼ evalInContext(Ψ(s | e ∈ η(s)), ∆) = F Unstable if e ∈ Σ ⊼ ∃s, r : s ∈ STATES, r ∈ Γ | r ∈ ρ(s | e ∈ η(s)) match(r, ℜ(s | e ∈ η(s)))⊼ recon f ig(ℜ(s | e ∈ η(s)),ρ(s | e ∈ η(s))) ⊼ evalInContext(Ψ(s | e ∈ η(s)), ∆) = U Exception if e ∈ Σ ⊼ ∃s : s ∈ STATES |∀r : r ∈ ρ(s | e ∈ η(s)) ¬match(r, ℜ(s | e ∈ η(s))) ⊻ e ∈ Σ ⊼ ∃s, r : s ∈ STATES, r ∈ Γ | r ∈ ρ(s | e ∈ η(s)) match(r, ℜ(s | e ∈ η(s)))⊼ ¬recon f ig(ℜ(s | e ∈ η(s)),ρ(s | e ∈ η(s))) ⊻ e ∈ Σ U \ Σ
For the target Fulfilled * state, s | e ∈ η(s)i st h ea c t u a lQ o S -l e v e ls t a t eo ff u l fi l l m e n t ,w h i l e Ψ(s | e ∈ η(s)) the corresponding QoS-level predicate to be satisfied. Σ U ,asdefinedpre viously , is the set of all possible context events that can be reported from context monitors.

Automatic Synthesis of QoSC FSM

To take full advantage of QoSC FSM in practical terms (i.e., in actual running software systems), our denotational semantics for QoS contracts must be executable. Algorithm 1 obtains the QoSC FSM denotation from a QoS contract instance by creating the states of contract fulfillment, adding the states of contract unfulfillment, and defining the mappings for the auxiliary functions and structures. These instances are specified in XML files using Eclipse or the AGG software tool with the CBSTYPE TAG definition as document type. Thus, this algorithm produces correct-by-construction QoSC FSM with respect to the QoS contract typing specification.

QoSC FSM Execution

We characterize the execution state of the QoSC FSM as a binary relation (i.e., a vector) between QoS properties and respective QoS levels. 7Definition 9 (QoSC FSM Execution State -QES). Given QoSC a QoS contract instance, and CBSAR the component-based structure application reflection states u b j e c tt oQ o S C ,t h eQ o S C FSM execution state is the tuple CURS TATE, CBSAR ,w h e r eC U R S T A T Ei st h eb i n a r yr e l a t i o n QoSC.property×(QoS C.property.obligation.SLOPredicate∪{Exception, Unstable})suchthat each QoS property appears exactly once in these pairs, related either to one of its corresponding QoS levels, or to the exception or unstable state.

That is, CURS TATE is defined by the set of pairs (QoS-property, QoS-level) for each QoS property in the contract. Each pair relates a QoS property either to its current QoS level state, if this is fulfilled by the managed application, or to the exception or unstable state, if unfulfilled. Algorithm 2 illustrates the QoSC FSM execution control block, which is executed in response to reconfiguration context events.

In the RVCS system of our application scenario, the contract defines a QoS property of confidentiality (cf. Table 1a). Thus, π = {(clearChannel, Con fidentiality), (con f identChannel, Con fidentiality), (localCache, Con fidentiality)}.Wheninitiallyexecutedfromanintranet-serviced area, the QoSC FSM execution state is CURS TATE = {(Con fidentiality, clearChannel)}.T h e n , when the software client moves into an extranet-serviced area, the QoSC FSM executor is invoked. Line 1 performs the state transition using the δ function and reconfigures CBSAR. Line 2 updates the QoSC FSM execution vector state (i.e., CURSTATE)onthepropertyaffected by e (i.e., π(s | e ∈ qfsm.η(s))), with the state returned by δ.W eus et henot a t i onqes.CURS TATE[p] ← s to express that the QoS property p is associated with s in the relation CURS TATE.H e n c e ,t h e execution state transitions into CURS TATE = {(Con fidentiality, con f identChannel)}.

However, given that the reconfiguration operates on CBSAR andv e r i fi e si t sc o m p o n e n tbased structural conformance before instrumenting the respective changes in the managed application, CBSAR is left inconsistent when this verification fails (i.e., the transition resulted in the Exception state as a result from the application of a faulty reconfiguration rule). In this case, line 4recoversthepre viousstateofCBSARfromtherunningmanaged application. Otherwise, the changes in the CBSAR are instrumented in the running system.

Finally, as the reconfiguration depends on the matching operation between reconfiguration rules and the managed application reflection structure, maintaining CBSAR updated allows further reconfiguration cycles in the managed application. In effect, even if it reaches an Exception state, as the managed application is left unmodified by the reconfiguration mechanism, this is not an impediment for its services to continue with their operation, although in a contract unfulfillment state. On the next context event, as CBSAR reflectsthecurrentstateofthemanaged application, and thanks to our generalized conditions for transitions to target states, a reconfiguration cycle can be performed with no special considerations.

The QoS Contract-Preserving Reconfiguration System

As we mentioned previously, the final objective of the previous definitions is the autonomous and reliable preservation of QoS contracts under varying context conditions. Contract preservation is defined in terms of continuous reconfiguration cycles that start and end in actual running software applications, triggered by context changes, such that the software applications fulfill the expected QoS levels under the different context situations. To complete the realization of our QoSC FSM as the semantics of our QoS contract definition, we define our QoS contract-preserving reconfiguration system, based on the previous definitions.

Definition 10 (QoS Contract-Preserving Reconfiguration System -QoSCRS). The QoS contract preserving reconfiguration system, QoSCRS, is the tuple CBSAR, QoS C, CBSRS, QoSC FSM , where CBSAR is the reflection structure of the managed application subject to the contract QoSC; CBSRS the component-based reconfiguration system; and QoSC FSM the state-machine for QoSC,allofthemaccordingtotheirrespecti vedefinitions. Onthis tuple, we define a QoS contract-preserving reconfiguration cycle as:

1. (When to reconfigure) Amanagedsoftwareapplicationreconfigurationistriggeredwhenever the QoSMonitor specified in the contract, QoSC.monitor,n o t i fi e sac o n t e x te v e n te that challenges the fulfillment of the current QoS level.

(What,

Where and How to reconfigure) From the contract denotation QoSC FSM and based on the context event e received, the affected QoS property (i.e., π(s | e ∈ η(s))) is identified. Then δ,thetransitionfunctionisin voked,identifyingthetargetstatetobereachedunder the new context situation (i.e., s | e ∈ η(s)). Also, the corresponding QoS-level predicate and guaranteeing reconfiguration rule-set for this state arer e t r i e v e d( i . e . ,Ψ(s | e ∈ η(s)) and ρ(s | e ∈ η(s)), respectively). With this, a state transition in the managed application reflection structure is induced, thus performing a reconfiguration CBSAR * ⇒ CBSAR ′ using the component-based reconfiguration system (i.e., recon f ig(CBSAR,ρ(s | e ∈ η(s)))). From this, a reconfiguration plan is synthesized (cf. Def. 6).

(Pre-update checks)

Once obtained CBSAR ′ ,thecomponent-basedstructuralconformance check is performed on it. We specify the corresponding conditions in Section 6.1. The verification of these conditions is performed in the reconfig function, and hence, their violation would lead to a contract unfulfillment state (with the respective notification to the user).

(Managed-application reconfiguration update)

If the new managed application reflection structure CBSAR ′ satisfies the pre-update checks, the synthesized reconfiguration plan is applied to the running managed application. Otherwise, the managed application is left without modifications, and the user notified. In any case, both, the contract state and the running-software state are updated in consequence, in the QoSC FSM execution state. In this way, the atomicity property is guaranteed, as detailed in Section 6.2.

Given the generic conditions that we established in the semantics of our QoSC FSM incoming transitions for target states, the user must only specify theQoSlevels(i.e.,theFSMstates)with the required guaranteeing reconfiguration rules (i.e, the incoming transitions for the specified states). That is, the user implicitly select the source states of the transitions by encoding the patterns associated to these states in the LHS of the reconfiguration rules.

QoS-CARE Reconfiguration Properties

In this section we analyze the properties of our QoS contract-preserving reconfiguration system, as a realization of the formal semantics presented previously.

Component-Based Structural Conformance

This property is defined as the conformance of the managed application with respect to the structural integrity constraints defined by the component-based (SCA) specification. This property must be preserved after each reconfiguration. The verifiability of full CB-structural compliance naturally results from Def. 2 and 3. Referred to our example scenario, it is straightforward to verify thatthespecifiedconditionsaresatisfied by the system reflection structures presented in Figure 6 and 10.

Atomic Reconfiguration

Atomicity in self-adaptive software systems is the propertysuchthat,eitherthereconfiguration (adaptation) process finishes successfully and the system is reconfigured, or it fails and the system preserves its (previous) configuration and state. Ourproofforthispropertyisasfollows.

Our strategy to apply design patterns to preserve QoS contracts is based on component-based software reconfiguration. Nonetheless, following steps 1 and 2 of our QoS Contract-Preserving Reconfiguration System (Def. 10), we first perform the reconfiguration on a graph model of the actual managed application and obtain a reconfiguration plan(Def.6).Instep3thereconfigured graph model is verified in its Full CB-Structural Conformance,andinstep4theactualmanaged application is reconfigured by instrumenting the reconfiguration plan in it. In addition, the Full CB-Structural Conformance is the only verification defined and managed in our semantic model that could make the reconfiguration fail.

Therefore, given that QoS-CARE performs a reconfiguration in the actual running managed application only if the Full CB-Structural Conformance verification succeeds, it is easy to conclude that QoS-CARE guarantees the atomicity of the reconfiguration process.

Reconfiguration Termination

Heckel et al. and Ehrig et al.,amongothers,showedseveralgraphtransformationtheorems and results on termination conditions as valid also for typeda t t r i b u t e dg r a p ht r a n s f o r m a t i o n systems (TAGTS) in [START_REF] Heckel | Confluence of typed attributed graph transformation systems[END_REF], [START_REF] Ehrig | Fundamental theory fort y p e da t t r i b u t e dg r a p ht r a n s f o r m a t i o n , i n : P r o c[END_REF], and [START_REF] Ehrig | Fundamentalso fA l g e b r a i cG r a p hT r a n s f o r m a t i o n ,S p r i n g e r -V e r l a g[END_REF]. In this section, we show that the CBS reconfiguration step of our component-based structure reconfiguration system (i.e., G 0 * ⇒ G n in CBSRS, Def. 6), is reducible to a typed attributed graph transformation system, as defined in [START_REF] Ehrig | Fundamentalso fA l g e b r a i cG r a p hT r a n s f o r m a t i o n ,S p r i n g e r -V e r l a g[END_REF]. As a result, the aforementioned theorems on termination properties are also valid for our reconfiguration system. In particular, we use the criteria established by Taentzer and others in [START_REF] Taentzer | AGG: A Graph Transformation Environment for Modeling and Validation of Software[END_REF][START_REF] Bucchiarone | Self-repairing systems modeling and verification using agg[END_REF][START_REF] Ehrig | Formal analysis and verification of self-healing systems[END_REF] to determine whether the CBS reconfiguration step with the user-defined reconfiguration rules in our reconfiguration system is terminating, contributing to its reliability.

Contract Robustness

Contract robustness with respect to context unpredictability requires guaranteeing the delivery of the agreed managed software application services on any of the managed application states, that is, even in states that differs from the expected ones. These states are those defined in the QoS contract with respect to the context situations, asspecifiedbytheuser .Therefore,to show that QoS-CARE guarantees robustness, it is sufficient to show that the QoS-CARE model, QoSC FSM ,considersallofthepossiblestatesthatamanagedsoftwareapplicationcanreachinits execution with respect to the QoS contract to satisfy (i.e., for both, the foreseen context situations to be faced by the managed application, and also for those unforeseen by the user).

Theorem 2 (Contract robustness with respect to context unpredictability). Let Q be a QoS contract according to Def. 4. QoSC FSM considers all of the possible states that a managed software application M, subject to Q, can reach in its execution.

Proof. Let Z be the set of all possible states of execution that M can reach,a se v a l u a t e dw i t h respect to the QoS levels defined in Q.T he n,fore v e ryz ∈ Z, z is considered by QoSC FSM ,given that 1. by Def. 4, Q defines a set of expected QoS levels, F,tobefulfilledbyM;and 2. by Algorithm 1, a QoSC FSM q is obtained from Q,suchthatitsstates,q.STATES,isinitialized with the set F of fulfillment states, and the corresponding conditions of fulfillment in q.Ψ (lines 2-16); and 3. by lines 18-19 of Algorithm 1, the Unstable and Exception states are added to q.STATES; and 4. by Def. 8 (the QoSC FSM transition function), δ : Σ×∆ U →{Fulfilled, Unstable, Exception}, that is, δ : Σ × ∆ U → F ∪{Unstable, Exception},has3generalconditionsforeachofits target transitions, depending on the context event (e)recei vedfromcontextmonitorsand the execution context (∆)ofM,whichimplythattheexecutionstateofM,z,asevaluated with respect to the QoS-level conditions q.Ψ:

(a) z ∈ F is a fulfillment state given that it satisfies one of the QoS levels defined in

F, that is, if e ∈ Σ ⊼ ∃s, r : s ∈ STATES, r ∈ Γ | r ∈ ρ(s | e ∈ η(s)) match(r, ℜ(s | e ∈ η(s))) ⊼ recon f ig(ℜ(s | e ∈ η(s)),ρ(s | e ∈ η(s))) ⊼ evalInContext(Ψ(s | e ∈ η(s)), ∆) = F (cf. condition (1), Sect. 5.1.3); or (b) z = Unstable if e ∈ Σ⊼∃s, r : s ∈ STATES, r ∈ Γ | r ∈ ρ(s | e ∈ η(s)) match(r, ℜ(s | e ∈ η(s))) ⊼ recon f ig(ℜ(s | e ∈ η(s)),ρ(s | e ∈ η(s))) ⊼ evalInContext(Ψ(s | e ∈ η(s)), ∆) = U (cf. condition (2), Sect. 5.1.3); or (c) z = Exceptionif e ∈ Σ⊼∃s : s ∈ STATES |∀r : r ∈ ρ(s | e ∈ η(s)) ¬match(r, ℜ(s | e ∈ η(s))) ∨ (e ∈ Σ U \ Σ) ∨ e ∈ Σ ⊼ ∃s, r : s ∈ STATES, r ∈ Γ | r ∈ ρ(s | e ∈ η(s)) match(r, ℜ(s | e ∈ η(s))) ⊼ ¬recon f ig(ℜ(s | e ∈ η(s)),ρ(s | e ∈ η(s))) (cf. con- dition (3), Sect. 5.1.3).
In conclusion, any of the possible states, z,ofMthatcanbereachedinitsexecution(z ∈ Z) is either fulfilling one of the QoS levels specified in Q,ornotfulfillinganyofthem,whiche ver this state z is. For this latter case, QoSC FSM classifies these possible states as either Unstable or Exception.

In other words, the expected states of fulfillment are the states corresponding to the QoS levels defined by the user in QoS contracts. These QoS levels are specified for each of the context conditions that the managed application can face in its execution, as foreseen by the user. However, given the unpredictable nature of context changes, it is easy to presume that the user can underestimate them (or omit them). Of course, this underestimation or omission originates the possibility for the managed application to reach unexpectedandundesirablestates. Nonetheless, even in these states the managed application is under controlled states (i.e., Exception or Unstable) that are automatically generated by our semantic model.I nt h i sw a y ,Q oS-CARE considers all of the possible states, with their respective transitions, that a managed software application can reach in its execution, with respect to its context (i.e.,asspecifiedinQoScontracts).Hence, we can conclude that the robustness conditions are realized in our QoS contract semantics, as part of our reconfiguration mechanism.

QoS-CARE Practical Feasibility

In contrast to other formal-based approaches, an important goal in the realization of our QoS contract semantics is an analysis of its practical feasibility, beyond analyzing its formal properties. This implies not only to show the approach applicability with a plausible example in the abstract (formulae) world, but building a systematic bridge between the abstract and actual running software world. Building this systematic bridge is not a trivial task. In fact, the key difference between the restricted applicability of a formal approach to a particular example and its generalized applicability to any software application demands the formulation of the approach as a sound and general semantics for the target artifacts of application, as presented in this paper.

To evaluate its applicability, we use QoS-CARE to preserve QoS contracts in three software applications with different sizes in a significant scale, and execute them in different configuration scenarios with the FraSCAti SCA runtime platform [START_REF] Seinturier | Reconfigurable SCA Applications with the FraSCAti Platform[END_REF]. In particular, we analyze two aspects. First, the effect size produced by the size of the managed software applications in the reconfiguration effort required to be managed in QoS-CARE. Second, we measure its mean-time to reconfigure (MTTR) the managed applications by executing a benchmark of experiments on the configuration scenarios, as a way to evaluate QoS-CARE's settling-time.

The first software application corresponds to a complete version of the example used through this paper, that is, the mobile RVCS system subject to a QoS contract on availability.Thesecond is a Web mashup application that dynamically composes and orchestrates the location service of Twitter8 with a weather web service from different weather information providers, such as Google 9 ,Y a h o o 10 ,a n dW e b S e r v i c e X 11 to improve the service readiness.T h et h i r di sa nR M I generic scalable sorting service subject to a QoS contract oncomputing-resourcesconsumption.

For each of the configured scenarios, we present the effect size of the managed SCA software application in terms of QoS-CARE reconfiguration rules, and the experimental MTTRs measured from their execution. The complete description of the scenarios, including the application software with the corresponding QoS contracts and thea n a l y s i so ft h et e r m i n a t i o na n d consistency of the corresponding reconfiguration rules, arepresentedin [START_REF] Tamura | QoS-CARE: A Reliable System for Preserving QoS Contracts through Dynamic Reconfiguration[END_REF].

Effect Size of Managed Application Sizes

The effect size of the managed applications sizes in the QoS-CARE effort required to reconfigure them are summarized in Table 3. The managed applicationsizesareexpressedintermsof the application's number of SCA components, Java classes/interfaces, and physical lines of Java code (LOCs). Their effect size in QoS-CARE is expressed in terms of the number of reconfiguration rules required to satisfy their corresponding QoS contracts. 12Counting LOCs for Java programs is not a trivial task, in part because there is no agreement on the counting procedure apart of counting physical lines including or not blank lines and comments (e.g., compare the Eclipse Metrics 13 and the CodePro AnalytiX14 projects). Additionally, in our case, the counting procedure has to deal also with SCA annotations in the Java code, and with the definition of SCA components written in XML, not mentioning that the FraSCAti middleware abstracts the implementation of crucial functionalities such as the intricacies of the invocation of remote procedures/methods for distributed components. Considering all these details, we count physical lines including comments and SCA annotations but not blank lines, for the Java files. We exclude the higher-level constructions andd e fi n i t i o n so fS C Ac o m p o n e n t s , but also the SCA middleware effects in the Java code, by not counting their lines but only the number of SCA components. Finally, to have an idea of the relationship between the number of SCA components and Java classes and interfaces, and also between Java classes and LOCs, we also counted the number of Java classes and interfaces.

The varying sizes of the managed SCA software applications int h et a b l e ,c o m p a r e dt ot h e number of reconfiguration rules required to satisfy their respective QoS contracts, show the applicability of QoS-CARE as independent of its managed application size. This applicability results from our semantic approach, which systematically processes the computational state of the managed application at runtime to build the graph model that QoS-CARE uses to transform and operate on. By virtue of the reconfiguration plan it synthesizes, the managed application is systematically and correspondingly transformed.

Reconfiguration Settling-time and Overhead

To measure the settling-time (MTTR) we used a set of benchmarks based on reconfiguration operations for each of the application scenarios, similar tot h eo n ed e s c r i b e di nS e c t i o n3 . W e used a context-events simulator to generate events notifying changes in each case, for instance changing the user's network access, from the intranet to the extranet, and vice versa, in the RVCS application. All of the experiments were performed on Intel i5@2.53Ghz processors with 4Gb of RAM running Mac OS X 10.6, using FraSCAti 1.4 with Java 1.6.0_23 allocated with 256MB of heap size. Table 4 presents the evaluation objective for each benchmark's configured scenario and the corresponding measured times. These objectives were selected considering the most representative operations on each case. Each scenario was executed 1,000 times. The obtained results confirm the applicability of QoS-CARE. On the one hand, the reconfiguration settling-times (MTTR) are small, between 157 and 876ms. On the other hand, compared to response times of regular Internet services, the overheadi n t r o d u c e db yQ oS-CARE, while running the managed applications in FraSCAti,isnegligible(3ms). of components and corresponding connectors, which determine particular levels of QoS properties. These design patterns are matched against (and replaced in) the software system structure, whose structure is not predefined. Finally, the referred proposal targets software systems with a static structure, that is, whose structure does not change atruntime(i.e.,theworkflo wgi venby the user is immutable at runtime). QoS-CARE targets dynamically self-reconfigurable software systems, and to support this reconfiguration capability at runtime it provides in its architecture the components to monitor, analyze, plan, and execute the structural modifications in the managed system that are required to fulfill a particular level of a QoS property.

From the formal semantics point of view, Fiadeiro and Lopes [START_REF] Fiadeiro | A model for dynamic reconfiguration in service-oriented architectures[END_REF] present a formalization for the dynamic reconfiguration of business process workflows in terms of service discovery, binding, and orchestration operations for the SOA domain. They propose several levels of abstraction, using different formalisms (linear-time logic, graphs, and partial algebras) at each level, to model the structural and behavioural corresponding aspects. The formalization is then proposed as a semantic domain with a corresponding operational semantics that enables an architecturedescription language (ADL) to be extended with dynamic reconfiguration operations. Braga et al. [START_REF] Braga | A formal semantics foraqualityofservicecontractlanguage[END_REF] formalize the semantics of a QoS contract language using operational calculus rules driven by a state machine. To guarantee the satisfaction of QoS constraints on the resulting states, they translate QoS specifications to the Maude model checking tool. As in QoS-CARE, this semantics considers actual monitored context conditions in its transitions.

QoS-CARE shares with these latter approaches the formalization of QoS properties and contract semantics, but differs from them by guaranteeing robustness. Moreover, our characterization of unstable states constitutes a strategy for detecting (and acting upon) the problem of reaching stability, as explained in previous sections. We evidence this problem in oscillations failing to fulfill a given QoS level from our runtime-monitored context evaluation in reconfiguration transitions. Nonetheless, the stability problem remains a majorc h a l l e n g ef o rc o n t r o l l i n gs o f t w a r e self-adaptation still asking for a general solution, as identified by Hellerstein et al. [START_REF] Hellerstein | Research Challenges in Control Engineering of Computing Systems[END_REF].

Conclusion

In this paper we have presented the definition, implementation, and evaluation of a twolayered denotational semantics for QoS contract preservation in component-based software systems under changing context situations, which guarantees reliability and robustness.

In the governing layer of this semantics we interpret a QoS contract as an extended FSM, with QoS-level conditions as states, and reconfiguration rules as transitions. The extended FSM guarantees contract robustness with respect to context unpredictability by characterizing the transitions and states of contract fulfillment and unfulfillment.Intheoperatinglayer ,FSMstatesare mapped to software structures denoted as TAGs, and transitions to software re-configurations through extended TAG transformation systems. The extended transformation system makes it possible to exploit design patterns at runtime, despite they have been applied until now at designtime to determine quality attributes. We implemented this contract semantics in QoS-CARE, a framework for developing context-aware and self-adaptive mechanisms, that is able to execute and reconfigure component-based software applications for fulfilling its associated QoS contracts in an autonomous, reliable and robust way. Thus, given a QoS contract, QoS-CARE process it as the high-level policy that governs the behavior of its reconfiguration mechanism over the managed software to maintain fulfilled its expected QoS levels.

The relevance of our two-layered denotational semantics forQoScontractsisthreefold.First, it generalizes the applicability of QoS-CARE by providing denotations for QoS contract ele-ments and software structures, systematically. Second, it bridges the formal (abstract) and actual running-software worlds with a function that translates the SCA structure of a software in execution to its operating denotation. Third, given a QoS contract, it guarantees atomicity and robustness, and verifies the reconfiguration terminationa n dc o m p o n e n t -b a s e ds t r u c t u r a lconformance conditions. Additionally, our evaluation results of the actual implementation of our formal semantics in the QoS-CARE framework, as applied to three application scenarios, show its practical feasibility, usability, and applicability.

As worth of future work, we consider three important aspects of our contribution. First, the formalism for specifying reconfiguration rules in QoS-CARE requires adequate training, despite the current graph-tools support. In order to make QoS-CARE more usable by non-experts we are developing a more legible and usable concrete syntax to specify these rules. The idea is to define a domain-specific language (DSL) with automated tools to assist the user in the writing of these rules in a more familiar notation, such as the used forcomponent-basedapplicationsin SCA. Second, on leveraging design patterns at runtime, not only to address QoS contracts as we showed with QoS-CARE, but also with other purposes. For instance, design-patterns at runtime could help to develop behaviour models to predict stability and efficient resource use in selfadaptive software systems. Finally, on improving contract robustness to context unpredictability. The states of contract unfulfillment managed by QoS-CARE constitutes only one step towards understanding how to achieve general robustness to context uncertainty and related problems of self-adaptation. For instance, as mentioned before, our unfulfillment-unstable state address the stability problem by detecting unstability, although not preventing it.

Table 1 :

 1 QoS contractual conditions and corresponding Service-Level Objectives (QoS levels) for: (a) Confidentiality (based on corporate network access) (b) Availability (based on bandwidth in kbit/s)

Figure 2 :

 2 Figure 2: QoS contract semantics in practice. The two layers of denotations for the running-system configurations (e.g., R1 and R2) are shown here vertically as I-TAGs (e.g., G1 and G2); and II-QoSC FSM (e.g., C1 and C2).

Figure 3 :

 3 Figure 3: (a) TAG definition and (b) TAG morphism t between TAGs G and H. Next, to ensure the conformity of TAG-based software structures with respect to the CBD specification, we define the component-based structure type,CBSTYPE TAG . Definition 2 (CBSTYPE TAG ). The component-based structure type, CBSTYPE TAG ,isthetuple (G, DS ig), where: • DS ig is a data signature over the disjoint union Integer + String + Inter faceS ignature + Inter faceRole, Inter faceRole = {Provided, Required},withtheusualCBDinterpretations;• G is the TAG (V 1 , V 2 , E 1 , E 2 , E 3 , (source i , target i ) i=1,2,3 )suchthatV 1 = {Component,Inter face, Binding};e a c ho ft h ed a t an o d e si nV 2 is named after its corresponding sort in DS ig, V 2 = Integer + String+ Inter faceS ignature + Inter faceRole; E 1 = {ifc, provided, required}; E 2 = {cname, iname, role, signature, c_QoS Provision, i_QoS Provision, ct_QoS Provision, cmultiplicity, imultiplicity, bmultiplicity}; E 3 = {ifcmult, pmult, rmult}; and functions (source i , target i ) i=1,2,3 as depicted in Figure 4

Figure 4 :

 4 Figure 4: The CBSTYPE TAG definition. The Integer type and mult attributes, for multiplicity constraints, are presented in the usual (short) notation.

Figure 5 :

 5 Figure 5: Runtime component-based structure application for Example 1 with a clear channel connection.

Figure 6 :

 6 Figure 6: TAG denotation for the component-based structure of the running application depicted in Figure 5.

Figure 7 :

 7 Figure 7: The TAG definition for the QoS Contract Type. The Integer type and mult attributes, for multiplicity constraints, are presented in the usual (short) notation.

Definition 5 (

 5 CBS Reconfiguration Rule). Ac o m p o n e n t -b a s e ds t r u c t u r er e c o n fi g u r a t i o nr u l e is defined as p = (LCBS TAG , KCBS TAG , RCBS TAG , l, r, lt, kt, rt), abbreviated p = (LCBS TAG l ←-KCBS TAG r -→ RCBS TAG ), where LCBS TAG (left hand side), KCBS TAG (left-right gluing), and RCBS TAG (right hand side) are TAGs related through graph morphisms l, r.T h e g r a p h m o rphisms lt : LCBS TAG → CBSTYPE TAG , kt : KCBS TAG → CBSTYPE TAG and rt : RCBS TAG → CBSTYPE TAG ensure that the rule involves only component-based structures. The rule p is said to reconfigure LCBS TAG into RCBS TAG .

Figure 8 :

 8 Figure 8: The R_clearChannel reconfiguration rule-set.

Figure 9 :

 9 Figure 9: The reconfiguration rule-sets for the confidentiality contract.

1 .

 1 (What and Where to reconfigure) The rule-set P is applied to the managed application reflection structure CBSAR = (CBS TAG , t)bygraph-basedpatternmatching.Thatis,foreachreconfiguration rule p = (L l ←-K r -→ R)inP,wedeterminewhethertheree xistsamatchof p in CBS TAG .T od ot h i s ,w ed e fi n et h eb o o l e a nmatch(p, CBSAR) function, which returnsTrue if there exists a morphism m : L → CBS TAG (called a matching of L in the CBS TAG element of CBSAR), and False otherwise. This matching determines the CBS TAG potential elements to be reconfigured in the managed application.

2 .

 2 (How to reconfigure) We call a direct reconfiguration G p,m ⇒ G ′ the application of the TAG transformation of G into G ′ ,asspecifiedbythereconfigurationrulep,accordingtoDef.5. 3. (CBSAR reconfiguration step)Finally ,theCBSARreconfigurationisperformedthroughthe recon f ig(CBSAR, P)operation.Thisoperationisdefinedasthesequenceofdirect reconfigurations of the CBS TAG element of CBSAR, CBS TAG

Figure 10 :

 10 Figure 10: TAG for the reflection system structure reconfigured with rule intra2extra.T h ec o m p o n e n t st h a tw e r e added and deployed by the applied reconfiguration rule are highlighted.

Figure 11 :

 11 Figure 11: Reconfigured running software structure corresponding to the CBS TAG of Figure 10.

Definition 11 (

 11 Full CB-Structural Conformance). Aruntimesystemreflectionstructure,CBSAR, is full CB-structural conformant iff its CBS TAG is a component-based structure (i.e., there exists agraphmorphismt :CBS TAG → CBSTYPE TAG ), and the following conditions hold: 1. ∀b1, b2 (b1, b2 ∈ CBS TAG .Binding∧b1.provided = b2.provided∧b1.required = b2.required) =⇒ b1 = b2 :e v e r yb i n d i n gm u s tc o n n e c td i fferent pairs of provided-required services. 2. ∀b∃i, j b ∈ CBS TAG .Binding ∧ i, j ∈ CBS TAG .Inter face ∧ i j ∧ b.provided = i ∧ b.required = j ∧ i.signat = j.signat :e a c hb i n d i n gc o n n e c t sd i fferent services that, nonetheless, have the same interface. 3. ∀i(i ∈ CBS TAG .Inter face =⇒∃ c(c ∈ CBS TAG .Component ∧ (c.ifcp = i ∨ c.ifcr = i))): every service must belong to some component. 4. ∀i∃c (i ∈ CBS TAG .Inter face ∧ c ∈ CBS TAG .Component ∧ c.ifcr = i) =⇒∃ b, j, d(b ∈ CBS TAG .Binding ∧ b.required = i ∧ b.provided = j ∧ j ∈ CBS TAG .Inter face ∧ d ∈ CBS TAG .Component ∧ d.ifcp = j ∧ c d) :al ls ervi cesrequi redbyacomponentmus tbe bound to services provided by another component.

Theorem 1 (

 1 Reducibility of CBS ReconfigurationStep). Let CBS RS be a component-based structure reconfiguration system according to Def.[START_REF] Becker | Quality of Service Modeling Language[END_REF]. A CBS reconfiguration step in CBS RS is reducible to a typed attributed graph transformation system, T AGT S .Proof. According to Def. 6, a CBSRS is a tuple (DS ig, CBSTYPE TAG , CBSAR, P). Of these elements, during the CBS reconfiguration step (i.e., G 0 * ⇒ G n ), the data signature, DS ig,t h e component-based structure typing definition, CBSTYPE TAG ,andthesetofreconfigurationrules P remain unchanged. Therefore, in a CBS reconfiguration step these elements can be omitted, depending only on the system reflection structure, CBSAR, andthesetofreconfigurationrules, P.G i v e nt h a t 1. a Component-Based Structure Application Reflection (CBSAR, Def. 3) is a tuple (CBS TAG , t), where CBS TAG is the TAG that denotes the component-based structure of the managed system CBS through the one-to-one function f :CBS→ CBS TAG ,andt is the TAG morphism t :C B S TAG → CBSTYPE TAG ,h e n c ei nt h eCBS reconfiguration step,t hede fi ni t i onof f remains also unchanged; and 2. a typed attributed graph is a tuple (AG, u), where AG is an attributed graph over a data signature TAGDSig,andu is an attributed graph morphism, u : AG → ATG,whereATG is a type graph; and 3. a component-based reconfiguration rule, p,accordingtoDef.5,isatuple(L, K, R, l, r, lt, kt, rt),p = (L l ←-K r -→ R),with lt : L → CBSTYPE TAG , kt : K → CBSTYPE TAG and rt : R → CBSTYPE TAG ;and 4. the typed attributed graph transformation rules are graphrewritingproductionsq = (X ), X, Y, Z graphs; and 5. both, the TAG system reflection structure CBS TAG and the typed attributed graphs are based on the same TAG definition, then, a CBS reconfiguration step can be reduced to a typed attributed graph transformation system, TAGTS,bymakingTAGDSIG = DS ig, AG = CBS TAG and ATG = CBSTYPE TAG .T h e TAGTS set of transformation rules can be defined as the set of component-based reconfiguration rules without the lt, kt, rt morphisms, given that, once defined the component-based reconfiguration rules, these morphisms are also unchanged.

Table 2 :

 2 Guaranteeing rule-sets for the QoS contract exampleonconfidentiality

	Context Events	Expected QoS Level	Guaranteeing Rule Set
	1: from_intranet	clearChannel	R_clearChannel
	2: from_extranet	confidentChannel	R_con f identChannel
	3: no_Network	localCache	R_localCache
		Responsibilities
	-SystemGuarantor:	System.NetAdapter a
	-ContextMonitor:	System.NetAdapter_AccessPointProbe b

a The component providing the network connection with required QoS conditions. b The component responsible for checking changes on the accesspointsusedbythe application network connection, and corresponding confidentiality violations.

Algorithm 1

 1 QoSC FSM _from_QoS_Contract Input: qosContract : QoS C /*QoSCfromDef.4*/ Output: qfsm : STATES, start, ACC EPT, Σ, Γ, Ψ,κ,η,ρ,ℜ,π,CBSRS /*QoSC FSM ,Def.7*/ 1: Initialize STATES, Σ, Γ, Ψ,κ,η,ρ,πwith {} 2: for all qosProp ∈ qosContract.C.property do

	3:	for all sloOblig ∈ qosProp.obligation do
	4:	curS tate ← make_indexed_state(sloOblig.SLOPredicate)
	5:	qfsm.STATES ← qfsm.STATES ∪{curS tate}/*buildalltheFSMstates*/
	6:	qfsm.Σ ← qfsm.Σ ∪ sloOblig.contextEvT ype /*theFSMevents*/
	7:	qfsm.Γ ← qfsm.Γ ∪ sloOblig.ruleS et /*andtheFSMreconfigurationrules*/
	8:	qfsm.Ψ ← qfsm.Ψ ∪{(curstate, sloOblig.SLOPredicate)}/*representedpredicate*/
	9:	qfsm.κ ← qfsm.κ ∪{(curstate, sloOblig.contextCondition)}/*contextcondition*/
		/*Then,fortheFSMtransitions:indexandassociate:*/
	10:	eventS et ← make_indexed_set(sloOblig.contextEvT ype) /*theevents*/
	11:	ruleS et ← make_indexed_set(sloOblig.ruleS et) /*andassociatedruleSet*/
	12:	qfsm.η ← qfsm.η ∪{(curstate, eventS et)}
	13:
	15:	end for
	16: end for
	17

qfsm.ρ ← qfsm.ρ ∪{(curstate, ruleS et)} 14: qfsm.π ← qfsm.π ∪{(curstate, qosProp)}

:

  qfsm.ACC EPT ← qfsm.STATES 18: qfsm.STATES ← qfsm.STATES ∪ make_indexed_state(Exception) 19: qfsm.STATES ← qfsm.STATES ∪ make_indexed_state(Unstable) 20: return qfsm Algorithm 2 QoSC FSM transition executor Input: e : Σ U , qes : QES, qfsm :QoSC FSM /* QES from Def. 9, QoSC FSM from Def. 7 */ Output: qes transitioned on the property affected by e,usingδ (Def. 8)

	4:	qes.CBSAR ← getC BS AR() /*recoverthepreviousstateofCBSAR*/
	5: else /*CBSARsuccessfullyreconfiguredinadvancew .r .t.themanaged application */
	6:	instrument_reconfiguration_plan_in_runtime_platform()
	7: end if
	8: return qes

1: S ′ ← δ(e, qfsm.∆) 2: qes.CURS TATE[π(s | e ∈ qfsm.η(s))] ← S ′ 3: if S ′ == Exception then /*reconfigurationproblems*/

Table 3 :

 3 Size of managed applications and its effect size in QoS-CARE reconfiguration rules

	Managed Application	Application Element	Components	Classes and Interfaces	LOCs of Classes	Reconfig. Rules
		Monitoring Elements	1	1	84
	RVCS	Application Logic	6	148	23,799	6
		Total	7	149	23,883
		Monitoring Elements	1	1	63
	Web Mashup	Application Logic	4	24	1,512	3
		Total	5	25	1,575
	Scalable	Monitoring Elements	1	1	71
	Sorting	Application Logic	3	6	1,032	2
		Total	4	7	1,103

Table 4 :

 4 Settling-time (MTTR) Benchmark Scenarios and Results

		Evaluation Objective in Configured Scenario	Time (msec.)
		Local component deployment/undeployment a	49
		Local reconfiguration (total MTTR local) a	634
	RVCS	"Remote" reconfiguration (total MTTR over loopback) a	640
		Remote reconfiguration (total MTTR over Internet) b	876
		QoS-CARE overhead (simulating 1 dummy event/3sec.)	3
		CBS TAG from FraSCAti's SCA domain translation	15
		CBS TAG transformation (one rule application)	14
	Web Mashup	Reconfiguration plan transmission (473 bytes, 15 lines) Reconfiguration plan execution	81 47
		Total mean-time to reconfigure (MTTR) c	157
		QoS-CARE overhead (simulating 1 dummy event/3sec.)	3
		Remote component deployment d	719
	Scalable Sorting	Remote reconfiguration (total MTTR over Internet) d	822
		QoS-CARE overhead (simulating 1 dummy event/3sec.)	3

a Client & Server in same machine. b Instrumented through a REST service over a "common" Internetaccess(~1Mbps,11hops). c Instrumented through a REST service over a loop-back connection. d Instrumented through a REST service in a local-area network.

The Components paradigm following Component-Based Development (CBD), Component-Based Software Engineering (CBSE), and Service Component Architecture (SCA).

[START_REF] Tran | A Survey and Analysis on Semantics in QoS for Web Services[END_REF] We use the open source project Attributed Graph-Grammar (AGG) System to represent and process our graph definitions -http://user.cs.tu-berlin.de/~gragra/agg/

TAGs combined with TAG morphisms form the category EGraphs.S e e[ 3 6 ]f o rm o r ed e t a i l so nt h i s .

Despite any names could be used, we chose very representativeo n e st om a k et h ee x a m p l e ss t r a i g h t f o r w a r dt or e a d .

Again, e is the particular event notified by a context monitor. Thus, itisboundtotherespecti vesensedvalue.

The abstraction of the "fulfillment" state can be seen as a superstate in the sense of Harel statecharts, in which substates can transition internally without affecting other states in the statechart. Harel statecharts areusedtoimprovethe legibility of finite-state machine representations[START_REF] Harel | On Visual Formalisms[END_REF]. Besides concurrency, this formalism models clustering, hierarchy and history with an excessively complex semantics, none of this required in our model.

Even though QoSC FSM can manage multiple QoS properties in a QoS contract, in this paper we leave this aspect out of discussion because of space limitations.

https://dev.twitter.com/docs/api

http://code.google.com/p/java-weather-api

http://weather.yahooapis.com/forecastrss

http://www.webservicex.net/ws/WSDetails.aspx?CATID=12&WSID=56

Their source code is available from http://gforge.icesi.edu.co/gf/project/seams

http://metrics.sourceforge.net

https://developers.google.com/java-dev-tools/download-codepro?hl=de-DE&csw=1

Acknowledgments. This work was funded in part by the Ministry of Higher Education and Research of Nord-Pas de Calais Regional Council and FEDER, CPER2007-2013,andduringthe tenure of an "Alain Bensoussan"ERCIMFellowshipbythethirdauthor.

Related Work

We state the contribution of our work in the application of formal models to the reliable and robust realization of QoS contract semantics, rather than int h ef o r m a lm o d e l sr e s e a r c ha r e aa s such. By defining the QoS contracts' semantics we emphasize onthegeneralityofthisapplication of formal models at the level of actual software systems,beyonditsapplicationatthele vel of software abstractions. More precisely, our contributionisfocusedonsatisfyingQoScontracts under changing execution contexts, their reliable and robust fulfillment with respect to context uncertainty, and related properties of self-reconfiguring software systems. Thus, in this section we compare QoS-CARE with other approaches in these respects.

Regarding software contract management, several approaches have been proposed since the first ideas on functional contracts (as assertions or invariants) introduced by Floyd and Hoare [START_REF] Floyd | Assigning Meaning to Programs[END_REF][START_REF] Hoare | An axiomatic basis for computer programming[END_REF]. In the object-oriented paradigm, one of those approaches is the design by contract theory defined by Meyer [START_REF] Meyer | Applying "Design by Contract[END_REF]. Based on a characterization of the different conditions used in the so-called defensive programming, Meyer formulated systematic rules to guarantee routines to satisfy their contracts. Invariant violation, monitoredatruntime,isautomaticallymanagedby the rescue clause, which must be handled by the programmer to restore a consistent state.

Conceptually, most of the approaches addressing QoS contracts follow the rescue clause idea of Eiffel. In contrast, in QoS-CARE the expected QoS-levels to fulfill can be seen, as a whole, as context-dependent "system invariants" to be satisfied continuously, accordingtocontext conditions. Nonetheless, our interpretation of invariant is not in the strict sense of Hoare (i.e., predicates expressed in static assertions that are true in the course of a specific sequence of instructions), but as predicates that are dynamically activated and deactivated at runtime according to changes in context conditions. A predicate must be activated and satisfied only when the respective context condition actually matches the current execution context.

Concerning robustness, Cheng et al. [START_REF] Cheng | Software Engineering for Self-Adaptive Systems: A Research Roadmap[END_REF] and de Lemos et al. [START_REF] De Lemos | Software Engineering for Self-Adaptive Systems: AS e c o n dR e se a r c hR o a d ma p[END_REF] identified context uncertainty as one of the most challenging problems faced by context-aware software systems. In this respect, the approach by Goldsby and Cheng [START_REF] Goldsby | Automatically generating behavioral models of adaptive systems to address uncertainty[END_REF] models dynamically adaptive systems as state-machines, with transitions as system reconfigurations, as QoS-CARE does. Inspired by the adaptability of living organisms, their approach models systems using UML diagrams that satisfy functional and non-functional invariants. Based on these diagrams, and by applying digital evolution techniques, they dynamically generate several target states for a given transition, and then assist the user to select the managed system with the mostappropriateQoSprovisions.

Other approaches that achieve self-adaptation triggered bycontextchanges,althoughnotaddressing uncertainty, are the ones by Colombo et al. [START_REF] Colombo | SCENE: A Service Composition Execution Environment Supporting Dynamic Changes Disciplined Through Rules[END_REF], Sykes et al. [START_REF] Sykes | Exploiting non-functional preferences in architectural adaptation for self-managed systems[END_REF], and Cheng et al. [START_REF] Cheng | eo b j e c t i v e s ,i n: Procs. of 2006 Intl. Workshop on Self-Adaptation and Self-Managing Systems[END_REF]. The first uses reconfiguration rules in Event-Condition-Actions to model service (re)composition in BPEL. These rules associate BPEL workflows with reconfiguration policies used upon QoS level violation. The second exploits QoS information, provided by the user or monitored from the system, to make informed decisions when performing architectural adaptation. Its strategy generates all possible configurations and, in case of failure, switches to one of these configurations driven by this QoS information. The third performs architectural adaptation by using utility functions on repair strategies based on pre-computed configurations. The best configuration is selected and applied in response to system constraints violation. QoS-CARE differs from these three approaches in two aspects. First, it guarantees robustness by considering states of contract unfulfillment if the available reconfiguration options fail to fulfill a given QoS level in some relevant (but possibly unanticipated) context situation. Second, it guarantees other relevant reconfiguration properties such as termination, and consistency. That is, QoS-CARE does not 32 assume that the user-defined policies always cope with and manage unexpected context conditions as these approaches do. In actual software systems these are crucial situations that must be considered in their execution, and QoS-CARE effectively identifies and manages them with explicit states of contract unfulfillment.

Regarding the use of graph transformation systems, QoS-CARE shares similar principles as those managed by Bucchiarone et al. [START_REF] Bucchiarone | Self-repairing systems modeling and verification using agg[END_REF] and Ehrig et al. [START_REF] Ehrig | Formal analysis and verification of self-healing systems[END_REF] to model dynamic software (re)configuration, and benefit from properties such as termination and deadlock-freeness. However, their approaches show these properties in particular application scenarios based on a given software abstraction with the purpose of guaranteeing self-repairing and self-healing properties when failures occur. Our purpose differs to theirs in that our use of graphs and state-machines as semantic denotations for QoS contracts not only generalizes the fulfillment of these contracts in different and actual running software systems, but also allows QoS-CARE to exploit designpatterns at runtime with the ultimate goal of preserving QoS levels. Another important difference is that QoS-CARE clearly separates running-software states from policy states, thus being able to have correct and valid software configuration states, event h o u g hn o tf u l fi l l i n gt h ee x p e c t e d QoS levels.

Concerning QoS property preservation in component-based software, Léger et al. [START_REF] Léger | Reliable Dynamic Reconfigurations in a Reflective Component Model[END_REF] address reliability for system reconfiguration in terms of structural consistency of components and connectors, while preserving system availability. They guarantee reliable reconfigurations in the Fractal platform [START_REF] Bruneton | The Fractal Component Model and its Support in Java[END_REF] by extending its FScript textual language with transactional properties (Atomicity, (structural) Consistency, Isolation and Durability -ACID). Delaval et al. [START_REF] Delaval | Reactive Model-Based Control of Reconfiguration in the Fractal Component-Based Model[END_REF] proposed another approach, also based on Fractal, to guarantee safety. Inspired by control theory, their approach synthesizes static reconfiguration controllers. This synthesis is performed from ac o n t r a c ts p e c i fi c a t i o n ,s i m i l a rt oo u rt r a n s l a t i o no fc o n t racts to state machines. However, in these two approaches, the reconfiguration transition functions must be written by hand for each possible state defined in the state machine. Hnětynka and Plášil [START_REF] Hnětynka | Dynamic reconfiguration and access to services in hierarchical component models[END_REF] preserve system structural properties in software reconfiguration. In order to prevent the dynamic reconfiguration from introducing architectural inconsistencies, their approach characterize three reconfiguration patterns that specifically aim at avoiding the degradation of the system structure. Then, they restrict the set of reconfigurations to be used to only those conforming to these patterns. In contrast to QoS-CARE, in this approach patterns are used apriori,beforereconfigurations,topreservestructural conformance. This property, nonetheless, is also preservedbyQoS-CARE aposteriori,byverifying it after each reconfiguration.

In the Web services area, El Hadad et al. [START_REF] Hadad | TQoS: Transactional and QoS-Aware Selection Algorithm for Automatic Web Service Composition[END_REF] propose a design-time selection approach for composing Web services automatically, where transactionalandQoSrequirementsareintegrated in the selection process. Their approach combines a transactional-aware service selection with a QoS-aware service selection, using local QoS optimization to reduce the set of possible transactional solutions. The purpose of this combination is to satisfy the global transaction requirements of workflow-based systems. The workflow activities are fulfilled with Web services, such that the combination of services satisfy also the systems' QoS requirements. Even though this proposal and QoS-CARE have in common the goal of preserving QoS properties, they differ in several aspects. First, this proposal manages services, that is, software artifacts as black boxes whose internal structure is not important, whereas QoS-CARE manages sets of components and their connectors (i.e., interconnected software structures providing functionalities). Second, the services selected by the referred approach are composed based onthestructureofagivenworkflow specified by the user, and based on this workflow, the system's QoS properties are evaluated to find an optimal combination. In contrast, in QoS-CARE the user specifies design-patterns as sets