Martin Monperrus

Jean-Marc Jézéquel

Joël Champeau

Brigitte Hoeltzener

A Model-driven Measurement Approach

Companies using domain specific languages in a model-driven development process need to measure their models. However, developing and maintaining a measurement software for each domain specific modeling language is costly. Our contribution is a model-driven measurement approach. This measurement approach is model-driven from two viewpoints: 1) it measures models of a model-driven development process; 2) it uses models as unique and consistent metric specifications, w.r.t a metric specification metamodel. This declarative specification of metrics is then used to generate a fully fledged implementation. The benefit from applying the approach is evaluated by two applications. They indicate that this approach reduces the domain-specific measurement software development cost.

Introduction

Model-driven engineering (MDE) [START_REF] Schmidt | Model-driven engineering[END_REF] is an approach to software development that advocates the creation of domain-specific languages (DSL). Contrary to general-purpose programming languages, a domain-specific language addresses a limited range of applications. The main goal of DSLs is to reduce the product development cost by means of generative techniques [START_REF] Lédeczi | Composing domain-specific design environments[END_REF]. From a MDE viewpoint, the DSL is specified with a metamodel; a program written in a DSL is called a model.

To address safety-critical concerns or quality assurance, models need to be measured. Ledeczi et al. state [START_REF] Lédeczi | Composing domain-specific design environments[END_REF], that another use of the models is design-time diagnosability analysis to determine sensor coverage, size of ambiguity groups for various fault scenarios, timeliness of diagnosis results in the onboard system, and other relevant domain-specific metrics. More recently, a similar point of view is expressed by Schmidt et al. [START_REF] Schmidt | Model-driven engineering[END_REF]: in the context of enterprise distributed real-time and embedded (DRE) systems, our system execution modeling (SEM) tools help developers, systems engineers, and end users discover, measure, and rectify integration and performance problems early in the system's life cycle.

Contrary to general-purpose programming language measurement software, domain-specific measurement software is not a big enough niche market; that is to say there are no measurement software vendors for specific domains. Hence, companies have to fully support the development cost of the model measurement software.

Conversely, generative techniques (e.g. [START_REF] Budinsky | Eclipse Modeling Framework[END_REF]) are used to generate most of the modeling environment from an abstract definition of the domain, called a metamodel. These techniques allow a low-cost modeling environment. Systems are produced by means of model-driven code generation, as well as modeling environment. In this context, it is not conceivable to manually develop the measurement software. Indeed, the NASA recommends that the cost of measurement should not add more than 2 percent to the software development or maintenance effort [START_REF]Software measurement guidebook[END_REF].

Classical object-oriented program measurement software packages are complex and costly [START_REF] Marinescu | Towards a simplified implementation of object-oriented design metrics[END_REF]. Similarly, the cost of a DSL measurement software comes from several requirements which are mainly: the automation of measurement, the integration into a modeling tool, the communication between the domain expert and developers, the need for extensibility and tailoring.

Our goal is to address the cost of a DSL measurement software by providing a generative measurement approach that can be applied to any kind of models. In other words, we would like to be able to generate a measurement software for design models, architectural models, performance models, requirements model, etc.

Our contribution is a model-driven measurement approach (we will use the expression MDM approach later in the paper). The core of the contribution is a metric specification metamodel. This measurement approach is model-driven from two viewpoints: 1) it measures models of a model-driven development process; 2) it uses models as unique and consistent metric specifications, w.r.t the metric specification metamodel. This approach consists of specifying metrics as instance of the metric specification metamodel. These metric specifications refer to a domain metamodel. The metric specifications are used to generate a fully fledged measurement software. The generated artifacts fully fullfill the requirements for measurement software presented above. The benefit from applying the MDM approach is evaluated with two applications.

The remainder of this paper is organized as follows. In section 2, we present the full process of model-driven measurement. Then, we present the metric specification metamodel (section 3). The instantiation of the whole approach is presented in two different contexts (section 4), including in an industrial one. We finally discuss related works in section 5 and conclude.

Overview of the MDM Approach

The measurement approach presented in this paper is intended to be applied to models of a MDE software development i.e.; applied to models fully described by a metamodel, which is later called domain metamodel. Our intuition was [START_REF] Monperrus | Counts count[END_REF] that it is possible to generate a measurement software from an abstract and declarative specification of metrics. This abstract level for metrics can be defined by a metamodel as well. In other words, the measurement software is generated from a model of metric specifications. Figure 1 presents our model-driven measurement approach as an UML activity diagram. The application of the MDM approach begins by considering a model space. This can be done into two ways. On the one hand, one can create a domain metamodel that exactly fits a given family of systems. On the other hand, one can choose an existing metamodel, for instance a standard one. Then, the MDM approach consists in specifying metrics as instances of a metric specification metamodel. This metric specification metamodel is the core of our contribution. It is presented in the next section. The metric metamodel is domain-indenpendent i.e.; does not contain concepts specific to a domain. It only contains concepts related to metrics. The next step of the MDM approach is to identify the models that will be measured. It is possible to measure models created for other engineering activities (e.g.; simulation) or to create new domain models. Eventually, the MDM approach allows to really measure models by means of generative techniques described below.

Figure 1 also sums up the artifacts involved in the approach. The metric specification metamodel is the core artifact, it remains unmodified in whatever applications of the MDM approach. A set of metric specifications is an instance of the metric specification metamodel. A metric specification refers to concepts of the domain metamodel. Domain models are created conforming to the domain metamodel and can be measured thanks to the metric specifications. Note that the same domain models can also ground other engineering activities such as code generation, verification and validation, or model transformations.

The MDM approach is a solution to the issue of the measurement software cost because all the models involved ground code generation. The metric specification metamodel is used to generate the metric specification editor. For this activity, the MDM approach is based on existing techniques [START_REF] Sztipanovits | Advances in model-integrated computing[END_REF][START_REF] De Lara | Atom3: A tool for multi-formalism and metamodelling[END_REF][START_REF] Budinsky | Eclipse Modeling Framework[END_REF]. The metric specification model is used to generate the measurement software itself. This generation activity is fully automated. The generator is implemented as methods of the metric specification metamodel. These methods output the corresponding

