Brice Morin

Olivier Barais

Jean-Marc Jézéquel

K@RT: An Aspect-Oriented and Model-Oriented Framework for Dynamic Software Product Lines ⋆

Software systems should often propose continuous services and cannot easily be stopped. However, in order to meet new requirements from the user or the marketing, systems should be able to evolve in order to propose new services or modify existing ones. Adapting software systems at runtime is not an easy task and should be realize with attention. In this paper, we present K@RT, our generic and extensible framework for managing dynamic software product lines. K@RT is composed of three parts: i) a generic and extensible metamodel for describing running systems at a high-level of abstraction, ii) a set of metaaspects that extends the generic metamodel with constraint checking, supervising and connections with execution platforms iii) some platform-specific causal connections that allow us to supervise systems running on different execution platforms.

Introduction

Developing, testing and validating adaptive systems is a daunting task. Indeed, such systems can propose a wide range of possible configurations at runtime [START_REF] Hallsteinsen | Dynamic Software Product Lines[END_REF][START_REF] Morin | An Aspect-Oriented and Model-Driven Approach for Managing Dynamic Variability[END_REF]. These systems can be seen as Dynamic Software Product Lines (DSPL) that can reconfigure themselves at runtime.

In order to facilitate the development, test and validation of DSPLs, we propose K@RT, our aspect-oriented and model-oriented framework for supervising componentbased systems. This generic framework is independent from any underlying execution platform and proposes to maintain a reference model at runtime [START_REF] Bencomo | Models@run.time[END_REF]. Using this highlevel view of the running system, we can navigate the runtime architecture using modeloriented languages [START_REF] Muller | Weaving Executability into Object-Oriented Meta-languages[END_REF] and invoke services that are delegated to the running system. K@RT also allows to adapt the running system by modifying its runtime model, checking constraints on the modified model and comparing the actual reference model to the modified model. This process produces a safe reconfiguration script that is executed on the running system. The modified model may be obtained with high-level modeltransformation languages [START_REF] Muller | Weaving Executability into Object-Oriented Meta-languages[END_REF] or Aspect-Oriented Modeling (AOM) approaches [START_REF] Fleurey | A Generic Approach For Automatic Model Composition[END_REF][START_REF] Morin | Weaving Aspect Configurations for Managing System Variability[END_REF][START_REF] Morin | A Generic Weaver for Supporting Product Lines[END_REF], avoiding users to write low-level platform-specific reconfiguration scripts.

The remainder of this paper is organized as follows. Section 2 introduces our generic and extensible metamodel for representing models at runtime. Section 3 briefly presents our causal link between a running system and a runtime model. Section 4 details the aspect-oriented architecture of K@RT. Section 5 evaluates our framework. Finally, Section 6 concludes and outlines future works.

A Generic and Extensible Metamodel for Runtime Models

In this section, we present our generic metamodel1 for representing component-based systems at runtime. This metamodel does not aim at representing high-level architectures but focuses on abstracting a running system. This metamodel is independent from any execution platform and can easily be mapped on Fractal [START_REF] Bruneton | An Open Component Model and Its Support in Java[END_REF][START_REF] Bruneton | The FRACTAL Component Model and its Support in Java. Software Practice and Experience, Special Issue on Experiences with Auto-adaptive and Reconfigurable Systems[END_REF], OpenCOM [START_REF] Coulson | The Design of a Configurable and Reconfigurable Middleware Platform[END_REF], PEtALS ESB [START_REF] Petals | The Open Source ESB Solution for Services Oriented Architectures[END_REF] or SCA [2].

Fig. 1. A Generic and Extensible Metamodel

Our generic metamodel is separated in three packages, as illustrated in Figure 1. The type package defines the notion of component type. A component type contains some ports. Each port has a UML-like cardinality (upper and lower bounds) indicating if the port is optional (lowerBound == 0) or mandatory (lowerBound > 0). It also indicate if the port only allows single bindings (upperBound == 1) or multiple bindings (upperBound > 1). A port also declares a role (client or server) and is associated to a service. A service encapsulates some operations, defined by a name, a return type and some parameters. Basically, a service has a similar structure than a Java interface.

The instance package defines the actual topology of a running system. A component has a type and a state (ON/OFF), specifying whether the component is started or stopped. It can be bound to other instances by a collaboration binding, linking a provided service (server port) to a required service (client port). A composite instance can additionally declare sub-instances and delegation bindings. Note that our metamodel allows shared components as a component may have several super components. A delegation binding specifies that a service from a sub-component is exported by the composite instance.

The implementation package contains metaclasses responsible for encapsulating the platform-specific attributes needed to implement components for a given platform. For example in Fractal, we should specify the implementation class (contentDesc) and a controller (controllerDesc) in order to be able to create a component.

We prefered to define a domain-specific metamodel (DSM) rather than reusing for example the UML 2.0 metamodel. Indeed, a reference model conforming to this metamodel is causally connected to the running system. Using a DSM allows us to reduce the number of entities that have to be maintained at runtime and consequently limit the memory overhead. This metamodel is strongly-typed and allows us to define algorithms with few casts whereas it is often necessary to perform casts when working at the platform level as they often deal with losely-typed objects. Moreover, this metamodel is aligned on the Service Component Architecture (SCA) [2] metamodel proposed by the Open Service Oriented Architecture collaboration (OSOA) [3] that brings together industrial partners like IBM, Sun, Oracle, SAP or Siemens. Our metamodel can be seen as a ligthweight version of SCA. This allows us to easily map our metamodel to SCA [2] and reuse the tools provided by SCA, such as a graphical editor to visualize the runtime architecture.

A Model-Driven Causal Connection

This section briefly presents our model-driven causal connection between a reference model, conforming to the metamodel we have presented in Section 2, and an execution platform. Currently, we have implemented such a causal connection for the Fractal [START_REF] Bruneton | An Open Component Model and Its Support in Java[END_REF][START_REF] Bruneton | The FRACTAL Component Model and its Support in Java. Software Practice and Experience, Special Issue on Experiences with Auto-adaptive and Reconfigurable Systems[END_REF] platform but it can also be implemented for other component-based execution platforms like OpenCOM [START_REF] Coulson | The Design of a Configurable and Reconfigurable Middleware Platform[END_REF] or PEtALS [START_REF] Petals | The Open Source ESB Solution for Services Oriented Architectures[END_REF], if they provide reflection and dynamic reconfiguration mechanisms. The architecture of this causal connection is illustrated in Figure 2 and is detailed in the next two subsections.

The Model2Platform component is in charge of reflecting the changes of the model to the platform. This components will be detailed in this section. Identically, the Plat-form2Model component reflects the changes of the running system to the model. These two components use the Factory component in order to instantiate model elements from runtime entities, and vice-versa. The Root component is a composite component that contains the system designed by the user. This component is not really part of the causal link and may be deployed on a different site than the other components implementing the causal connection.

From Platform to Model

This subsection describes how we generate and update a reference model that represents, at a higher level of abstraction, the running system.

Fractal [START_REF] Bruneton | An Open Component Model and Its Support in Java[END_REF][START_REF] Bruneton | The FRACTAL Component Model and its Support in Java. Software Practice and Experience, Special Issue on Experiences with Auto-adaptive and Reconfigurable Systems[END_REF] and all the reflective component-based execution platforms propose mechanisms for introspecting a running system. These mechanisms allows to discover which components actually compose the system, how they are bound to each others, etc. We extend the introspection operations provided by middleware approaches in order to discover the operations and their parameters that are provided/required by ports. In the Java-based distribution of Fractal or OpenCOM, each port (provided or required interface) is associated to a Java interface. We use the java.lang.reflect API to discover these operations and give a more precise view of the system.

Using reflection is very useful to instantiate a model from scratch. But, if we want to keep the model up-to-date, instantiating a complete model periodically may be time and resource consuming if only minor changes occurs. We have instrumented the Fractal platform to observe and notify all the architectural reconfigurations that appear in the running system. This allows us to update the reference model.

