J Girardot

N Ranc

M Schneider

P Lorong

L Illoul

L Berthe

V Favier

Procédé de perçage par laser : Comparaison entre des données expérimentales et une simulation 2D basée sur la méthode CNEM

Keywords: laser, perçage, simulation, CNEM laser, drilling, simulation, CNEM

Ces travaux présentent une alternative numérique au problème de simulation du procédé de perçage par laser. L'utilisation des éléments finis pour modéliser la propagation du trou au cours du temps montre des limites face à un problème de frontières mobiles induit par un changement de phase rapide et des forts gradients thermiques. L'utilisation d'un code CNEM a donc été testée avec comme objectif de résoudre ces difficultés numériques et d'utiliser le fort potentiel de cette méthode originale. Le principe physique du perçage laser sera rappelé et le modèle mathématique choisi pour le modéliser sera précisé. Enfin une comparaison entre des valeurs expérimentales et des sorties des simulations sera faite suivant la puissance laser.

Introduction

La simulation d'un procédé d'usinage tel que le perçage laser en régime de percussion en fonction des paramètres procédés est d'un grand intérêt pour prédire la morphologie des trous ainsi que les effets induits sur la matière percée. Elle permettrait aussi de mieux comprendre les phénomènes physiques locaux au cours du perçage tels que l'absorption du faisceau laser. Pour des densités de puissance de 10 à 50 MW/cm², l'interaction principale entre le laser focalisé et le substrat consiste à chauffer la surface du matériau jusqu'à la température entrainant la fusion puis la vaporisation d'une partie de la matière. La partie qui reste fondue est éjectée par la pression de vapeur, créant ainsi l'enlèvement de matière. Cette interaction se poursuit tout au long de la pulsation laser et on obtient à la fin un trou complet. Il résulte donc de ce perçage des échanges thermiques entre le faisceau, la partie liquide en mouvement et la partie solide qui doivent être pris en compte dans notre simulation. La figure 1 présente le processus physique au cours d'un perçage laser. Plusieurs travaux de simulation du perçage laser ont déjà été proposés en utilisant des codes de calcul basés sur la méthode des éléments finis et sur des méthodes de suivi d'interface de type ''front-capturing'' (level set) [START_REF] Ki | Modelling of high-density laser-material interaction using level set method[END_REF] & [START_REF] Ge | Three-dimensional transient numerical simulation of Gaussian laser beam drilling process[END_REF] ou de type ''front tracking'' (ALE) [START_REF] Revuz | Etude de l'endommagement d'un superalliage monocristallin à base de nickel induit par perçage laser[END_REF] & [START_REF] De Lange | Melt ejection during laser drilling[END_REF]. Ces choix numériques comportent des inconvénients qui limitent le travail de simulation, notamment à cause de la présence d'un maillage et de la représentation volumique de conditions aux limites physiquement surfaciques sur les interfaces mobiles (liquide/vapeur et solide/liquide).. Cet article présente une nouvelle approche de ce problème de simulation par l'utilisation de la méthode CNEM (Constraint Natural Element Method [START_REF] Chinesta | Natural Element Method for the simulation of Structures and Processes[END_REF]), une méthode à mi-chemin entre celle sans maillage et celle des éléments finis. La CNEM nous permet de façon simple et sans hypothèse numérique simplificatrice lourde de suivre l'évolution des interfaces liquide/solide et liquide/vapeur. Elle facilite l'implémentation des équations de la chaleur et de Navier-Stokes. La non-linéarité induite par la vaporisation sera aussi pris en compte dans notre modèle. L'objectif premier de ces travaux est de proposer une nouvelle approche numérique basée sur les hypothèses et les équations communément utilisées dans les simulations avec la méthode des éléments finis. On rappellera d'abord le modèle physique choisi ainsi que les couplages multiphysiques avant de présenter brièvement la méthode CNEM, utilisée pour discrétiser ces équations. Ce modèle sera ensuite utilisé pour modéliser le cas test du barreau et on présentera ensuite les premiers résultats du travail de simulation du perçage laser.

Modèle mathématique

Notre modèle se base sur l'implantation de l'équation de la chaleur dans le domaine solide et liquide et de l'équation de Navier-Stokes uniquement dans le liquide. On supposera par la suite les hypothèses suivantes :

-Le faisceau laser est circulaire et normal à la surface du matériau supposé comme homogène. Le problème peut donc être considéré axisymétrique où l'axe de symétrie est parallèle au faisceau laser et passe par son centre ; -Les grandeurs physiques sont prises constantes dans chaque domaine (liquide et solide) et indépendantes de la température ; -La matière liquide éjectée ainsi que celle vaporisée ne sont pas représentées géométriquement dans le calcul ; -Le flux de chaleur appliqué sur la surface est réparti spatialement suivant une fonction dépendante de la machine de perçage utilisée et temporellement suivant la montée en charge de la source laser. La valeur de l'intensité sur l'axe est prise égale aux mesures expérimentales réalisées préalablement au moyen d'une sphère intégrante. Les lois d'absorptivité ne sont donc pas implantées dans notre modèle ; -Le comportement mécanique du métal liquide est incompressible et newtonien ; -La partie solide est supposée rigide et seuls les échanges thermiques sont pris en compte ; -Les phénomènes liés aux tensions superficielles de la surface libre sont pris en compte.

