Bilal Komati
email: bilal.komati@femto-st.fr

Cédric Clévy
email: cclevy@femto-st.fr

Micky Rakotondrabe

Philippe Lutz
email: philippe.lutz@femto-st.fr

Dynamic Force/Position Modeling of a one-DOF Smart Piezoelectric Micro-Finger with Sensorized End-Effector

In this paper, a generic microscale system is studied where a smart microsystem composed of an active based material actuator, sensorized structure and transformation system is studied. This problem is important at the microscale because it offers a force measurement of the applied force by the actuator to a flexible environment which enables to understand the interaction between the complete smart microsystem and the environment and to design and control the interaction between the system and the environment. A special case where a sensorized end-effector is fixed on the tip of a piezoelectric actuator is detailed. Integrating a sensorized end-effector influences the behavior of the smart microfinger and is not studied in recent works.

The complete finger, which is called in this paper smart finger, consists of a piezoelectric actuator, an end-effector and a novel piezoresistive force sensor. A complete model is developed for generating both force and displacement at the finger's tip while interaction with a flexible environment. A nonlinear model of the piezoelectric actuator is considered and a complete model is developed taking into account the frequency dependent hysteresis of the piezoelectric actuator. The model of the hysteresis is based on the Bouc-Wen method which simplifies the parameter estimation. The complete dynamic force/position model of the finger is validated experimentally with small errors (less than 10%).

I. INTRODUCTION

Piezoelectric materials are commonly used for the actuation of microsystems and microrobots. Their use is due to their high resolution, high speed, low response time and their ability to produce large forces. They are widely used for the development of microgrippers [START_REF] De Lit | A four-degree-offreedom microprehensile microrobot on chip[END_REF], robotic platforms [START_REF] Dong | Design of a precision compliant parallel positioner driven by dual piezoelectric actuators[END_REF], nanopositioning [START_REF] Yong | Design, identification, and control of a flexure-based xy stage for fast nanoscale positioning[END_REF] for examples. However, the problem of the piezoelectric materials are the presence of nonlinearities which increases the difficulty of modeling and control of such systems. The nonlinearities are notably manifested by the hysteresis and the creep. The modeling and the control of the hysteresis and of the creep have raised many works, including linear approximation and linearization [START_REF] Chonan | Nonlinear hysteresis compensation of piezoelectric ceramic actuators[END_REF], algebraic or differential nonlinear modeling [START_REF] Al-Janaideh | An analytical generalized prandtl-ishlinskii model inversion for hysteresis compensation in micropositioning control[END_REF], [START_REF] Xiao | Modeling and high dynamic compensating the ratedependent hysteresis of piezoelectric actuators via a novel modified inverse preisach model[END_REF], feedforward control [START_REF] Leang | Hysteresis, creep, and vibration compensation[END_REF], [START_REF] Rakotondrabe | Bouc-wen modeling and inverse multiplicative structure to compensate hysteresis nonlinearity in piezoelectric actuators[END_REF] and feedback control [START_REF] Rakotondrabe | Quadrilateral modelling and robust control of a nonlinear piezoelectric cantilever[END_REF] [10], [START_REF] Mokaberi | Compensation of scanner creep and hysteresis for afm nanomanipulation[END_REF].

Most of the developed models study the model of voltage/displacement of the piezoelectric actuator. Some other works, study the voltage/force/displacement model of the piezoelectric actuator [START_REF] Rakotondrabe | Quadrilateral modelling and robust control of a nonlinear piezoelectric cantilever[END_REF], [START_REF] Low | Modeling of a three-layer piezoelectric bimorph beam with hysteresis[END_REF]. These models are limited for the piezoelectric actuator itself and do not study the problem of adding an end-effector to the piezoelectric actuator which modifies the complete model of the finger. However, for many applications, it is important to integrate force measurement into a piezoelectric actuator in order to develop the complete model of the piezoelectric actuator, determine the contact, study the interaction between the actuator and the environment and control precisely the interaction. Most of the force sensing techniques used for the piezoelectric actuators are the self-sensing [START_REF] Grasso | Piezoelectric self sensing actuators for high voltage excitation[END_REF], force estimation using models [START_REF] Xu | A new method of force estimation in piezoelectric cantileverbased microgripper[END_REF] and vision based force sensors [START_REF] Reddy | Miniature compliant grippers with vision-based force sensing[END_REF]. However, the integration of calibrated force sensors is of great interest for precise dynamic measurement for many applications.

In this paper, a generic microscale problem is studied where a classic piezoelectric actuator is used to interact with an environment. However, in order to model the interaction between the actuator and the environment, a sensorized endeffector is fixed on the tip of the piezoelectric actuator. The end-effector is composed of a rigid silicon part and an novel piezoresistive force sensor presented in [START_REF] Komati | Prototyping of a highly performant and integrated piezoresistive force sensor for microscale applications[END_REF]. This generic problem can be extended to other examples of microsystems where actuator and force sensors are integrated. The complete finger composed of a piezoelectric actuator with a sensorized end-effector is called in this paper Smart Finger. Unfortunately, the complete model of such a smart finger is not studied in literature to the knowledge of the authors.

The first objective of the paper is to develop a precise position/force dynamic nonlinear model of the smart finger which enables to design and control such a smart finger interaction with a flexible environment. The model is developed taking into consideration the effect of adding a sensorized end-effector to the piezoelectric actuator which influences the existing force/position models to the piezoelectric actuator without an end-effector. The second objective of the paper is to experimentally validate the developed model.

The paper is organized as follows. The piezoelectric actuator nonlinear dynamic model is revised in section II. The model of the smart finger at the sensorized end-effector's tip is detailed in section III. In section IV, an experimental setup is proposed to validate the model of the smart finger. Section V presents the experimental results to validate the model. Section VI concludes the paper.

II. PIEZOELECTRIC ACTUATOR MODEL

A generic microrobotic scenario is considered in this paper. Consider that the smart finger comes into contact with a flexible environment. The environment is modeled as a mass-spring-damper system as it was done in [START_REF] Kazerooni | Robust compliant motion for manipulators, parts i and ii[END_REF]. The complete system is shown in Figure 1 where four cases are considered: case of the no contact no voltage are applied (Figure 1-(a)), case of an applied voltage without contact (Figure 1-(b)), case of applied voltage and just at contact with a zero force (Figure 1-(c)) and case of both voltage and contact applied (Figure 1-(d)). In this figure, A and B represent respectively the actuator's tip A and the endeffector's tip B. y A and y B represent respectively the position of the actuator's tip A and the end-effector's tip B at time t. y e represents the location of the environment without any deformation when no force is applied to the environment (y e = y B just at contact when the applied force is null). y = y B represents the position of the environment and the end-effector tip B when a contact is established between the end-effector and the environment. α A is the angle at the actuator tip A. L is the length of the end-effector. m e , d e and k e are respectively the mass, the damping and the stiffness of the environment.

In order to determine the complete model for the smart finger, the piezoelectric actuator's voltage/force/position nonlinear model is revised in this section and the complete model of the smart finger is then detailed in section III. The aim is to develop a simple dynamic nonlinear model in order to facilitate the identification process. The inputs of the model of the piezoelectric actuator are the voltage applied on the electrodes of the piezoelectric actuator, U, and the forces and the torque applied to the actuator's tip A (as considered in literature) and the outputs are the displacement at the actuator's tip A and the angle at the tip of the actuator α A (see Figure 1). Using [START_REF] Low | Modeling of a three-layer piezoelectric bimorph beam with hysteresis[END_REF], [START_REF] Ballas | Piezoelectric Multilayer Beam Bending Actuators: Static and Dynamic Behavior and Aspects of Sensor Integration[END_REF], a piezoelectric actuator could be modeled in the time domain as follows:

       m ÿA + b ẏA + ky A = du -Γ -f A - 3 2L a M A m αA + b αA + kα A = 2 L a (du -Γ) - 3 2L a f A - 3 L 2 a M A (1)
where parameters m, b and k are respectively the mass, the damping and the stiffness of piezoelectric actuator; d is the piezoelectric constant, L a is the length of the actuator, u = u(t) is the input voltage, y A = y A (t) is the displacement of the actuator's tip A according to the Y axis and

α A = α A (t)
is the angle between the actuator's tip A and the X axis (see Figure 1), f A = f A (t) and M A = M A (t) are respectively the force and the torque applied at the actuator's tip A and Γ = Γ(t, u, f ) is an operator to represent the nonlinearities of the piezoelectric actuator which consist of rate-dependent hysteresis and creep. The variable time t is simplified from the equations for the simplicity of the writing.

In the rest of the paper, the frequency domain is used for the equations where the Laplace operator, s will be used instead of the time domain. Knowing that [START_REF] Rakotondrabe | Quadrilateral modelling and robust control of a nonlinear piezoelectric cantilever[END_REF]:

Γ(U, s) = H(U, s) +C r (U, s) (2)
where H(U, s) and C r (U, s) are respectively the hysteresis and the creep of the piezoelectric actuator. According to (2), the two nonlinearity phenomenas could be decoupled and each could be treated in an independent way. The effect of the creep is neglected in this paper.

The hysteresis of piezoelectric material is called ratedependent hysteresis because the hysteresis is function of the frequency or the rate of the input of the system. An approximate model of the rate-dependent hysteresis have parameters which are also rate-dependent. This will increase the complexity of the model. This problem is simplified in [START_REF] Rakotondrabe | Quadrilateral modelling and robust control of a nonlinear piezoelectric cantilever[END_REF] where the authors proposed to model the dynamical hysteresis of the piezoelectric actuator, H(U, s), by a static hysteresis, H s (U), followed by a linear dynamical part, D(s), as shown in Figure 2. D(s) is a second order transfer function which represents the dynamics of the actuator. In Figure 2, Fig. 2. Dynamic hysteresis could be decomposed in a static part followed by a dynamical part.