In: Proceedings of the ACM/IEEE 11th International Conference on Model Driven Engineering Languages and Systems (MODELS'2008) Java code. To sum up, a metric specification model is taken as input to a generator which outputs a fully fledged measurement software integrated into the generated modeling environment. Hence, the MDM approach gives an enhanced modeling environment; where the enhancement consists of the measurement features.

To conclude this overview, the prototype that supports the MDM approach has been developed in the Eclipse (a generic development environment, see www.eclipse.org) and EMF [START_REF] Budinsky | Eclipse Modeling Framework[END_REF] world. Metric specifications and domain models are EMF models w.r.t an EMF metamodel. The prototype generates an Eclipse plugin directly from the metric specifications. This plugin is a fully-functional software integrated into Eclipse.

The Metric Specification Metamodel

The MDM approach consists in specifying metrics as an instance of a metric specification metamodel. The metamodel is a definition of the metric concepts. It grounds the complete generation of the measurement software from an instance of the metamodel, called a metric specification model. The concepts of the metric specification metamodel can be applied to any domain models. For instance, the same concept can be instantiated as a metric for implementation models, real-time models, software architecture models or requirements models. In that sense, our metric specification metamodel is domain-independent [START_REF] Monperrus | Measuring models[END_REF]. It has been built following a bottom-up approach: from existing metrics to concepts of the metamodel. In regard to the application cases we studied, no other parts are needed. Supporting example and syntax The presentation of the metric specification metamodel will be helped by several examples. Note that the concepts of the metric specification metamodel will be further called classes. Main ones will be emphasized as italic. Examples consists of instances of the metamodel. Illustrative metrics are for a simple domain metamodel for software architecture depicted in figure 2. In this domain metamodel, the concepts manipulated are Component and Interface, and their relationships. This example metamodel is presented for demonstration purposes only.

A proto-textual syntax is used to textually represent the metrics, because a XMI-based model is not readable. Since our approach is model-driven, the most important artifacts remains the metamodel and its conforming models. That's why we use a proto-syntax and do not further define and discuss it. However, for sake of understandability, we tried to define an intuitive one, with explicit cognitive links between keywords and the metric specification metamodel. A MetricSpecificationSet refers to a domain metamodel (attribute metamod-elURI), and to a ComputationStrategy. A computation strategy defines which parts domain model are measured. This can be a file, a predefined list of model elements or a transitive closure on all model elements. A MetricSpecification is an abstract class that defines an atomic metric specification. Note that we use MetricSpecification and not Metric alone, to be able to differentiate a metric specification from a metric value. The modeling of measurement results i.e; metric values and their interpretation, is outside the scope of this metamodel. A MetricSpecification is subclassed. The DerivedMetricSpecification class handles arithmetic and based function based metrics (e.g.; addition, exponential): the subclassess of DerivedMetricSpecification are used to express complex metric formula. CollectionBasedDerivedMetricSpecification is the class that handles higher order metrics, mainly statistical operators, based on a set of metric values. It is subclasses as Sum, Average, Median, Stddev which are not represented in figure 3. The last subclass of MetricSpecification is PredicateMetricSpecification.

A PredicateMetricSpecification is an abstract class that contains a predicate. A predicate is a function from the set of model elements to the truth values.

Predicate-related classes are presented later. Predicates are an important part of a metric specification since they precisely define the considered model elements for a given metric specification. We now consider the concrete classes that can be instantiated. The right part of figure 3 shows the classes that are instantiated as a metric specification for a given domain metamodel.

A SigmaMetric metric specification is the count of model elements that satisfy a predicate. The predicate can be as complex as needed. Similarly, the TauMetric is the count of model links; i.e. a link between two model elements. In this case, one has to specify the considered reference and if necessary, predicates for the link root and the link target. In the listing below, two instances of these classes considering the example domain metamodel of figure 2 are presented. A metric specification starts with the declaration of its type, a mandatory identifier, and an optional textual description. Then comes the declarative part of the metric. For instance, a SigmaMetric declares a predicate and a TauMetric a reference name. Note that the predicate is a textual syntax of predicate-based model elements, that will be presented later. The PerX class is an abstract class to specify metrics that are related to a given model element. By definition, the measurement of a domain model thanks to a PerX metric specification gives several values. The subclasses of PerX can be considered per se, or be given as input to a CollectionBased metric specification presented above, for instance the statistical operator average.

A ValuePerX metric specification represents metrics that can be obtained by considering only the model element satisfying a predicate. The ValuePerX class is abstract. It is subclassed as AttributeValuePerX, MultiplicityPerX. An AttributeValuePerX is a metric whose value is directly given by an attribute of the model element. A MultiplicityPerX metric is directly given by the actual multiplicity of a reference. Let us now consider two instances of these classes. A AboutMeMetricSpecification is a metric that considers a given object as primary variable. This metric type is used each time the domain model contains derived relationships. That is to say, when a metric is the number of elements that has something to do with an object (symbolized by me in the name), but when there is not the corresponding reference is the domain metamodel.

A x satisfy " this . isInstance ( Component )" elements satisfy " this . isInstance ( Interface )" references followed " required , provided , extends " endmetric metric A b o u t M e M e t r i c S p e c i f i c a t i o n COUPLING is description " coupling to this interface " elements satisfy " Interface . isInstance ( self )" internal metric spec is metric SigmaMetric COUPLING_ is description " used for COUPLING " elements satisfy " this . provided == __me__ or this . required == __me__ " endmetric metric P a t h L e n g t h M e t r i c S p e c i f i c a t i o n DD is description " Depth in decomposition "

x satisfy " this . isInstance ( LeafComponent )" references followed " container " endmetric Metric specifications heavily rely on predicate. We now present the definition of predicates in the metamodel. This presentation is supported by figure 4.

A predicate can be composed of an arbitrary number of subpredicates, in the same manner as a boolean function. Therefore, the metamodel contains the AndPredicate, OrPredicate, and NotPredicate. There are also classes to handle tests on the type of the model element. They are subclasses of the TypePredicate class. IsInstance tests the metaclass of a model element; IsDirectInstance tests the metaclass or one of its superclasses. The remaining class OnFeaturePredicate handles tests on features of a given model element. In this context, a feature means an attribute (e.g. a string "foo"), or a reference to another model element. OnFeaturePredicate class is further presented in the next paragraph.

The right part of figure 4 shows what are the possible tests on a given feature. ObjectEqualityPredicate enables us to test whether a reference points to a model element referred by a variable. ValuePredicate enables to test the value of an attribute (e.g. a boolean equals to "false" or an integer equals to "13"). LambdaPredicate enables us to apply a predicate to all elements of a collection. It is subclassed as Exists and ForAll to express first-order logic quantifiers. For sake of space, the following predicates do not appear on the figure. Contains us enables to test if a collection contains a model element referred by a variable. MultiplicityPredicate (not on the figure) enables us to test the actual size of a collection.

Limitations of the MDM approach Since the metamodel is declarative, all metrics that are defined on top of explicit concepts of the metamodel can generally be specified within the MDM approach. The reciprocal statement is also true: any metrics that is composed of concepts not present in the metamodel cannot be expressed within the MDM approach. This point will be illustrated in the next section.

We have presented in this section the backbone of our model-driven measurement approach: the metric specification metamodel. An instance of this metamodel is a set of metric specifications formalized enough to generate the complete measurement software implementation.

Study of Instances of the MDM Approach

In this section we present the application of the MDM approach into two different contexts i.e.; the instantiation of the metric specification metamodel for two different domain metamodels.

Considering a Java program as an implementation model

Let us consider Java programs as models conforming to Java metamodel. We can then specify Chidamber and Kemerer metrics [START_REF] Chidamber | Towards a metrics suite for object-oriented design[END_REF] within the MDM approach. This viewpoint will help to demonstrate that 1) our metric specification metamodel encompasses with existing software metrics and 2) the code volume of the metrics implemented within the MDM approach is much smaller than the volume of the final executable code.

We have used the SpoonEMF (http://tinyurl.com/spoonemf) tool to transform a Java software to an Eclipse/EMF model. SpoonEMF is a binding between Spoon and EMF. Spoon [START_REF] Pawlak | Spoon: Program analysis and transformation in java[END_REF] provides a complete and fine-grained Java metamodel where any program element (classes, methods, fields, statements, expressions, etc.) is accessible. SpoonEMF transforms a whole Java software into a single XMI model file.

We will now present the specification of the Chidamber and Kemerer metrics [START_REF] Chidamber | Towards a metrics suite for object-oriented design[END_REF] as instance of our metric specification metamodel refering to the Spoon/Java metamodel. It is a fully declarative specification.

Weighted Methods per Class: We consider the Basili et al's [START_REF] Basili | A validation of object-oriented design metrics as quality indicators[END_REF] version of WMC, which is the number of methods defined in each class. metric M u l t i p l ic i t y P e r X WMC is description " Weighted Methods per Class " elements satisfy " this . isInstance ( CtClass )" reference is " Methods " endmetric Depth in Inheritance Tree per Class: DIT is defined as the maximum depth of the inheritance graph of a class.

metric P a t h L e n g t h M e t r i c S p e c i f i c a t i o n DIT is description " Depth in Inheritance Tree per Class "

x satisfy " this . isInstance ( CtClass )" references followed " Superclass " endmetric Number of Children of a Class: NOC is the number of direct descendants for each class. It is a typical use of the AboutMeMetricSpecification metric type: there is not the reference children in CtClass. AboutMeMetricSpecification fills this lack and enables us to correctly specify the metric. Lack of Cohesion on Methods: Is is not possible to specify the LCOM metric of Chidamber and Kemerer as an instance of the metric specification metamodel. The reason is that it involves as the core metric component the concept of pair of functions. This concept is artificial w.r.t. the Java language and is not present in any form in the Java metamodel. However it still remains possible to manually develop the implementation of LCOM on top of the Java XMI model and the Java metamodel.

The benefits The metric specification metamodel is rich enough to re-specify all but one Chidamber and Kemerer metrics with the MDM approach. In this context, the main artifacts are: a Java program considered as a model conforming to a Java metamodel, a set of metric specifications as a metric model instance of our metric specification metamodel.

The MDM approach is generative. The specification of Chidamber and Kemerer metrics is 24 lines of code with our textual declarative language. The generative step of the MDM approach generates a Java program of around 100 lines of code (LOC). This Java program uses a model measurement library of around 3000 LOC, that is not dedicated to Java but used in all the MDM approach instances. This library seats on top of SpoonEMF/EMF/Eclipse. It is not possible to estimate precisely the size of the actually used part of these software packages. By comparison, the Metrics (http://metrics.sourceforge.net) Java measurement tool is more than manually coded 20000 lines of code (its maturity and completeness has to be taken into account). Note that Java is a verbose language. With a more compact generated language like Smalltalk, this generated code volume would decrease but without the conciseness of pure dedicated declarative metric concepts.

Industrial application: metrics for maritime surveillance system models

In this section, we present the application of the MDM approach in an industrial context. Our industrial partner, Thales Airborne Systems, is a world-wide company that designs and develops maritime surveillance systems. The MDM approach applied early in the system life cycle enables engineers to obtain: 1) metric values that estimate operational performance of the system; 2) architectural metric values that are used to dimension the system. A maritime surveillance system (further called MSS) is a multi-mission system. It is intended to supervise the maritime traffic, to prevent pollution at sea, to control the fishing activities, to control borders. It is usually composed of an aircraft, a set of sensors, a crew and a large number of software artifacts. The number of functionalities, the relationships between hardware and software components and the communication between the system and others entities (base, other MSSs) indicate the complexity of the system.