Problème thermique

Les échanges dans les domaines solide et liquide sont décrits par la diffusion de l'énergie thermique avec l'équation de la chaleur en tenant compte des hypothèses de notre modèle :

(1) où , et sont respectivement la masse volumique, la capacité calorifique et la conductivité thermique du domaine i. La convection thermique due à l'éjection liquide est prise en compte dans le sens où la dérivée temporelle de la température est une dérivée lagrangienne. Cette description entrainera donc un maillage mobile. Plus de détails seront donnés dans le paragraphe 3. La fusion du matériau est prise en compte au moyen d'une capacité calorifique dépendante de la température ajoutée à une fonction gaussienne centrée sur le point de fusion dont l'intégrale est égale à la chaleur latente de fusion. Les conditions limites appliquées au domaine sont représentées sur la figure 2 :

Problème hydrodynamique

Les mouvements dans le fluide sont décrits avec l'équation de Navier-Stokes en tenant compte des hypothèses de notre modèle :

La loi de comportement du fluide est :

̿ ̿ ( ⃗ ̿̿̿̿ ⃗ ̿̿̿̿ ) (3)
où est la viscosité dynamique du métal liquide. Les conditions limites appliquées au domaine sont représentées sur la figure 2 :

Couplage aux conditions limites de la surface libre

Nos hypothèses pour notre modèle ne tiennent pas compte d'un éventuel couplage thermomécanique dans le domaine liquide à savoir par exemple une viscosité dépendante de la température. Ces hypothèses pourront être discutées par la suite et ne constituent pas la plus grande difficulté numérique du problème globale. En effet, le processus physique de perçage a comme moteur d'avancement la température de surface. Ainsi, le flux de chaleur réelle qui doit être appliqué correspond à l'intensité incidente et absorbée de notre faisceau laser diminué de la perte d'énergie par évaporation. Il est communément pris comme modèle, l'équation d'Hertz-Langmuir [START_REF] Samokhin | First-order phase transitions induced by laser radiation in absorbing condensed matter[END_REF] issue d'une conservation adiabatique de la densité atomique sur un petit élément de l'interface de vaporisation, couplée au modèle de Clapeyron donnant la pression de saturation en fonction de la température de surface. Le phénomène de rétrodiffusion due à la présence d'une couche de Knudsen [START_REF] Ytrehus | Kinetic theory approach to interphase processes[END_REF] est pris en compte par le coefficient , [START_REF] Knight | Theoretical modeling of rapid surface vaporization with back pressure[END_REF], [START_REF] Mas | Modélisation du procédé de découpe de métaux par laser[END_REF] et [START_REF] Samokhin | First-order phase transitions induced by laser radiation in absorbing condensed matter[END_REF]. Notre flux de chaleur devient donc :

(

La pression de recul appliquée sur la surface libre est donc elle aussi dépendante de la température de surface et sa valeur est régie par la relation de Clapeyron en tenant compte des pertes par rétrodiffusion et diminuée de la valeur de la pression ambiante suivant la discussion de K. Hirano & R. Fabbro [START_REF] Hirano | Experimental determination of temperature threshold for melt surface deformation during laser interaction on iron at atmosphere pressure[END_REF] :

( ) [ ( ( )) ] ( ) (5)
Les grandeurs physiques sont décrites dans le tableau suivant :

Intensité laser absorbé W.m -2 Coefficient de rétrodiffusion Masse atomique kg Chaleur latente de vaporisation J.kg -1 Seuil de vaporisation à pression ambiante K° m

Masse molaire kg.mol -1 Constante de Boltzmann m 2 .kg.s -2 .K -1 R Constante des gaz parfait J.mol -1 .K -1 Pression atmosphérique Pa Table I. Grandeurs physiques dans les couplages aux conditions limites 3 Implémentions numériques

Discrétisation CNEM

La méthode CNEM (Constraint Natural Element Method) est une technique alternative à la méthode des éléments finis [START_REF] Chinesta | Natural Element Method for the simulation of Structures and Processes[END_REF] & [START_REF] Yvonnet | Nouvelles approches sans maillage basées sur la méthode des éléments naturels pour la simulation numérique des procédés de mise en forme[END_REF]. Elle est une adaptation de la méthode NEM à des domaines non-convexes et présente deux atouts fondamentaux qui vont être utilisés dans notre modèle pour l'implémentation des équations précédentes :

(1) L'interpolation des champs est définie en tout point grâce aux informations fournies par les seuls noeuds environnants et n'est pas dépendante de la qualité du maillage. Ainsi, nos équations de conservations écrites dans une formulation lagrangienne et nécessitant un déplacement des noeuds n'entrainent pas de distorsion de la maille dans la zone liquide, zone où la matière se déplace. Pour plus de renseignement, on pourra se référer aux travaux de Gonzales & al. [START_REF] Gonzales | A natural element updated Lagrangian strategy for free-surface fluid dynamics[END_REF] qui utilisent cette formulation dite "lagrangienne actualisée" dans le cas de la mécanique des fluides ; (2) Des discontinuités mobiles sont insérées dans un nuage de noeuds fixes quelconques de manière triviale, par simple insertion ou suppression d'une nouvelle frontière intérieure. On peut retrouver dans [START_REF] Yvonnet | The constraint natural element method (CNEM) for treating thermal models involving moving interfaces[END_REF] des travaux sur la simulation de la propagation d'un front de fusion par cette méthode. Dans notre cas, la frontière mobile de fusion ne se déplace pas suivant la relation de Stefan [START_REF] Vuik | Some historical notes about the Stefan problem[END_REF] mais est repérée directement après le calcul thermique via l'isotherme de fusion.

Schéma d'intégration temporel

Les dérivées temporelles seront discrétisées par un schéma aux différences finis implicite. Pour un champ quelconque, on a donc entre l'instant et l'instant ;

( ) (6)
où est le pas de temps considéré.

Le couplage aux conditions limites correspondant au flux de chaleur perdu par vaporisation entraine une non-linéarité de l'équation de la chaleur dans la zone liquide. On rend le système linéaire en utilisant les températures du précédent pas de temps. Les pas de temps considérés dans ce problème étant faibles, de l'ordre de 20ns, cette méthode donne de bons résultats, notamment sur les températures de surface. Les propriétés physiques des phases liquides et solides sont celles du fer pur et la boucle de calcul est explicitée ci-après : 1) Calcul des champs thermiques en tenant compte de la fusion et de la vaporisation.