U is the voltage applied to the piezoelectric actuator, δ is the displacement of the actuator tip, δ s is the static displacement which is the output of the Bouc-Wen static hysteresis model, H(U, s) is the rate-dependent hysteresis which depends on the voltage, U, and the frequency which is written as the Laplace operator, s = j2π f , and H s (U) is the static hysteresis determined by the Bouc-Wen model.

The dynamical hysteresis of the piezoelectric actuator is determined using the following steps, [START_REF] Rakotondrabe | Bouc-wen modeling and inverse multiplicative structure to compensate hysteresis nonlinearity in piezoelectric actuators[END_REF]:

1) The transient part of the piezoelectric actuator, D(s), is identified. The dynamical part could be considered independent of the amplitude of the input voltage U.

It is determined by applying several steps of different amplitudes and then the dynamical response could be approximated by a second order transfer function as is commonly used.

2) We apply a sine voltage with a low frequency (0.1 Hz) and identify the Bouc-Wen parameters to minimize the error between the experimental result of the displacement of the actuator and the Bouc-Wen model for the displacement of the actuator. Using this method we determine H s (U).

3) The dynamical hysteresis of the piezoelectric actuator is determined, using the two previous steps, by the relation H(U, s) = H s (U) • D(s). Finally, using the Bouc-Wen model presented in [START_REF] Ismail | The hysteresis bouc-wen model, a survey[END_REF] and using the Laplace transform of (1), the adopted model for the displacement at the tip of the piezoelectric actuator is given, in the frequency domain, by the following:

             y A (s) = d p U -H s -s p F A - 3 2L a s p M A D(s) α A (s) = 2 L a (d p U -H s ) - 3 2L a s p F A - 3 L 2 a s p M A D(s) Ḣs = α U -β | U|H s -γ U|H s | (3

) where

• y A is the displacement of the piezoelectric actuator's tip A along the Y axis, • α A is the angle between the actuator's tip A and the X axis,

• d p = d
k is the piezoelectric constant and s p = 1 k is the elastic constant,

• F A is an external force applied at the actuator's tip A,

• M A is an external torque applied at the actuator's tip A,

• U is the applied voltage to the piezoelectric actuator, • H s is an internal variable to represent the hysteresis, • D(s) is a transfer function to represent the dynamics of the actuator, • α is a parameter which determines the amplitude of the hysteresis, • β and γ are parameters which determine the shape of the hysteresis. Second order transfer functions are commonly used to model the dynamics of a piezoelectric actuator [START_REF] Low | Modeling of a three-layer piezoelectric bimorph beam with hysteresis[END_REF], [START_REF] Rakotondrabe | Quadrilateral modelling and robust control of a nonlinear piezoelectric cantilever[END_REF]. D(s) is then considered as a second order transfer function with a static gain 1 (D(0) = 1). It can be written as follows:

D(s) = k ms 2 + bs + k (4)

III. MODEL OF THE SMART FINGER AT THE END-EFFECTOR TIP

The aim of this section is to develop the model of the complete smart finger with and without contact with the environment. The inputs of the smart finger in this case are the voltage applied on the piezoelectric actuator electrodes, U, and the distance between the equilibrium position of the environment without any contact and the X axis, y e , while the outputs of the system are the position of the sensorized end-effector's tip B and the interaction force between the end-effector and the environment, F e .

The model of smart finger is developed using the model developed in (3) of the piezoelectric actuator where a force and a torque is applied at the tip A of the piezoelectric actuator ( f A and M A ). Then, However, in the case of the paper, the force will be applied at the end-effector's tip B. Thus, the effect of applying a force at the end-effector's tip B is studied and the relation between the force applied at the tip B and the reaction forces and torque at the tip A is determined. Finally, the complete model of the smart finger when a force is applied at tip B is deduced for the non contact and contact scenarios. One unified model is developed and derived from the two models.

Starting with the case where a force is applied by the environment at the force sensor's tip B, a reaction force F A and a reaction torque M A exist on the actuator's tip A, which can be written as follows:

F A = -F s + m s ÿB = F e + m s ÿB M A = -LF s = LF e ( 5
)
where F e = F end-effector→environment is the force applied by the end-effector to the environment and F s =f e = F environment→end-effector is the force applied by the environment to the end-effector when a contact exists; m s is the mass of the force sensor. The mass of the force sensor is neglected because it is small compared to the mass of the actuator (m s = 0). As the force sensor is also flexible, it can be modeled as a mass-spring-damper system where the mass is neglected and then the force sensor is modeled as a spring-damper. On a force F s is applied at the force sensor's tip B, the force sensor deforms and the displacement of the force sensor is δ = y By o B where y o B is the supposed position of the force sensor's tip B without considering the deformation of the force sensor. The relation between the F s , y B and y o B is given, in the time domain, as follows:

F s = -F e = b s ( ẏB -ẏo B ) + k s (y B -y o B ) (6)
where b s and k s are respectively the damping and the stiffness of the force sensor and its mass is neglected. y o B is given as follows:

y o B = y A + Lsinα A (7)
Since α A is supposed to be small sinα A ≈ α A and using (3), [START_REF] Al-Janaideh | An analytical generalized prandtl-ishlinskii model inversion for hysteresis compensation in micropositioning control[END_REF], and [START_REF] Leang | Hysteresis, creep, and vibration compensation[END_REF], Y o B is given as follows:

Y o B (s) = 1 + 2L L a (d p U -H s ) - 1 + 3L 2L a + 3L 2 L 2 a s p F e D(s) (8)
Using [START_REF] Rakotondrabe | Bouc-wen modeling and inverse multiplicative structure to compensate hysteresis nonlinearity in piezoelectric actuators[END_REF] and the Laplace transform of (6), the displacement at the end-effector's tip B is given as follows:

Y B (s) = L u k ms 2 + bs + k (d p U -H s ) - ms 2 + b + b s L f s + k + k s L f (b s s + k s ) (ms 2 + bs + k) F e ( 9
)
where

L u = 1 + 2L L a and L f = 1 + 3L L a + 3L 2 L 2 a
In addition, the force applied by the end-effector on the environment is given by: f e = m e ÿB + b e ẏB + k e (y By e ) if y B ≥ y e 0 if y B < y e [START_REF] Devasia | A survey of control issues in nanopositioning[END_REF] where m e , b e and k e are respectively the mass, damping and stiffness of the environment. Using ( 9) and the Laplace transform of [START_REF] Devasia | A survey of control issues in nanopositioning[END_REF], the following could be deduced:

F e (s) = G u (s) [d p U -H s -G e (s)Y e ] if y B ≥ y e 0 if y B < y e ( 11
)
where: 9) and ( 11), the final model at the end-effector's tip B could be written as follows:

         G u (s) = L u
                       Y B = 1 + 2L L a (d p U -H s ) - 1 + 3L 2L a + 3L 2 L 2 a s p F e D ′ (s) F e = G u (s) [d p U -H s -G e (s)Y e ] if y B ≥ y e 0 if y B < y e Ḣs =α U -β | U|H s -γ U|H s | (13)
The complete model of the smart finger can be represented by the scheme in figure 3 where the inputs of the model are U and y e and the outputs are y B and F e .

IV. EXPERIMENTAL SETUP

The experimental setup used in this paper, in order to validate the developed model, is composed of a smart finger and displacement and force sensors. The smart finger is composed of a duo bimorph piezoelectric actuator presented in [START_REF] De Lit | A four-degree-offreedom microprehensile microrobot on chip[END_REF] and a novel piezoresistive force sensor presented in [START_REF] Komati | Prototyping of a highly performant and integrated piezoresistive force sensor for microscale applications[END_REF]. Two Keyence laser sensors are used to measure the displacement of the actuator's tip A and the end-effector's tip B. A force sensor from FemtoTools, with a sensing range of 10mN, is fixed on a XY positioning stage from PiezoSys-temJena, PXY D12 with a displacement range of 200µm. The force sensor comprises a probe of 3mm of length and 50µm of thickness, that moves along its main direction (Y according to Figure 4) once a force is applied at its tip. The XY positioning is used to move the FemtoTools force sensor towards the piezoresistive force sensor to calibrate the force sensor and to simulate a contact between the smart finger and the force sensor. The whole system is controlled using a dSpace1104 with a sampling frequency of 10kHz. The experimental setup is shown in Figure 4.

V. EXPERIMENTAL STUDIES

In this section, the presented model in section III is verified experimentally. The validation of the model is performed in three steps. First, the model of the displacement/voltage is determined without any contact between the smart finger and the environment. Then, the model of force/displacement is determined without any applied voltage. Finally, the complete model (displacement/force/voltage), defined in [START_REF] Grasso | Piezoelectric self sensing actuators for high voltage excitation[END_REF], is tested by applying both voltage and contact to the smart finger. The identified parameters are summarized in Table I.

A. Displacement/Voltage Model of the Smart Finger

In this section, no force is applied at the tip of the smart finger. Two Keyence sensors are used to measure the displacement at points A and B of the actuator and end-effector respectively. The experiments are done in the following steps:

1) the parameters of the actuator, d p , α, β and γ, defined in (3) are identified by applying a sine wave with a frequency of 0.1Hz (to ignore the dynamic part D(s)) without any force and using the nonlinear least square method in order to fit the experimental results with the model. A comparison between the model and the experiments after the parameter estimation is shown in Figure 5 for three different amplitudes of the sine waves (30V, 60V and 100V), 2) the dynamic part, D(s), of piezoelectric actuator is determined by applying several steps with different amplitudes and determining the second order transfer function which fits the best to the experimental data.