Finally, it is possible to visualize the runtime architecture in the graphical editor provided by SCA. Indeed, we have defined a model transformation in Kermeta [START_REF] Muller | Weaving Executability into Object-Oriented Meta-languages[END_REF], that maps the concepts of our metamodel to the concepts of SCA.

From Model to Platform

This subsection describes the other part of our causal connection. In K@RT, the only way to adapt a running system is to submit a new model to the causal link (see Section 4). When a new model is submitted to the causal link, we perform a difference analysis between the modified model and the actual reference model. In the current implementation of K@RT, we use EMF Compare [START_REF]EMF Compare[END_REF] in order to realize this analysis. EMFCompare provides a generic comparison engine that can be customized for any domain-specific metamodel.

After analyzing the output provided by the comparison engine, we can determine what has been removed from the model, added into the model or updated. However, we cannot directly adapt the running system using these elements. Indeed, we cannot ensure that the order we discover the modifications during the analysis will result in a consistent adaptation of the running system. For example, if we discover that some bindings and some components have been removed, it would probably lead to dangling bindings in the running system if we directly adapt the system. In order to adapt the running system in a consistent way, we reify every significant modification as a command. Each command declares a priority (e.g., a command that removes a binding has a higher priority than a command that removes a component). These commands are automatically ordered with a Comparator. Once all the commands are instantiated, they are executed in the right order in order to actually adapt the running system. We first stop the components that needs to be stopped, we remove all the bindings and the components, add the new components and the bindings and finally restarts the components.

K@RT: Kermeta at RunTime

This section presents our aspect-oriented and model-oriented framework for supervising component-based systems at runtime. This framework is based on the generic and extensible metamodel presented in Section 2 (Figure 1) and is implemented in Kermeta [START_REF] Muller | Weaving Executability into Object-Oriented Meta-languages[END_REF]. Three Kermeta meta-aspects, constraint checker, supervising and platform adapter extends the generic metamodel, as illustrated in Figure 3. Kermeta metaaspects allows us to statically introduce new features in existing model elements: adding classes in packages, adding super classes in the inheritance tree, adding and implementing new operations and adding contracts (invariants, pre/post conditions).

Constraint checker meta-aspect

This subsection details the constraint checker meta-aspect. This aspect weaves invariants into metaclasses. These invariants can be written in OCL [START_REF]Object Constraint Language Specification[END_REF] and translated into Kermeta thanks to the OCL Kermeta plugin, or directly written in Kermeta. We illustrate this aspect by detailing one of the invariants we have implemented.

The completeCollaborationBindings invariant illustrated in Figure 4 specifies that all the client (PortRole.CLIENT) and non optional ports defined in the type (self.type) of the component should be targeted (b.client) by the client reference of a binding owned by the component (self.binding).

This invariant uses the OCL-compliant operators provided by Kermeta (e.g. select, forAll, exists, etc), which significantly reduce the complexity of writing invariants. The same invariants implemented in Java/EMF needs 15 lines of code and would even be more complex if it was directly implemented using the platform API.

Specifying constraints on the metamodel allows us to check well-formedness rules that all the runtime models, and consequently all the running systems must respect. Using model-oriented constraint languages like OCL or Kermeta allows designers to rapidly implement such invariants as these languages propose high-level operators for manipulating models. Note that it is possible to aspectized this constraint checker aspect in order to implement additional constraint. For example, if the underlying execution platform do not support shared component, an invariant can check that components have no more than one super component. Currently, 6 invariants are implemented in the constraint checker aspect.

Supervising meta-aspect

The supervising aspect implements an administration console. It introduces two metaclasses: DisplayContext and DisplayElement. The DisplayContext metaclass is responsible for managing the history of the administration console and provides some useful method for displaying information. The DisplayElement simply defines an abstract operation display(context : DisplayContext). In the aspect, this metaclass is introduced as a super class for all the elements that may be displayed: Component, ComponentType, Binding, etc. The display operation is implemented in each subclass. The DisplayContext and DisplayElement metaclasses can be seen as an interactive and history-aware visitor pattern allowing to display the elements chosen by the user and to go back to the previously visited elements.

Adapter meta-aspect

This aspect is responsible for connecting Kermeta to the execution platform. Kermeta proposes a seamless mechanisms for calling Java programs. Thus, it is possible to connect our K@RT framework with Java-based distribution of Fractal (Julia, AOKell), -Instantiating the reference model from scratch using the introspection API provided by the underlying middleware platform. In Fractal, we use the content, binding, name, lifecycle and attribute controllers. -Getting the current reference model using the notification mechanisms provided by the underlying middleware platform. This allows updating the reference model instead of generating it from scratch. We have implemented a new controller for Fractal that notifies all the runtime architectural changes to registered observers. -Loading a model. It loads the model, analyzes the diff and match models and computes a safe reconfiguration script, as described in Section 3. -Invoking services. Fractal does not propose controllers for easily accessing and invoking methods in a reflective way. We tackle this issue by directly using the java.lang.reflect API in order to discover which operations can be called and actually call them from Kermeta. We plan to integrate this implementation in a Fractal controller.

Discussion

K@RT is implemented according to our generic metamodel, instead of directly refering to an underlying execution platform e.g. Fractal, OpenCOM, PEtALS, etc. It allows us to reuse it for different platforms provided that they could be mapped, in both directions, to the metamodel. However, if the execution platform cannot directly be mapped to the metamodel, it is possible to aspectize the metamodel and the related meta-aspects to extend them with new concepts.

Fractal Explorer [6] is a tool for managing Fractal-based applications via a graphical console. Currently, our console is textual but it would be possible to connect K@RT to a Java-based graphical console, as Kermeta programs can be connected to Java programs. The main differences between Fractal Explorer and K@RT are summarized below:

-K@RT is technology independent while Fractal Explorer is based on Fractal. Indeed, K@RT is based on our generic and extensible metamodel that allows us to connect it to different execution platforms -K@RT offers a higher level of abstraction. Indeed, in Fractal Explorer all the details of the Fractal component model are displayed in the console: content-controller, binding-controller, lifecycle-controller, etc. In K@RT, a Fractal component that declares a binding-controller and a lifecycle-controller is simply represented by a component that contains some bindings and declares a state. The Fractal-specific notion of controller is abstracted. -K@RT offers a higher level reconfiguration process. Indeed, K@RT proposes to adapt the running system by modifying the reference model. It is possible to use any transformation languages like Kermeta [START_REF] Muller | Weaving Executability into Object-Oriented Meta-languages[END_REF] or Aspect-Oriented Modeling tools [START_REF] Fleurey | A Generic Approach For Automatic Model Composition[END_REF][START_REF] Morin | Weaving Aspect Configurations for Managing System Variability[END_REF][START_REF] Morin | A Generic Weaver for Supporting Product Lines[END_REF] to modify the model. Then, this modified model is checked and automatically translated in a safe reconfiguration script. Fractal explorer is limited to fine grained reconfiguration.

Evaluation of K@RT

In order to evaluate K@RT, we have implemented a prototype in Fractal. This example is based on the service discovery system [START_REF] Flores-Cortés | An Adaptive Middleware to Overcome Service Discovery Heterogeneity in Mobile Ad Hoc Environments[END_REF]. A service discovery system can either advertise or request services. It can also provide both functionalities. A service discovery system can communicate via several technologies (at least one). In this example, we propose WiFi and Bluetooth (BT). Figure 5 shows the complete architecture of the service discovery system, with both roles and both communication technologies. This model is automatically generated from the running system and mapped to SCA. We define each functional role (Advertiser or Requester) as an aspect and each communication technology (WiFi or Bluetooth) as an aspect. We use an Aspect-Oriented Modeling tool (SmartAdapters [START_REF] Ph | Introducing Variability into Aspect-Oriented Modeling Approaches[END_REF][START_REF] Morin | Weaving Aspect Configurations for Managing System Variability[END_REF][START_REF] Morin | Towards a Generic Aspect-Oriented Modeling Framework[END_REF]) to weave these aspects and produce all the possible configurations [START_REF] Morin | Weaving Aspect Configurations for Managing System Variability[END_REF][START_REF] Perrouin | Reconciling Automation and Flexibility in Product Derivation[END_REF]. There exists 9 possible configurations for the service discovery system: Advertiser role, Requester role or both and WiFi, Bluetooth or both. Consequently there is 9*(9-1) = 72 possible transitions from one configuration to another. Our causal link succeed to reconfigure the system at runtime for all these 72 transitions. The average time for reconfiguration was 200 ms.