2)

Maillage de la zone liquide uniquement.

3)

Calcul des champs de vitesses dans la zone liquide.

4)

Actualisation des domaines via les vitesses d'interfaces et du champ de vitesse.

Résultats

Modèle test du "barreau"

Le modèle test du "barreau" permet de vérifier la bonne implémentation des équations tout en simplifiant la mise en oeuvre numérique et les étapes de remaillage. Le faisceau laser et le barreau ont le même diamètre et l'éjection liquide provoquée par l'interaction laser/matière n'est pas suivie (voir figure 3). Un premier résultat de perçage laser est illustré sur la figure 6. Les champs de température et de vitesse d'éjection du liquide dans le domaine global, au bout de 182 µs, pour un flux absorbé de 3 MW/cm² présentent de très forts gradients au voisinage du trou. Les valeurs de température de surface sont comprises entre 2000 K (en haut du trou) et 4500 K (au fond du trou). La température varie dans l'épaisseur de la zone fondue qui est de l'ordre de 20-30 µm. Les vitesses d'éjection du liquide sont de 35 m/s sur une épaisseur de quelques dizaines de micromètres. Tous ces résultats sont en bon accord avec l'expérience [START_REF] Schneider | Recoil pressure and surface temperature in laser drilling[END_REF], et sont donc très encourageants. On notera que les valeurs expérimentales de la température [START_REF] Schneider | Recoil pressure and surface temperature in laser drilling[END_REF] ne sont pas des mesures directes. En effet, la température est obtenue à partir de l'observation de l'hydrodynamique du gaz au moyen d'une caméra rapide (la fréquence d'acquisition est de 100 000 i/s). Comme la température est le moteur de cet écoulement, un modèle a été proposé pour obtenir les valeurs de température utilisées pour la comparaison avec les résultats numériques.

Conclusion

Une modélisation multiphysique du perçage laser a été proposée. La méthode CNEM a été choisie pour représenter le mouvement de la frontière liquide/solide et le mouvement du liquide au cours du perçage. Les premières comparaisons entre calculs et expériences montrent la pertinence de la modélisation physique et numérique proposée. Des études comparatives plus poussées sur la géométrie des trous (profondeur, largeur, épaisseur de zone resolidifiée) et les valeurs de vitesses d'éjection liquide sont actuellement en cours.

FIG. 1 -

 1 FIG. 1 -Processus physique du perçage laser. FIG. 2 -Conditions limites du modèle.

FIG. 5 - 4 . 2

 542 FIG.5-Comparaison sur la température de surface entre les résultats de simulation du modèle du barreau et des valeurs expérimentales obtenues lors de perçages laser réels[START_REF] Schneider | Recoil pressure and surface temperature in laser drilling[END_REF].

  La simulation est effectuée suivant les équations et le schéma numérique présentés plus haut pour une géométrie 2D axisymétrique. La répartition spatiale du faisceau est constante et les propriétés thermo-physiques du matériau sont celles du fer pur. Le modèle se révêle robuste et nous permet de balayer la plage d'intensité absorbée à savoir de 5 à 20 MW/cm². La figure4représente en fonction du temps la température de surface et la vitesse d'enfoncement sur l'axe de symétrie. On voit que la température de surface sature au bout d'une centaine de microseconde due à l'energie perdue par vaporisation. La température et la vitesse de perçage augmentent avec l'intensité absorbée ce qui est la tendance observée experimentalement. La figure 5 compare les valeurs experimentales[START_REF] Schneider | Recoil pressure and surface temperature in laser drilling[END_REF] de la température de surface au cours d'un perçage avec celles obtenues sur le modèle du barreau. La simulation prédit correctement l'ordre de grandeur de la température mais on peut noter que celle-ci est surestimée par rapport à la valeur expérimentale. FIG.3-Schéma de principe du barreau.Cela provient probablement de la différence de géométrie entre les deux problèmes : un corps solide froid entoure la zone percée dans le cas du perçage alors que ce corps froid est limité à un côté dans la simulation du barreau. La difference entre les deux peut être expliquée par le faible rayon du barreau.

	laser
	Barreau Faisceau	R Front de fusion Ejection liquide