Current system engineering process are mainly document-centric. Current MSS simulators are mainly code centric. During the system engineering activities, the problem is that it is very costly to develop a measurement software on top of both documents and code, in order to obtain operational metrics for MSS. This context of system engineering metrics for MSS is a good candidate to apply the MDM approach. Therefore, we tried to obtain MSS domain metrics with our approach. In a previous paper [START_REF] Monperrus | Model-driven simulation of a maritime surveillance system[END_REF], we presented a model-driven simulator for maritime surveillance systems. In this paper, we measure the models involved in the model-driven simulation with the MDM approach.

There is no standard metamodels for maritime surveillance systems. Consequently, we created a domain metamodel for maritime surveillance systems. The final metamodel is divided into three packages that address different concerns. More information on the models can be found in [START_REF] Monperrus | Model-driven simulation of a maritime surveillance system[END_REF]. The MSS system architecture package contains architectural concepts. It is divided in five packages following a functional decomposition. The scenario package contains all the needed classes to represent a tactictal situation. A model, instance of this metamodel, specifies the surveillance zone, the number and types of objects that are in the zone. For each object is specified a trajectory including the speed of the object. The operational event package contains classes that represent events that have a semantic with respect to a simulation at the system engineering level.

Domain metrics To choose the domain metrics, we studied the legacy simulators and discussed with systems engineers of the company. We agreed on 16 metrics to be implemented with the MDM approach. The domain metrics in the context of the MMS development at the system engineering are of different types. The types follow the same functional decomposition as the packages.

System architecture metrics (5 metrics) These metrics are related to the architecture itself e.g.; the number of sensors in the system. These metrics are mostly dedicated to cost estimation and planning. Scenario metrics (4 metrics) These metrics are related to the tactical operation in which the system will evolve. For instance, the number of boats in the surveillance zone. The system dimensioning depends on such domain metrics. Simation trace metrics (7 metrics) These metrics are computed on simulation trace. They are estimations of the system properties; for instance the ratio of detected ships during the surveillance mission.

Each of these domain metrics has been specified as instance of the metric specification metamodel. Conclusion In the context of maritime surveillance system development at the system engineering level, we presented the application of the MDM approach. We presented the main components of the approach: the domain metamodels, models and metrics. The MDM approach enables engineers to obtain domain metric values for three different type of models used during the system engineering activities. This comprehensive and consistent way of measuring system models is an added value compared to costly ad hoc developments which consider either too document-centric or too code-centric artifacts.

We implemented 16 domain metrics for maritime surveillance systems using the MDM approach within 1 week (one day for the metrics, 4 days to solve bugs in the measurement software generator prototype). For comparison, a previous project that developed a similar set of domain metrics for an agent-based similator took several months. However, this dramatic cost reduction factor has to be mitigated by the differences in maturity level and reliability of the obtained software. Still, it is clear that the MDM approach reduces the development cost by an order of magnitude (when creating the domain metamodel from scratch or to fit an existing DSL, the cost of its creation has also to be taken into account).

The success of this project is a first validation of the MDM approach. It also shows that measurement is not orthogonal to other engineering activities. The measured models, which give an estimation of the future characteristics of the system being built, are the same that are used for simulation. We assume that they could also be used for other model-driven activities such as model transformations, or model-driven testing.

Related Work

Links with the GQM Compared to the Goal/Question/Metric (GQM) approach [START_REF] Basili | The goal question metric approach[END_REF], ours is temporarily after in a measurement plan. To a certain extent, the MDM approach can be considered as an automated implementation of metrics obtained by the GQM approach.

Metrics on top of metamodels Misic et al. [START_REF] Misic | From formal metamodels to metrics: An object-oriented approach[END_REF] define a generic object-oriented metamodel using Z. With this metamodel, they express a function point metric using the number of instances of a given type. They also express a previously introduced metric called the system meter. Along the same line, [START_REF] Reissing | Towards a model for object-oriented design measurement[END_REF] extends the UML metamodel to provide a basis for metrics expression and then use this model to express known metrics suites with set theory and first order logic. Tang and Chen address [START_REF] Tang | Measuring OO design metrics from UML[END_REF] the issue of model metrics early in the life cycle. Hence, they present a method to compute object-oriented design metrics from UML models. UML models from Rose are parsed in order to feed their own tool in which metrics are hard-coded. Similarly, El-Wakil et al. [START_REF] El Wakil | A novel approach to formalize and collect object-oriented design-metrics[END_REF] use XQuery to express metrics for UML class diagrams. Metrics are then computed on XMI files of UML models. On the implementation issue, [START_REF] Harmer | An extensible metrics extraction environment for object-oriented programming languages[END_REF] exposes a concrete design to compute semantic metrics on source code. The authors create a relational database for storing source code. This database is fed using a modified compiler. Metrics are expressed in SQL for simple ones, and with a mix of Java and SQL for the others.

All these approaches differs from ours on crucial points. They are limited to models of object-oriented software. Hence, they do not address the growing amount of domain-specific languages. Metrics are manually implemented in a general-purpose programming languages. This kind of implementation can be considered complex and costly. Baroni et al. [20] propose to use OCL to express metrics. They use their own metamodel exposed in a previous paper. Likewise, in [START_REF] Mcquillan | Experiences of using the dagstuhl middle metamodel for defining software metrics[END_REF], the authors use Java bytecode to instantiate the Dagstuhl metamodel and express known cohesion metrics in OCL. OCL, although initially designed to write constraints on UML class diagrams, can be easily extended to define metrics on any domainmetamodel.

OCL and the MDM approach are not disjoint, for instance, a part of the predicate package is similar to some OCL constructs. However, from a conceptual viewpoint, our metric metamodel define the right concepts for specifying model metrics. On the contrary, specifying model metrics with OCL involves the adaption of concepts from OCL to metrics. From a code reduction viewpoint [START_REF] Marinescu | Towards a simplified implementation of object-oriented design metrics[END_REF] the MDM approach enables to write shorter metric specifications. The implementation of the C&K metrics in OCL made in [START_REF] Mcquillan | A definition of the chidamber and kemerer metrics suite for uml[END_REF] are much longer to the one made here with the MDM approach. However, it is worth studying the mix of the MDM approach and the widely known OCL syntax and constructs to express the predicates.

Abstraction level for expressing metrics Mens et al. define [START_REF] Mens | A graph-based metamodel for object-oriented software metrics[END_REF] a generic objectoriented metamodel and generic metrics. They then show that known software metrics are an application of these generic metrics. Marinescu et al. propose [START_REF] Marinescu | Towards a simplified implementation of object-oriented design metrics[END_REF] a simplified implementation of object-oriented design metrics with a metric language called SAIL.