Since all the aspects are independent from each others, it would be possible to handle the adaptive behavior of the service discovery systems with 8 scripts, for adding/removing each aspects. The identification of aspect dependencies and the generation of the minimal set of reconfiguration scripts will be subject to future work.

Conclusion and Future Works

In this paper, we have presented K@RT, our framework for developing, testing and validating Dynamic Software Product Lines (DSPL). This framework allows us to construct adaptive systems by defining model transformations [START_REF] Muller | Weaving Executability into Object-Oriented Meta-languages[END_REF] or weaving aspects into a base model [START_REF] Morin | Weaving Aspect Configurations for Managing System Variability[END_REF][START_REF] Perrouin | Reconciling Automation and Flexibility in Product Derivation[END_REF]. It is possible to check the different configurations of the system, represented by platform independent models (compliant with SCA) that can be visualized in a graphical editor. Finally, using our causal link, it is possible to adapt a system at runtime and switch from one configuration to another, without writing reconfiguration scripts. In future work, we plan to reuse an existing framework for monitoring interesting properties of the environment and develop a reasoning framework that will automatically select or generate (e.g., by weaving some aspects into a base model) the most adapted configuration. After checking some constraints, our causal link will automatically reconfigure the running system. We plan to use the WildCAT monitoring framework [START_REF] David | An Aspect-Oriented Approach for Developing Self-Adaptive Fractal Components[END_REF] in combination with the Intel Mobile Platform Software Development Kit [START_REF]Intel Mobile Platform Software Development Kit[END_REF] that provides a set of implemented probes.

Fig. 2 .

 2 Fig. 2. Architecture of our Causal Connection

Fig. 3 .

 3 Fig. 3. K@RT overview

1 aspect c l a s s Component { 2 i n v completeCollaborationBindings i s do 3 end 7 }Fig. 4 .

 374 Fig. 4. Component metaclass aspectized with an invariant

Fig. 5 .

 5 Fig. 5. Service Discovery Runtime Architecture

In this paper, "metamodel" refers to the MOF terminology, not the middleware terminology.

Acknowledgment

Brice Morin thanks the Collège Doctoral International of the Université Européenne de Bretagne for funding his visit to Lancaster University.

⋆ This work was funded by the DiVA project (EU FP7 STREP, Theme 1.2: Service and Software Architectures, Infrastructures and engineering, Contract 215412)


Freddy Munoz
email: fmunoz@irisa.fr

Benoit Baudry
email: bbaudry@irisa.fr

Olivier Barais
email: barais@irisa.fr

Improving Maintenance in AOP Through an Interaction Specification Framework

The invasiveness of aspects is beneficial to modularize crosscutting concerns that require the modification of the data or control flow. However, it introduces subtle errors that are hard to locate and fix in case of evolution. In this paper we illustrate this issue by evolving a program implemented using aspects. Interaction issues, between aspects and the program, emerge from this evolution. We locate them through manual inspection and test execution. This tedious process motivates the need for an abstract specification of intended interactions. To tackle this issue, we propose a framework for specifying the types of invasiveness pattern that are allowed of forbidden in the program. We have also implemented a tool that automatically checks whether the specification is satisfied by the aspects.

Introduction

Aspect-oriented programming (AOP) is a paradigm that enhances current approaches to modularizing software. AOP enables separation of concerns that crosscut the implementation of a system. This is done by encapsulating crosscutting concerns into single units called aspects. An aspect itself is composed of several units realizing the crosscutting behavior, these units are called Advices. Aspects also provide pointing elements that designate well defined points in the program execution or structure. These are the points where the program executes the crosscutting behavior. Generally the pointers are called point-cut and the execution points Join-points. Different approaches to AOP have been proposed [START_REF] Kiczales | Aspect-oriented programming[END_REF][START_REF] Mezini | Conquering aspects with caesar[END_REF][START_REF] Pawlak | Spoon: annotation-driven program transformation -the aop case[END_REF][START_REF] Bockisch | Adapting virtual machine techniques for seamless aspect support[END_REF]. Each of these approaches provide a different mechanism to compose aspects with the base program (main concern). These composition mechanisms range from simple program augmentation to more complex operations such as behavior replacement.

Invasive AOP approaches use composition mechanisms that allow developers to manipulate almost any structure of the base program. This ability to manipulate the base program structures is called invasiveness. Invasive AOP provides several strategies to manipulate the base program. These strategies range from less invasive such as the augmentation of a procedure execution to more invasive ones such as the replacement of a procedure execution. An invasiveness pattern is the characterization of invasive behavior, i.e. the strategy or a combination of them to manipulate the base program.

Invasive aspects are useful to introduce functionalities that otherwise must be hardcoded into the base program. For example, a system transaction concern is implemented using an invasive aspect because it requires to stop executing the intercepted behavior each time a transaction fails. However, invasive aspects can also do harm to the base program. When they introduce the functionalities they are designed for, they can also introduce side effects, hence, generating unexpected interactions.

The work presented in this paper is divided in two parts. In the first part we illustrate the issues that can arise when evolving an aspect-oriented program that is built with aspects (some of them invasive). This is an special case of the AOSD-Evolution paradox [START_REF] Tourwé | On the existence of the AOSD-evolution paradox[END_REF], which results to be aggravated in presence of invasive aspects. We consider a distributed chat application as a case study. First, we illustrate how invasive aspects are useful to implement cross-cutting features in this example. Then we evolve the system to enable authentication in the application. While regression testing the application errors emerge. We then propose an iterative process involving manual inspection and test execution in order to locate the source of the problem. It allows us to track back the issues to unexpected interactions between aspect and the program. From this study and the debugging process we learn that invasive aspects can introduce faults that emerge only when evolving the system. We also learn that these faults are difficult to locate and that debugging requires a complex and error-prone process. Moreover, the crosscutting nature of aspect makes difficult to reason about their impact in interaction with the base program. This study demonstrates the need to reason about expected interactions, and to control the usage of invasive aspects.

In the second part of this work we propose a framework for specifying the expected interactions in the base program as well as the way in which aspects can be invasive. The specification on aspects is based on a classification proposed in previous work [START_REF] Munoz | Vigilant usage of aspects[END_REF][START_REF] Munoz | A classification of invasive patterns in aop[END_REF]. This classification identifies different patterns according to which AspectJ aspects can be invasive. Based on this specification, the base program declares which type of invasiveness it allows or forbids. We have developed a tool support for this framework. This tool analyzes aspects to infer which invasive pattern they encapsulate. It can also statically check that the aspects conform to the specification of the base program. Based on this approach, we revisit the chat application and illustrate that specifying interactions is useful to early detect when invasive aspect can perform harmful. This experience expresses that it is worth specifying the interactions between aspect and base program. Besides, having specification reduces the time to locate and fix issues consequence of unexpected interaction.

The contributions of this work are summarized as follows:

• An illustration through a rigorous inspection process on a case study of the AOSD-Evolution paradox in presence of invasive aspects. • A framework for the characterization of invasiveness patterns on aspects and the specification of expected invasiveness patterns in the base program.

This paper is organized as follows. Section 2 explain the chat application case study and a process to detect problems introduced by invasive aspects. Section 3 explains our specification framework. Section 4 describes the implementation of the specification framework. Section 5 revisits the case study using the specification framework. Section 6 presents the related work and finally section 7 concludes.

Motivating Case Study

In this section we illustrate the AOSD-evolution paradox [START_REF] Tourwé | On the existence of the AOSD-evolution paradox[END_REF] in presence of invasive aspects. Our goal is to show that invasive aspects offer efficient mechanisms to implement cross-cutting concerns, but that they can also introduce complex errors in case of evolution.