Olivier Finot

Jean-Marie Mottu

Gerson Sunyé

Thomas Degueule

Using Meta-model Coverage to Qualify Test Oracles

Keywords: Test, Oracle Quality, Meta-model Coverage

The definition of oracle is a significant part of model transformation testing. The tester has to ensure their quality. Rather than using mutation analysis which is an implementation dependent and expensive task, we propose to qualify oracles by measuring their coverage of the transformation's specification.

Introduction

Model transformations are among the key elements of Model Driven Engineering. As for any other piece of software, developers must ensure that implementations are correct w.r.t. specifications. Software testing is a well-known technique for ensuring the correctness of an implementation. Testing a transformation consists of providing a set of test cases, where each test case is mainly composed of a test model and a test oracle. The role of the latter is to ensure that the output model produced by executing the test model over the transformation under test (TUT) is correct w.r.t. the transformation specification. Defining a test oracle is usually a manual task, performed by the tester, which relies on the specification.

In the context of model transformation testing, the qualification and generation of test models have already been studied [START_REF] Fleurey | Qualifying input test data for model transformations[END_REF]. However, beyond the scope of model transformation testing, few studies have been dedicated to the evaluation of test oracles. Mutation analysis [START_REF] Demillo | Hints on test data selection: Help for the practicing programmer[END_REF] is a technique used to qualify test cases, according to their ability to detect real faults in an implementation. Faulty versions of the program, or mutants, are created by voluntary injecting faults in the TUT. The mutants are then executed over the test data and the oracles check the produced models. The more mutants an oracle detects, the more efficient it is. However performing mutation analysis is an expensive task.

The goal of this paper is to propose a lighter approach to qualify oracles for model transformation testing. Instead of using mutation analysis, we rely on output meta-model coverage, i.e., we measure the elements of the output metamodel that are exercised by the oracle. We claim that between two sets of oracles, the one covering more elements of the output meta-model is able to detect more faults than the other. When measuring the coverage of the output meta-model, the tester obtains two results: a coverage rate and a list of uncovered elements. The coverage rate is an indicator of the oracle's quality; the more an oracle covers the output meta-model, the higher its quality is. The list of uncovered elements is an indicator on how to improve the oracle. To validate our approach, we developed a tool to qualify oracles, relying on meta-model coverage and we compared its results with the results of mutation analysis on two case studies. Experiments show that sets of oracles with an higher coverage rate kill more mutants, and therefore detect more errors.

This paper is organized as follows. Section 2 discusses the evaluation of test case quality, including outside the scope of model transformations. Section 3 details our approach to qualify oracles for model transformation testing based on their coverage of the output meta-model. Section 4 presents the experiments we ran on two case studies and discusses the results.

Context

Test case quality has been studied both in the general scope of software testing and in the topic of model transformation testing.

Test Case Representativeness

Test Data Representativeness Several studies have been conducted on the generation or selection of test data. Many criteria to evaluate test data rely on the coverage of the System Under Test (SUT) by the test data. Zhu et al. [START_REF] Zhu | Software unit test coverage and adequacy[END_REF] list several of these criteria. In the simplest criterion, the test data must cover each of the SUT's instructions. In another one, the tester checks that all the execution paths are covered during the execution of the SUT over the test suite.

Other approaches rely on the SUT's specification rather than it's implementation. With Model Based Testing (MBT), the tester generates test cases using a model specifying the SUT. Utting et al. [START_REF] Utting | A taxonomy of model-based testing approaches[END_REF] classified existing approaches and tools using MBT. In their study, the test case qualification relies only on the test data selection criterion. This selection can be based on the coverage of the model or it can also be random and stochastic. Also in the work of Dias Neto et al. [START_REF] Dias Neto | A survey on model-based testing approaches: a systematic review[END_REF], only the criteria of control or data flow coverage are presented on the topic of test case evaluation.

Test Oracle Evaluation

In a test case, the oracle is as important as the test data. However, while the generation and selection of test data has been the subject of many studies, there has been fewer about the oracle. Bertolino [START_REF] Bertolino | Software testing research: Achievements, challenges, dreams[END_REF] recognizes that the oracle quality is a topic that should be more studied. Staats et al. [START_REF] Staats | Programs, tests, and oracles: the foundations of testing revisited[END_REF]

o(t, p) ⇒ corr t (t, p, s)
If the test passes, then p is correct w.r.t. s for the test data t. Therefore, if there is an error in the program the test fails. An oracle that is both sound and complete is perfect:

∀t, o(t, p) ⇔ corr t (t, p, s)
They also propose to compare test oracles based on their power. They state that an oracle o 1 is more powerful than an other o 2 w.r.t. a test set T S (written o 1 ≥ T S o 2 ) for a program p and a specification s if:

∀t ∈ T S, o 1 (t, p) ⇒ o 2 (t, p)
If o 1 does not detect a fault for a given test case, then neither does o 2 . Mutation analysis can then be used to qualify test oracles [START_REF] Jézéquel | Reliable objects: a lightweight approach applied to Java[END_REF][START_REF] Staats | Automated oracle creation support, or: How I learned to stop worrying about fault propagation and love mutation testing[END_REF]. In this case it evaluates an oracle ability to detect faults; therefore it could be used to compare test oracles. The more faults an oracle detects, the more powerful it is. However, as we mentioned before, mutation analysis is too expensive to be used to compare oracles efficiently.

Test Case Quality in Model Transformation Testing

In this section we discuss published studies on the topic of test case quality for model transformation testing. They cover the generation and selection of representative test models or the evaluation of the oracle.

Test Models Generation Fleurey et al. [START_REF] Fleurey | Qualifying input test data for model transformations[END_REF] propose to qualify test models based on their coverage of the input meta-model. They adapted criteria defined by Andrews et al. [START_REF] Andrews | Test adequacy criteria for UML design models[END_REF] for UML Class diagram coverage:

-Class Coverage: each meta-class is instantiated at least once.

-Association End Multiplicities: for each association extremity, each representative multiplicity must be covered. -Class Attribute: for each attribute, each representative value interesting for the tester must be covered.

The last two criteria use the notion of representative value. The representative values are determined using partition analysis. An attribute or a multiplicity's value domain is partitioned into equivalence classes inside which the transformation's behavior is believed to be the same. One value is chosen by equivalence class. Sen et al. [START_REF] Sen | Using models of partial knowledge to test model transformations[END_REF] developed a tool based on these criteria to automatically generate test models.

Oracle Qualification Mottu et al. [START_REF] Mottu | Reusable mda components: A testingfor-trust approach[END_REF] use mutation analysis to evaluate model transformation test oracles. They create mutants for the TUT, then transform the input models with those mutants. In the following step, they compare the output models produced by the TUT with those produced by the mutants; if there is a difference, the mutant is killed. Among the alive mutants the tester must identify the ones that are equivalent to the TUT and remove them. Then, they evaluate the possibility of improving the mutation score by adding new test models. Once a sufficient mutation score is reached, they check the output models produced by the mutants with their oracles; the mutant is killed if the test fails. The higher is the mutation score, the better is the oracle.

However, despite its effectiveness, mutation analysis has two main drawbacks. The first one is that the application of mutation analysis depends on the TUT's transformation language. Mottu et al. defined generic mutation operators, which are language independent. However, the creation of mutants is manually done by the tester and the application of the operators depends of the transformation language. Furthermore, mutation analysis is an expensive task due to the costs of execution and a lack of automation.

Using Meta-model Coverage to Compare Test Oracles

Our goal is to provide an alternative to the expensive and language-dependent mutation analysis process, to qualify test oracles dedicated to model transformations. To qualify an oracle we measure its coverage of the TUT's specification. Our approach focuses on the models and is independent from the TUT. It can be applied to any model in the widely used EMF framework. We first present our approach, then detail the process of measuring the coverage of the specification by the oracles.

Qualifying Model Transformations' Test Oracles

For Staats et al. [START_REF] Staats | Programs, tests, and oracles: the foundations of testing revisited[END_REF] an oracle's power is its ability to detect faults. We use this power as an indicator of an oracle's quality. As with mutation analysis, an oracle of higher quality detects more faults. We qualify oracles by measuring their coverage of the TUT's specification. More precisely, we measure the coverage of the output meta-model by the set of oracles in the test suite.

When applying our approach to a transformation and a set of oracles (for instance expected output models for each of the test models), the tester will measure the coverage of the output meta-model by all of these oracles together. The result of this measure is composed of two elements: a coverage rate and a list of uncovered elements. The goal of the tester is to maximize the coverage in order to obtain an efficient oracles set. If the coverage rate is lower than 100%, the oracles may have room for improvement. To improve the oracle, she will try to cover one or more of the uncovered elements.

However, reaching a coverage rate of 100% is not always feasible. The output meta-model may contain elements that should not be instantiated in a correct output model w.r.t. the transformation's specification. Given the list of uncovered elements, the tester may decide that some of these elements should not be covered. Therefore, the tester does not measure the coverage based on the complete output meta-model. She starts by defining the effective output metamodel, containing only elements handled by the transformation, according to its specification.

Output Meta-Model Coverage

We measure the coverage of the output meta-model by a set of test oracles. Fleurey et al. [START_REF] Fleurey | Qualifying input test data for model transformations[END_REF] qualify test models based on their coverage of the input metamodel. We propose to adapt these criteria for the coverage of the output metamodel. We use the same criteria for the coverage of the meta-model (Class Coverage, Association Coverage, Class Attribute). However, while Fleurey et al. combine these criteria to build representative models, we do not.

For input models, it is important to combine elements' values as different combinations can produce several different results. However for output models it is not as relevant. Fleurey et al. proposed a way to handle inheritance links, only considering concrete meta-classes. For each of them, they check all their proper and inherited properties (attributes and references). We use the same process. When measuring the meta-model coverage of a given model, we mark as covered any EAttribute or EReference instantiated in the model. Then, each concrete EClass is marked as covered if all of its properties are.