These contributions both explore the possibility of an abstraction level for expressing metrics. However, the domain of application of the abstraction level is limited to object-oriented software metrics. On the contrary, the MDM approach is domain-independent. It can be applied to any imperative or declarative modeling language specified by a metamodel (implementation metamodel, real-time system metamodel, software architecture metamodel, requirements metamodel, system of systems metamodel, etc.).

There are also previous contributions about a measurement-related metamodel. It is to be noted that a measurement-related metamodel can address three different concerns: the measurement process, the measurement results, and the metric specifications. The metamodel of [START_REF] Garcìa | Towards a consistent terminology for software measurement[END_REF] is more about the two first points (e.g.; classes InformationNeed, ScaleType, MeasurementResult). The OMG requested proposals for a Software Metrics Meta-Model1 . Very recently, the unique submission was published2 . This RFP was not very precise on which aspect the metrics metamodel is intended, but the proposed metamodel explicitely supports the three aspects.

Compared to these contributions, the MDM approach has a smaller scope: the metric specifications. Our declarative ways of specifying metrics are novel (except SigmaMetricSpecification and PathLengthMetricSpecification [START_REF] Mens | A graph-based metamodel for object-oriented software metrics[END_REF]) and are not dedicated to software metrics but to any artifacts specified by a metamodel. The main difference is that the MDM approach is fully thought in a generative way.

Domain specific metrics

The issue of domain specific metrics is a very new research field. As of today and to our knowledge, it has only been explored by Guerra et al. very recently in [START_REF] Guerra | Visual specification of measurements and redesigns for domain specific visual languages[END_REF]. They propose to visually specify metrics for any DSL and introduce a taxonomy of generic metrics. Our approach is similar. We also create a metric specification in order to measure any domain models thanks to code generation.

Since their main goal, visual specification and redesign, is different, we explore different aspects of the issue and study different application cases. We consider metamodels in the EMOF context [26], whereas their metamodels are Entity-Relationships based. We propose new concepts to the metric specification metamodel which enable us more declarative metric specifications.

Conclusion

Our Model-driven Measurement Approach is a new technique in the field of measurement and model-driven engineering. Whatever the domain, whatever the maturity of the product during the development life cycle, it allows the effective measurement thanks to a complete generation of the measurement software from an abstract and declarative metric specification.

This generative approach cuts the development cost of measurement software. From a code volume viewpoint, the ratio between the final implementation and the abstract metric specifications is more than 10. At the system engineering level, it allows measurement not really made before.

On this basis, future research will be conducted to empirically measure the productivity enhancement achieved by a model-driven measurement approach. An important milestone will be to define an intuitive way of specifying metrics conform to the metric specification metamodel so as to let domain experts writing metrics by themselves.

Fig. 1 .

 1 Fig. 1. Model-driven measurement: actions and artifacts

Fig. 2 .

 2 Fig. 2. The domain metamodel used for demonstration purposes

Fig. 3 .

 3 Fig. 3. The core of the metric specification metamodel