To illustrate these issues, we present an example implemented in Java and AspectJ. The example is a chat application implemented with 5 aspects. We run system-level test cases on the application to validate the initial version. Then, we evolve the application adding authentication capabilities. While testing the new version, we have detected errors.

We precisely discuss the analysis we perform to trace the source of the error back to a wrong interaction between aspects and the base program. Based on these observations, we motivate our approach to assist the validation and verification of aspect-oriented programs.

A chat application

A chat application is a program that allows users to communicate with each other in real time. Our chat is composed of two parts: a client and a server. The server handles client, manages the communication between them and ensures their uniqueness. The client transmits messages to the server that are dispatched to other clients. The global behavior of a chat application can be described as follows. Initially, the server is waiting for clients. The establishment of communications is called association. The cease of communication is called disassociation. Before associating a client, the server checks the uniqueness of the client's nickname. Clients using existing nicknames are not associated. Once associated, the clients can send messages. Such messages are encrypted and decrypted by the clients. Each client's chat session is recorded in a log file. The server also stores each session into a log file. A graphical user interface (GUI) controls the client and server behavior.

Initial version

We have implemented a chat in Java TM . From the requirements documents, we separated the core concerns form the cross-cutting concerns. Figure 1 shows the class diagram for the core concerns of the chat application. The method transmit(Message) notifies the GUI about the arrival of a new message. Finally the method abort() aborts the execution of the client. The StandardServer class realizes the server interface. As in the client, the methods attach(Client) and detach(Client) associate and dissociate a client. The send(Message) method dispatches the messages to other clients associated to the server. The class Client is a container for the client's information. The class Message supports the messaging mechanism between client and server. Client and Server communicate using the Java RMI distribution mechanism [START_REF]Java Remote Method Invocation Specification[END_REF]. The client and the server GUI are implemented with the Standard Widget Toolkit (SWT).

Crosscutting concerns

We have identified the following crosscutting concerns and implemented them with AspectJ.

• Message encryption encrypts and decrypts the incoming/outgoing messages. Encryption/decryption occurs just before the execution of the methods send and transmit. It replaces the method arguments with the encrypted/decrypted version of the message. • Message logging logs the incoming/outgoing messages for each user. Its behavior executes before transmitting a message and after receiving a message (before the encryption and after the decryption). • Error handling captures the communication exceptions and raises an alert indicating communication problems. Its behavior executes after an exception of type remote is thrown. • Server logging logs the server activity in a file. Its behavior executes before and after all the methods of the IServerIM interface. This is, it observes the execution of each method of the server. • Nickname uniqueness checks the existence of only one nickname in the server. Its behavior executes just before the server association methods (attach and detach).

In the case of association, it checks the existence of the client's nickname on the server. If the nickname exists, it throws an exception. Otherwise, it adds the name to a list and executes the association normally. In the case of dissociation, it removes the client's nickname from a list.

Listing 1. Implementation of the encryption concern

Listing 1 shows the implementation of the Message encryption concern. It is clear from the code that the three advices of this aspect are changing the argument values of the intercepted methods (lines 9-10, 13-14, 17-18). The original message is replaced by the encrypted/decrypted version and then it is re-injected to the original method (proceed call). This concern can only be implemented by using invasive aspects, otherwise it must be hard-coded in the base program.

Listing 2. Implementation of the unique nickname concern

Listing 2 shows the implementation of the Nickname uniqueness concern. This aspect manages a list of the currently associated clients nicknames (nameList line 8). If the actual client nickname does not exist in the list (line 12) then it is added to the list (line 13) and the intercepted method is executed. Otherwise, the method is never executed and an exception is raised. This aspect conditionally replaces the execution of the methods it intercepts. Analogously to the Message encryption concern, it can only be implemented by using invasive aspects.

These examples illustrates that invasive aspects help implementing the crosscutting concerns that modify the flow or data in the program.

Validating the initial version

We test the initial version with 7 system-level test scenarios. Each scenario validates a different dimensions of the system. These dimensions are summarized as follows:

1. The association mechanism between client and server. 2. The association mechanism supports multiple clients. 3. Clients can send/receive messages. 4. The server distributes the messages among clients. 5. The server detects clients named with an existing nickname. 6. The server association mechanism removes a used nickname when disassociating a client.

7. The error handling mechanism handles the exceptions.

All the test scenarios pass on the initial version composed of the core concern and 5 aspects.

Evolving the chat application

The initial version of the chat application allows any user to associate with a server. Here, we add an authentication mechanism to ensure that only the registered users are able to associate with a server. We also want to ensure that the clients of this new version are compatible with the old version. As a consequence, a server without authentication must be able to associate an authenticated client. Authenticated servers must refuse the association of unauthenticated clients. The chosen authentication protocol proceeds as follows: the client provides the nickname and password data to the server. The server checks the nickname, password pair internally. If the pair is authentic, then the server will associate the client, otherwise the client is not associated.

In order to implement the evolution, we have added two classes: AuthenticatedSever that extends StandardServer and overrides the method attach(Client);

AuthenticatedClient that extends StandardClient and overrides the methods transmit(Message) and receive(Message). Additionally, we have performed minor changes in the class Client and the client GUI adding support for password. Since this evolution is only adding new behavior, the behavior for the initial version should be kept. The crosscutting concerns present in the initial version remains in this evolution with no further implementation changes.

Validating the new version

We use the previous test scenarios for regression testing. To do so, we replace the standard client/server with the authenticated one. We also add 5 scenarios to validate the authentication mechanism as well as the compatibility between the two versions. The dimensions addressed by these scenarios are summarized as follows:

8. The authentication mechanism detects invalid nicknames and passwords. 9. The server detects void nicknames or password (or both). 10. The client association mechanism is compatible with the standard server. 11. The authenticated server is incompatible with the standard client. 12. The authenticated client messaging mechanism is able to send messages to standard clients.

The results of the executing tests 1 to 12 are summarized in table 1.

Table 1. Test results after evolution

Test 1 2 3 4 5 6 7 8 9 10 11 12 x x x x x x x x

Reasoning about the problems

Looking at the results of the test scenario execution it is not easy to see where the problems are located. However, a rigorous manual analysis will help detecting the problems. We deal with the authenticated association issues and later the compatibility issues.

The failure of the two first test cases tells that the client cannot associate with the server or the server cannot authenticate/associate the clients. The failure of tests 3, 4, 5, 6 and 7 are consequence of the failure of the test case 1 and 2. This is because the preconditions cannot be fulfilled: there is no connected client. The success of tests 8 and 9 provides no information about the association mechanism. The success of the first test is fundamental to obtain more information about tests 3 to 7. This guides our analysis to examine the association and the authentication mechanism.

After rigorously inspecting the base program we found no errors, however, we need to take into account that the chat runs with aspects. Before examining the aspects code, we try to run the server without aspects that could interfere with the association/authentication mechanism. We remove only the invasive aspects because they are the only ones that can change the final behavior of the application. Moreover, the test scenarios that fail (except for the test case 5) evaluate only the functionalities implemented in the base program.

Table 2 shows the test results after removing the Nickname uniqueness aspect. Now test cases 1 to 4 pass, however, the test case 5 fails because it depends on the aspect. Removing the aspect helped to localize the problem (the Nickname uniqueness aspect is interfering with the association mechanism). Nevertheless, we still ignore the specific localization of the failure and its cause.

After rigorously inspecting the aspect code and the places it affects, we finally localize the specific cause of the problem. The problem occurs because the aspect captures a wrong join point, the execution of the attach method in the StandardServer class. The point-cut descriptor captures all the executions of the attach method in the server. This, while the body of the advice realizing the crosscutting concern is designed to be executed just once at each join point. This means, once from the beginning to the end of the method execution. Then, the aspect finds that the client nickname is not in the registry (exist(client.name)=false) and adds its name into the registry (add(client.name)). The aspect also captures the second call that performs the association (StandardServer.attach(client)).

Table 2. Test results after removing the Nickname uniqueness aspect