The dynamic response of the piezoelectric actuator is independent of the voltage amplitude. The parameters m k and b k of ( 4) are then determined in Table I, 3) the model of y B defined in ( 13) is tested without contact and at different frequencies of sine waves. The results are shown in Figure 6. 1) parameters s p and k are determined by applying a force by moving the FemtoTools sensor towards tip A and measuring the displacement at tips A and B, 2) a force is applied at tip B and the models defined in (3) and ( 13) are tested without voltage (eliminating parameters U and H s ). The comparison between the models and the experimental results is shown in Figure 7 where the model fits the experimental results with an error less than 2%. In this section, after validation the displacement/voltage and force/displacement, the two models are combined to test the complete displacement/force/voltage. Sine waves are applied to the actuator's electrodes. The smart finger starts deforming and approaches the environment until entering in contact with the environment and the force starts to increase. Then, the smart finger returns back and separate the contact. The action is repeated many times. The models of y B and F e given in ( 13) are compared to the experimental results in Figure 8. The experimental results fit to the model with errors less than 10%.

All the experimental results fit with the developed model ( 13) with errors less than 10%. Thus, the developed model in ( 13) is validated. The identified parameters of the smart finger are shown in Table I.

VI. CONCLUSION

In this paper, a generic microscale problem is studied where a sensorized end-effector is fixed on the tip of a piezoelectric actuator. This problem is important at the microscale because it offers a force measurement of the applied force by the actuator to a flexible environment which enables to understand the interaction between the complete finger (actuator + sensorized end-effector) and to design and control the interaction between the finger and the environment. The effect of adding a sensorized end-effector influences the behavior of the actuator and is not studied in recent works.

The complete finger, which is called in this paper smart finger, consists of a piezoelectric actuator, an end-effector and a novel piezoresistive force sensor. A complete model is developed for both force and displacement at the finger's tip while interaction with a flexible environment. A nonlinear model of the piezoelectric actuator is considered and a complete model is developed taking into account the frequency dependent hysteresis of the piezoelectric actuator. The model of the hysteresis is based on the Bouc-Wen method which simplifies the parameter estimation. The complete model of the finger is validated experimentally with small errors (less than 10%). These errors are due to the approach of modeling the rate-dependent hysteresis which simplifies the identification of the parameters and the implementation of the method. These errors can be reduced by using more complex and advanced models of the rate-dependent hysteresis which is not the objective of the paper. This paper offers a complete theoretical method for modeling such systems where this method can be used to model other types of actuators and actuated MEMS structures.

Fig. 1 .

 1 Fig. 1. Complete scheme of the smart finger and the environment: (a) without contact and without any applied voltage, (b) without contact and with an applied voltage, (c) just at contact (F e = 0) and with an applied voltage and (d) with contact (F e = 0) and with an applied voltage.

  k m e s 2 + b e s + k e (b s s + k s ) H(s) G e (s) = k e ms 2 + bs + k L u k (m e s 2 + b e s + k e ) (12) where H(s) =m e s 4 + mb s + mb e + m e b + L f b s s 3 + mk s + bb s + mk e + m e k + L f k s + b e b + L f b s s 2 + bk s + kb s + b e k + L f k s + k e b + L f b s s+ kk s + k e k + L f k s Using (

Fig. 3 .

 3 Fig. 3. Bloc diagram showing the model of the complete smart finger in interaction with a flexible environment.

Fig. 4 .

 4 Fig. 4. The whole experimental setup used in this paper including the smart finger, the XY positioning stage, a Keyence laser sensor and the FemtoTools force sensor.

Fig. 5 .

 5 Fig. 5. Comparison between the Bouc-Wen static hysteresis model and experimental results for many sine voltages with three different amplitudes 30V, 60V and 100V at a frequency 0.1Hz.

Fig. 6 .

 6 Fig. 6. Comparison between the displacement model of the end-effector tip B y B given in (13) and experimental results for many sine voltages with an amplitude of 100V and with different frequencies where no force is applied: (a) 10Hz, (b) 50Hz, (c) 100Hz and (d) 500Hz. Small errors (less than 10%) between the model and the experimental result exist on the displacement/voltage model due to the model of Bouc-Wen used where the dynamic hysteresis is estimated using the static hysteresis determined by the Bouc-Wen method, H s (U), and the transient part of the actuator, D(s) and the dynamic hysteresis is identified by H(U, s) = H s (U) • D(s) B. Force/Displacement Model of the Smart Finger After validating the displacement/voltage model of the smart finger, the electrodes of the piezoelectric actuator are

Fig. 7 .

 7 Fig. 7. Comparison between the displacement model at tips A and B, y A and y B , given in (13) and (3) and experimental results when a force is applied at the end-effector's tip B in static and with a short circuit on the electrodes of the actuator: (a) comparison at actuator's tip A, y A , and (b) comparison at end-effector's tip B, y B

Fig. 8 .

 8 Fig. 8. Comparison between the model of the force, given in (13), applied by the smart finger on the environment and the measured force. Parameter Identified Values d p 0.54µm/V s p 3.57×10 -4 α 0.316 β 0.019 γ 0.0033 m 1.347 × 10 -4 b 0.469 k 2800 L a 13.5mm L 8mm k s 130N/m

TABLE I THE

 I IDENTIFIED PARAMETERS USED IN THIS PAPER

ACKNOWLEDGMENT

These works have been partially funded by the Franche-Comté region, the Labex ACTION project (contract "ANR-11-LABX-01-01") and the French RENATECH network through its FEMTO-ST technological facility.


João Bosco

Ferreira Filho
email: joao.ferreirafilho@inria.fr

Olivier Barais

Mathieu Acher

Jérôme Le Noir

Axel Legay

Benoit Baudry

J B F Filho

Generating Counterexamples of Model-based Software Product Lines

Keywords: Software Product Lines, Model-based Engineering, Counterexamples

In a Model-based Software Product Line (MSPL), the variability of the domain is characterized in a variability model and the core artifacts are base models conforming to a modeling language (also called metamodel). A realization model connects the features of the variability model to the base model elements, triggering operations over these elements based on a configuration. The design space of an MSPL is extremely complex to manage for the engineer, since the number of variants may be exponential and the derived product models have to be conforming to numerous well-formedness and business rules. In this paper, the objective is to provide a way to generate MSPLs, called counterexamples (also called anti-patterns), that can produce invalid product models despite a valid configuration in the variability model. We describe the foundations and motivate the usefulness of counterexamples (e.g., inference of guidelines or domain-specific rules to avoid earlier the specification of incorrect mappings; testing oracles for increasing the robustness of derivation engines given a modeling language). We provide a generic process, based on the Common Variabil-

Introduction

A Software Product Line (SPL) is a set of similar software products that share common features and assets in a particular domain [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF]. Based on a desired set of features -usually documented in a variability model -the corresponding domain assets are combined during a so-called product derivation process. There can be different automation levels of product derivation, from manual development effort to more sophisticated technologies, including automated variant configuration and generation [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF]. The challenge for practitioners is to develop and exploit what products have in common and manage what varies among them [START_REF] Svahnberg | A taxonomy of variability realization techniques: Research articles[END_REF][START_REF] Chen | Variability management in software product lines: a systematic review[END_REF]. SPL engineering has emerged to address the problem [START_REF] Clements | Software Product Lines : Practices and Patterns[END_REF][START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF] involving both the research community and the industry.

Model-based SPLs (MSPLs) have the same characteristics and objectives of an SPL, except that it extensively relies on models and automated model transformations. Models, as high-level specifications of a sys-tem, are traditionally employed to automate the generation of products as well as their verifications [START_REF] Schmidt | Model-Driven Engineering[END_REF]. The derivation of the customized models, corresponding to a final product, is achieved through a set of transformations.

MSPL in Industry and CVL

A variety of models may be used for different development activities and artefacts of an SPL -ranging from requirements, architectural models, source codes, certifications and tests to user interfaces. Likewise, different stakeholders can express their expertise through specific modeling languages (also called metamodels) and environments. It is an important requirement in large companies like Thales [START_REF] Voirin | Method & tools to secure and support collaborative architecting of constrained systems[END_REF]. Many domains of expertise are indeed involved during the design, development and certification of systems. Stakeholders, whatever their roles or professions (requirement engineers, system engineers, software developers) in the organization, use a specific language to express his or her expertise. Stakeholders also use an associated and specific environment for elaborating and evolving the models, checking their complex properties, etc. As variability cross-cuts all development phases of an MSPL -from requirements to testing, stakeholders necessarily face the need to manage commonalities and variabilities within their models and throughout their specific modeling environments.

Numerous MSPL techniques have been proposed (e.g., see [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF][START_REF] Perrouin | Reconciling automation and flexibility in product derivation[END_REF][START_REF] Heidenreich | Relating feature models to other models of a software product line: A comparative study of featuremapper and vml*[END_REF][START_REF] Czarnecki | Mapping features to models: A template approach based on superimposed variants[END_REF][START_REF] Classen | Model checking lots of systems: efficient verification of temporal properties in software product lines[END_REF][START_REF] Czarnecki | Verifying feature-based model templates against well-formedness ocl constraints[END_REF][START_REF] Ziadi | Software product line engineering with the uml: Deriving products[END_REF][START_REF] Voelter | Product line implementation using aspect-oriented and model-driven software develop-ment[END_REF]). They usually consist in i) a variability model (e.g., a feature model or a decision model), ii) a model (e.g., a state machine, a class diagram) expressed in a specific modeling language (e.g., Unified Modeling Language (UML) [START_REF] Group | OMG Unified Modeling Language (OMG UML)[END_REF]), and iii) a realization layer that maps and transforms variation points into model elements. Based on a selection of desired features in the variability model, a derivation engine can automatically synthesise customized models -each model corresponding to an individual product of the SPL. The Common Variability Language (CVL) [START_REF] Fleurey | Standardizing Variability -Challenges and Solutions[END_REF] has recently emerged as an effort to standardize and promote MSPLs (see Section 2 for background information). For instance, Thales prototypes the use of CVL on dedicated domain-specific modeling languages for systems engineering.