Figure 3

 3 Figure 3 presents the classes that structure the metric specification metamodel. A class MetricSpecificationSet is the root element. It contains several MetricSpecification. A MetricSpecificationSet represents a set of domain metrics collected by a domain expert. They can come from the literature, existing tools, company quality plans, expert know-how.A MetricSpecificationSet refers to a domain metamodel (attribute metamod-elURI), and to a ComputationStrategy. A computation strategy defines which parts domain model are measured. This can be a file, a predefined list of model elements or a transitive closure on all model elements. A MetricSpecification is an abstract class that defines an atomic metric specification. Note that we use MetricSpecification and not Metric alone, to be able to differentiate a metric specification from a metric value. The modeling of measurement results i.e; metric values and their interpretation, is outside the scope of this metamodel. A MetricSpecification is subclassed. The DerivedMetricSpecification class handles arithmetic and based function based metrics (e.g.; addition, exponential): the subclassess of DerivedMetricSpecification are used to express complex metric formula. CollectionBasedDerivedMetricSpecification is the class that handles higher order metrics, mainly statistical operators, based on a set of metric values. It is subclasses as Sum, Average, Median, Stddev which are not represented in figure3. The last subclass of MetricSpecification is PredicateMetricSpecification.A PredicateMetricSpecification is an abstract class that contains a predicate. A predicate is a function from the set of model elements to the truth values.

  metric SigmaMetric NOCompComp is description " too complex components " elements satisfy " this . isInstance ( Component ) and this . required > 10 and this . provided > 10 and this . subComponents > 5" endmetric metric TauMetric NODeComp is description " The number of decomposition " link is " C o m p o s i t e C o m p o n e n t : subComponent " endmetric

  metric A t t r i b u t e V a l u e P e r X NODev is description " The number of developers per component " elements satisfy " this . isInstance ( Component )" value is " this . numDevelopers " endmetric metric AverageMetric ANORI is description " The average number of required interfaces per component " input metric M u l t i p l i c i t y P e rX is elements satisfy " this . isInstance ( Component )" multiplicity of " this . required " endmetric endmetric In: Proceedings of the ACM/IEEE 11th International Conference on Model Driven Engineering Languages and Systems (MODELS'2008)A SetOfElementsPerX metric specification is the number of model elements obtained after performing a transitive closure. The SetOfEdgesPerX class is similar to the SetOfElementsPerX class, except that it counts the number of edges considered during the transitive closure.

  PathLengthMetricSpecification is the maximum path length of a set of path starting from a root model element to other model elements. PathLength-MetricSpecification class is used to specify metrics that are based on a domain distance. Let us now consider instance examples of these metrics.

Fig. 4 .

 4 Fig. 4. Predicates in the metric specification metamodel

  metric A b o u t M e M e t r i c S p e c i f i c a t i o n NOC is description " Number of Children of a Class " x satisfy " this . isInstance ( CtClass )" input metric SigmaMetric _NOC is elements satisfy " this . Superclass == __me__ " endmetric endmetric Coupling Between Object Classes: CBO is the number of classes to which a given class is coupled.

7 ThenStatement 10 D

 710 metric A b o u t M e M e t r i c S p e c i f i c a t i o n CBO is description " Coupling Between Object Classes " elements satisfy " this . isInstance ( CtClass )" input metric SetO fEdgesP erX _CBO is target satisfy " this . isInstance ( C tT yp e Re fe re n ce ) and this . QualifiedName == __me__ . SimpleName " endmetric endmetric Response For a Class: RFC is the number of methods that can be potentially executed in response to a message. metric S e t O f E l e m e n t s P e r X RFC is description " Response For a Class " elements satisfy " this . isInstance ( CtClass )" x satisfy " this . isInstance ( C t E x e c u t a b l e R e f e r e n c e )" references followed " Methods , Body , Statements , Expression , AssertExpression , CaseExpression , In: Proceedings of the ACM/IEEE 11th International Conference on Model Driven Engineering Languages and Systems (MODELS'2008) e c l a r i n g E x e c u t a b l e " 11 endmetric

OMG document adtmf/2006-09-03

OMG document adtmf/2008-02-01


Brice Morin

Olivier Barais

Jean-Marc Jézéquel

Weaving Aspect Configurations for Managing System Variability

Variability management is a key concern in the software industry. It allows designers to rapidly propose applications that fit the environment and the user needs, with a certain Quality-of-Service level, by choosing adapted variants. While Aspect-Oriented Programming has been introduced for managing variability and complexity at the code level, the Software Product-Line community highlights the needs for variability in the earlier phases of the software lifecycle, where a system is generally described by means of models. In this paper, we propose a generic approach for weaving flexible and reusable aspects at a model level. By extending our generic Aspect-Oriented Modeling approach with variability, we can manage variability and complexity in the early phases of the software lifecycle.

Introduction

Variability management is a key concern in the software industry. It allows designers to rapidly propose a wide range of applications by choosing adapted variants and options. These customized systems will fit the environment and the user needs, with a certain Quality-of-Service level. In order to improve traceability, reliability and maintainability, variability should be explicitly modeled.

The Aspect-Oriented Software Development (AOSD) paradigm proposes to separate distinct concerns into different aspects e.g., security, logging or persistency, and finally compose them into the base system. It first appeared at the code level [START_REF] Kiczales | Aspect-Oriented Programming[END_REF] and has more recently gained attention in the earlier steps of the software life-cycle [START_REF] Araújo | Modeling and Composing Scenario-Based Requirements with Aspects[END_REF][START_REF] Baniassad | Theme: An Approach for Aspect-Oriented Analysis and Design[END_REF][START_REF] Cottenier | Joinpoint Inference from Behavioral Specification to Implementation[END_REF][START_REF] Klein | Weaving Multiple Aspects in Sequence Diagrams[END_REF][START_REF] Rashid | Modularisation and Composition of Aspectual Requirements[END_REF]: requirement, architecture, design, leading to the creation of numerous ad-hoc Aspect-Oriented Modeling (AOM) approaches, and a dispersion of effort in their tooling, docu-mentation and adoption.

In order to manage variability, recent works [START_REF] Alves | Extracting and Evolving Mobile Games Product Lines[END_REF][START_REF] Anastasopoulos | An evaluation of aspectoriented programming as a product line implementation technology[END_REF][START_REF] Apel | Aspectual Mixin Layers: Aspects and Features in Concert[END_REF][START_REF] Kästner | A Case Study Implementing Features using AspectJ[END_REF][START_REF] Mezini | Variability Management with Feature-Oriented Programming and Aspects[END_REF] discuss the use of Aspect-Oriented Programming (AOP) for implementing Software Product Lines (SPL). At the code level, AOP offers mechanisms to encapsulate (optional) cross-cutting features. In contrast, with more traditional mechanisms like conditional compiling, these features would be tangled and scattered across the program.

Meanwhile, the SPL community points out the needs for managing the variability during the entire software lifecycle [START_REF] Loughran | From Requirements Documents to Feature Models for Aspect Oriented Product Line Implementation[END_REF][START_REF] Van Gurp | On the Notion of Variability in Software Product Lines[END_REF], this in order to trace variability from requirements to implementation and even execution. The Model-Driven Engineering (MDE) paradigm proposes to consider models as first class entities during the entire life cycle. For example, requirement models [START_REF] Brottier | Producing a Global Requirement Model from Multiple Requirement Specifications[END_REF] represent the user needs, class and component diagrams specify the structure of the system, scenarios and state machines specify its behavior, and runtime models [START_REF] Bencomo | Proceedings of the Models@run[END_REF] monitor the running system. MDE techniques allow to automate the transition between the different steps of the life cycle. All these models conform to different metamodels, and are generally described by Domain Specific Modeling Languages (DSML), or metamodels.

We argue that Aspect-Oriented Modeling (AOM) can help users to design optional and variant parts of a model, like AOP does at the code level. By weaving incrementally aspects into a base model it is possible to construct a final product step-by-step. But, to be able to weave aspect into different kinds of model, users have to adapt to numerous ad-hoc AOM approaches. Indeed, AOM approaches [START_REF] Araújo | Modeling and Composing Scenario-Based Requirements with Aspects[END_REF][START_REF] Baniassad | Theme: An Approach for Aspect-Oriented Analysis and Design[END_REF][START_REF] Cottenier | Joinpoint Inference from Behavioral Specification to Implementation[END_REF][START_REF] Klein | Weaving Multiple Aspects in Sequence Diagrams[END_REF][START_REF] Rashid | Modularisation and Composition of Aspectual Requirements[END_REF] often propose domain-specific mechanisms to represent aspects. We tackle this issue by automatically generating domain-specific AOM frameworks that all rely on the same concepts. Thus, designers do not need to adapt to a new AOM framework for all the domain metamodels they have to deal with. Weaving aspect represents the first variability dimension of our approach.

Moreover, AOM approaches are often said flexible and reusable, but actually not enough. Using these approaches, it is often impossible to weave an aspect into a base model if it does not exactly propose what the aspect expects. Additionnaly, when it is possible to weave an aspect into the base model, it is always composed the same way. Based on previous work [START_REF] Lahire | Introducing Variability into Aspect-Oriented Modeling Approaches[END_REF], we propose to integrate variability mechanisms into aspects themselves to tackle the issue of the limited reusability of aspects. These mechanisms turn standard aspects into configurable aspects, more reusable and flexible. Aspect configuration represents the second variability dimension of our approach.

The remainder of this paper is organized as follows. Section 2 presents our generic approach for aspect weaving. Section 3 details our 2-dimension approach for managing variability of software systems. Finally, Section 4 presents related works and Section 5 concludes and discusses future works.

Our Generic Model-Driven Approach for Aspect Weaving

This section presents our generic model-driven approach for aspect weaving. It briefly introduces the notion of metamodeling, with a simple running example, and introduces the notion of Aspect-Orientation. Then, it details our approach for automatically generating Aspect-Oriented Modeling frameworks, for any domain metamodel.

Metamodeling, AOP and AOM

Metamodeling A domain metamodel describes all the concepts of a particular domain of interest, and their relations. To illustrate our approach, we introduce a simple domain metamodel MM for state machines, illustrated in Figure 1. A region contains several vertices and transitions, that are the main elements of a state machine. Note that the Vertex meta-class is abstract and cannot be instantiated in a model, but is extended by two concrete meta-classes: PseudoState and State. A transition must declare a source and a target vertex.

This metamodel allows designers to represent state machines, with any number of transitions and vertices, in any configuration. Then, it is possible to simulate models or generate other artifacts, using Model-Driven Engineering techniques and dedicated tools like Kermeta [START_REF] Muller | Weaving Executability into Object-Oriented Meta-languages[END_REF], an opensource environment 1 for metamodel engineering. There exists metamodels for state machines, components, scenarios, class diagrams, etc.

Aspect-Oriented Programming (AOP)

The Aspect-Oriented paradigm first appeared at the code level [START_REF] Kiczales | Aspect-Oriented Programming[END_REF] and has been popularized with the AspectJ [START_REF] Kiczales | An Overview of AspectJ[END_REF] programming language. AspectJ extends Java with the following concepts:

1. Join Point: point of interest in a program e.g., method execution/call, attribute reading/writing.

2. Pointcut: it defines a set of join points where the aspect will intervene e.g., all the calls to a given method.

3. Advice: it specifies the additional behavior that will modify the base program. It is executed in all the join points identified by a pointcut.

AOP allows users to encapsulate cross-cutting concerns into advice, and implicitly weave them into a base program, in all the join points identified by a pointcut. AOP significantly reduces the complexity of softwares a the code-level, by limiting the scattered and tangled code.

Aspect-Oriented Modeling (AOM)

At a model level, AOM approaches [START_REF] Baniassad | Theme: An Approach for Aspect-Oriented Analysis and Design[END_REF][START_REF] Fleurey | A Generic Approach For Automatic Model Composition[END_REF][START_REF] Lahire | Introducing Variability into Aspect-Oriented Modeling Approaches[END_REF][START_REF] Reddy | Directives for Composing Aspect-Oriented Design Class Models. Transactions on Aspect-Oriented Software Development I[END_REF][START_REF] Straw | Model Composition Directives[END_REF] propose to encapsulate cross-cutting and reusable concerns. AOM concepts are comparable to AOP ones. But, as opposed to AOP, AOM mainly focus on the composition of structural and behavioral models, in the early phases of the software lifecycle, before implementation.

Template models represent what the aspect expects from the base model i.e., the model elements needed to be able to weave the aspect into the base model, and their relations. Template do not need to be consistent models, for example, it can only be composed of a single operation, without representing its containing class, that is normally mandatory. Templates could be assimilated as pointcuts.

Then, aspect are woven into a base model. This is similar to advice weaving in AOP. On the one hand, symmetric AOM approaches [START_REF] Baniassad | Theme: An Approach for Aspect-Oriented Analysis and Design[END_REF][START_REF] Fleurey | A Generic Approach For Automatic Model Composition[END_REF][START_REF] Reddy | Directives for Composing Aspect-Oriented Design Class Models. Transactions on Aspect-Oriented Software Development I[END_REF][START_REF] Straw | Model Composition Directives[END_REF], that do not differentiate aspect and base, propose to systematically merge all the corresponding concepts, and specify how to introduce non-shared ones. On the other hand, asymmetric approaches [START_REF] Lahire | Introducing Variability into Aspect-Oriented Modeling Approaches[END_REF][START_REF] Morin | Towards a Generic Aspect-Oriented Modeling Framework[END_REF][START_REF] Schauerhuber | Towards a Common Reference Architecture for Aspect-Oriented Modeling[END_REF], that clearly differentiate aspect and base, propose to specify how to integrate the aspect. Generally, symmetric composition is a better way to compose homogeneous views of a given system, using a partially automated procedure, whereas asymmetric composition is a better way to introduce new concerns into models, and often offers better reusability, but the composition protocol must be explicited.

In the remainder of this paper, our running example focuses on state machines. However, our asymmetric approach is completely independent from any domain metamodel.

Generating the pointcut language

The previously introduced domain metamodel allows users to design consistent state machines, but it is too restrictive for designing aspects. For example, a template model might only be composed of a region with a vertex (whatever its type), a final state and a transition that links the vertex to the final state. We may also want the vertex to be an indirect source of the transition i.e., it is possible to fire the (dashed) transition from vertex, directly or not. This model does not conform to MM because the Vertex meta-class cannot be instantiated and MM does not consider the semantic notion of indirect source. This template model is illustrated in Figure 2. Moreover, we want to be able to declare some elements as roles i.e., elements that must be substituted by actual base model elements, whereas other elements can be seen as structural constraints that the pattern must respect. For example, if we want to modify all the quitTransitions from the region, we will declare the transition and the region as roles to be able to manipulate them. The other elements are just structural constrains: the transition must link a vertex to a final state.

Figure 2. A Simple Template Model

In order to be able to describe more easily target models, we construct on demand a more flexible metamodel [START_REF] Ramos | Matching Model Snippets[END_REF] MM', using a model transformation written in Kermeta [START_REF] Muller | Weaving Executability into Object-Oriented Meta-languages[END_REF]. MM' is equivalent to MM, except that:

1. No invariant or pre-condition is defined in MM';

2. All features of all meta-classes in MM' are optional; 3. MM' has no abstract element. This model transformation is generic because instead of manipulating the domain elements (Vertex, Transition, . . . ), it manipulates higher-level concepts provided by ECore, MOF or EMOF for describing metamodels. Consequently, MM' can be generated for any input metamodel MM. Figure 3 illustrates the result of this transformation applied to the metamodel for state machines (Figure 1).

Figure 3. The Unconstrained Metamodel MM'

In MM' (Figure 3), we can see that a transition can declare no source/target vertex and can be instanciated without its containing region. Moreover, if a user wants to match a vertex, whatever its real type, he can now instantiate the Vertex meta-class. Additionally, we introduce two semantic associations (allTargets and allSources) to represent states (in)directly after or before a given transition. We also weave these associations as derived properties into MM to be able to compute all the state before/after a transition. Note that weaving derived properties does not change the metamodel, it only adds semantic.

In order to ease the detection of model elements that can match roles, we use a Prolog-based pattern matching engine [START_REF] Ramos | Matching Model Snippets[END_REF], implemented in Kermeta [START_REF] Muller | Weaving Executability into Object-Oriented Meta-languages[END_REF]. The domain metamodel is automatically mapped onto a Prolog knowledge base. Then, patterns with roles are transformed into a Prolog queries over this knowledge base. Finally, the Prolog results are converted back into a Kermeta data-structure. This process is totally hidden from the user who only designs model snippets like the one presented in Figure 2.

Generating Adaptations

The second step of an Aspect-Oriented approach is the weaving process. It consists in composing aspects into the base model, at the places identified by the template model. The key concept is the adapter [START_REF] Lahire | Introducing Variability into Aspect-Oriented Modeling Approaches[END_REF][START_REF] Lahire | New Perspective To Improve Reusability in Object-Oriented Languages[END_REF], that describes the aspect structure (what will be woven), a template model with roles(where it will be woven) and a composition protocol (how it will be woven). The composition protocol is described by adaptations, that are weaving operations manipulating the concepts of the domain. For example, in the context of class diagrams, an adaptation can add a super class to another class, introduce methods or attributes in a class, etc. These concepts are structured in the adaptation metamodel illustrated in the top-part of Figure 4.

Figure 4. A Framework for Aspect Weaving

This metamodel is composed of three parts: i) a generic part describing the concept of adapter, adaptations and aspect (structure and target), ii) the unconstrained metamodel MM' that is linked to the generic part by introducing the meta-class PObject as the root element of MM', and iii) domain specific adaptations extending the generic metaclass Adaptation (bottom-part of Figure 4).