It is here where the aspect finds that the name exists in the registry and throws an exception. This problem is hard to detect because it can be a combination of a failure in the point-cut descriptor and a limited implementation of the advice. To solve this problem we could modify the advice implementation or the point-cut descriptor. However, we think that the advice implementation realizes in a proper manner the crosscutting concern. Therefore, we modify the point-cut description.

Once we had detected and fixed the association problem, we explore the compatibility problems. The failure of test 12 is due to a compatibility problem when sending/receiving messages. Following the procedure we used to localize cause of the association issue we localize the case of the compatibility issue. The problem is localized in the Encryption aspect and is analogous to the association problem. The advice captures the execution of the messaging methods twice, therefore, it encrypts/decrypts the messages twice. On the other hand, the standard client encrypts/decrypts the messages only once. We solve this problem by changing the point-cut descriptor to match only one execution each time.

Discussion

Through this experiment we have shown that despite the features provided by invasive aspects, they can hamper the software evolution. The main issue is that it is very hard to reason about the aspects impact on the final application, and it is very hard to trace them as the source of the problems to aspects.

The successive execution of a set of test scenarios and the manual inspection of code helped us tracing the problems to aspects. However, this process is tedious, time consuming and error prone. Besides, there is no generic formula to trace this kind of problems. In the chat application, the problems were localized by removing the aspect. This was possible because the test scenarios we used were testing the base program functionalities. Nevertheless, it is not always possible to simply remove the aspects.

Actually there is a missing element in the AOP support. The tedious process we performed tells us that there is a need to abstract from code to reason about the interactions between aspects and the base program. To tackle this issue, we propose a framework for specifying the (1) the invasiveness patterns that aspects realize, and (2) the invasiveness patterns expected on the base program. This means specifying the interaction between aspects and base program. Such specification assist developers to localize and solve problems due to faulty invasive aspects.

Specifying aspects-base program interaction

The specification of interactions between aspects and base program consists of two parts. In the first, we characterize aspects with specific invasiveness patterns (Aspect specifications). In the second, we specify the invasiveness patterns the base program allows from aspects.

For the first we propose to use our previous work [START_REF] Munoz | A classification of invasive patterns in aop[END_REF] on classifying invasive aspects. For the second we propose to specify assertions that allow/forbid invasiveness patterns to interact with the base program elements.

The goal of these specifications is to obtain information about the potential unexpected interactions that invasive aspects can produce. Such information will help developers to reason about the harmfulness of aspects. Therefore, it assists developer to track potential faults (introduced by invasive aspects).

Aspect specification

In [START_REF] Munoz | Vigilant usage of aspects[END_REF][START_REF] Munoz | A classification of invasive patterns in aop[END_REF] we present a classification of invasive aspects. Such classification is the result of an analysis of the invasive mechanisms that AspectJ [6] provides. It allows us to identify specific invasiveness patterns and therefore abstract from code. Such abstraction helps reasoning about the interaction of aspects and the base program. We use this classification to characterize aspects with invasiveness patterns.

In AspectJ, aspects crosscut the base program at two levels. At class level (aspect) modifying the program structure and at method level (advice) manipulating the method's behavior. Our classification addresses these two levels. In the following, we list the classification elements with a brief description. Aspect invasiveness patterns are marked with ‡, and advice invasiveness patterns are marked with †. † Augmentation: After crosscutting, the body of the intercepted method is always executed. The advice augments the behavior of the method it crosscuts with new behavior that does not interfere with the original behavior. Examples of this kind of advices are those realizing logging, monitoring, traceability, etc. † Replacement: After crosscutting, the body of the intercepted method is never executed. The advice completely replaces the behavior of the method it crosscuts with new behavior. This kind of advices eliminate a part of the base program. † Conditional replacement: After crosscutting, the body of the intercepted method is not always executed. The advice conditionally invokes the body of the method and potentially replaces its behavior with new behavior.

Examples of this kind of advices are advices realizing transaction, access control, etc. † Multiple: After crosscutting, the body of the intercepted method is executed more than once. The advice invokes two or more time the body of the method it crosscuts generating potentially new behavior. † Crossing: After crosscutting, the advice invokes the body of a method (or several methods) that it does not intercepts. The advice have a dependency to the class owning the invoked method(s). † Write: After crosscutting, the advice writes an object field.

This access breaks the protection declared for the field and can modify the behavior of the underlying computation. † Read: After crosscutting, the advice reads an object field.

This access breaks the protection declared for the field and can potentially expose sensitive data. † Argument passing: After crosscutting, the advice modifies the argument values of the method it crosscuts and then invokes the body of the method. The body of the method always executes at least once. ‡ Hierarchy: The aspect modifies the declared class hierarchy. For example, the aspect adds a new parent interface to an existing one. ‡ Field addition: The aspect adds new fields to an existing class declaration. These fields depending on their protection can be acceded by referencing an object instance of the affected class. ‡ Operation addition: The aspect adds new methods to an exiting class declaration. These methods depending on their protection can be acceded by referencing an object instance of the affected class.

All the advices of the Encryption aspects (Listing 1) are clas-sified Argument passing. This because they modify the argument values of the methods they intercept. The advices of the Nickname uniqueness aspect (Listing 2) are classified Conditional Replacement (lines 9-18) and Augmentation (lines 19-21). The first conditionally replaces the execution of the methods it intercepts, the second is orthogonal to the methods it intercepts.

Core specification

We specify the base program (core) by asserting the patterns of invasiveness allowed/forbidden to interact with it. Such specification emanates from the base program designers and declares an expected interaction.

Aspects crosscut the base program at the level of classes (modifying the class structure), methods (modifying the declared behavior) and fields (accessing the data contained in object fields). This motivates us to attach specifications to each one of these elements. By default (implicit specification) only the patterns Augmentation, Crossing, Read are allowed to advise the base program. This is because a priori these classes do not alter the program flow, data or structure, hence, they are less harmful than the others. Specification for classes: Specify the invasiveness patterns allowed englobing two levels. The first is related to the class structure modifications like the addition of a field. The second is related with methods and fields declared in the class. A class is specified with an allowed invasiveness patterns that applies to its fields and methods. This specification can allow any invasiveness pattern forbidden by default, and forbid any invasiveness pattern allowed by default. This specification corresponds to (a) in figure 3 covering all the class definition.

Specification for fields: Specify the invasiveness patterns that a field allows in terms of how advices access it. This specification can allow Write and forbid Read. This specification corresponds to (b) in figure 3 covering only a field definition.

Specification for methods: Specify the invasiveness patterns allowed on a specific method. It can allow Replacement, Conditional replacement, Multiple, Write, Argument passing. It can forbid Augmentation, Crossing, Read. This specification corresponds to (c) in figure 3 covering only a method definition.

It is worth mentioning that a class specification can be reused in the case of the inheritance. For example, The class B extends class A. If C is the specification of A, and B is not explicitly specified, then C is the specification of B.

In the case of conflicts between the specifications of fields, methods and classes we propose the following: The specification of fields is always used if it exists. If a method is specified (explicitly), its specification is used instead of the global.

Specification matching

We compare the core and aspect specifications in order to detect when aspects or advices violate the core specifications. An aspect or an advice violates a core specification when it realizes invasiveness patterns that the core specification forbid. This gives us information about the invasive aspects harmfulness. Such information is used to assist the developer to reason about the impact of aspects on the composed program.

We detect violations of specification in the following way: At the aspect level, for each aspect we obtain the classes it targets adding fields, methods or modifying the hierarchy. Then, we compare the specification of forbidden patterns on each class with the specification of the aspect. At the advice level, for each advice we obtain the methods it advises. Then, we compare the specification of forbidden patterns on each method with the specification of the advice. For the advices accessing fields, the matching is analogous to the previous.

A specification framework for interactions

We have implemented a tool for matching specification as well a language to express the base program specifications called ABIS (Aspect-Base Interaction Specification) 1 ABIS is built on top of the AJDT eclipse plug-in and is completely integrated with eclipse. After a short presentation of the global structure of ABIS we detail how each aspect and advice is automatically classified. Then we describe how to specify the base program with the expected invasiveness patterns.