Supporting the design of an MSPL

The design space (also called domain engineering) of an MSPL is extremely complex to manage for a developer. First, the number of possible products of an MSPL is exponential to the number of features or decisions expressed in the variability model. Second, the derived product models 1 have to be conformant to numerous well-formedness and business rules expressed in the modeling language (e.g., UML exhibits 684 validation rules in its EMF implementation). The number of derived models can be infinite while only part of the models are safe and conforming to numerous wellformed and business rules. Consequently, a developer has to understand the intrinsic properties of the modeling language when designing an MSPL. Last but not least, the two modeling spaces should be properly connected so that all valid combinations of features (configurations) lead to the derivation of a safe model. It is easy to forget a constraint between features in a variability model and allow a "valid" configuration despite the derivation of an unsafe product. It is also easy to specify a mapping that both delete and add the same model element for a given configuration. In the case of CVL, the realization model that connects a variability model and a set of design models, can be very expressive.

A one-size-fits-all support for designing MSPLs is unlikely, since models are conformant to their own wellformedness (syntactic) rules and domain-specific (semantic) rules. Each time a new modeling language is used for developing an MSPL, the realization layer should be revised accordingly. We observed this kind of situation in the context of prototyping the use of CVL with Thales. For instance, in [START_REF] Filho | Customizing the common variability language semantics for your domain models[END_REF], we expose different strategies to customize the derivation engine since the one provided by default in CVL does not suit the needs. Without adequate support, a developer of an MSPL is likely to introduce errors. The tooling support can provide different facilities: anti-patterns (counterexamples) to document what should be avoided during the design of an MSPL; domain-specific rules to avoid earlier the specification of incorrect mappings; examples to show possible correct MSPL, etc. Moreover, the support offered to domain experts should be ideally specific to a domain metamodel. Methodological support and guidelines are also needed to identify what constructs of a metamodel are likely to vary; to define an accurate realization model; or to develop specific derivation engines for a given modeling language.

Contributions

In this article, the objective is to provide a way to generate counterexamples of MSPLs, that is, examples of MSPLs that authorize the derivation of syntactically or semantically invalid product models despite a valid configuration in the variability model. These counterexamples aim at revealing errors or risks -either in the derivation engine or in the realization model -to stakeholders of MSPLs. On the one hand, counterexamples serve as testing "oracles" for increasing the robustness of checking mechanisms for the MSPL. Developers can use counterexamples to foresee boundary values and types of MSPLs that are likely to allow incorrect derivations. On the other hand, stakeholders may repeat the same kind of errors when specifying the mappings between a variability model and a base model. Counterexamples act as "antipatterns" that should avoid bad practices or decrease the amount of errors for a given modeling language.

We provide a systematic and automated process, based on CVL, to randomly search the space of MSPLs for a specific formalism (see Section 3). We develop a generic tool for supporting the methodology and approach initiated in [START_REF] Filho | Generating counterexamples of model-based software product lines: an exploratory study[END_REF]. The tool, called LineGen, aims to assist developers of MSPL and builders of MSPL tools by generating counterexamples of MSPLs (see Section 4). expressed in a given domain metamodel. Li-neGen relies on CVL and is flexible to target different scenarios. It can work either with just the domain metamodel as input or also with pre-defined variability models and base models. More details about LineGen can be found online: https://code.google.com/p/linegen/ wiki/LineGen.

We validate the effectiveness of this process for three formalisms (UML, Ecore and a simple finite state machine) with different scales (up to 247 metaclasses and 684 rules) and different ways of expressing validation rules (see Section 5).

Another extension of our previous work [START_REF] Filho | Generating counterexamples of model-based software product lines: an exploratory study[END_REF] is the application of the approach in an industrial setting (see Section 6). We describe the rationale behind the introduction of LineGen and CVL at Thales; we also report on how we do scale for a very large metamodel with 20+ domain-specific modeling languages.

Background and Motivation

Model-based Software Product Lines

An SPL is a set of similar software products that share common features and assets in a particular domain. The process of constructing products from the SPL and domain assets is called product derivation. Depending on the form of implementation, there can be different automation levels of product derivation, from manual development effort to more sophisticated technology, including automated variant configuration and generation.

An MSPL has the same characteristics and objectives of an SPL, except that it extensively relies on models. In an MSPL, domain artefacts (requirements, tests, graphical interfaces, code) are represented as models conformant to a given modeling language, also called metamodel. (For instance, state machines can be used for specifying and testing the behavior of a system.) The goal of an MSPL is to derive customized models, corresponding to a final product, through a set of automated transformations [START_REF] Voelter | Product line implementation using aspect-oriented and model-driven software develop-ment[END_REF][START_REF] Czarnecki | Generative programming for embedded software: An industrial experience report[END_REF].

Numerous approaches, being annotative, compositional or transformational, have been proposed to develop MSPLs (see Section 7 for more details). We will use the Common Variability Language (CVL) throughout the paper. We chose CVL because many of the MSPL approaches are actually amenable to this language (CVL is an effort involving both academic and industry partners to promote standardization for MSPLs).

Common Variability Language

In this section, we briefly present the main concepts of CVL and introduce some formal definitions that are useful for the remainder of this paper. CVL is a domainindependent language for specifying and resolving variability over any instance of any MOF2 -compliant metamodel. The overall principle of CVL is close to many MSPL approaches: (i) A variability model formally represents features/decisions and their constraints, and provides a high-level description of the SPL (domain space); (ii) a mapping with a set of models is established and describes how to change or combine the models to realize specific features (solution space); (iii) realizations of the chosen features are then applied to the models to derive the final product model.

CVL offers different constructs to develop an MSPL, and they can be distinguished in three parts:

-Variability Abstraction Model (V AM ) expresses the variability in terms of a tree-based structure. Inspired by feature and decision modeling approaches [START_REF] Czarnecki | Cool features and tough decisions: a comparison of variability modeling approaches[END_REF], the main concepts of the V AM are the variability specifications, called VSpecs. The VSpecs are nodes of the V AM and can be divided into three kinds (Choices, Variables, or Classifiers). In the remainder of the paper, we only use the Choices VSpecs, making the V AM structure as close as possible to a Boolean feature model -the variant of feature models among the simplest and most popular in use [START_REF] Benavides | Automated Analysis of Feature Models 20 Years Later : A Literature Review[END_REF]. These Choices can be decided to yes or no (through ChoiceResolution) in the configuration process. -Base Models (BM s) a set of models, each conforming to a domain-specific modeling language (e.g., UML). The conformance of a model to a modeling language depends both on well-formedness rules (syntactic rules) and business, domain-specific rules (semantic rules). Using CVL, the decision of a Choice will typically specify whether a condition of a model element, or a set of model elements, will change after the derivation process or not. In this way, these choices must be linked to the model elements, and the links must explicitly express what changes are going to be performed. The aforementioned links compose the V RM , determining what will be executed by the derivation engine. Therefore, these links contain their own meaning. We consider that these links can express three different types of semantics:

-Existence. It is the kind of VP in charge of expressing whether an object (ObjectExistence variation point) or a link (LinkExistence variation point) exists or not in the derived model. -Substitution. This kind of VP expresses a substitution of a model object by another (ObjectSubstitution variation point) or of a fragment of the model by another (FragmentSubstitution) -Value Assignment. This type of VP expresses that a given value is assigned to a given slot in a base model element (SlotAssignment V P ) or a given link is assigned to an object (LinkAssignment V P ).

Using the models provided by CVL, one can completely express the variability over any MOF-compliant BM . In addition, it is possible to derive a family of models that will compose an MSPL. Therefore, it is possible to properly define an MSPL in terms of CVL (see Definition 1).

Definition 1 (Model-based SPL) An MSPL = CVL, δ is defined as follows:

-A CV L = V AM, V RM, BM S model is a 3-tuple such that: -V AM is a tree-based structure of VSpecs. We denote C V AM the set of possible valid configurations for V AM ; -V RM is a model containing the set of mapping relationships between the V AM and the BM3 ; -BM S = {BM 1 , BM 2 , . . . , BM n } is a set of models, each conforming to a modeling language; -δ : CV L × c → DM is a function that produces a derived model DM from a CV L model and a configuration 4 c ∈ C V AM . This function represents the derivation engine.

Issues in Realizing Variability

We now introduce our running example to illustrate CVL and the issues raised when developing an MSPL. Running Example. Let us consider the Finite-State Machine (FSM) modeling language. As shown in Figure 1, the FSM metamodel has three classes: State, Transition, and FSM. The metamodel defines some rules and constraints: a finite state machine has necessarily one initial state and a final state; a transition is necessarily associated to a state, etc. Some other rules may be expressed with OCL constraints (they are not in Figure 1 for conciseness), for example, to specify that there are no States with the same name.

Using CVL and the metamodel of Figure 1, we can define a family of finite state machines. As shown in Figure 2, the V AM is composed by a set of VSpecs, while the VRM is a list of variation points, binding the V AM to the BM . The BM is a set of states and transitions conforming to the metamodel presented in Figure 1. The schematic representation of Figure 2 depicts a V AM (left-hand side) with 6 boolean choices (e.g., V S 5 and V S 6 are mutually exclusive) as well as a VRM that maps V S 3 , V S 2 , V S 5 and V S 6 to transitions or states of a base model denoted BM .