We propose a systematic way to generate domain-specific adaptations.

For each meta-classes MyMetaClass of a metamodel MM, we generate four adaptations: The generation of these adaptations is also generic and can be done for any metamodel MM: we navigate the metaclasses and their properties and use Kermeta Emitter Template (KET) to generate all the above adaptations, specific to a domain metamodel. In our approach, we use KET to generate Kermeta files, but we can generate any kind of files such as Java code or textual documentation, by defining template. A template describes the structure of the output files (Kermeta, Java, text, etc), and the navigation is written in Kermeta, encapsulated in specific marks 2 .

All these generated adaptations can manipulate elements from the template model or from the aspect structure i.e., composition protocols written with these adaptations are totally independent from any base model, and can be reused in different contexts. This section briefly exposed the principles of our generic model driven approach for aspect weaving. Our approach can be customized for any domain metamodel, to obtain a domain specific AO framework, through two extension points (Figure 4):

1. PObject: represents an abstraction of any (unconstrained) domain metamodel that allows us to describe the adaptation metamodel with no domain concepts. When we specialize the framework for a given domain, PObject is automatically introduced as the root meta-class of all the element of MM', with a model transformation written in Kermeta [START_REF] Muller | Weaving Executability into Object-Oriented Meta-languages[END_REF].

2. Adaptation: represents an abstraction of any domainspecific weaving operation. All the domain-specific adaptations must extend this meta-class, declare some attributes, and implement the execute method that describes a composition between some model elements.

We automatically generate some basic adaptations, but designers can create some additional adaptations that extends Adaptation, or modify existing ones.

Two-Dimension Variability Management

In the previous section we present our approach for generating Aspect-Oriented Modeling frameworks, for any domain with a well defined metamodel. In this section, we extend these AOM frameworks and describe our 2-dimension approach for managing the variability of software systems.

The main idea is that each aspect is considered as a variability dimension i.e., aspects integrate variability mechanisms to make them configurable and reusable in different contexts. Then, different configurations of an aspect can be woven (or not) in order to propose different variants of the system.

Variability Mechanisms for Aspects

The variability mechanisms we propose to integrate in the aspects are inspired by SPL approaches [START_REF] Sinnema | COV-AMOF: A Framework for Modeling Variability in Software Product Families[END_REF][START_REF] Ziadi | Families Research Book, chapter Product Line Engineering with the UML: Products Derivation[END_REF] 3 :

• Alternatives/Variants: specify that there exist several possible ways to compose the aspect (composition variability) and/or several different places where to compose it (targeting variability). All the variants are exclusive i.e., we can only choose exactly one variant per alternative.

• Options: specify that some adaptations may be executed or not, and that some elements from the template model are mandatory i.e., they may be or not in the base model where we want to weave the aspect.

• Constraints: control the variability mechanisms and limit the number of derived aspects to sensible ones. Without constraints, the number of possible combinations may become huge, and most of them would not be sensible. For example, we can easily imagine that some options or variants require (dependency) or exclude (mutual exclusion) some others.

We propose variability both for the composition protocol and for the targeting. For composition variability, we only need to apply the above concepts on adaptations, and integrate them in the adaptation metamodel. For the targeting variability, MM' does not allow designers to propose the full possible range of variability in their snippets because it is not possible to propose variants on certain features that have for example a [0..1] cardinality. For example, we can imagine that we want to instantiate a transition that targets either a pseudo-state or a state, and not simply a vertex, because the composition protocol uses adaptations that are specific to pseudo-state or state, in two distinct variants of an alternative. In order to propose variability in the target model, we propose to generate the maximum metamodel MM" that is equivalent to MM', except that all the features can be multiple i.e., all the upper bound are set to * (possibly infinite).

In order to allow composition and target variability, we extend the adaptation metamodel (Figure 4) presented in Section 2 with the following key concepts (see Figure 5): 3 see http://www.sei.cmu.edu/productlines/ and http://www.splc.net