Measuring the coverage of an output meta-model by a set of oracles is a two steps process (cf Figure 1):

1. The first one transforms the meta-model M M out to add coverage information. Each element to be covered is annotated. This annotated meta-model is the coverage model.

Experiments and Discussion

In this section, we validate our approach on two case studies. First we present the two transformations under test (already used in previous works as detailed in [START_REF] Finot | Partial test oracle in model transformation testing[END_REF]), then we detail our testing protocol and finally we discuss the results we obtain (experimental material is available2 ).

Case Studies

1. Flattening of a finite state machine fsm2ffsm is a refactoring, the flattening of a hierarchical state machine. The input model of the transformation is a hierarchical state machine, the output model is another state machine expressing the same behavior without any composite state. This transformation has been implemented in Kermeta3 . 2. UML to CSP uml2csp transforms a simplified UML activity diagram into its corresponding modeled CSP program. We implemented it in ATL4 .

Evaluation Protocol

We use mutation analysis to evaluate the quality of the oracles in the same way as Mottu et al. in [START_REF] Mottu | Reusable mda components: A testingfor-trust approach[END_REF]. First, we create a set of mutants. Second, we create a set of test models which reaches a 100% mutation score, meaning that those test models are able to highlight the injected faults. Third, we create a set of oracles and we measure how many injected faults they detect (knowing that test models highlight all of them).

Mutation Analysis

Using the mutation operators dedicated to model transformation testing in [START_REF] Mottu | Reusable mda components: A testingfor-trust approach[END_REF], we create mutants by injecting one single fault per version. Once the equivalent mutants are removed, we obtain 83 mutants for fsm2ffsm and 137 for uml2csp.

Test Models

We combine input meta-model coverage and testing knowledge to create test models reaching 100% mutation score. Using the approach proposed by Sen et al. [START_REF] Sen | Automatic model generation strategies for model transformation testing[END_REF], we define model fragments. The intent of these fragments is to cover the input meta-model according to a strategy. Additionally, we improve the fragments using our own knowledge of the transformation [START_REF] Sen | Using models of partial knowledge to test model transformations[END_REF], increasing the coverage of the specification. For fsm2ffsm, we obtain 11 fragments using the IFCombΣ strategy. Each model fragment is completed producing two test models of different sizes. We finally obtain 22 test models.

For uml2csp, the IFCombΠ strategy is used to obtain 8 model fragments. The low number of fragments is due to the fact that there are few references and many inheritances in the output meta-model used for this transformation, and almost none of the inherited classes or their superclasses contain attributes or references. Thus, in order to cover these classes, for each reference towards the superclass, we define one model for each of its non abstract inherited classes. We define all the possible combinations, and after eliminating the incorrect cases, we create 35 test models.

Test Oracles

For each case study we create several sets of oracles, using two of the existing oracle functions [START_REF] Finot | Partial test oracle in model transformation testing[END_REF]: comparison with an expected output model and contracts.

For the first oracle function we create a complete expected model for each test case. We also create several sets of partial ones as introduced in previous work [START_REF] Finot | Partial test oracle in model transformation testing[END_REF]. All of our oracle sets for each case study rely on the same expected models, but for the partial ones we use a filtered comparison to control only part of the output model. We systematically create partial oracles by rejecting successively each meta-class, each attribute, and each reference. In each partial oracle, we remove only one element.

The other oracle function uses contracts expressing properties on the output models, or between the test models and their corresponding outputs, as used by Cariou et al [START_REF] Cariou | Ocl contracts for the verification of model transformations[END_REF]. We write small contracts. Each contract corresponds to a property we want to check; for instance one contract checks that there is no composite states in the result of the transformation that flattens a state machine. By incrementally combining our small contracts we build new ones. We start by choosing the contract with the lower coverage of the output meta-model, then we gradually add each of the others. Each time we add the contract which will minimize the coverage rate's improvement.

Afterwards, for each oracle set, we measure its coverage of the effective output meta-model.

Results and Discussions

To validate our approach we must answer the following questions :

1. Can we measure the coverage of the output meta-model by a test oracle? 2. Is the coverage of the output meta-model related to the mutation score? 3. Does a 100% coverage rate indicates that the set of oracles is sound for the transformation? 4. Is the coverage of the output meta-model a good indicator of the quality of a set of oracles?

We developed and used tools to measure the coverage of a meta-model by a test oracle (or a set of test oracles) thus answering the first question.

In order to answer the second question, let us take a look at the graphs from Figure 2 and Figure 3. They show the relationship between meta-model coverage rate and mutation score, for each case study and for both types of oracles. On the left hand side graphs, each mark corresponds to a set of oracles (or several sets of oracles having the same coverage rate and the same mutation score). We also add a trend curve to see the impact of the coverage rate on the mutation score. The right hand side graphs display two series of values. Each triangle mark corresponds to one individual small contract, while each square mark represents one step of the definition of the incremental contracts. We add a trend curve for each of these two series, the dotted one corresponds to individual oracles and the full one corresponds to the incremental ones. In the graph from Figure 2(a), we can see that by combining input metamodel coverage strategies with our knowledge of the transformation, we kill all of the mutants. We have 9 sets of oracles, however 4 of them having the same coverage rate kill the same number of mutants. The set of oracles without any filtering kill all of the mutants. In this case we can see that when the coverage rate increases then the mutation score does not decrease, at least, it stays unchanged. Moreover the trend curve is strictly growing, meaning that the mutation score generally grows alongside the coverage rate. These two measures are related.