VAM t1# t3# t2# Object#Existence1# Link#Existence1# Link#Existence2# Link#Existence3# A B# C# VS 1 # VS 6 # VS 4 # VS 5 # VRM BM VS 2 # 0..1 # VS 3 #
Fig. 2 CVL model over an FSM base model.

Considering the MSPL of Figure 2, it is actually possible to derive incorrect FSM models even starting from a valid BM and valid configurations of VAM. This is illustrated in Figure 3. Configuration 1 gener-

t1# t2# A C# 0# 1# 1# 0# 0..1 # 1# 1# 1# 1# 0# 0# 0..1 # 0# 1# t3# A C# 1# 1# 0# 1# 0..1 # 1# 1# t1# t3# A B# C# Derivation Derivation Derivation Configuration 1# Configuration 2 Configuration 3
Fig. 3 Configuration and derivation of FSMs.

ates a correct FSM model, i.e., conforming to its metamodel. Conf iguration 2 and Conf iguration 3, despite being valid configurations of the VAM, lead to two unsafe products. Indeed, the FSM model generated from Conf iguration 2 is not correct: according to the metamodel, an outgoing transition must have at least one target state, which does not hold for transition t1. In the case of Conf iguration 3, the derived product model has the incoming transition t3 without a source state, which also is incorrect with respect to the metamodel. Even for a very simple MSPL, several unsafe product models can be derived in contradiction to the in-tention of an MSPL designer. In practice, specifying a correct MSPL is a daunting and error-prone activity due to the fact that the number of choices in the VAM, the number of classes and rules in the metamodel and the size of the VRM can be bigger.

The problem of safely configuring a feature or a decision model is now well understood [START_REF] Benavides | Automated Analysis of Feature Models 20 Years Later : A Literature Review[END_REF]. Moreover, several techniques exist for checking the conformance of a model for a given modeling language. The connection of both parts (the VAM and the set of base models) and the management of the realization layer are still crucial issues [START_REF] Thaker | Safe composition of product lines[END_REF][START_REF] Asirelli | Formal description of variability in product families[END_REF][START_REF] Svendsen | Specifying a testing oracle for train stations -going beyond with product line technology[END_REF][START_REF] Czarnecki | Verifying feature-based model templates against well-formedness ocl constraints[END_REF][START_REF] Classen | Model checking lots of systems: efficient verification of temporal properties in software product lines[END_REF].

Generating Counterexamples

We argue that the realization layer may concern at least two kinds of users:

designers of MSPLs in charge of specifying the VAM, the BMs, as well as the relationships between the VAM and the BMs (V RM )(see CV L of Definition 1); -developers of derivation engines in charge of automating the synthesis of model products based on a selection of features (Choices) (function δ of Definition 1);

Incorrect derivation engines or realization models may authorize the building of unsafe products. The majority of the existing work target scenarios in which an existing MSPL has been designed and seeks to first check its consistency, then to generate unsafe product models -pointing out errors in the MSPL. These techniques are extremely useful but assume that a generic derivation engine exists and is correct for the targeted modeling language -which is hardly conceivable in our case. Moreover, designers of MSPLs are likely to perform typical errors for a given modeling language (e.g., FSM).

Counterexamples to the Rescue

We precisely want to provide support to the two kinds of users in their activities. Specifically, we are interested on finding MSPLs that apparently would derive models that respect the domain modeling language, as they have a correct variability model and a conforming base model, but however, either their VRM or their derivation engine were incorrectly designed. Definition 2 formalizes this kind of MSPL as counterexamples.

Definition 2 (Counterexample of MSPL) A counterexample CE is an M SP L in which:

-CVL is well-formed;

-There exists at least one valid configuration in VAM:

C V AM = ∅; -∃ c ∈ C V AM , δ (CV L, c , BM ) = DM ′ such that
DM ′ does not conform to its modeling language.

The expected benefits are as follows:

-SPL designers in charge of writing CVL models, can better understand the kinds of errors that should be avoided (Figure 3 gives two "antipatterns"). -developers of derivation engines can exploit counterexamples as testing oracles, anticipating the kinds of inputs that should be properly handled by their implementation. Furthermore, they can enrich the derivation engine with domain specific validation rules. In addition, specific error reports can be generated when an MSPL is incorrect, inspired by the catalogue of counterexamples.

Overview of the Generation

In order to systematically generate counterexamples of MSPLs, we have defined a set of activities that can be performed for this purpose. Figure 4 presents an overview of the process that generates a single counterexample, as well as the input and output for the different phases. We have divided the process into four phases, which are explained in details in the following subsections; the second and the third phases are part of the greater activity of generating a CVL model.

1. The first phase is the set up of the input that will be taken into account; different activities can be performed, depending on the input. 2. The second phase is the generation of a random variability model and of a valid random configuration. 3. The third phase is the generation of the relationships between the VAM and the base model elements, i.e., the variability model (VRM). 4. The fourth and last phase is to identify whether the generated model is a counterexample or not. In case it is not, we go back to the second step.

Set up input

Generally, companies that use or decide to set up a product line already have an initial set of core assets.

In the case of MSPLs, if the models are not available, it is common to have the metamodel and the wellformedness rules of the modeling language. Considering this, the metamodel and the rules of the domain-specific modeling language are a starting point to generate a CVL model. Our approach is adaptable to work with both cases, whether the models are available or only their metamodel. In the case they are not available, we apply randomizations over the metamodel to create random models. These random instances populate the Base Model, and their correctness is checked against the metamodel and the well-formedness rules. If a created model is not correct, this instance is discarded. In the case of the FSM modeling language, the checked well-formedness rules are: if the initial state is different of the final, if the FSM is deterministic and if all the states are reachable. On the other hand, if we already have a set of models, we can use mutation operators to increase the number of samples, or just not modify the base models. Mutations operators are basic CRUD (Create, Read, Update, Delete) operations on the base model that are applied randomly.

Generate VAM and Resolution

For generating the V AM and the V RM , the following parameters are required:

-The maximum depth of the V AM (MAX DEPTH) and the maximum number of children for each V Spec (MAX CHILDREN). -The percentage of V Specs that will be linked to variation points (LINK PERCENT). For example, in Figure 4, the V AM was generated with a percentage of 66%, as four out of six V Specs are linked to V P s.

Once the BM is established and the parameters have been set, we take them as input to start the generation of the CVL model. First, if the V AM is not provided by the user, we generate it, creating a root V Spec and its children. The number of children is decided randomly, ranging from 0 to MAX CHILDREN. The V Spec creation is repeated for each generated child until the (MAX DEPTH) is reached or there are no more V Specs with children. The only imposed generation is of the root node of the tree, after, it is a random decision between creating (or not) each child.

After generating the V AM , it is necessary to check its correctness, as we are not interested in wrong V AM s. For this reason, we translate the VAM to a language that can provide us a background for analysing it. The FAMILIAR language is executable and gives support to manipulate and reason about feature models [START_REF] Acher | Familiar: A domain-specific language for large scale management of feature models[END_REF] (we could also rely on existing frameworks like FaMa [START_REF] Benavides | Automated Analysis of Feature Models 20 Years Later : A Literature Review[END_REF]). As stated in Section 2.2, the kinds of VAM we consider in this paper are amenable to boolean feature models supported by FAMILIAR. Using FAMILIAR, we check whether the variability model is valid or invalid. If it is an invalid model, we discard it and return to the V AM generation step. A resolution model is necessary in order to resolve the variability expressed in the V AM . To generate the configuration, we create the corresponding resolution CV L element for each V Spec. Meanwhile, random values (true or false) are set for each ChoiceResolution that has been created. We use standard satisfiability techniques to randomly generate a resolution, which is, by construction, a valid configuration of the V AM .

Generate VRM

Once we have a correct V AM and a correct BM , we can generate the V RM to link each other. To do this, we iterate over the set of choices in the V AM , deciding if the given choice is pointed or not by a Variation Point. This decision is done based on the (LINK PERCENT) parameter. If the decision is true, we create the V P in the V RM . The type of the V P is also random. To finish the creation of the VP, we also randomize its target over the set of model elements of the BM . Naturally, we restrict the set of the randomization with respect to the kind of V P , e.g., a LinkExistence has a random target randomized over the subset of BM references.

The VRM generation can also be independent, from existing VAMs and BMs, one could then explore the possibilities of relationships between them.

Detect Counterexample

Although Figure 4 describes the process of generating one single counterexample, we iterate the process to produce a set of counterexamples. For this reason, the first parameter to be taken into account is the stopping criteria. The stopping criteria can be specified in two different ways. The first one defines a target number of counterexamples, making the process repeat until this number is reached. The second one is to set an amount of time, stopping the process after it has elapsed.

After the aforementioned steps have been performed, we have a correct CVL model, composed by a correct V AM and a V RM created in conformance to the CVL metamodel. We also have a valid configuration c and a correct set of models composing the BM . The next step is to derive a product model using the CVL, c and the BM . If the derived model is incorrect, in other words, having δ (CV L, c , BM ) incorrect, we have found a counterexample as states the Definition 2, and consequently, we add it to the oracle. If the model is correct then we discard it and we come back to the generate VAM phase, synthesising a new entire CVL model.