• Derivable Adapter: a derivable adapter is an adapter that contains variability i.e., alternatives, options and constraints. It proposes both composition and targeting variability.

• Adapter Element: an adapter element is an element that can be optional or involved in an alternative: adaptation, target, alternative, conjunction (group of adapter elements). It is introduced as a super metaclass for all these elements.

• Alternative: an alternative describes several possible variants that are mutually exclusive. Each variant is an adapter element.

• Constraints: a constraint describes either a dependency or a mutual exclusion between some adapter elements. A dependency specifies that a source element requires some other elements, and an exclusion specifies that some elements are mutually exclusive i.e., two elements cannot be present at the same time, after derivation.

• Derivation: a derivation allows designers to derive a derivable adapter i.e., to fix variability. It allows designers to select options, and choose one variant, for each alternative.

• Conjunction: a conjunction is a block of dependent adapter elements. It allows to define optional blocks and variant blocks in an alternative.

To illustrate some of the variability mechanisms, the generated adaptations and the target model specific to state machines, we will describe an aspect that adds a Log state before reaching the final state e.g., for logging errors. Optionally, we propose to come back to a previous vertex after logging an error, instead of reaching the final state. The target model and the aspect structure are the model snippets shown in Figure 6.

In the target model, the containing region, the final state, the transition that targets the final state are mandatory i.e., they must be matched by actual base model elements before weaving the aspect into a base model. An option specify that we can target any vertex before the transition. All the elements of the target model are associated to roles, because we want these elements to be bound to base model elements, in order to modify the base model. Now, we need to define the composition protocol that will describe how the structure will be woven into any base model. Note that the composition protocol is totally defined with elements from the target model and from the aspect structure i.e., it does not reference elements from any base model. This protocol is illustrated in Figure 7.

The composition protocol describes the operations needed for integrating the aspect. In this example, all the The concrete syntax we propose for adaptations is very basic. For example, the first adaptations (Line 01) is called introduceStruct and its real type is SetRegion. Its first parameter is the region to set (Line 01-a), and all the following parameters refer to the element we want to introduce in the targeted region: some subvertices (Line 01-b) and transitions (Line 01-c). The three following adaptations aims at connecting the transitions (Lines 2 and 3) and renaming the Log state (Line 04) to fit its context. Finally, we declare an optional conjunction (Lines 5) that aims at introducing and connecting the backTransition.

Note that MDE tools like Sintaks 4 [START_REF] Muller | Model-Driven Analysis and Synthesis of Concrete Syntax[END_REF] can easily bridge abstract syntax (metamodel) and concrete syntax (text), by parsing texts into models, and transforming models into texts, according to rules defined in a Sintaks model. 4 available at http://www.kermeta.org/sintaks

Weaving Aspect Configurations

The previous sub-section details the first variability dimension i.e., the integration of variability mechanisms into aspects. This sub-section details the second variability dimension: the configuration, or derivation of aspects and the weaving process.

The aspect presented in the previous sub-section ( If we consider several aspects, we can easily propose many different variants of the system by configuring aspects and weaving them, or not, into the base system. The derivation process can be summarized as follows:

1. Constraints: we check that the derivation d provided by the user respects all the constraints of the derivable adapter. We just call the check(d) method for all the constraints of the adapter, that is implemented directly in the adaptation metamodel (see Constraint in Figure 5), with Kermeta. If one constraint is not reached, the framework raises an exception telling the user that his derivation is not well-formed.

2. Adaptations: the composition protocol (adaptations) of the derived adapter is built in a positive way i.e., selected options and variants are added into the derived adapter.

3. Target Model: the target model is (un)built in a negative way i.e., the model elements that are not selected (non-chosen options and variants) are deleted from the target model.

4. Post-condition: after derivation, the target model must conform to MM', and not only to MM". Otherwise it means that a cardinality is over the maximum bounds, and consequently the target model cannot be matched by any model snippet.

When an aspect is successfully configured, it can be woven into a base model, following this process:

1. Binding phase: the user provides a binding that links target model elements to actual base model elements.

Note that bindings can automatically be found/checked using the pattern matching framework of Ramos et al. [START_REF] Ramos | Matching Model Snippets[END_REF], to guide the user.

2. Weaving phase: for each binding selected by the user, we apply the composition protocol. In the adaptations, the target model elements are substituted with their corresponding actual base model elements, according to the binding. Between each binding, some elements of the aspect structure, or cloned/created elements (Clone/Create * adaptations), can be cloned, or remain unchanged. This choice depends on whether the user wants to use the same instances or introduce new instances, for each binding.

3. Post-condition : after composition, the modified base model must conform to MM, and not only to MM' or MM". Otherwise it would mean that the composition protocol violates some constraints (e.g., it removes mandatory features), or adds too many elements. In this case, we roll back to the initial base model.

The process can be applied several times and is potentially infinite and/or nondeterministic: if we consider that the process has been applied (n-1) times, we denote resp. configuration n , binding n , weaving n , resp.

the aspect configuration, the chosen binding and the result after weaving, for the n-th time. We have: binding n =f(configuration n , weaving n-1 ) and weaving n =g(configuration n , binding n )=h(configuration n , weaving n-1 ). The configuration of an aspect may change the target model, and the previous weaving modify the base model, and potentially adds/removes possible targets, so the binding is dependent from the configuration and the previous weaving. The weaving depends on the aspect configuration (the selected adaptations) and on the selected binding, and consequently, it depends on the previous weaving. For this reason, the process is not fully automated: the user configures the aspect, then he chooses the binding and the composition protocol is applied. Next, he can reconfigure the aspect, choose another binding, etc. Figure 9 illustrates the composition of the aspect when no option is selected. In this case, we only introduce a Log state before reaching the final state.

Figure 9. Behavior of a phone with error logging

Finally, Figure 10 illustrates the composition of the aspect when the option is selected. In this case, we also introduce a Log state before reaching the final state. Additionally, we introduce a roll-back transition that targets a previous state.

Figure 10. Behavior of a phone with error logging and roll-back

Note that is possible to combine different combination of the aspect to exactly fit the user needs.

Related Works

Our approach extends the SMARTADAPTERS approach [START_REF] Lahire | Introducing Variability into Aspect-Oriented Modeling Approaches[END_REF][START_REF] Lahire | New Perspective To Improve Reusability in Object-Oriented Languages[END_REF] by i) generalizing its concepts to any domain metamodel [START_REF] Morin | Towards a Generic Aspect-Oriented Modeling Framework[END_REF] (not only Java programs and UML class diagrams), and ii) representing targets as model snippets [START_REF] Ramos | Matching Model Snippets[END_REF], instead of declaring targets and constraints one by one. In [START_REF] Lahire | Introducing Variability into Aspect-Oriented Modeling Approaches[END_REF], we introduce variability mechanisms in the base SMARTADAPTERS approach for class diagrams. In our generic approach, we also integrate these mechanisms (Section 3), in a slightly different way. Thus, we can propose configurable aspect, and weave them into models conforming to any domain metamodel.

Recent works discuss the use of Aspect-Oriented Programming (AOP) for managing variability at the code level, and implementing Software Product Lines (SPL). Some of these approaches advocate AOP for managing optional and variants cross-cutting features [START_REF] Anastasopoulos | An evaluation of aspectoriented programming as a product line implementation technology[END_REF], or extracting and evolving SPL from a single application [START_REF] Alves | Extracting and Evolving Mobile Games Product Lines[END_REF], and propose different variants, while some approaches like [START_REF] Kästner | A Case Study Implementing Features using AspectJ[END_REF], insist on limitations and drawbacks of AspectJ for SPL implementation: code readability and maintainability, pointcut fragility making aspect weaving difficult. Moreover they point out that most of the mechanisms specific to AspectJ are not useful in most of the cases. Mezini et al. [START_REF] Mezini | Variability Management with Feature-Oriented Programming and Aspects[END_REF] point out the limitations of feature-oriented approach and AspectJ, especially its pointcut mechanism, and propose to use CaesarJ for resolving these problems. AOP is an interesting but still immature technology for managing variability. The combination of Aspect-Oriented Modeling (AOM) and Model-Driven Engineering (MDE) makes our approach more abstract and independent from problems inherent to the source code level. Unlike AspectJ pointcuts, our target models are totally independent from any base models and our aspect can be reused in different contexts, by binding target model elements to actual base model elements. There is no need for modifying the target model (pointcut), the aspect structure or the composition protocol (advice). Finally, AOP approaches for managing variability only propose one variability dimension and do not propose variability into the aspect itself, as we do.