In the graph from Figure 2(b), we can see that with our incremental contracts we kill 93% of the mutants. Both series contain 8 contracts and in both cases 2 pairs of contracts have the same coverage rate and mutation score. We can see from both trend curves that improving the coverage rate improves the mutation score.

Answering the third question we can see that while we cover the whole effective output meta-model, we do not kill all the mutants. Therefore a coverage rate of 100% does not imply that our oracles are sound.

For our other case study, in the graph from Figure 3(a) we can see the measures concerning the oracles relying on comparison with a partial expected output model. We have 16 sets of oracles, however 5 of them have the same coverage rate along with the same mutation score. The set of oracles without any filtering once again kills all the mutants. The other sets of oracles have a lower coverage of the output meta-model and kill less mutants (between 86.86% and 95.91%). Answering the second question, similarly to the first case study, we see that the mutation score grows alongside the coverage rate.

As for the contracts, the graph from Figure 3(b) once again shows that we managed to entirely cover the effective output meta-model. Our final incremental oracle covering 100% of the output meta-model does not kill all the mutants, two of them are still alive. This result once again answers the third question. While the trend curve for the incremental contracts shows a noticeable improvement in the mutation score with the growth of the coverage rate, it is not so obvious for the individual partial contracts. Still in this case the trend curve indicates that improving the mutation score does not diminish the average mutation score. For both case studies, we are able to measure the coverage of the effective output meta-model by an oracle or a set of oracles. From the obtained results, we notice that a better coverage rate comes with a better mutation score. However, we can also notice that entirely covering the effective output meta-model does not imply that the oracle is sound, since some faults may not be detected. Still to answer our fourth question, while our approach is not as precise as mutation analysis, it has some advantages: it is lighter and it is not dependent from the implementation of the transformation. Therefore, we can conclude that the coverage rate of the effective output meta-model by an oracle is a good indicator of the quality of this oracle.

Conclusion

In this paper we presented an approach to qualify oracles for model transformation testing, based on meta-model coverage. The more elements an oracle covers, the higher is its quality. We validated our approach by comparing the results of two different experiments with those of mutation analysis for the same experiments. The experiments showed that the oracles covering more meta-model elements killed more mutants. An important benefit of meta-model coverage over mutation analysis to qualify test oracles is that coverage is implementation independent and is less expensive perform.

Fig. 1 .

 1 Fig. 1. Measuring Output Meta-model Coverage of Test Oracles

Fig. 2 .

 2 Fig. 2. Relations Between Coverage and Mutation Score with fsm2ffsm

Fig. 3 .

 3 Fig. 3. Relations Between Coverage and Mutation Score with UML2CSP

  also insist on the importance of the test oracle. They propose to describe a testing system as a collection (P, S, T, O, corr, corr t ) where:If p is correct w.r.t. s for test data t, then the test passes. A complete oracle does not produce false positives. They also consider and define the soundness of an oracle; an oracle is sound if:

	-T is a set of test data
	-O is a set of oracles working as predicates
	-corr ⊆ P × S
	-corr t ⊆ T × P × S
	O is a set of oracles (predicates) o such that o : T × P → Boolean. For a
	given t ∈ T and p ∈ P , o(t, p) = true denotes that the test passes. corr(p, o) =
	true denotes that p is correct w.r.t. s. corr t (t, p, s) = true denotes that the
	specification s holds while executing p with the test data t. Hoffman [8] considers
	completeness as one characteristic of test oracles. Completeness can go from
	no prediction of the expected result to a complete duplication that is another
	implementation of the SUT. Staats et al. [7] also mention the oracle completeness
	but they define it differently; an oracle is complete w.r.t. p and s if for each test
	data t:
	corr t (t, p, s) ⇒ o(t, p) 1
	-S is a set of specifications
	-P is a set of programs

For a predicate Q(x), we simply write Q(x) instead of Q(x) = true

https://sites.google.com/site/qualifyingtestoraclesmt/

http://www.kermeta.org

http://www.eclipse.org/atl


PhD Student Olivier Finot
email: olivier.finot@univ-nantes.fr

Jean-Marie Mottu

Gerson Sunyé

Christian Attiogbe

Filtered Comparison for Oracle in Model Transformation Testing

Focusing on one part of a produced output helps in improving model transformation testing

Introduction

Models are becoming a key element in software engineering. With Model Driven Engineering, they are the heart of the development process. They are used to describe a system at some state of its development, and they evolve with transformations. Model transformations can be chained, up to the production of executable code. However, any error in a transformation of such a chain will be spread to the resulting code. But while testing the produced code might detect the bug, finding its origin will be difficult. Therefore, it would be useful to check the chain's development by verifying the transformations. Several contributions have already been published on the verification of model transformation. Our goal is to pursue research on this field and improve existing methods to test model transformations. More specifically, we focus on the problem of the definition of a test oracle. In Section 2, we present our proposal for the definition of a partial oracle for the test of model transformations1 . Then, in Section 3 we discuss current and future work. Finally we conclude in Section 4.