The derivation engine is an algorithm that visits each of the variation points in the CVL model, executing them according to the resolution of the variability model. Our implementation of the CVL derivation engine follows the operational semantics of each variation point defined in the CVL specification (for further details, see the Annex A of the CVL revised submission provided in http://www.omgwiki.org/variability).

To check if the derived model is correct, we relied on the EMF Diagnostician, using it as a black box to validate the conformance of the generated instance of the given metamodel.

As we will discuss in Section 4, these counterexamples can be helpful to the domain experts in charge of designing the CVL model or developing their derivation engines for their domain.

Tool Support

To support the process of generating counterexamples of MSPLs (exposed in the previous section), we developed a dedicated tool, called LineGen. Figure 5 gives an overview of the main features of LineGen. Depending on the inputs, the tool addresses different scenarios of counterexamples' generation -from the whole exploration of a modeling space (in the case only a metamodel is given) to the design of a specific MSPL (the variability model and the base model can be given by the user).

Specifically, the only mandatory input for LineGen is the metamodel of the base language. Additionally, the user can choose to provide existing base model and variability model; if this is the case, LineGen will not modify these models, setting them as immutable during the generation. To generate an MSPL example or counterexample, LineGen synthesizes a variability model, a configuration, a base model, and a set of realization relationships. LineGen calls the EMF's Diagnostician and checks the conformance of the base model with its input metamodel. After, LineGen checks the correctness of the variability model and the satisfiability of the configuration; to do so, it uses the reasoning engine within the FAMILIAR language. If they pass, LineGen carries on generating the realization relationships, finishing the CVL model.

After everything is generated, LineGen calls the CVL derivation engine, giving as input the generated CVL model (the triplet: variability model, realization model and base model) and a configuration. The goal of the call to the derivation engine is to determine whether the derived model is conforming to its modeling language. If it is, the CVL model given as input to the derivation engine is considered as an example of MSPL; otherwise it is considered as a counterexample.

We used different technologies as part of the Line-Gen implementation. As the user interface is an Eclipse 4 RCP application, it is written in Java. The core algorithms of the model generation parts are in Scala; we chose to use the same language in which we previously implemented the CVL derivation engine. We used the EMF API to manipulate and check the Ecore metamodels and model instances. To benefit from automatic analysis of the variability model, we translated the VAM to the FAMILIAR language [START_REF]FAMILIAR: FeAture Model scrIpt Language for manIpulation and Automatic Reasonning[END_REF].

Figure 5 shows the graphical user interface of Line-Gen. The user must load the Ecore metamodel of the modeling language to be able to perform the generation steps (see 1 ). Once the metamodel has been successfully loaded-the Console (see 6 ) shows whether Line-Gen successfully completed an operation or not-it is possible to generate a base model by pressing the Generate BM button (see 2 ); a file named BaseModel is created with the chosen extension. The Max Many field should be set to limit the number of instances of a given model element.

The same process applies to the VAM generation (see 3 in Figure 5). The user specifies the maximum depth of the VAM, as well as the maximum number of children per feature. After pressing the Generate VAM button, LineGen creates a CVL model with just the VAM part defined. In the VRM tab, the user can define the percentage of features linked to a variation point in the VRM (see 4 ).

In the Counterexamples and Examples tabs (see 5 ), the user can start the generation process that will randomly search for examples or counterexamples of MSPLs. If the user chooses to use the Load Existing Base Model or Load Existing VAM tabs, LineGen uses the loaded models without modifying them and just generates VRM models. The field Number of Counterexamples determines when LineGen has to stop the search. The Console tab also provides exception messages, in case an unexpected error occurs. More details Fig. 5 LineGen user interface about LineGen can be found online: https://code. google.com/p/linegen/wiki/LineGen.

Evaluation

The goal of this evaluation is to verify the applicability and effectiveness of the proposed approach, as well as to assess important properties of the generated counterexamples. Regarding the effectiveness, we formulated the following question:

-RQ1. Can the approach generate counterexamples in a reasonable amount of time?

Then we seek to answer questions about the properties of the generated counterexamples, such as:

-RQ2. Does the number of counterexamples increase in a more complex domain? -RQ3. With respect to the metamodel or the OCL rules, what errors are the most common in the counterexamples? -RQ4. Is it possible to prevent the generation of counterexamples by the designer?

RQ1. (Applicability and Effectiveness)

Answering this question will allow us to know if the approach can actually generate counterexamples and how long it takes to generate a range of counterexamples. Objects of Study. To answer RQ1, we need to apply the proposed approach to specific scenarios and verify if it effectively produces counterexamples. As a first scenario, we use the FSM modeling language that was presented in previous sections. As second and more complex scenario, we use the Ecore modeling language. We provide the corresponding metamodel and validation rules as input for both scenarios. As previously mentioned, the FSM metamodel has 3 classes and 4 rules, while the Ecore metamodel has 20 metaclasses, 33 datatypes and 91 validation rules. We set up the parameters equally for both scenarios: the stopping criteria is set to the number of 100 counterexamples, the MAX DEPTH is set to 5, the MAX CHILDREN is set to 10 and the LINK PERCENT is set to 30%.

Experimental Setup. Once the parameters and the input are ready, we start the automatic generation of the counterexamples. The generation was performed in a machine with a 2nd Generation Intel Core I7 processor -Extreme Edition and 16GB of 1333MHz RAM memory, running under a linux 64bit with a 3.8.0 kernel, Scala 2.9.3 and an oracle Java Runtime Environment 7.

Experimental Results. The times are shown in Figure 6, ranging from 0 to 12625 seconds. For both FSM and Ecore, we could successfully find and generate counterexamples in a reasonable time. The time for generating 10 counterexamples for the Ecore-based MSPL was approximately 15 minutes, which is acceptable, considering the complexity of the Ecore metamodel. Thus, as the target number of counterexample increases, we can confirm a linear growth of the time. The linear trendlines are a good fit to the obtained time values, with R 2 values close to 1. Each time value is an average of 10 executions, this was done to minimize the random effect. Fig. 6 Counterexamples for FSM and Ecore.

RQ2. (Counterexamples vs Domain Complexity)

This research question aims at analysing the consequences of applying the approach in a more complex domain. Answering this question helps whether and to which extent it is more likely to design counterexamples (i.e., unsafe MSPLs) when the domain becomes more complex or not.

Objects of Study. To address RQ2, we compared the ratio between the number of invalid DM s and valid DM s. We made this comparison with three different modeling languages: FSM, Ecore (with the Eclipse Modeling Framework implementation) and UML (with the Eclipse UML2 project implementation. We classified these modeling languages in the following increasing sequence of complexity: FSM < Ecore < UML. Indeed, the FSM metamodel contains only 3 metaclasses 1 datatype and 4 validation rules. The Ecore metamodel contains 20 metaclasses, 33 datatypes and 91 validation rules. Finally, the UML contains 247 metaclasses, 17 datatypes and 684 validation rules.

Experimental Setup. For each modeling language, we applied our approach to obtain 100 counter examples, using the same parameters of the first experiment, and we collect the number of correct DM s we obtain. The evaluation was performed on the same computer of the previous experiment. For generating valid UML model, we do not create UML models from scratch, but we mutate existing UML models. We chose the footnote referred set of UML models to create the BM5 .

Experimental Results. The experiment resulted in the generation of 469 correct DM s for 100 counterexamples for FSM, 292 correct DM s for 100 counterexamples for Ecore and 52 correct DM s for 100 counter examples for UML 6 . We can therefore verify the ratio of incorrect per correct derived models. In the case of FSM, the ratio is 1 incorrect DM to 5 correct DMs, while in the case of Ecore, this ratio is 1 to 3, and for UML the ratio is 1 to 0,5. These results provide evidence that, as the domain modeling language becomes more complex, the chance to get a correct DM becomes lower. In a sense, it confirms the relevance of our procedure for generating counterexamples. More importantly, the practical consequence is that the designer is likely to produce much more unsafe MSPLs when the targeted modeling language is complex.

RQ3. (Nature of the errors)

The purpose here is to evaluate whether the errors are a violation to the structural properties of the metamodel or to the validation rules (i.e., OCL rules). Answering this question can help to understand which part of the modeling language is more likely to reveal more errors. Hence, we conducted the following experiment to investigate the research question.

Objects of Study. To identify the nature of the errors in the counterexamples, we used the generation of the 100 counterexamples for the three modeling languages that were previously used to answer RQ2. Our object of study is the quantity of counterexamples with errors violating the metamodel or the OCL rules.

Experimental Setup. For each modeling language, we applied our approach to obtain 100 counterexamples under the same parameters, and then we identify in which part of the modeling language definition is the error of the DM. The evaluation was performed using the same computer of the previous experiment.

Experimental Results. For the FSM language, among the 100 counterexamples, we generate 10 models that do not conform to the metamodel and 90 models that violate one of the validation rules. For the Ecore modeling language, among the 100 counter examples, we generate 64 models that do not conform to the metamodel and we generate 36 models that violate one of the validation rules. For the UML modeling language, among the 100 counter examples, we generate 22 models that do not conform to the metamodel and we generate 78 models that violate one of the validation rules.

We now correlate these numbers with the properties of the modeling language. FSM contains only three structural rules (i.e., a state-machine must contain at least one state, one initial state and at least one final state). Most of the errors are the validation rules that are violated. Ecore contains much more structural rules (mainly lower case constraints for cardinality). Therefore lots of errors come from structural inconsistencies. Finally UML contains so many validation rules that it is unfeasible to create a valid UML model randomly.

(That is why we used mutation from a set of valid UML models.) For this case we obtained much more DM s that violate validation rules expressed in OCL.

Yet, it is hard to draw definitive conclusions on whether structural or validation rules expressed in OCL participate the most in generating incorrect MSPLs. The results indicate that the kind of errors that are the most common in the counterexamples depend mainly on the domain modeling language (Ecore vs UML). It is well known, for instance, that some OCL rules can be refactored as structural constraints in the metamodel.

In a sense, it partly confirms -in the context of CVL -some of the results exposed in [START_REF] Cadavid | Searching the boundaries of a modeling space to test metamodels[END_REF] showing there exists different "styles" of expressing business or domainspecific rules within a metamodel.

RQ4. (Antipattern Detection)

The purpose of RQ4 is to evaluate the feasibility of expressing validation rules on the triplet V AM , BM , V RM to decrease the risk of creating invalid DM s from a valid CV L model and a correct BM , being C the set of possible valid configurations for a valid V AM . This question helps to know if it is possible for a domain designer to detect early "bad" CVL models (acting as "antipatterns") for a given domain.

Objects of Study. To evaluate this research question, we created two validation rules to detect antipattern for the FSM modeling language. Rule 1 prevents a substitution between a final state and an initial state, and vice versa. Rule 2 constrains the fact of having an object existence that targets the initial state of an FSM. These rules have been implemented in Scala and can be written in few lines using an OCL writing style, as shown in Listing 1.

Listing 1 Antipattern rules for FSM i f ( ( f . g e t F i n a l S t a t e ( ) . c o n t a i n s ( p ) && f . g e t I n i t i a l S t a t e ( ) . e q u a l s ( p1 ) ) | | ( f . g e t F i n a l S t a t e ( ) . c o n t a i n s ( p1 ) && f . g e t I n i t i a l S t a t e ( ) . e q u a l s ( p ) ) ) r e t u r n f a l s e ; 9 } 10 / * Rule 2 f o r e a c h ( p=> { i f ( f . g e t I n i t i a l S t a t e ( ) . e q u a l s ( p . g e t R e f e r e n c e ( ) ) ) r e t u r n f a l s e ; } ) } } ) 13 r e t u r n t r u e } Experimental Setup. For the FSM modeling language, we applied our approach to obtain 100 counterexamples and we compare the number of valid DM s we obtain either checking the antipatterns rules or not. The evaluation was performed on the same computer that the previous experiment, as well as with the same parameters.