Figure 4 presents the ABIS' organization. We extend the AspectJ AST Visitor (1) in order to create a simplified (SAST) version of the Abstract Syntax Tree (AST). ABIS obtains information about the structure of the program (aspects and base program) from AJDT and builds a model of the program structure (2). This model contains the relations between aspects and the base program (advised and introduced element relations). An automatic classification process inspects the SAST and classifies each aspect and advice according to its invasiveness pattern [START_REF] Bockisch | Adapting virtual machine techniques for seamless aspect support[END_REF]. Then the model and the classified advices are checked following the previously 1 Available at http://contract4aj.gforge.inria.fr presented matching process (4). If specification violations are found, then they are reported to the eclipse GUI (5).

Automatic classification of aspects

ABIS is able to automatically identify invasiveness patterns in aspects and advices according to their de-facto properties. Then, by using the identified patterns, aspects and advices are classified according to the classification presented in section 3.1. [START_REF] Meyer | Object-Oriented Software Construction[END_REF][START_REF] Mezini | Conquering aspects with caesar[END_REF][START_REF] Munoz | Vigilant usage of aspects[END_REF][START_REF] Munoz | A classification of invasive patterns in aop[END_REF]. The root node of the SAST corresponds to the advice declaration. From the root node, we find the parameter declaration and the advice body node. The children of the body node are the statements declared on the advice. The node assignment corresponds to the assignment in line 10 of Listing 1. The node proceed call represents the call to the proceed(arg) method (line 11 of Listing 1) (it executes the intercepted method) and its children are the arguments it receives.

The classification algorithm applied to the Encryption aspect is the following:

1. Initially, select all the advice argument nodes (step 1, argument arg).

2. Traverse the SAST searching for the nodes representing a call to the proceed method (proceed node).

(a) If all the arguments nodes reference the advice parameter nodes, then select it (step 2, proceed(arg)).

(b) If the proceed arguments are different from the advice parameters, then classify the advice as Parameter passing. The process proceeds as follows: once obtained the advices SASTs a set of identification rules are applied to them. The results of this inquiry are the invasiveness patterns that the inspected SAST realizes. For example, an identification rule can check whether the left hand side of an assignment node is a reference to an object field, and then detected the invasiveness pattern Write.

Aspects invasive patterns are detected according to the aspect structural declarations. For example, if an aspect declares Inter-Type field, then the detected invasive pattern is Field Addition.

Writing specification in the base program

The base program specification is represented as metainformation by using Java 5 annotations [START_REF] Bloch | A metadata facility for the java programming language[END_REF]. The parameterized annotation @Spec([allow=..|forbid=..]) specifies the expected invasiveness pattern in the base program. It can be attached to classes, fields and methods, and the possible values for its parameters vary as described in section 3.2.

The parameters allow and forbid are exclusive, i.e. only one can be used in each specification. The allow parameter indicates the invasiveness patterns allowed to interact with the base program. The default policy is to allow the non-invasiveness patterns Augmentation, Crossing and Read. Analogously the forbid parameter indicates the invasiveness patterns forbidden to interact with the base program. The compile-time feature of the tool is also a drawback. The current implementation is unable to detect and check dynamic join points (for example using the if keyword in As-pectJ).

Case study revisited

In this section we revisit the case study presented in section 2 by specifying the interaction between aspects and base program. Then, we use these specifications to spot and solve the problems that arise after the base program evolution.

Specifying the initial version

We annotate the initial version of the chat application specifying the allowed invasiveness pattern. The annotations we added allow the invasiveness patterns that interact safely with the base program. Therefore, only the advices realizing the specified patterns can advise the base program. Listing 3 and 4 present the fragment of the specified methods. The methods send, transmit and retransmit were specified to allow the invasiveness pattern Argument passing. Aspect were automatically specified by ABIS. Thanks to these specifications, ABIS informs that no aspect is violating the base program specifications. Furthermore, the addition of annotations is transparent for the tests we execute, hence, the test results are not affected.

Evolution with specification, problems detection and solving

After specifying the initial version of the chat application, we evolve it as explained in section 2.5. As a result of this evolution, ABIS reports that some aspects are violating the base program specifications. The reports indicate that the aspects EncryptionAspect and UniqueName are violating the specifications on AuthenticatedClient (attach method) and AuthenticatedServer (send and transmit methods) respectively. This means that potentially unexpected behavior can emerge from the weavage of these invasive aspects advising new join points.

Using this information we trace unexpected interactions to the violator advices (problems presented in section 2.7). Knowing the violating pattern helps us reasoning about the causes of the unexpected interaction, hence, reasoning about the source of the problem. For example, the violating pattern Conditional Replacement tells us that something is wrong because it is possible that a method, which must always execute, sometimes will not be executed.

The further correction of the problems is a developer decision, however, the violated specification may help making the solution. In this case, we have applied the same procedure used in section 2.7, i.e. change the point-cut descriptors. Once applied the corrections, ABIS reports that no specification is violated and aspects are valid in relation with the base program specifications.

Discussion

Specifying interactions gives feedback about the harmfulness of aspects. This information assists developers in the process of creating an aspect-oriented program and ensuring that aspects perform as expected. It also helps developers to be conscious about the aspects they write and enforces the reasoning about the interaction between aspects and base program.

The violation of an specification indicates that a developer may review the code of the violator aspects and reason about their impact on the base program. Besides, specifying interactions reduce the effort and time required to locate faulty aspects because there is no need to successively execute a set of tests. We thinks that all these reasons justify the effort and time involved in specifying (annotating) the base program.

The Open Closed Principle [START_REF] Meyer | Object-Oriented Software Construction[END_REF] describes that a module/class should be open for extension but closed for modification. Of all the principles of object oriented design, this is the most important. It means that we should write modules so that they can be extended without requiring them to be modified. In other words, we must be able to change the modules behavior without changing their code. Our framework is completely coherent with this principle. Aspects offer a new way to extend the behavior of classes without modifying their code (classes are opened). Therefore, developers have to anticipate these potential extensions and specify which kind of behavior modification (invasiveness pattern) is allowed.

Related work

The characterization of aspects has already been explored. In [START_REF] Rinard | A classification system and analysis for interactions in aspect-oriented programs[END_REF] categories of direct and indirect interactions between aspects and methods are identified. Direct interaction is whether an advice interferes with the execution of a method, whereas indirect is whether advices and methods may read-/write the same fields. This classification is similar to ours, however, it addresses a different dimension. We identify invasiveness patterns instead of direct/indirect interactions. Moreover, in our work the identification of invasive patterns is only a portion of a whole specification framework. In [START_REF] Katz | Diagnosis of harmful aspects using regression verification[END_REF] aspects are characterized among Spectative, Regulatory and Invasive aspects according to their invasiveness. This classification is similar to ours, however, our characterization of is more fine grained.

Several approach have been proposed to control the interactions between aspects and the base program. Spectators and Assistants [START_REF] Clifton | Observers and assistants: A proposal for modular aspect-oriented reasoning[END_REF] proposes to control interactions by specifying the invasive aspects that can advise the base program. It classifies aspect among Spectators (non invasive advices) and Assistants (invasive advices). Then, the base program explicitly demands the assistance of assistant aspects (identified by their names). We propose the same type of specifications, but we address a finest granularity and abstraction by referring to invasiveness patterns instead of specific invasive aspects.

Open Modules [START_REF] Aldrich | Open modules: Modular reasoning about advice[END_REF] is a system that focuses on the exposure of specific join-points. This approach hides all the joinpoints, then each module declares the join-point it will expose. Open Modules goes in a similar direction than our work. However, we perform this task in a very different way. Open Modules exposes join-points without distinguishing the aspects advising them, whereas we expose joint-point to aspects realizing specific invasiveness patterns. Moreover, our approach is intended to verify and validate aspect-oriented programs and assist developers when creating aspects.

XPI [START_REF] Griswold | Modular software design with crosscutting interfaces[END_REF] are interfaces that mediate between aspects and the base program. They establish a set of design rules to im-plement aspects and the base program in such a way that the evolution is coordinated through the XPI. This approach restraint the manners in which developers may write programs. Instead, to check whether advices may be harmful to the base program, then advising developers to check the potential unexpected interaction introduced by invasive aspects.