Partial Oracle for Model Transformation Testing

Model transformations are automated to be highly reused. If we want to reuse a piece of software, we have to trust it. We can not have any errors in something we will reuse numerous times. We use test to ensure the correctness of a model transformation w.r.t. its specification. The tester provides a valid input model, then she executes the transformation under test over this input model. Finally the test oracle controls the output model produced by the SUT's execution. Building test oracles, we face the transformation's output complexity. In some cases, the transformation's specification might allow several valid variants of a given output; the transformation here has polymorphic outputs. For example if we consider a program running an operation on a Finite State Machine (FSM) in order to flatten it, the input of this program is transformed into another FSM expressing the same behavior without using any composite state. We can transform the input model presented in Figure 1 into the output model depicted in Figure 2(a). With such state machines, the number of final states is not limited to only one. Thus, the FSM presented in Figure 2(b) is also a correct output for the flattening of the FSM presented in Figure 1. While the implementation of such a transformation is deterministic, the specification allows several variants. The developer implements only one of these variants. However, when building an oracle, the tester must not consider the transformation's implementation, since she might be influenced by the errors made by the developer. Thus, she has to design an oracle that checks that the produced output of the Transformation Under Test is one of the possible variants. The classical approach to build an oracle for model transformation testing, is to compare the produced output model with a reference one. The reference output model is the output model expected for the correct transformation of the input. Applying this approach to model transformations with polymorphic outputs would mean having the tester define one reference output model for each of the variants and then compare the produced output model to all of them. If the produced output model is identical to one of the reference output models, the test passes; otherwise it fails. Applying this classical approach to polymorphic outputs is time-and effort-consuming for the tester. She has to manually define all the reference outputs, and run the comparisons. In [START_REF] Finot | Comparaison de modèles filtrée pour le test de transformations de modèles[END_REF], we propose a more efficient approach to build an oracle to test model transformations with polymorphic outputs. We notice that in the polymorphic outputs of a model transformation some elements do not change from one variant to the other. In the example of the Figure 2, this is the case for the initial and simple states as well as for the transitions between them, they belong to the common part of the variants; the other elements form the variable part. Our idea is to build an oracle focussing on this common part. Since by definition, the common part is identical in all the variants, this oracle will only need one reference output model as oracle data. The produced output model is compared to the reference one. The result of this comparison is then filtered in order to eliminate any difference concerning the variable part of the output model. If the filtered result of the comparison is empty, the common parts of both the produced and reference output model are identical, the test passes. Otherwise, the produced output model contains errors, an then the test fails. Figure 3 summarizes our approach. We provide as oracle data the reference output model as well as patterns. In order to eliminate the differences about the variable part, we need to know which elements belong to this variable part. We define these elements according to their types (e.g. their meta-classes). The patterns we provide are meta-model excerpts defining the variable part of the transformation's output, they are defined only once for all the test cases of a given transformation.

Fig. 3. Our Approach to Build a Partial Oracle

In our approach, we focus on controlling one part the produced output, producing a partial verdict. Nevertheless, a partial verdict is already a good piece of information. We are able to detect errors in the produced output model using only one reference output model, whereas the classical approach requires to define as many reference output models as correct variants of the output model.

Ongoing Work

To ensure the complete correctness of a model transformation with polymorphic outputs, the next step after the proposition of our approach is to be able to control the variable part of the produced output. Whereas for the common part we use a reference output model, the idea here is to work directly on the produced output model. The tester starts by checking that the expected elements for this variable part are present in the model (in Figure 2, transitions from the states B and C towards final states). Then she ensures that there is nothing else in the variable part (no other instance of the meta-model fragments used for the filter). We discussed in Section 3 an approach aimed at partially controlling the polymorphic outputs of a model transformation. However, we believe that the approach is not limited to these particular model transformations. Having a partial verdict could be interesting for other programs as well. The larger the handled models become, the harder it is for the tester to define a reference output model. It is time and effort consuming for the tester to manually define a large and often complicated model. With our approach, she could use a partial reference output model to obtain a partial verdict about a part of the produced output model. Our approach could be useful even outside the scope of model transformation testing. Models as well as graphs or databases can be seen as a particular kind of complex outputs. Complex outputs are not just big sets with many properties, these properties are organised and structured. Polymorphic outputs can also be seen as complex data, the complexity coming in this case from the numerous variants of a given output. Our approach allows the tester to efficiently control part of a program's complex output and obtain a partial verdict. She only needs a partial reference output and a definition of the part she would not be interested in. The partial reference output could either be manually defined, or obtained through another version of the system under test in the case of regression testing.

Conclusion

The topic of this PhD is about test in a model driven engineering environment. Our first contribution is the proposition of an efficient approach to build a partial oracle controlling the common part of polymorphic outputs. We are currently working on controlling the remaining, variable part. Also while the proposed approach was defined to control the polymorphic outputs of a model transformation, it can be applied in other cases either inside our outside the scope of model driven engineering.

Fig. 1 .Fig. 2 .

 12 Fig. 1. Example M in , of Hierarchical State Machine

a paper on the subject is currently under review for ICST13