In [START_REF] Loughran | Framed Aspects: Supporting Variability and Configurability for AOP[END_REF], Loughran et al. propose an approach that combines notions from AOP, frame technology and Feature-Oriented Domain Analysis (FODA). AOP aims at modularizing cross-cutting concerns and frame technology provide some means to configure aspects and make them contextindependent and thus, more reusable. Using our approach, designers can also define context independent aspects using targets and adaptations that only reference elements from the aspect template or structure, and not directly base model elements. They use the variability mechanisms (alternative and options) of FODA models to represent the whole system e.g., a generic cache. Then, they can delineate framed aspects and implement them in a reusable way using the frame technology. Frame is a fine mechanism to parameterize for example, the name and the type of attribute, method, parameters. In our approach, we use alternatives, options and constraints inside the aspect itself, for managing the different possible configurations. Frames are similar to our target model: both framed parameter and target model elements are substituted with actual elements from the base program/model, using bindings. Framed-aspect do not really propose internal variability, only configuration. Finally, both approach propose two variability dimensions, but they mainly focus on the system variability while we mainly focus on the aspect variability.

In [START_REF] Schauerhuber | Towards a Common Reference Architecture for Aspect-Oriented Modeling[END_REF], Schauerhuber et al. propose a common reference architecture for Aspect-Oriented Modeling. The concepts they identify are quite similar to the ones identified by Lahire et al. in the SMARTADAPTERS approach [START_REF] Lahire | Introducing Variability into Aspect-Oriented Modeling Approaches[END_REF][START_REF] Lahire | New Perspective To Improve Reusability in Object-Oriented Languages[END_REF], that we leverage to generalize the concepts of AOM to any domain metamodel. The approach of Schauerhuber et al. is also language-independent and may be applied for any domain metamodel. But, they do not propose means to generate the pointcut language nor domain-specific adaptations. Our generative approach, based on MDE techniques, allows designers to automatically specialize our framework, for any domain, by generating an unconstrained domain metamodel for designing target models (pointcuts), and generating domain-specific adaptations dealing with updating (addition/removal), creating and cloning elements. Moreover, they do not propose variability mechanisms, whereas we introduce mechanisms inspired by Software Product Line approaches.

In [START_REF] Kim | An Aspect-Oriented Approach for Reprensenting Variability in Product Line Architecture[END_REF], Kim et al. combine this reference AOM architecture with a component-based SPL architecture. They propose to model variability using aspects, as we do in this paper. The variability mechanism is the variability point that is equivalent to our alternatives and options. In their architectures, they do not reify the notions of constraints, and do not really explicit how variants are selected, with their variability point bindings. In our metamodel, constraints and derivation clearly specify the dependencies between variants, and how to derive variants.

In [START_REF] Jayaraman | Model Composition in Product Lines and Feature Interaction Detection Using Critical Pair Analysis[END_REF], Whittle et al. propose the MATA (Modeling Aspects Using a Transformation Approach) tool for composing features in UML models (class diagrams, state charts and scenarios), based on graph rewriting. MATA allows user to describe the composition using stereotypes directly in feature models. The stereotypes they propose for composing features are similar to our Create/Set/Unset adaptations, but we also propose cloning adaptations. This can be useful, for example to implement a proxy, where all the operation needs to duplicate. Their notion of variable is equivalent to our notion of role i.e., elements that can be substituted. With MM' and MM", we can create more generic pattern by instantianting abstract elements and defining unconstrained models. Moreover, we propose variability mechanisms both for the matching and the composition whereas they only propose one variability dimension.

In [START_REF] Fleurey | A Generic Approach For Automatic Model Composition[END_REF], Fleurey et al. generalize the Composition Di-rectives approach [START_REF] Reddy | Directives for Composing Aspect-Oriented Design Class Models. Transactions on Aspect-Oriented Software Development I[END_REF] and propose "a generic approach for automatic model composition", that can be adapted to any metamodel. This approach is based on signature matching and systematic merging of model elements. Their symmetric approach aims at merging different views of the same system e.g., marketing and management views in order to obtain an integrated view of the system, using an automated weaving process that can be customized. Our asymmetric approach is different and aims at composing aspects, that can be considered as reusable patterns, into different base models, using parameterized composition protocols. Fleurey et al. do not propose variability mechanisms, but users can customize the matching by defining the signature of model elements, and customize the merging with context-specific composition directives. They do not propose alternatives, options and constraints for managing all the possible variants and consequently designers have to define as many aspects as possible configurations. Our approach allows designers to model an aspect per concern, with all the possible configurations. Then users select the most appropriate configurations to weave into their models.

In [START_REF] Heidenreich | Aspect-Orientation for Your Language of Choice[END_REF], Heidenreich et al. propose to extend the "Aspect Orientation for Your Language of Choice". Their generic approach is based on the Invasive Software Composition (ISC). Both base model and aspect model elements are annotated with Slot, Hook and Anchor. A slot indicates that a base element can be replaced by an aspect element with an anchor whereas a hook indicates a place in the base model where some anchored elements from the aspect can be added. They illustrate their approach on a UML class diagram and a Java program. Our approach is also generic but do not need to modify base models to make them aspect aware, letting base model oblivious of the aspect. We only use a binding mechanism before composition.

Conclusion

In this paper, we have presented our generic modeldriven approach for aspect weaving: for any metamodel describing a given language or domain, we can generate both the targeting language and some weaving instructions that allow users to design reusable aspects. Then, we have extended this generic approach with variability mechanisms, and presented our 2-dimension approach for variability management. After deriving an aspect by choosing most appropriate variants and options, aspect configurations can be woven into base models, to integrate new features and propose different variants of the system.

In future work, we will extend our 2-dimension approach for variability management to runtime models [START_REF] Bencomo | Proceedings of the Models@run[END_REF], in the context of self-adaptive systems. The main idea is to use aspects at a model level, to adapt the running system, instead of hard-coding the adaptation logic at the platform level. Then, using a causal connection, modifications on the runtime model should be reflected on the running system. Moving models from design-time to runtime will reduce the complexity of runtime adaptations, by providing a higher level of abstraction. We are currently working on the implementation of the causal for the Fractal [START_REF] Leclercq | Supporting Heterogeneous Architecture Descriptions in an Extensible Toolset[END_REF] component model. However, our causal link is not Fractal-specific and may be applied to other platforms like OpenCOM [START_REF] Coulson | The Design of a Configurable and Reconfigurable Middleware Platform[END_REF].

1Figure 1 .

 1 Figure 1. A Domain-Metamodel (MM)

Figure 5 .Figure 6 .

 56 Figure 5. Extended Adaptation Metamodel

Figure 7 .

 7 Figure 7. Composition Protocol

• Variant 1 :• Variant 2 :• Variant 3 :

 123 Figures 6 and 7) can be configured in two different ways, and consequently there are three possible variants: Do not weave the aspect Just add the Log state Variant 2, and we add a transition back to a previous state

Figure 8 .Figure 8

 88 Figure 8. Basic behavior of a phone

  CloneMyMetaClass: this adaptation allows user to clone an existing instance of MyMetaClass. It is generated only if MyMetaClass is concrete. Similarly, CloneState allows designers to clone an existing, and manipulate it.

	4.
	2. UnsetPropertiesOfMyMetaClass: this adaptation al-
	lows user to unset or update (removal) any property of
	MyMetaClass. Similarly, UnsetPropertiesOfRe-
	gion allows designers to remove states and transitions
	in a region.
	3. CreateMyMetaClass: this adaptation allows user to
	create a new instance of MyMetaClass. It is gen-
	erated only if MyMetaClass is concrete. For ex-
	ample, CreateState allows designers to create a new
	state, that can be manipulated in the remainder of the
	composition protocol.

1. SetPropertiesOfMyMetaClass: this adaptation allows user to set or update (addition) any property of MyMetaClass. For example, SetPropertiesOfRegion allows designers to add states and transitions in a region.

similarly to Java code encapsulated in JSP or JET