An approach to assist developers is proposed in [START_REF] Störzer | Using pointcut delta analysis to support evolution of aspect-oriented software[END_REF]. Through an analysis that compares the changes in the set of matched join-points for two different version of a program it reveals unexpected changes in the matching behavior of point-cuts. This analysis serves to assist developers finding bugs introduced by broken point-cuts. This work is close to ours. However, the dimensions in which this is accomplished are very different. Our approach advises developer about the potential undesired interactions introduced by invasive aspects instead of broken point-cuts. Moreover, our approach require the specification of the base program, which we think enforces the reasoning about the interactions with aspects.

Conclusions

The evolution of aspect-oriented programs is a complicated issue because necessary interactions of one version can introduce issues after evolution. This occurs as a consequence of the AOSD-Evolution paradox and invasive aspects. Through the evolution of an aspect-oriented chat application we have shown that tracing problems to unexpected interactions is a long and tedious process. Such a process involves rigorous manual inspection of code and the execution of several test scenarios.

This paper tackles this problem by specifying the interactions between aspect and the base program. Aspects are specified with the invasiveness patterns they realize, and the base program with assertions allowing or forbidding invasiveness patterns. The violations of these specifications are used to alert developers about the risk introduced by unexpected interactions. This assists developers reviewing the harmful code and to reason about its interaction with the base program. By specifying and evolving the chat application we have shown that specifying interactions reduces the time and effort necessary to locate problems introduced by unexpected interactions.

The specification of aspect-oriented programs improves their maintenance and evolvability. It also increases the confidence that developers have on aspect. This because developers can ensure that critical parts of the base program will not be modified unexpectedly by future addition of aspects.

Acknowledgments

This work was partially supported by the european project DiVA (EU FP7 STREP).

Figure 1 .

 1 Figure 1. Chat application class diagram

Figure 2 Figure 2 .

 22 Figure 2 depicts schematically the association

Figure 3 .

 3 Figure 3. Base program specification covering

Figure 4 .

 4 Figure 4. ABIS structure diagram

Figure 5 .- 12 Figure 5 ,

 5125 Figure 5. SAST of Encryption aspect, Listing 1, lines 9-12 Figure 5, shows the SAST of the first advice of the Encryption aspect (Listing 1, lines[START_REF] Meyer | Object-Oriented Software Construction[END_REF][START_REF] Mezini | Conquering aspects with caesar[END_REF][START_REF] Munoz | Vigilant usage of aspects[END_REF][START_REF] Munoz | A classification of invasive patterns in aop[END_REF]. The root node of the SAST corresponds to the advice declaration. From the root node, we find the parameter declaration and the advice body node. The children of the body node are the statements declared on the advice. The node assignment corresponds to the assignment in line 10 of Listing 1. The node proceed call represents the call to the proceed(arg) method (line 11 of Listing 1) (it executes the intercepted method) and its children are the arguments it receives.The classification algorithm applied to the Encryption aspect is the following:

3 .Figure 6 .

 36 Figure 6. Automatic advice classificationFigure6depicts the automatic classification process or advices. The process proceeds as follows: once obtained the advices SASTs a set of identification rules are applied to them. The results of this inquiry are the invasiveness patterns that the inspected SAST realizes. For example, an identification rule can check whether the left hand side of an assignment node is a reference to an object field, and then detected the invasiveness pattern Write.Aspects invasive patterns are detected according to the aspect structural declarations. For example, if an aspect declares Inter-Type field, then the detected invasive pattern is Field Addition.

1 @Listing 3 .

 13 Spec(allow={"ConditionalReplacement"}) 2 public synchronized int attach(Client client) attach method specified with an annotationListing 3 shows the attach method of the standard server specified with an annotation (line 2). Finally, this method allows advices realizing the following patterns to advise it: Augmentation, Crossing, Conditional replacement and Read. All the other patterns are forbidden.

4. 3 .

 3 Contribution of the ABIS frameworkABIS statically computes and gives information, at compile-time, about the specification violation. This information is a useful and valuable:1. Feedback for developers in the process of writing advices a specifying the base program. 2. For verifying an aspect-oriented program when aspects and the base program are developed separately. 3. For verifying an aspect-oriented program when aspects or the base program evolve.


Freddy Munoz
email: fmunoz@irisa.fr

Benoit Baudry
email: bbaudry@irisa.fr

Validation challenges in model composition: The case of adaptive systems *

Keywords: Model Driven Engineering, Aspect Oriented Modeling, Model Composition Validation, Model Validation, Model Driven Engineering for Adaptive Systems

Model Driven Engineering helps dealing with complexity by promoting models as abstraction units. Aspect Oriented Modeling helps separating concerns that crosscut across different models. MDE and AOM have well identified challenges that need to be addressed. However, there are new challenges that appear when combining both techniques. In this paper we present the challenges that appear when validating the model composition in the context of MDE and AOM applied to adaptive systems.

Introduction

Model Driven Engineering (MDE) promotes abstraction as a basis for managing complexity. MDE proposes the systematic use of models as primary engineering artifacts. Such models can have a variety of natures and range in abstraction and complexity. Models from higher abstraction level are refined (transformed) into lower levels until the implementation. Besides, models can be transformed from one domain to another in order to ease the resolution of a defined problem.

Aspect Oriented Modeling (AOM) helps separating crosscutting concerns at model level by encapsulating them into different modeling dimensions referred as aspect. AOM enables a clear modularization of the different concerns constituting a design model. It also allows designers to reason about each concern separately, and later composed into a global model.

Research challenges have been widely identified for AOM and MDE [START_REF] France | Model-driven Development of Complex Software: A Research Roadmap[END_REF]. Model transformation testing [START_REF] Baudry | Model Transformation Testing Challenges[END_REF], model verification and validation [START_REF] Faivre | MoDeVVA: 5th workshop on Model Driven Engineering, Verification, And Validation: Integrating Verification And Validation In MDE[END_REF], and AOM weaving mechanism definition [START_REF] Aldawud | AOM: 11th International Workshop on Aspect-Oriented Modeling[END_REF] are just a few examples of the challenges faced by these technologies.

Nevertheless, not all the challenges have been identified as far as validation in MDE and AOM is concerned. Challenges regarding the composition and refinement of aspect models need to be identified. This is critical to ensure that composed models will perform as expected, and therefore, their refined implementation will do so [START_REF] Baleani | Correct-by-construction transformations across design environments for model-based embedded software development[END_REF][START_REF] Dion | Correct-by-Construction Methods for the Development of Safety-Critical Applications[END_REF]. This is a fundamental issue for the adoption of AOM as a mechanism for separation of concerns and MDE as a complexity coping mechanism.

In this paper we present the challenges that arise from the validation of model composition. We specially address the challenges that arise in the case of adaptive systems, where models are used to abstract from the executing platform and aspects represent the dynamic variability of system. Such challenges range from the combinatorial explosion produced by the composition order of different aspects, to the specification of the model resulting from the composition.

The remainder of this paper is organized as follows. Section 2 presents MDE and AOM applied to adaptive systems. Section 3 presents the challenges that arise when validating AOM and MDE in the context of adaptive systems. Finally, section 4 concludes.

MDE and AOM for adaptive systems

Designing, developing, maintaining and executing adaptive systems is very complex and error prone. Model Driven and Aspect Oriented techniques can help dealing with this complexity. In this section we present the contribution of MDE and AOM to handle the complexity when dealing with adaptive systems.

Adaptive systems are software systems capable of change their internal structure and behavior in response to changes in their environment [START_REF] Aksit | Dynamic, Adaptive, and Reconfigurable Systems Overview and Prospective Vision[END_REF]. They are typically deployed in heterogeneous computing devices ranging from mobile devices such as phones or PDAs to large computer systems. Generally, several variation points are defined in order to develop an adaptive system. Each variation point represents a different option in the system implementation that might be chosen to adapt the system. The selection of different variation points to derive the adapted system leads to a huge number of possible configurations. Reasoning over that huge set of configurations to choose the best possible configuration to adapt is too time consuming because of the large number of evaluations needed. Moreover, the adaptation logic relies on reconfiguration policies that are generally complex lowlevel and hand-written in the application producing large and complex reconfiguration files. These factors make the construction, execution and maintenance of adaptive systems highly complex. MDE and AOM help dealing with this complexity by the meaning of abstraction and separation of concerns [START_REF] Morin | An Aspect-Oriented and Model-Driven Approach for Managing Dynamic Variability[END_REF].

MDE techniques provide the means to automate and optimize the creation of reconfiguration scripts. Besides, MDE helps abstracting from the target platform by defining models independent of target devices and technologies. Models representing the system in execution (models at runtime) help to manage the execution at more abstract level; therefore, they enable designers to reason about the system properties and adaptation logic at higher level.

Aspect-Oriented modeling techniques [START_REF] France | Providing Support for Model Composition in Metamodels[END_REF][START_REF] Jayaraman | Model Composition in Product Lines and Feature Interaction Detection Using Critical Pair Analysis[END_REF][START_REF] Lahire | Introducing Variability into Aspect-Oriented Modeling Approaches[END_REF][START_REF] Morin | Weaving Aspect Configurations for Managing System Variability[END_REF] help encapsulating distinct variation points into aspects separated from the base model functionalities. Different aspects might be composed with the base model in order to obtain different configurations. This reduces the reasoning space to a limited number of aspects, therefore avoiding the combinatorial explosion due to different variants. Figure 1, presents an overall approach for adapting systems by using MDE and AOM techniques. At design-time, the application base (AM) and variant architecture (AS) models are designed. At this time, the adaptation model, which states when, and how to adapt is built. At runtime, the adaptation mechanism processes the adaptation model in order to adapt when needed [START_REF] Aksit | Dynamic, Adaptive, and Reconfigurable Systems Overview and Prospective Vision[END_REF]. When an adaptation is required, the adaptation mechanism chooses (driven by the adaptation model) a set of aspects (variants) and weaves them into the base (2). This weaving results in multiple models that could be used to adapt the executing system. The adaptation mechanism chooses only one model (3) and then automatically generates the reconfiguration scripts used to adapt the executing system (4).

Challenges

MDE and AOM can help dealing with the complexity involved in the life cycle of adaptive systems. However, their usage raises new challenges regarding the validation of model composition. In the following we summarize the challenges and research questions related to the validation in the context of adaptive system. 1): The selection of the best possible configuration is critical for adaptive systems. The aspects modifying the base configuration must produce configurations that will not break down the system and that response in the best possible way to environmental changes . Therefore, it is crucial to ensure that the composed models fit the adaptation requirements. A model that is valid with respect to the adaptation requirements will lead to a correct adaptation. Testing techniques such as combinatorial testing [START_REF] Grindal | Handling Combinatorial Explosion in Software Testing[END_REF][START_REF] Yilmaz | Covering Arrays for Efficient Fault Characterization in Complex Configuration Spaces[END_REF] and search based testing [START_REF] Mcminn | Search-based software test data generation: a survey[END_REF] may help validating that the composed model fits the adaptation requirements. Such testing techniques provide the means to explore a huge adaptation space and test whether the chosen configurations are fitted adaptations. Formal behavioral specification techniques [START_REF] Zhang | Model-based development of dynamically adaptive software[END_REF] may also be useful to verify that the composed models will fit the adaptation invariants.