: P o i n t i n g an O b j e c t E x i s t e n c e t o an i n i t i a l s t a t e i s f

Experimental Results. The experimental results show that we generate 1860 correct DM s for 100 counterexample for FSM when the antipattern rules for CVL are activated, against 469 correct DM s for 100 counter examples for FSM when the CVL validation rules for CVL are not activated. For this domain, writing only 2 rules on the triplet of V AM , V RM , BM allowed us to decrease 4 times the risk of generating an invalid DM . Therefore, it is feasible to detect identified antipatterns using our approach, writing validation rules that detect a priori and therefore earlier these errors.

Discussion

Besides the checking operations, the time results presented in Figure 6 are mainly dependent on the following factors:

1. The time to generate a correct set of models to compose the BM; 2. The time to generate a correct VAM; 3. The time to generate a VRM; These three factors are resulting from the generality and the full automation of our approach that does not require any input models. The approach gives the ability of finding possible design errors without having yet designed the MSPL. This allows users to explore the design space of an MSPL, given a modeling languagethis is the main scenario we initially target. However, it is possible to predefine some inputs. It could enhance the scalability of our generative process, since there is no need to spend time in generating these inputs. It may be the case when a designer of an MSPL already has an established BM. Another possible situation is when the VAM has been previously designed, as it is often one of the starting points of an MSPL. Therefore, we can claim that the conducted experiment address the worst case input for our approach. Consequently, our approach is sufficiently generic, as it does not assume that it is always the case of having a VAM or the BM as input. In addition, because it is fully automated, the approach does not demand a great effort to be used. Another benefit of predefining some inputs is that we could address other scenarios, like the debugging of an existing MSPL or the definition of various realization models given predefined BMs and VAMs.

By definition, an MSPL is a complex structure, composed by different connected models. This characteristic makes hard to design a correct MSPL, as errors can occur in any design phase. Given this great proneness to error, it is relevant to discuss the causes and to reason where is the lack of safety. For this purpose, we can analyse and give a rationale about two questions:

1. How a VAM and its analysis tools check and prevent configurations that result in incorrect DMs? 2. Is the fact of a derivation operator generate an incorrect DM fault of the own derivation operator (derivation engine) or is it fault of how it was invoked (realization model)?

Regarding the first question, it seems unfeasible to have a generic checker that, for any domain, could detect whether a configuration derives or not an incorrect model. It is rather needed to customize a derivation engine and/or a consistency checker (e.g., a simulator [START_REF] Zhang | Towards correct product derivation in model-driven product lines[END_REF]) that takes into account the syntactic and semantic rules of the domain. Likewise, faulty configurations, currently not supported by the MSPL, could be better identified and located. From this aspect, counterexamples can help to devise such specific simulators and oracles. For the second question, we can argue that there is a tradeoff between the expressiveness of the realization model and the safeness of the derivation. On the one hand, if more restrictions are applied to the derivation engine, we limit what could be generated. Also, a realization design can be wrong in one domain, but correct in another. On the other hand, if the derivation engine is not customized to address the specific meanings of a modeling language, then it is necessary to have checking mechanisms for the VRM that takes into account the syntax and semantics of the domain. More practical investigations are needed to determine when to customize the derivation engine or when to develop specific checking rules for the VRM. Counterexamples can be used for implementing both solutions.

Approach in an Industrial Case

In the last session, we evaluated our approach against well-known modelling languages; we could verify that it produces counterexamples in a reasonable time and we could also assess properties of the counterexamples. In this section, we present how the approach performs facing an industrial case. First, we describe the company's scenario; second, we report on how we could successfully apply the approach on it; and finally, we reproduce the applicability and effectiveness experiments done in the RQ1 of the evaluation.

Thales Scenario

Thales is a large company involved with different industry sectors (aerospace, space, defence and transportation areas, etc.); they produce software intensive systems, using model-based technologies, and they seek to evolve towards a product line approach. Thales already has a well-established and functional model-based method for developing their systems and software, the ARCA-DIA, however they seek to leverage this development from single software to families of software, maintaining their safety and quality standard [START_REF] Filho | Leveraging variability modeling for multi-dimensional modeldriven software product lines[END_REF].

The ARCADIA method is a viewpoint-based architectural description, defining 5 different abstraction levels of a system, following the ISO/IEC 42010, Systems and Software Engineering -Architecture Description [START_REF]ISO: International organization for standardization: Iso/iec fcd 42010: Systems and software engineering -architecture description[END_REF]. Thales' engineers use numerous domain specific modeling languages to develop integrated sets of systems according to ARCADIA. These languages are built within a set of dedicated representations to analyze specific problems. The language workbench provides a set of customizable and highly dynamic representations working seamlessly together on top of models. These representations can be combined and customized according to the concept of Viewpoints. Views, dedicated to a specific Viewpoint, can adapt both their display and behavior depending on the model state and on the current concern. The same information can also be simultaneously represented through diagram, table or tree editors.

These languages are defined as a set of 20 metamodels with about 400 metaclasses and about 200 validation rules; they model the ARCADIA method in an eclipse-based environment. Besides, this workbench is extensible and new languages can be defined to design specific viewpoints of a system. Therefore, leveraging product line engineering for each of these languages and domains is very expensive and error-prone; it has to be supported by automated tools.

Several stakeholders have to work during the design process on the tool chain:

-Product-line engineers who have to identify the commonalities and the variants and in charge of designing the VAM and the VRM. -Product engineers who have to create specific products, focusing on creating valid products regarding a set of requirements. -DSL designers who are in charge of creating or extending existing DSLs (base metamodel). They define where and how we can put variability within (at the M2 level) the architecture and the derivation semantics [START_REF] Filho | Customizing the common variability language semantics for your domain models[END_REF] The use of the proposed counter example framework aims at easing the correct cooperation between these stakeholders. It is used to provide a pragmatic approach to guide these stakeholders to design CVL model that provides only valid products.

Approach Application and Results

We applied the approach to the Thales' representative sample model of weather balloons; this base model has 2079 model elements and 563Kb and, despite of being one single subdomain, it can serve as a pilot application for other similar areas of the organization. The set of metamodels and validation rules of ARCADIA are considered as input to the approach. In contrast of what we did to evaluate the approach in a generic way (generating everything else besides the metamodel), we could simplify the generation because Thales provided a variability model and the aforementioned preliminary base model, narrowing down the problem space. Therefore, we fixed the VAM and the BM, randomizing only over the configurations of their variability model and generating the set of variation points to compose the realization model. However, it was necessary to adapt the implementation to meet some technical requirements from Thales for loading and saving the models.

Reproducing the same experimental setup of RQ1, we performed 10 rounds and measured the average time for generating 100 counterexamples. The results in seconds are shown in Figure 7. We could verify that in a situation where the VAM and the BM are provided, it is around 27 times faster to generate the same amount of counterexamples, and the curve still behaves linearly. About 30% of the models generated for this domain were wrong, meaning that, in average, if we randomly define realization relationships among the features and the model elements of this domain, almost one third can result on counterexamples. Another interesting result is the fact that only one OCL rule added to the VRM can remove 50% of the counterexamples (Forbidden an object existence on a specific kind of model element "EventSendCallAction") and 80% of the counterexamples can be removed in writing 8 basic OCL rules. With this example, we can show that the generation of coun-terexamples from a reference model can help to detect some anti-patterns that can be easily constrained and detected for a particular domain. The result is the improvement of the use of CVL in this industrial context an early detection of CVL model that capture invalid products.

Related Work

MSPLs. Different variability modeling approaches have been proposed. Annotative approaches derive concrete product models by activating or removing parts of the model. Variant annotations define these parts with the help of, for example, UML stereotypes [START_REF] Ziadi | Software product line engineering with the uml: Deriving products[END_REF] or presence conditions [START_REF] Classen | Model checking lots of systems: efficient verification of temporal properties in software product lines[END_REF][START_REF] Czarnecki | Verifying feature-based model templates against well-formedness ocl constraints[END_REF][START_REF] Czarnecki | Mapping features to models: A template approach based on superimposed variants[END_REF]. Compositional approaches associate model fragments with product features that are then composed for a particular configuration (i.e., combination of features). For instance, Perrouin et al. offer means to automatically compose modeling assets based on a selection of desired features [START_REF] Perrouin | Reconciling automation and flexibility in product derivation[END_REF]. Apel et al. propose to revisit superimposition technique and analyze its feasibility as a model composition technique [START_REF] Apel | Model superimposition in software product lines[END_REF]. Dhungana et al. provide support to semi-automatically merge model fragments into complete product line models [START_REF] Dhungana | Structuring the modeling space and supporting evolution in software product line engineering[END_REF]. Annotative and compositional approaches have both pros and cons. Voelter and Groher illustrated how negative (i.e., annotative) and positive (i.e., compositional) variability [START_REF] Voelter | Product line implementation using aspect-oriented and model-driven software develop-ment[END_REF] can be combined. Delta modeling [START_REF] Schaefer | Delta-oriented programming of software product lines[END_REF][START_REF] Clarke | Abstract delta modeling[END_REF] promotes a modular approach to develop MSPL. The deltas are defined in separate models and a core model is transformed to a new variant by applying a set of deltas.

The variability realization layer of CVL, as exposed in Section 2.2, provides the means to support annotative, compositional or transformational approaches [START_REF] Svendsen | Developing a software product line for train control: A case study of cvl[END_REF][START_REF] Haugen | Adding standardized variability to domain specific languages[END_REF]. Therefore we believe our work is applicable to a wide range of existing MSPL approaches.

Verification of SPLs. Some techniques specifically address the problem of verifying SPL or MSPL [START_REF] Apel | Strategies for product-line verification: Case studies and experiments[END_REF]. The objective is usually to guarantee the safe composition of an SPL, that is, all products of an SPL should be "safe" (syntactically or semantically). In [START_REF] Thaker | Safe composition of product lines[END_REF], Batory et al. proposed reasoning techniques to guarantee that all programs in an SPL are type safe: i.e., absent of references to undefined elements (such as classes, methods, and variables). At the modeling level, Czarnecki et al. presented an automated verification procedure for ensuring that no ill-structured template instance (i.e., a derived model) will be generated from a correct configuration [START_REF] Czarnecki | Verifying feature-based model templates against well-formedness ocl constraints[END_REF]. In [START_REF] Classen | Model checking lots of systems: efficient verification of temporal properties in software product lines[END_REF][START_REF] Classen | Symbolic model checking of software product lines[END_REF], the authors developed efficient model checking techniques to exhaustively verify a family of transition systems against temporal properties. Asirelli et al. proposed a framework for formally reasoning about modal transition systems with variability [START_REF] Asirelli | Formal description of variability in product families[END_REF]. In [START_REF] Alférez | Supporting consistency checking between features and software product line use scenarios[END_REF], Alfeérez et al. applied VCC4RE (for Variability Consistency Checker for Requirements) to verify the relationships between a feature model and a set of use scenarios. Zhang et al. [START_REF] Zhang | Towards correct product derivation in model-driven product lines[END_REF] developed a simulator for deriving product models as well as a consistency checker. Svendsen et al. present an approach for automatically generating a testing oracle for train stations expressed in CVL [START_REF] Svendsen | Specifying a testing oracle for train stations -going beyond with product line technology[END_REF].

Some of this work generate counterexamples when the property of safe composition is violated, typically for presenting to a developer an error in the specification of an SPL. In our approach, the goal is not to produce unsafe products of an existing MSPL, but to generate unsafe MSPLs. We do not assume variability models, models or configurations as inputs and the approach is fully automated. We thus target scenarios that go beyond debugging an existing MSPL. Our objective is rather to prevent the unsafe specification of realization models, i.e., generated counterexamples act here as "anti-patterns" that should prevent practitioners in specifying unsafe MSPLs. Another important difference is that verification techniques previously described assume that the derivation engine is correct. In our context, we cannot formulate the same hypothesis and have rather the crucial needs to implement new and robust derivation engines -each time a new modeling language is used in the MSPL. We provide quantitative evidence that the specificity of the modeling language should be taken into account. The generation of counterexamples aims at producing testing "oracles" and guide developers when building a derivation engine.

Techniques for combinatorial interaction testing of feature models (the V AM part of CVL) [START_REF] Johansen | An algorithm for generating t-wise covering arrays from large feature models[END_REF][START_REF] Perrouin | Pairwise testing for software product lines: comparison of two approaches[END_REF][START_REF] Gotlieb | Minimum pairwise coverage using constraint programming techniques[END_REF] have been proposed. As future work we plan to consider their use as part of our generation process.

Classification. In [START_REF] Thüm | A classification and survey of analysis strategies for software product lines[END_REF], Thüm et al. present a classification and survey of analysis strategies for SPLs. According to their classification, our work can be seen as an incremental product-based approach analysis, due to the fact that we produce and explore sample products. A limitation that follows every product-based approach is that it takes exponential effort to guarantee that the SPL model is safe. Given the design space complexity of a modeling language, it is unlikely to generate every possible counterexamples. We thus rely on randomization to synthesize a finite set of counterexamples.

Besides, we recognize as a limitation the fact that, in our experiments, we did not consider coverage criteria of counterexamples. It is hard to specify such coverage criteria for any domain-specific modeling language. For example, it is hard to synthesize a set of base models that covers any constructs offered by a language. Our approach has the merit of being agnostic of a domain and leaves to the user the choice of how exhaustive he/she wants to search the problem space. Considering this scenario, our target is not to directly provide mechanisms to verify the safety of an existing SPL (i.e., ensuring there is no unsafe product). As motivated by our industrial case study with Thales, we rather aim to help the engineers in charge of building mechanisms for MSPLs.

Verification and debugging of models. Numerous techniques have been proposed for debugging or verifying consistency of models or model transformations (e.g., [START_REF] Baudry | Barriers to systematic model transformation testing[END_REF][START_REF] Egyed | Automatically detecting and tracking inconsistencies in software design models[END_REF]). These works do not address specific issues of MSPL engineering, especially those related to the realization layer.

Conclusions and Future Work

Because of the combinatorial explosion of possible derived variants, the great variety and complexity of its models, correctly designing a Model-based Software Product Line (MSPL) has proved to be challenging. It is easy for a developer to specify an incorrect set of mappings between the features/decisions and the modeling assets, thus authorizing the derivation of unsafe product models in the MSPL. In this continuation paper, we have presented a systematic and fully automated approach to explore the design space of an MSPL. The main objective of the approach was to generate counterexamples of MSPLs, i.e., MSPLs that can produce invalid product models. This kind of MSPL can be used to test derivation engines or provide examples of invalid VRMs, which could serve as a basis to establish antipatterns for developers.

For this purpose, we have formalized the concepts of an MSPL, based on the Common Variability Language (CVL), as well as the concept of a counterexample. We explained in details each step of our generative approach and illustrated it with a running example. The tool LineGen, built on top of CVL and modeling technologies, supports the generative process. It enables practitioners to explore the whole design space of a given modeling language but also to focus on a specific MSPL with a pre-defined variability and base models. We performed experiments to assess the applicability and effectiveness of the tool-supported approach. The conducted experiments allowed us to evaluate the approach when applied to different modeling languages, at different scales of complexity. We could successfully generate counterexamples for each modeling language in a reasonable amount of time, which could be drastically reduced when the approach received additional input. In addition, we explored the natures of errors found in the counterexamples and our ability to detect antipatterns. We also reported on our experience when instantiating the approach and LineGen in an industrial context.

As future work, we seek to automate as much as possible the safe construction of an MSPL, using the counterexamples and examples as material to design an MSPL. In particular, we want to combine machinelearning techniques to automatically classify the counterexamples w.r.t. the kinds of error. Our hope is to provide an efficient approach to synthesize domain-specific rules that can prevent earlier the detected anti-patterns.

Fig. 1

 1 Fig. 1 FSM metamodel.

Fig. 4

 4 Fig. 4 Overview.

1

  def checkVRM ( f : FSM, vrm : VPackage ) : B o o l e a n = { 2 vrm . a s I n s t a n c e O f [ VPackage ] . g e t P a c k a g e E l e m e n t ( ) . f o r e a c h ( e=> { 3 / * Rule 1 : R e p l a c i n g a f i n a l s t a t e by an i n i t i a l one , and v i c e v e r s a , i s 4 f o r b i d d e n . * / 5 i f ( e . i s I n s t a n c e O f [ O b j e c t S u b s t i t u t i o n ] ) { 6 var p = e . a s I n s t a n c e O f [ O b j e c t S u b s t i t u t i o n ] . g e t P l a c e m e n t O b j e c t ( ) . g e t R e f e r e n c e ( ) 7 var p1 = e . a s I n s t a n c e O f [ O b j e c t S u b s t i t u t i o n ] . g e t R e p l a c e m e n t O b j e c t ( ) . g e t R e f e r e n c e ( ) 8

  o r b i d d e n . * / 11 e l s e i f ( e . i s I n s t a n c e O f [ O b j e c t E x i s t e n c e ] ) { 12 e . a s I n s t a n c e O f [ O b j e c t E x i s t e n c e ] . g e t O p t i o n a l O b j e c t ( ) .

Fig. 7

 7 Fig. 7 Counterexamples for ARCADIA sample model.

CVL uses the term materialization to refer to the derivation of a model. Also, a selected/unselected feature corresponds to a positively/negatively decided VSpec. We adopt the well-known vocabulary of SPLE for the sake of understandability.

The Meta-Object Facility (MOF) is an OMG standard for modeling technologies. For instance, the Eclipse Modeling Framework is more or less aligned to OMG's MOF.

realization layer in the current CVL specification

http://goo.gl/kC0sx

Source code for the experiment is available at http://goo.gl/PgkrL