Validation of composed models (3 in figure

It is an intuition to think that, if the chosen aspects are valid and the base model is valid, then the composed model will be valid. Is this always true? How can it be ensured? These questions are fundamental because they may allow to reason about the aspects and model validity separately and then compose a valid model. However, event if this is true, it is still an issue how to validate the aspect models and how to validate the base model. Moreover, the composition engine must also be valid in order to produce valid compositions. 1): The weaving of different aspects leads to different composed models. Likewise, the weaving order of aspects may also generate different models. Therefore, the rate of models resulting from the composition of different aspects and composition orders grows exponentially with the amount of aspects to weave. Moreover, there is no assurance that the composed models will be valid or fits the adaptation requirements. This is a serious issue because it is necessary to validate a huge amount of composed models. Such validation may consume an unrealistic amount of time. 1): Different aspects have different effects on the base model. Some aspects may add new system properties whereas others may remove them. The effect of aspects may depend on the order in which they are weaved. For instance, consider two aspects, one relating the communication (C) and another relating the security concerns (S). When C is woven first, the system network response is very short, whereas when S is woven first, the system network response is slower but more secure. Some weaving orders or combinations of aspects could add or remove system properties unexpectedly. Controlling the emergence of properties introduced/ removed by aspects is very important to ensure that the composition result will be valid and aspects will perform as expected. Similar problems have been studied at code level. Solutions such as the specification of the aspect behavior [START_REF] Aldrich | Open Modules: Modular Reasoning About Advice[END_REF][START_REF] Clifton | Observers and Assistants: A Proposal for Modular Aspect-Oriented Reasoning[END_REF][START_REF] Munoz | Improving Maintenance in AOP Through an Interaction Specification Framework[END_REF] are used to increase the maintainability of aspect-oriented programs. The properties added/ removed by the aspects are controlled by the specifications. Aspects adapting a system will interact in a variety of ways. Some interactions may include/ exclude the weaving of some aspects; other interactions may interfere or partially invalidate the effect of aspects over the system. Moreover, interactions and the effect of aspects may change according to the target model they are weaved into. Therefore, detecting aspects interactions in advance is very important to avoid composition conflicts and know before hand the aspects dependencies [START_REF] Sanen | Classifying and documenting aspect interactions[END_REF][START_REF] Truyen | Support for distributed adaptations in aspect-oriented middleware[END_REF]. This issue is related to critical pair analysis [START_REF] Detlef | Hypergraph rewriting: critical pairs and undecidability of confluence[END_REF][START_REF] Leen | Efficient Conflict Detection in Graph Transformation Systems by Essential Critical Pairs[END_REF][START_REF] Praveen | Model Composition in Product Lines and Feature Interaction Detection Using Critical Pair Analysis[END_REF] in which the conflicts between different interacting features are detected via graph analysis. Critical pair analysis detects functional inclusive/ exclusive aspects configurations. However, interaction issues can be beyond functional interactions. Aspects can have a qualitative impact over the system, for instance making the quality of service better or worst. At code level, the characterization of interactions could be used to determine patterns of interactions for instance to detect aspect interferences [START_REF] Katz | Diagnosis of Harmful Aspects Using Regression Verification[END_REF].

Combinatorial explosion of composed models (2 in figure

Aspects effects and interactions (2, 3 in figure

Runtime / Design time validation: Since adaptation happens at runtime, adaptive systems have to respond to hard time and hardware constraints when adapting, a fundamental question is how much of the validation and analysis can be done statically? The ideal will be to calculate at design time all the possible interactions and effect of aspects and their possible weaving orders. However, this may not be possible due to the huge amount of possible weaving orders An idea to cope with these issues is defining contracts on the aspect models. These contracts may be an abstract specification of the effect of the aspects over the system and the interactions between aspects. For instance, they can explicitly declare that an aspect will increase the overall system security but making it slower. They could also allow us to calculate optimal and valid weaving orders. By specifying include/ exclude relations between aspects. Moreover, they may be helpful to detect interactions conflicts at design time, thus saving some computation time when adapting at runtime. The abstract description of the aspects' effect will help determining whether aspects may be valid or not in relation to a base model.

Conclusions

In this paper we have identified the challenges that appear when validating the model composition in the context of adaptive systems. Issues such as the weaving order of aspect models, interaction issues and the validation of the composed model are not trivial. Tackling these issues is fundamental to assess the usage of MDE and AOM.

We have pointed out possible ways to address the validation challenges presented here. We specially suggest the definition of contracts to tackle several challenges and ease the solution of others. In future work we will explore how contracts must look like, which information they must contain and how to successfully use them at design time and runtime.

Fig. 1 .

 1 Fig. 1. Overall MDE/AOM approach for adaptive systems

* This work was partially funded by the DiVA project (EU FP7 STREP)