Un îlot formel pour les transformations de modèles qualifiables

HAL Id: tel-01081055

https://tel.archives-ouvertes.fr/tel-01081055

Submitted on 6 Nov 2014

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

qualifiables

Jean-Christophe Bach

To cite this version:

Jean-Christophe Bach. Un îlot formel pour les transformations de modèles qualifiables. Langage de

programmation [cs.PL]. Université de Lorraine, 2014. Français. �tel-01081055�

Institut National de Recherche en Informatique et Automatique Universit´ e de Lorraine Ecole doctorale IAEM (Informatique, Automatique, ´ ´ Electronique et Math´ ematiques)

Un ˆılot formel pour les transformations de mod` eles qualifiables

TH` ESE

pr´esent´ee et soutenue publiquement le 12 septembre 2014 pour l’obtention du

Doctorat de l’Universit´ e de Lorraine

(sp´ ecialit´ e informatique)

par

Jean-Christophe Bach

Composition du jury

Rapporteurs : Antoine Beugnard Professeur, Telecom Bretagne

Laurence Duchien Professeur, Universit´e de Lille 1, LIFL

Examinateurs : Mark van den Brand Professeur, Eindhoven University of Technology

Benoˆıt Combemale Maˆıtre de conf´erences, Universit´e de Rennes 1, IRISA, Inria Marc Pantel Maˆıtre de conf´erences, Universit´e de Toulouse, INPT, IRIT Encadrant de th`ese : Pierre-Etienne Moreau Professeur, Universit´e de Lorraine, ´ Ecole des Mines de Nancy

Laboratoire Lorrain de Recherche en Informatique et ses Applications — UMR 7503

iii

Remerciements

Je tiens ` a remercier mes encadrants de th` ese, Marc Pantel et Pierre-Etienne Moreau, qui ont accept´ e de m’encadrer en tant que doctorant, malgr´ e la distance pour l’un et les responsabilit´ es administratives pour l’autre.

Je voudrais aussi remercier les personnes qui m’ont fait l’honneur d’accepter de faire partie de mon jury de soutenance : Laurence Duchien et Antoine Beugnard qui ont accept´ e d’ˆ etre rapporteurs de ce travail de th` ese, Benoˆıt Combemale et Mark van den Brand d’en ˆ etre examinateurs.

Merci aux membres et ex-membres de l’´ equipe Pareo, ` a Lo¨ıc ainsi qu’au groupe du projet quarteFt, sans qui ce travail n’aurait pas ´ et´ e possible.

Et bien sˆ ur, un merci ` a toutes celles et ceux qui m’ont accompagn´ es durant cette th` ese.

En particulier Kar¨ en qui a ´ et´ e pr´ esente tout au long de ma th` ese malgr´ e sa vie bien charg´ ee, son mari, son fils et ses concours.

Merci ` a Pierre, Gilles, Martin et ses trolls (et pas forc´ ement dans cet ordre) pour les discus- sions scientifiques, techniques et politiques, ainsi que les rafraˆıchissantes pauses de « bidouille

& m´ ediation scientifique ».

Evidemment, je n’oublie pas mes impitoyables relectrices-correctrices — Chlo´ ´ e, Kar¨ en et Marion — et leur rigueur qui m’ont aid´ e ` a am´ eliorer la qualit´ e grammaticale, orthographique et typographique de mon tapuscrit.

Une mention sp´ eciale ` a mes soutiens distants : ` a Cl´ audia qui m’a soutenu par la mise en place d’une fili` ere br´ esilienne d’importation de Tang et de caf´ e ; ` a Val´ erie depuis Rennes qui r´ edigeait en parall` ele.

Et parce que dans la th` ese il n’y a pas que la th` ese, merci ` a toutes les personnes avec qui j’ai discut´ e et pass´ e du temps : Cl´ ement, Sergue¨ı et le triumvirat C´ eline-Fabrice-Guillaume pour les discussions politico-syndicales ; Paul, Pini, Jonathan, Christophe et tous les connect´ es du canal de discussion relay´ ee par Internet #linux pour leurs trolls et d´ ebats libro-informatiques ; Ju, S´ eb, les membres de LDN et autres d´ efenseurs du logiciel libre et d’un Internet neutre ; Nico lors de mes retours pour mise au vert ` a Lille.

Une pens´ ee pour les adorables petits bouts — L´ eonard, Margaux et Thomas — qui m’ont aid´ e ` a me changer les id´ ees.

Enfin, merci ` a mes parents sans qui je n’aurais pu commencer ni finir cette ´ epreuve.

Table des mati` eres

Table des figures ix

Introduction 1

I Etat de l’art ´ 5

1 Un langage bas´ e sur la r´ e´ ecriture : Tom 7

1.1 R´ e´ ecriture . . . . 7

1.1.1 Signature alg´ ebrique et termes . . . . 7

1.1.2 Filtrage . . . . 8

1.1.3 R´ e´ ecriture . . . 10

1.1.4 Strat´ egies de r´ e´ ecriture . . . 11

1.2 Le langage Tom . . . 13

1.2.1 Signature alg´ ebrique . . . 14

1.2.2 Construction backquote « ‘ » . . . 14

1.2.3 Filtrage de motif . . . 15

1.2.4 Notations implicite et explicite . . . 18

1.2.5 Strat´ egies : maˆıtriser l’application des r` egles de r´ e´ ecriture . . . 19

1.3 Ancrages formels . . . 20

1.4 Domaines d’applications . . . 24

1.5 Apport de la th` ese au projet Tom . . . 24

2 Transformations de mod` eles 27 2.1 Mod´ elisation . . . 27

2.2 Transformations de mod` eles . . . 31

2.2.1 Taxonomie des transformations . . . 32

2.2.2 Approches de d´ eveloppement des transformations de mod` eles . . . 33

2.2.3 Outils existants . . . 34

2.3 Limitations actuelles et points d’am´ elioration . . . 37

3 V´ erification du logiciel 39 3.1 Approches pour la v´ erification du logiciel . . . 39

3.1.1 Relecture . . . 39

v

3.1.2 Tests . . . 40

3.1.3 Simulation . . . 40

3.1.4 Preuve . . . 41

3.1.5 Model-checking . . . 41

3.2 Certification et qualification . . . 42

3.3 Tra¸cabilit´ e . . . 43

II Contributions 45 4 Transformations de mod` eles par r´ e´ ecriture 47 4.1 Choix et int´ erˆ et d’une approche hybride . . . 47

4.2 Repr´ esentation de mod` eles par une signature alg´ ebrique . . . 48

4.3 Transformation de mod` eles par r´ e´ ecriture . . . 49

4.3.1 Approche compositionnelle . . . 50

4.3.2 R´ esolution - r´ econciliation . . . 53

4.4 Validation par un cas d’´ etude . . . 54

4.5 Synth` ese . . . 56

5 Sp´ ecification et tra¸ cabilit´ e des transformations 57 5.1 Sp´ ecification . . . 57

5.2 Tra¸ cabilit´ e . . . 58

5.2.1 Tra¸ cabilit´ e interne . . . 59

5.2.2 Tra¸ cabilit´ e de sp´ ecification . . . 59

5.3 Synth` ese . . . 61

6 Outils pour exprimer une transformation de mod` eles en Tom 63 6.1 Exemple d’utilisation des outils . . . 63

6.1.1 Exemple support . . . 63

6.1.2 Mode op´ eratoire . . . 65

6.2 Extension du langage . . . 67

6.2.1 Expression d’une transformation . . . 70

6.2.2 R´ esolution . . . 70

6.2.3 Tra¸ cabilit´ e . . . 71

6.3 Travaux d’impl´ ementation . . . 72

6.3.1 Architecture du projet Tom et chaˆıne de compilation . . . 72

6.3.2 G´ en´ erateur d’ancrages alg´ ebriques . . . 75

6.3.3 Mise en œuvre de l’extension . . . 78

6.4 Synth` ese . . . 82

7 Etudes de cas : illustration et utilisation du langage ´ 83 7.1 Cas SimplePDLToPetriNet . . . 83

7.1.1 M´ etamod` eles . . . 83

vii

7.1.2 Exemple de processus et de r´ eseau de Petri r´ esultant . . . 84

7.1.3 Impl´ ementation en utilisant les outils d´ evelopp´ es . . . 85

7.2 Aplatissement d’une hi´ erarchie de classes . . . 93

7.2.1 Exemple de transformation . . . 93

7.2.2 M´ etamod` ele . . . 93

7.2.3 Impl´ ementation utilisant les outils d´ evelopp´ es . . . 94

7.3 Synth` ese . . . 98

8 R´ esultats exp´ erimentaux 101 8.1 Utilisabilit´ e . . . 101

8.2 Performances . . . 102

8.2.1 Tom-EMF . . . 102

8.2.2 Transformation . . . 103

8.3 Perspectives . . . 108

Conclusion 111 A ´ Etude de cas : Transformation SimplePDLToPetriNet 115 A.1 Code de la transformation SimplePDLToPetriNet . . . 115

A.2 Mod` ele source . . . 119

A.3 Mod` ele r´ esultant . . . 119

A.4 V´ erification du r´ esultat . . . 120

B ´ Etude de cas : aplatissement d’une hi´ erarchie de classes 123 B.1 Code de la transformation . . . 123

B.1.1 Version 1 : transformation en Java+EMF . . . 123

B.1.2 Version 2 : transformation en Tom+Java simple (+EMF) . . . 124

B.1.3 Version 3 : transformation en Tom + Java avec strat´ egies (+ EMF ) . . 126

B.1.4 Version 4 : transformation en Tom+Java avec les nouvelles construc- tions (+EMF) . . . 128 C Impl´ ementation ATL de SimplePDLToPetriNet 131

Glossaire 135

Bibliographie 137

Table des figures

1.1 Exemple de repr´ esentation arborescente d’un terme. . . . 8

1.2 Notation des positions dans un terme. . . . 8

1.3 Exemple de r` egle de r´ e´ ecriture : distributivit´ e de la multiplication par rapport ` a l’addition dans un anneau, ` a savoir x × (y + z) → (x × y) + (x × z). . . 10

1.4 Propri´ et´ es sur les relations binaires. . . . 11

1.5 Fonctionnement global du projet Tom en d´ ebut de th` ese. . . 25

1.6 Fonctionnement global de Tom et contributions de ce travail de th` ese au projet. 26 2.1 Organisation du MDA en 4 niveaux d’abstraction (3+1). . . . 29

2.2 Interpr´ etation des niveaux d’abstraction du MDA . . . 30

2.3 Classification des cat´ egories de transformations de mod` eles. . . 33

2.4 Architecture du standard QVT [OMG08]. . . 36

4.1 M´ etamod` ele des graphes. . . . 49

4.2 Transformation du mod` ele source A;B en un mod` ele cible graphique. . . 50

4.3 R` egles de transformation de A, ; et B. . . 50

4.4 Sch´ ema d’extension du m´ etamod` ele cible par l’ajout d’´ el´ ements interm´ ediaires resolve. . . . 52

4.5 R` egles de transformation de A, ; et B effectives avec la construction d’´ el´ ements resolve (en pointill´ es color´ es). . . 52

4.6 R´ esultat interm´ ediaire de la transformation, avant phase de r´ esolution. . . 53

4.7 Phase de r´ esolution. . . 53

4.8 R` egles de transformation de A, ; et B effectives, avec tra¸ cage des ´ el´ ements cor- respondant ` a un ´ el´ ement resolve d’une autre d´ efinition (token color´ e de la couleur du r´ esultat d’une d´ efinition). . . 54

4.9 Exemple de processus SimplePDL. . . 54

4.10 R´ eseau de Petri correspondant au processus d´ ecrit par la figure 4.9. . . 55

4.11 Transformations ´ el´ ementaires composant SimplePDLToPetriNet. . . 55

5.1 M´ etamod` ele SimplePDL possible. . . 58

5.2 M´ etamod` ele des r´ eseaux de Petri. . . 58

5.3 M´ etamod` ele g´ en´ erique de trace. . . 59

6.1 Exemple de transformation de texte en formes g´ eom´ etriques color´ ees. . . 63

6.2 Un m´ etamod` ele pouvant d´ ecrire le formalisme textuel (source) utilis´ e dans l’exemple support. . . 64

6.3 Un m´ etamod` ele pouvant d´ ecrire le formalisme graphique (cible) utilis´ e dans l’exemple support. . . 65

6.4 Diagramme d’activit´ e d´ ecrivant le processus de compilation d’un programme Tom. . . 74

6.5 Phases du compilateur Tom. . . 74

6.6 Processus de compilation d’une transformation de mod` eles Tom-EMF. . . 76

ix

6.7 Bootstrap de Tom-EMF : remplacement des ancrages alg´ ebriques Ecore.tom

´ ecrits manuellement par les ancrages g´ en´ er´ es. . . 77

6.8 Processus de r´ esolution de liens inverses. . . 81

7.1 M´ etamod` ele SimplePDL. . . 84

7.2 M´ etamod` ele des r´ eseaux de Petri. . . 84

7.3 Exemple de processus d´ ecrit dans le formalisme SimplePDL. . . 85

7.4 R´ eseau de Petri ´ equivalent au processus d´ ecrit par la figure 7.3. . . 85

7.5 R´ eseau de Petri r´ esultant de la transformation d’un Process. . . 86

7.6 R´ eseau de Petri r´ esultant de la transformation d’une WorkDefinition. . . . 88

7.7 R´ eseau de Petri r´ esultant de la transformation d’une WorkSequence. . . 90

7.8 Aplatissement d’une hi´ erarchie de classes. . . 93

7.9 M´ etamod` ele d’UML simplifi´ e. . . 94

7.10 M´ etamod` ele consid´ er´ e pour l’´ etude de cas. . . 94

7.11 Arbres repr´ esentant les mod` eles source des exemples SimplePDLToPetriNet (a) et ClassFlattening (b). . . 97

8.1 Forme g´ en´ erale des mod` eles d’entr´ ee g´ en´ er´ es. . . 104

8.2 R´ eseaux de Petri images d’un Process, d’une WorkDefinition et d’une Work- Sequence. . . 104

8.3 Temps moyen de transformation (en ms) en fonction du nombre d’´ el´ ements

dans le mod` ele source (phase 1, phase 2, total). . . 106

Introduction

Le sujet de cette th` ese est l’´ elaboration de m´ ethodes et outils pour le d´ eveloppement logiciel fiable s’appuyant sur des transformations de mod` eles. Plus pr´ ecis´ ement, la question est de savoir comment am´ eliorer la confiance dans un logiciel et dans son processus de d´ eveloppement alors que les chaˆınes de d´ eveloppement se complexifient et que les outils se multiplient.

L’industrie adopte progressivement les techniques de l’Ing´ enierie Dirig´ ee par les Mod` eles.

L’un des int´ erˆ ets de ce domaine est d’acc´ el´ erer le d´ eveloppement logiciel ` a moindre coˆ ut par l’usage de langages d´ edi´ es et d’outils de g´ en´ eration de code. Dans ce contexte, les logiciels sont donc en partie issus de chaˆınes de transformations op´ er´ ees sur des mod` eles jusqu’` a la g´ en´ eration du code et sa compilation.

Dans le cadre du d´ eveloppement de syst` emes critiques, les logiciels doivent ˆ etre v´ erifi´ es afin d’ˆ etre certifi´ es. Se pose alors la question de la qualification des logiciels utilis´ es dans les chaˆınes de d´ eveloppement des syst` emes critiques. Il faut s’assurer que les outils n’introduisent pas de bogue ` a chaque ´ etape du processus de d´ eveloppement et qu’une trace puisse ˆ etre conserv´ ee, de la sp´ ecification au code.

Le langage Tom repose sur le calcul de r´ e´ ecriture et fournit des fonctionnalit´ es telles que le filtrage ` a des langages g´ en´ eralistes comme Java ou Ada. Des constructions de haut niveau permettent de d´ ecrire formellement des algorithmes. Il offre la possibilit´ e d’´ etablir des r` egles de transformation pour ´ ecrire des outils de transformation sˆ urs.

La finalit´ e de cette th` ese est donc de proposer des m´ ethodes et outils pour exprimer des transformations de mod` eles qualifiables. On s’int´ eresse ` a fournir des constructions d´ edi´ ees pour d´ ecrire une transformation de mod` eles et pour assurer la tra¸ cabilit´ e entre le mod` ele source et le mod` ele cible. Le but ´ etant alors de donner des ´ el´ ements de confiance suppl´ ementaires ` a l’utilisateur responsable de la v´ erification de la chaˆıne de d´ eveloppement.

1

Contexte et motivations

Les syst` emes se complexifiant, l’ing´ enierie dirig´ ee par les mod` eles ( IDM ) a apport´ e des solutions pour faciliter et acc´ el´ erer le d´ eveloppement logiciel. Ce domaine a v´ eritablement pris son essor ` a la fin du XX

si` ecle avec la publication de l’initiative MDA (Model Driven Architecture) par l’ OMG (Object Management Group). L’industrie a adopt´ e les m´ ethodes et technologies issues du monde des mod` eles, y compris dans le cadre du d´ eveloppement de sys- t` emes critiques. Cependant, si la mani` ere de d´ evelopper un logiciel ainsi que les technologies utilis´ ees ont chang´ e depuis les d´ ebuts de l’informatique, les contraintes li´ ees ` a la maintenance (´ evolution du logiciel, d´ eboguage) ainsi qu’` a la fiabilit´ e (qualification, certification) persistent.

Les technologies des domaines critiques tels que l’a´ eronautique, l’automobile et la m´ edecine reposant de plus en plus sur l’informatique, il est particuli` erement important de s’assurer du bon fonctionnement des logiciels avant leur mise en production. Pour cela, il est n´ eces- saire de les v´ erifier. Plusieurs approches compl´ ementaires sont disponibles pour augmenter la confiance en un logiciel : le test, la preuve, la simulation et le model-checking. Chacune d’entre elles comporte ses sp´ ecificit´ es, ses avantages et ses inconv´ enients. Dans le cadre de la qualifi- cation et de la certification, ces approches sont rarement suffisantes une ` a une et sont donc g´ en´ eralement combin´ ees ou pratiqu´ ees en parall` ele. Lors de la certification, il est n´ ecessaire d’avoir une confiance forte dans les outils utilis´ es dans le processus de d´ eveloppement. Cette confiance est accord´ ee par leur qualification qui exige une tra¸ cabilit´ e entre la sp´ ecification et l’impl´ ementation d’un logiciel. L’int´ egration de l’ IDM dans les chaˆınes de d´ eveloppement de syst` emes critiques tendant ` a se g´ en´ eraliser, il est fondamental de d´ evelopper des m´ ethodes et des outils pour aider au processus de qualification des nouveaux outils.

Dans ce contexte, nous nous proposons de travailler ` a l’´ elaboration de m´ ethodes et d’outils permettant d’apporter des ´ el´ ements de confiance pour la qualification du logiciel. Nous nous pla¸ cons ` a la fronti` ere de deux domaines : celui de l’Ing´ enierie Dirig´ ee par les Mod` eles ainsi que celui de la r´ e´ ecriture de termes. L’industrie a vu l’int´ erˆ et pratique de l’ IDM et a adopt´ e les outils qui en sont issus. Les m´ ethodes formelles, en particulier le domaine de la r´ e´ ecriture qui nous int´ eresse, sont quant ` a elles moins connues, mais indispensables pour un d´ eveloppement logiciel de qualit´ e. Se placer ` a la fronti` ere des deux domaines permet de tirer le meilleur des deux mondes et de pousser l’utilisation des m´ ethodes formelles dans l’ing´ enierie du logiciel, que ce soit dans un cadre acad´ emique ou industriel.

L’un des piliers de l’ IDM r´ eside dans les transformations de mod` eles. Nous souhaitons leur apporter plus de fiabilit´ e en fournissant des outils s’appuyant sur le langage Tom. Celui-ci re- pose sur la r´ e´ ecriture et le filtrage pour manipuler et transformer des structures complexes. Il s’int` egre au sein de langages g´ en´ eralistes tels que Java et offre des constructions d´ edi´ ees per- mettant ` a l’utilisateur d’appr´ ehender et d’exprimer plus ais´ ement des algorithmes complexes

`

a mettre en œuvre dans un langage g´ en´ eraliste. Fournir des constructions de haut niveau est un moyen de donner plus de confiance ` a l’utilisateur dans le code r´ esultant : les algorithmes sont exprim´ es plus formellement et il est donc plus facile de raisonner dessus ` a des fins de v´ erification du logiciel. Un autre avantage d’une approche reposant sur des constructions d´ e- di´ ees r´ eside dans la r´ eduction des coˆ uts de d´ eveloppement : l’usage de g´ en´ erateurs de code permet de r´ eduire la quantit´ e de travail et le temps par rapport ` a un d´ eveloppement manuel.

Contributions

Dans ce contexte, la contribution de cette th` ese comprend trois volets principaux : Transformation de mod` eles par r´ e´ ecriture : Nous avons d´ evelopp´ e une m´ ethode de

transformation de mod` eles par r´ e´ ecriture de termes. Pour cela, nous op´ erons une trans-

formation permettant de manipuler un mod` ele sous la forme d’un terme alg´ ebrique. Nous

nous appuyons ensuite sur les strat´ egies de r´ e´ ecriture du langage Tom pour mettre en

œuvre la m´ ethode de transformation. Cette m´ ethode se d´ eroule en deux temps : nous

effectuons d’abord une transformation par parties qui fournit des r´ esultats partiels, puis

3 nous r´ esolvons ces r´ esultats interm´ ediaires pour former le mod` ele cible r´ esultant. Nous avons donc ´ etendu le langage Tom en proposant un ˆılot formel d´ edi´ e pour transformer les mod` eles. Ce nouvel ˆılot impl´ emente notre m´ ethode de transformation par r´ e´ ecriture.

Repr´ esentation alg´ ebrique de mod` eles : Pour transformer un mod` ele dans notre con- texte de r´ e´ ecriture de termes, il est n´ ecessaire d’op´ erer au pr´ ealable un changement d’espace technologique. Pour ce faire, nous proposons un outil permettant de donner une vue alg´ ebrique d’un mod` ele. Il traduit un m´ etamod` ele donn´ e en une signature alg´ ebrique int´ egrable dans notre environnement Tom.

Tra¸ cabilit´ e d’une transformation de mod` eles : Afin de r´ epondre aux exigences du pro- cessus de qualification, nous avons travaill´ e sur la tra¸ cabilit´ e des transformations et avons propos´ e une tra¸ cabilit´ e de sp´ ecification. Nous l’avons impl´ ement´ ee par un ˆılot for- mel d´ edi´ e permettant d’ajouter une forme de tra¸ cabilit´ e au sein d’un langage g´ en´ eraliste tel que Java.

Durant ce travail de th` ese, nous nous sommes attel´ es ` a d´ evelopper des outils op´ erationnels impl´ ementant notre travail. Nous avons toujours gard´ e ` a l’esprit qu’ils doivent pouvoir ˆ etre aussi utilis´ es par des utilisateurs ext´ erieurs en vue d’un usage dans un cadre industriel. Nous avons donc exp´ eriment´ e et am´ elior´ e nos outils afin de leur permettre un passage ` a l’´ echelle.

De plus, tout ce que nous avons d´ evelopp´ e est disponible librement et gratuitement sur le site du projet Tom. L’ensemble de nos exp´ eriences reposant sur du code ouvert document´ e ainsi que sur des mod` eles diffus´ es librement, cela assure leur reproductibilit´ e par un utilisateur averti. Cet aspect d’ouverture et de diffusion libre des r´ esultats et des donn´ ees s’inscrit dans le mouvement de l’open science, qui est indispensable ` a une recherche v´ erifiable et reproduc- tible. Nous posons ainsi les conditions id´ eales pour tout utilisateur souhaitant tester, v´ erifier, utiliser, modifier et ´ etendre nos travaux.

Plan de la th` ese

La suite de ce document se d´ ecompose en huit chapitres r´ epartis dans deux grandes parties.

La premi` ere consiste en un ´ etat de l’art de trois chapitres, traitant trois th´ ematiques li´ ees au contexte de cette th` ese. La seconde constitue les contributions de ce travail de th` ese. Nous r´ esumons bri` evement chaque chapitre.

Conseils et guide de lecture : Chaque chapitre de la premi` ere partie peut ˆ etre lu ind´ epen- damment des autres. Les chapitres 4 et 5 expliquent le fond du travail de th` ese, tandis que les chapitres 6, 7 et 8 sont plus techniques. Le chapitre 6 d´ ecrit les travaux d’impl´ ementation des deux chapitres pr´ ec´ edents. Le chapitre 7 illustre l’utilisation des outils appliqu´ es sur deux cas d’´ etude. Le chapitre 8 comprend des r´ esultats exp´ erimentaux et donne des perspectives d’´ evolution technique de nos outils.

Partie I : ´ Etat de l’art

Les trois chapitres composant l’´ etat de l’art traitent de la r´ e´ ecriture et du langage Tom 1, des transformations de mod` eles 2 ainsi que de la v´ erification du logiciel 3.

Chapitre 1 – Un langage bas´ e sur la r´ e´ ecriture : Tom

Dans ce chapitre, nous donnons le cadre formel de la r´ e´ ecriture et d´ efinissons toutes les notions importantes sous-jacentes au langage Tom. Nous le d´ ecrivons ensuite et d´ etaillons les diff´ erentes constructions le composant. Nous nous appuyons sur des exemples simples pour les illustrer. Ce chapitre peut constituer un manuel court du langage Tom.

Chapitre 2 – Transformations de mod` eles

Ce chapitre donne le cadre de la mod´ elisation et des transformations de mod` eles. Nous

donnons une taxonomie des transformations qui se r´ epartissent selon les crit` eres li´ es aux

m´ etamod` eles et aux changements de niveau d’abstraction. Nous expliquons aussi quelles sont les approches principales pour transformer des mod` eles et quels sont les outils existants.

Chapitre 3 – V´ erification du logiciel

Ce chapitre d´ ecrit le contexte de la v´ erification du logiciel et plus particuli` erement celui de la qualification et de la certification. C’est dans ce contexte que s’inscrit notre travail de th` ese.

Partie II : Contributions

La seconde partie regroupe les contributions de ce travail de th` ese, d´ ecoup´ ees en cinq chapitres r´ esum´ es ci-apr` es.

Chapitre 4 – Transformations de mod` eles par r´ e´ ecriture

Dans ce chapitre, nous exposons notre approche de transformation de mod` eles dans notre environnement utilisant la r´ e´ ecriture. Elle consiste ` a repr´ esenter des mod` eles sous la forme de termes en op´ erant un changement d’espace technologique, puis ` a effectuer une transformation par parties du mod` ele source. Chaque partie est transform´ ee sans notion d’ordre grˆ ace ` a une strat´ egie de r´ e´ ecriture. L’ensemble des transformations partielles est suivi d’une phase de r´ esolution du r´ esultat partiel et produit le mod` ele cible.

Chapitre 5 – Sp´ ecification et tra¸ cabilit´ e des transformations

Dans ce chapitre, nous exprimons la tra¸ cabilit´ e d’une transformation de mod` ele exig´ ee par le processus de qualification. Elle consiste ` a lier les sources aux cibles de la transformation en fonction de la sp´ ecification.

Chapitre 6 – Outils pour exprimer une transformation de mod` eles en Tom Dans ce chapitre, nous d´ etaillons les outils d´ evelopp´ es durant cette th` ese pour la mise en œuvre des m´ ecanismes expliqu´ es dans les chapitres 4 et 5. Nous expliquons donc comment nous op´ erons le changement d’espace technologique, en quoi consiste le nouvel ˆılot formel du langage Tom pour exprimer une transformation de mod` eles. Nous d´ ecrivons l’impl´ ementation au sein du projet Tom.

Chapitre 7 – ´ Etudes de cas : illustration et utilisation du langage

Dans ce chapitre, nous illustrons l’utilisation de nos outils sur deux ´ etudes de cas : Sim- plePDLToPetriNet et l’aplatissement d’une hi´ erarchie de classe. La premi` ere ´ etude permet de d´ etailler le processus complet d’´ ecriture. L’´ etude de la seconde transformation a pour but de montrer les points d’am´ elioration de nos outils et d’ouvrir des perspectives de recherche et de d´ eveloppement suite ` a ce travail.

Chapitre 8 – R´ esultats exp´ erimentaux

Ce chapitre est compos´ e de r´ esultats exp´ erimentaux pour donner une premi` ere ´ evaluation de nos outils. Nous les avons test´ es sur des mod` eles de tailles importantes afin de les pousser

`

a leurs limites en termes de performances et de valider leur potentiel usage dans un cadre

industriel. Nous d´ ecrivons aussi l’´ evolution de nos outils suite aux premi` eres exp´ eriences et

nous tirons certaines conclusions.

Premi` ere partie

Etat de l’art ´

5

Chapitre 1

Un langage bas´ e sur la r´ e´ ecriture : Tom

Dans ce chapitre, nous abordons les notions ´ el´ ementaires utiles ` a la lecture de ce document.

Nous pr´ esentons d’abord la r´ e´ ecriture de termes, puis nous d´ ecrivons le langage Tom [MRV03, BBK

07] et nous terminons par les ancrages formels.

1.1 R´ e´ ecriture

1.1.1 Signature alg´ ebrique et termes

Cette section traite des notions de base concernant les alg` ebres de termes du premier ordre.

D´ efinition 1 (Signature). Une signature F est un ensemble fini d’op´ erateurs (ou symboles de fonction), dont chacun est associ´ e ` a un entier naturel par la fonction d’arit´ e, ar : F → N . F

d´ esigne le sous-ensemble de symboles d’arit´ e n, c’est-` a-dire F

= {f ∈ F | ar(f ) = n}.

L’ensemble des constantes est d´ esign´ e par F

.

On classifie parfois les termes selon leur type dans des sortes. On parle alors de signature multi-sort´ ee.

D´ efinition 2 (Signature alg´ ebrique multi-sort´ ee). Une signature multi-sort´ ee est un couple (S, F) o` u S est un ensemble de sortes et F est un ensemble d’op´ erateurs sort´ es d´ efini par F = S

S1,...,Sn,S∈S

F

. Le rang d’un symbole de fonction f ∈ F

not´ e rank(f ) est d´ efini par le tuple (S

,. . . ,S

,S) que l’on note souvent f : S

× . . . × S

→ S

D´ efinition 3 (Terme). Etant donn´ ´ e un ensemble infini d´ enombrable de variables X et une signature F, on d´ efinit l’ensemble des termes T (F, X ) comme le plus petit ensemble tel que :

— X ⊆ T (F , X ) : toute variable de X est un terme de T (F, X ) ;

— pour tous t

, . . . , t

´ el´ ements de T (F, X ) et pour tout op´ erateur f ∈ F d’arit´ e n, le terme f (t

, . . . , t

) est un ´ el´ ement de T (F, X ).

Pour tout terme t de la forme f (t

, . . . , t

), le symbole de tˆ ete de t, not´ e symb(t) est, par d´ efinition, l’op´ erateur f .

Un symbole de fonction dont l’arit´ e est variable est appel´ e op´ erateur variadique, c’est-` a-dire qu’il prend un nombre arbitraire d’arguments.

D´ efinition 4 (Variables d’un terme). L’ensemble Var(t) des variables d’un terme t est d´ efini inductivement comme suit :

7

— V ar(t) = ∅, pour t ∈ F

;

— V ar(t) = {t}, pour t ∈ X ;

— V ar(t) = S

i=1

Var(t

), pour t = f (t

, . . . , t

).

On note souvent a, b, c, . . . les constantes et x, y, z, . . . les variables.

On repr´ esente les termes sous forme arborescente. Par exemple, on peut repr´ esenter le terme f (x, g(a)) comme dans la figure 1.1 :

f

x g

a

Figure 1.1 – Exemple de repr´ esentation arborescente d’un terme.

D´ efinition 5 (Terme clos). Un terme t est dit clos s’il ne contient aucune variable, c’est-` a- dire si Var(t) = ∅. On note T (F) l’ensemble des termes clos.

Chaque nœud d’un arbre peut ˆ etre identifi´ e de mani` ere unique par sa position.

D´ efinition 6 (Position). Une position dans un terme t est repr´ esent´ ee par une s´ equence ω d’entiers naturels, d´ ecrivant le chemin de la racine du terme jusqu’` a un nœud t

du terme.

Un terme u a une occurrence dans t si u = t

pour une position ω dans t.

On notera P os(t) l’ensemble des positions d’un terme t et t[t

]

le remplacement du sous- terme de t ` a la position ω par t

.

Par exemple, la figure 1.2 illustre la notation des positions pour le terme t = f (x, g(a)).

On obtient l’ensemble des positions P os(t) = {, 1, 2, 21} ce qui correspond respectivement aux sous-termes t

= f (x, g(a)), t

= x, t

= g(a) et t

= a.

f

x g

a ω =

ω = 1 ω = 2

ω = 21

Figure 1.2 – Notation des positions dans un terme.

1.1.2 Filtrage

Une substitution est une op´ eration de remplacement, uniquement d´ efinie par une fonction des variables vers les termes clos.

D´ efinition 7 (Substitution). Une substitution σ est une fonction de X vers T (F), not´ ee lorsque son domaine Dom(σ) est fini, σ = {x

7→ t

, . . . , x

7→ t

}. Cette fonction s’´ etend de mani` ere unique en un endomorphisme σ

: T (F, X ) → T (F, X ) sur l’alg` ebre des termes, qui est d´ efini inductivement par :

— σ

(x) =

σ(x) si x ∈ Dom(σ) x sinon

— σ

(f(t

, . . . , t

)) = f (σ

(t

), . . . , σ

(t

)) pour tout symbole de fonction f ∈ F

.

1.1. R´ e´ ecriture 9 D´ efinition 8 (Filtrage). Etant donn´ ´ es un motif p ∈ T (F, X) et un terme clos t ∈ T (F), p filtre t, not´ e p < < t, si et seulement s’il existe une substitution σ telle que σ(p) = t :

p < < t ⇔ ∃σ, σ(p) = t

On parle de filtrage unitaire lorsqu’il existe une unique solution ` a l’´ equation de filtrage.

Si plusieurs solutions existent, le filtrage est non unitaire.

Le filtrage peut aussi ˆ etre modulo une th´ eorie ´ equationnelle. Cela signifie que l’on a associ´ e une th´ eorie ´ equationnelle au probl` eme de filtrage.

D´ efinition 9 (Filtrage modulo une th´ eorie ´ equationnelle). Etant donn´ ´ es une th´ eorie ´ equa- tionnelle E , un motif p ∈ T (F, X) et un terme clos t ∈ T (F), p filtre t modulo E, not´ e p < <

t, si et seulement s’il existe une substitution σ telle que σ(p) =

t, avec =

l’´ egalit´ e modulo E :

p < <

t ⇔ ∃σ, σ(p) =

t

Dans la suite de cette section, nous allons expliquer ce concept, donner des exemples de th´ eories ´ equationnelles et illustrer notre propos.

Une paire de termes (l, r) est appel´ ee ´ egalit´ e, axiome ´ equationnel ou ´ equation selon le contexte, et est not´ ee (l = r). Une th´ eorie ´ equationnelle peut ˆ etre d´ efinie par un ensemble d’´ egalit´ es. Elle d´ efinit une classe d’´ equivalence entre les termes. Dans la pratique, les th´ eories

´

equationnelles les plus communes sont l’associativit´ e, la commutativit´ e et l’´ el´ ement neutre (ainsi que leurs combinaisons).

D´ efinition 10 (Op´ erateur associatif). Un op´ erateur binaire f est associatif si ∀x, y, z ∈ T (F, X ), f (f (x, y), z) = f (x, f(y, z)).

Par exemple, l’addition et la multiplication sont associatives sur l’ensemble des r´ eels R : ((x + y) + z) = (x + (y + z)) et ((x × y) × z)) = (x × (y × z)). En revanche, la soustraction sur R n’est pas associative : ((x − y) − z) 6= (x − (y − z)).

D´ efinition 11 (Op´ erateur commutatif). Un op´ erateur binaire f est commutatif si ∀x, y ∈ T (F, X )f (x, y) = f (y, x).

Par exemple, l’addition et la multiplication sont commutatives sur R , ainsi x + y = y + x et x × y = y × x. Ce qui n’est pas le cas de la soustraction sur R , en effet x − y 6= y − x.

D´ efinition 12 ( ´ El´ ement neutre). Soit un op´ erateur binaire f et x ∈ T (F, X), la constante e ∈ T (F) est :

— neutre ` a gauche pour f si f (e, x) = x ;

— neutre ` a droite pour f si f (x, e) = x ;

— neutre si elle est neutre ` a gauche et neutre ` a droite pour f .

Pour illustrer cette notion d’´ el´ ement neutre, examinons la constante 0 avec l’addition sur l’ensemble des r´ eels R :

— 0 + x = x, 0 est donc neutre ` a gauche pour l’addition ;

— x + 0 = x, 0 est donc neutre ` a droite pour l’addition ;

— on en d´ eduit que 0 est neutre pour l’addition sur R .

On note g´ en´ eralement A, U et C les th´ eories ´ equationnelles engendr´ ees respectivement par l’´ equation d’associativit´ e, l’´ equation de neutralit´ e et celle de commutativit´ e. On note AU la th´ eorie engendr´ ee par les ´ equations d’associativit´ e et de neutralit´ e.

La th´ eorie associative est associ´ ee aux op´ erateurs binaires. Pour des raisons techniques,

elle est souvent associ´ ee ` a une syntaxe variadiques dans les langages de programmation fon-

d´ es sur la r´ e´ ecriture. Par exemple, l’op´ erateur variadique list est simul´ e par l’op´ erateur

nil d’arit´ e nulle, ainsi que par l’op´ erateur binaire cons. Cela permet d’´ ecrire que le terme

list(a, b, c) est ´ equivalent au terme list(list(a, b), c), et qu’ils peuvent ˆ etre repr´ esent´ es par cons(a, cons(b, cons(c, nil))).

On peut alors d´ efinir des op´ erations modulo une th´ eorie ´ equationnelle : on parlera de filtrage ´ equationnel lorsque le filtrage sera associ´ e ` a une telle th´ eorie. Pour illustrer cette notion, prenons deux exemples simples de filtrage.

Exemple 1 : Le filtrage associatif avec ´ el´ ement neutre (AU ) — aussi appel´ e filtrage de liste — est un probl` eme bien connu en r´ e´ ecriture. Il permet d’exprimer facilement des algo- rithmes manipulant des listes. En consid´ erent X1∗ et X 2∗ comme ides variables repr´ esentant 0 ou plusieurs ´ el´ ements d’une liste, le probl` eme de filtrage list(X 1∗, x, X2∗) list(a, b, c) admet trois solutions : σ

= {x → a}, σ

= {x → b} et σ

= {x → c}.

Exemple 2 : Illustrons le filtrage associatif-commutatif (AC) et l’addition, dont les axiomes d’associativit´ e et commutativit´ e sont les suivants :

— ∀x, y, plus(x, y) = plus(y, x) ;

— ∀x, y, plus(x, plus(y, z)) = plus(plus(x, y), z).

Le probl` eme de filtrage plus(x, y) plus(a, b) pr´ esente deux solutions distinctes modulo AC : σ

= {x → a, y → b} et σ

= {x → b, y → a}.

1.1.3 R´ e´ ecriture

En r´ e´ ecriture, on oriente des ´ egalit´ es que l’on appelle des r` egles de r´ e´ ecriture et qui d´ efi- nissent un calcul.

D´ efinition 13 (R` egle de r´ e´ ecriture). Une r` egle de r´ e´ ecriture est un couple (l,r) de termes dans T (F, X ), not´ ee l → r. l est appel´ e membre gauche de la r` egle, et r membre droit.

Un exemple de r` egle de r´ e´ ecriture est l’addition de n’importe quel entier x avec 0 : x + 0 → x

Un autre exemple un peu plus complexe de r` egle de r´ e´ ecriture est la distributivit´ e de la multiplication par rapport ` a l’addition dans un anneau, comme illustr´ e par la figure 1.3.

×

x +

y z

−→

+

×

x y

×

x z

Figure 1.3 – Exemple de r` egle de r´ e´ ecriture : distributivit´ e de la multiplication par rapport ` a l’addition dans un anneau, ` a savoir x × (y + z) → (x × y) + (x × z).

D´ efinition 14 (Syst` eme de r´ e´ ecriture). Un syst` eme de r´ e´ ecriture sur les termes est un en- semble de r` egles de r´ e´ ecriture (l,r) tel que :

— les variables du membre droit de la r` egle font partie des variables du membre gauche (Var(r) ⊆ Var(l)) ;

— le membre gauche d’une r` egle n’est pas une variable (l / ∈ X ).

D´ efinition 15 (R´ e´ ecriture). Un terme t ∈ T (F , X ) se r´ e´ ecrit en t

dans un syst` eme de r´ e´ ecriture R, ce que l’on note t →

t

, s’il existe :

— une r` egle l → r ∈ R ;

1.1. R´ e´ ecriture 11

— une position ω dans t ;

— une substitution σ telle que t

= σ(l) et t

= t[σ(r)]

. On appelle radical le sous-terme t

.

Pour une relation binaire →, on note →

sa fermeture transitive et r´ eflexive. La fermeture transitive, r´ eflexive et sym´ etrique de → — qui est alors une relation d’´ equivalence — est not´ ee

↔

.

D´ efinition 16 (Forme normale). Soit → une relation binaire sur un ensemble T. Un ´ el´ ement t ∈ T est r´ eductible par → s’il existe t

∈ T tel que t → t

. Dans le cas contraire, on dit qu’il est irr´ eductible. On appelle forme normale de t tout ´ el´ ement t

irr´ eductible de T tel que t →

t

. Cette forme est unique.

Deux propri´ et´ es importantes d’un syst` eme de r´ e´ ecriture sont la confluence et la terminai- son. Lorsque l’on souhaite savoir si deux termes sont ´ equivalents, on cherche ` a calculer leurs formes normales et ` a v´ erifier si elles sont ´ egales. Cela n’est possible que si la forme normale existe et qu’elle est unique. Une forme normale existe si → termine, et son unicit´ e est alors assur´ ee si → est confluente, ou si elle v´ erifie la propri´ et´ e de Church-Rosser, qui est ´ equivalente.

D´ efinition 17 (Terminaison). Une relation binaire → sur un ensemble T est dite terminante s’il n’existe pas de suite infinie (t

)

d’´ el´ ements de T telle que t

→ t

→ · · ·.

D´ efinition 18 (Confluence). Soit une relation binaire → sur un ensemble T.

(a) → est confluente si et seulement si :

∀t, u, v (t →

u et t →

v) ⇒ ∃w, (u →

w et v →

w) (b) → v´ erifie la propri´ et´ e de Church-Rosser si et seulement si :

∀u, v, u ↔

v ⇒ ∃w, (u →

w et v →

w) (c) → est localement confluente si et seulement si :

∀t, u, v (t → u et t → v) ⇒ ∃w, (u →

w et v →

w) La figure 1.4 illustre ces propri´ et´ es.

t

u v

w

(a) Confluence

∗ ∗

∗ ∗

u v

w

(b) Church-Rosser

∗

∗ ∗

t

u v

w

(c) Confluence locale

∗ ∗

Figure 1.4 – Propri´ et´ es sur les relations binaires.

1.1.4 Strat´ egies de r´ e´ ecriture

En r´ e´ ecriture, on applique habituellement de mani` ere exhaustive toutes les r` egles sur le

terme pour calculer sa forme normale, c’est-` a-dire que l’on applique toutes les r` egles jusqu’` a ce

qu’aucune r` egle ne puisse plus ˆ etre appliqu´ ee. Il est cependant courant d’´ ecrire des syst` emes

de r´ e´ ecriture ne terminant pas ou n’´ etant pas confluents. La m´ ethode d’application des r` egles

adopt´ ee prend donc de l’importance, car elle a, dans ce cas, un effet sur le r´ esultat. Il est par

cons´ equent important d’avoir un contrˆ ole sur l’application des r` egles du syst` eme de r´ e´ ecriture.

C’est l’objet du concept de strat´ egie que nous allons d´ ecrire dans cette section.

Illustrons ce probl` eme par un exemple o` u l’on consid` ere le syst` eme de r´ e´ ecriture suivant avec la signature {a, f}, a ´ etant d’arit´ e 0 et f d’arit´ e 1 :

f (x) → f (f (x)) (r1)

f (a) → a (r2)

Sans aucune pr´ ecision sur la mani` ere d’appliquer les r` egles, nous remarquons qu’il existe une suite infinie de pas de r´ e´ ecriture partant de f (a) si l’on applique toujours la r` egle r1 : f (a) −→

f (f (a)) −→

f (f (f (a))) −→ · · ·

Le calcul ne termine pas. Si l’on applique les r` egles de r´ e´ ecriture r1 et r2 diff´ eremment, nous constatons que f (a) se r´ eduit en a :

f(a) −→

f (f (a)) −→

f (a) −→

a

↓

a

Cet exemple illustre clairement le fait que les r´ esultats du calcul ne sont pas les mˆ emes selon la m´ ethode d’application des r` egles. Pour avoir des calculs qui terminent, on pourrait alors adopter une strat´ egie d’application des r` egles donnant la priorit´ e ` a la r` egle r2 : f (a) → a par rapport ` a la r` egle r1 : f (x) → f (f (x)).

Apr` es cette intuition de ce qu’est une strat´ egie, nous pouvons donner des d´ efinitions plus formelles des concepts li´ es. La notion de syst` eme abstrait de r´ eduction (Abstract Reduction System – ARS) [BKdV03] est une mani` ere abstraite de mod´ eliser les calculs par transforma- tions pas ` a pas d’objets, ind´ ependamment de la nature des objets qui sont r´ e´ ecrits. Un ARS peut se d´ efinir comme un couple (T , →), o` u → est une relation binaire sur l’ensemble T . De l` a, [KKK

08] donne une repr´ esentation des ARS sous forme de graphe et introduit le concept de strat´ egie abstraite.

D´ efinition 19 (Syst` eme abstrait de r´ eduction). Un syst` eme abstrait de r´ eduction (ARS) est un graphe orient´ e ´ etiquet´ e (O, S). Les nœuds O sont appel´ es objets, les arˆ etes orient´ ees S sont appel´ ees pas.

Pour un ensemble de termes T (F, X), le graphe (T (F, X ), S) est l’ARS correspondant ` a un syst` eme de r´ e´ ecriture R. Les arˆ etes correspondent ` a des pas de r´ e´ ecriture de R et sont

´

etiquet´ ees par le nom des r` egles de R.

D´ efinition 20 (D´ erivation). Soit un ARS A :

1. un pas de r´ eduction est une arˆ ete ´ etiquet´ ee φ compl´ et´ ee de sa source a et de sa desti- nation b. On note un pas de r´ eduction a →

b, ou simplement a →

b lorsqu’il n’y a pas d’ambigu¨ıt´ e ;

2. une A-d´ erivation (ou s´ equence de T -r´ eductions) est un chemin π dans le graphe A ; 3. lorsque cette d´ erivation est finie, π peut s’´ ecrire a

→

a

→

a

· · · →

a

et on dit que a

se r´ eduit en a

par la d´ erivation π = φ

φ

. . . φ

; not´ ee aussi a

→

a

ou simplement a

→

a

. n est la longueur de π ;

(a) la source de π est le singleton {a

}, not´ ee dom(π) ; (b) la destination de π est le singleton {a

}, not´ ee π[a

].

4. une d´ erivation est vide si elle n’est form´ ee d’aucun pas de r´ eduction. La d´ erivation vide de source a est not´ ee id

.

D´ efinition 21 (Strat´ egie abstraite). Soit un ARS A :

1. une strat´ egie abstraite est un sous-ensemble de toutes les d´ erivations de A ;

2. appliquer la strat´ egie ζ sur un objet a, not´ e par ζ[a], est l’ensemble de tous les ob- jets atteignables depuis a en utilisant une d´ erivation dans ζ : ζ[a] = {π[a] | π ∈ ζ}.

Lorsqu’aucune d´ erivation dans ζ n’a pour source a, on dit que l’application sur a de la

strat´ egie a ´ echou´ e ;

1.2. Le langage Tom 13 3. appliquer la strat´ egie ζ sur un ensemble d’objets consiste ` a appliquer ζ ` a chaque ´ el´ ement a de l’ensemble. Le r´ esultat est l’union de ζ[a] pour tous les a de l’ensemble d’objets ; 4. le domaine d’une strat´ egie est l’ensemble des objets qui sont la source d’une d´ erivation

dans ζ : dom(ζ) = S

δ∈ζ

dom(δ) ;

5. la strat´ egie qui contient toutes les d´ erivations vides est Id = {id

| a ∈ O}.

Concr` etement, on peut exprimer ces strat´ egies de mani` ere d´ eclarative grˆ ace aux langages de strat´ egies que proposent la plupart des langages ` a base de r` egles tels que Elan [Vit94, BKK

98, BKK

96], Stratego [VBT98, Vis01a], Maude [CELM96, CDE

02, CDE

11] et Tom, que nous allons pr´ esenter dans la section suivante.

Elan. Elan propose deux types de r` egles : les r` egles anonymes syst´ ematiquement appliqu´ ees (servant ` a la normalisation de termes) et les r` egles ´ etiquet´ ees pouvant ˆ etre d´ eclench´ ees ` a la demande sous contrˆ ole d’une strat´ egie. Le r´ esultat de l’application d’une telle r` egle sur un terme est un multi-ensemble de termes, ce qui permet de g´ erer le non-d´ eterminisme. Elan a introduit la notion de strat´ egie en proposant un langage de combinateurs permettant de composer les strat´ egies et de contrˆ oler leur application. Parmi ces combinateurs, on retien- dra notamment l’op´ erateur de s´ equence, des op´ erateurs de choix non-d´ eterministes et des op´ erateurs de r´ ep´ etition.

Stratego. S’inspirant d’Elan, Stratego se concentre sur un nombre restreint de combinateurs

´

el´ ementaires, ainsi que sur leur combinaison. ` A ces combinateurs (s´ equence, identit´ e, ´ echec, test, n´ egation, choix d´ eterministe et non-d´ eterministe) sont ajout´ es un op´ erateur de r´ ecursion (µ) et des op´ erateurs permettant d’appliquer la strat´ egie : sur le i

fils du sujet (i(s)), sur tous les sous-termes du sujet (All(s)), sur le premier fils du sujet sans ´ echec (One(s)), sur tous les sous-termes du sujet sans ´ echec (Some(s)). Grˆ ace ` a ces op´ erateurs, il est possible d’´ elaborer des strat´ egies de haut niveau telles que TopDown et BottomUp.

Maude. L’approche de Maude est un peu diff´ erente : le contrˆ ole sur l’application des r` egles s’op` ere grˆ ace ` a la r´ eflexivit´ e du syst` eme [CM96, CM02]. Les objets du langage Maude ayant une repr´ esentation meta, il est possible d’utiliser un op´ erateur (meta-apply) pour appli- quer les r` egles. Cet op´ erateur ´ evalue les ´ equations, normalise le terme, et retourne la meta- repr´ esentation du terme r´ esultant de l’´ evaluation. On peut contrˆ oler l’application des r` egles de r´ e´ ecriture par un autre programme d´ efini par r´ e´ ecriture. Pour des raisons pratiques, des travaux ont ´ et´ e men´ es plus r´ ecemment [MOMV05, EMOMV07] pour offrir un langage de strat´ egies plus proche de ce que Elan, Stratego et Tom proposent.

Tom. A partir du concept de strat´ ` egie et en s’inspirant de ces langages, Tom impl´ emente lui aussi un langage de strat´ egies [BMR08, BMR12]. Il est fond´ e sur des strat´ egies ´ el´ ementaires (Identity et Fail), sur des combinateurs de composition (Sequence, Recursion —µ—, Choice, Not, IfThenElse) et de travers´ ee (All, One, Up et Omega). De ces combinateurs, ` a l’image de Stratego, des strat´ egies compos´ ees peuvent ˆ etre ´ elabor´ ees (Try, Repeat, Innermost, etc.).

Nous reviendrons sur les strat´ egies de Tom dans la section suivante, en particulier sur leur utilisation concr` ete au sein du langage.

1.2 Le langage Tom

Tom [MRV03, BBK

07] est un langage con¸ cu pour enrichir des langages g´ en´ eralistes de

fonctionnalit´ es issues de la r´ e´ ecriture et de la programmation fonctionnelle. Il ne s’agit pas

d’un langage stand-alone : il est l’impl´ ementation du concept des « ˆılots formels » (formal

islands ) [BKM06] qui sont ajout´ es au sein de programmes ´ ecrits dans un langage hˆ ote. Les

constructions Tom sont transform´ ees et compil´ ees vers le langage hˆ ote. Parmi les fonction- nalit´ es apport´ ees par Tom, on compte le filtrage de motif (pattern-matching ), les r` egles de r´ e´ ecriture, les strat´ egies, ainsi que les ancrages alg´ ebriques (mappings ).

Dans la suite de cette section, nous d´ ecrirons le langage Tom en illustrant ses fonctionna- lit´ es et constructions par des exemples simples. Sauf indication contraire, les extraits de code hˆ ote seront en Java. Pour une documentation compl` ete et d´ etaill´ ee, le lecteur int´ eress´ e pourra se r´ ef´ erer au manuel disponible en t´ el´ echargement [BBB

09] ou directement en ligne [BB

13].

Les outils sont tous accessibles via le site officiel du projet Tom

.

1.2.1 Signature alg´ ebrique

Tom permet ` a l’utilisateur de sp´ ecifier des signatures alg´ ebriques multi-sort´ ees via l’outil Gom [Rei07]. Le langage Gom permet de d´ ecrire une structure de donn´ ees et d’en g´ en´ erer l’impl´ ementation typ´ ee en Java. Le listing 1.1 illustre une d´ efinition de signature Gom :

1

module Peano

2

abstract syntax

4

Nat = zero()

5

| suc(n:Nat)

Listing 1.1 – Signature alg´ ebrique Gom pour les entiers de Peano.

Un module Gom est compos´ e d’un pr´ eambule comportant un nom — Peano dans cet exemple — pr´ ec´ ed´ e du mot-clef module (ligne 1). Le d´ ebut de la signature est annonc´ e par le mot-clef abstract syntax (ligne 2). Cet exemple ´ etant extrˆ emement simple, le pr´ eambule est compos´ e uniquement de ces deux lignes. Pour un module plus complexe qui utiliserait des types d´ efinis dans une autre signature, la clause imports suivie des signatures ` a importer peut ˆ etre intercal´ ee entre les deux clauses pr´ ec´ edentes. Le projet Tom fournit notamment une biblioth` eque de signatures pour les types primitifs (types builtin) tels que les entiers (int), les caract` eres (char), les flottants (float) et les chaˆınes de caract` eres (String). La signature en elle-mˆ eme est compos´ ee d’un ensemble de sortes — Nat dans notre exemple — ayant des constructeurs — zero et suc ici.

Ce g´ en´ erateur propose un typage fort au niveau de la structure de donn´ ees Java g´ en´ er´ ee, ce qui garantit que les objets cr´ e´ es sont conformes ` a la signature multi-sort´ ee. Un second aspect int´ eressant de cet outil est le fait qu’il offre le partage maximal [AC93], rendant les structures g´ en´ er´ ees tr` es efficaces en temps (tests d’´ egalit´ e en temps constant) et en espace.

Les classes g´ en´ er´ ees peuvent ˆ etre modifi´ ees par l’interm´ ediaire de la fonctionnalit´ e de hooks.

Ce m´ ecanisme permet d’ajouter des blocs de code Java aux classes g´ en´ er´ ees (par exemple, int´ egration d’attributs invisibles au niveau alg´ ebrique, mais manipulables par la partie Java de l’application) ou d’associer une th´ eorie ´ equationnelle telle que A, AC, ACU ` a certains op´ erateurs. Il est mˆ eme possible de sp´ ecifier cette th´ eorie ´ equationnelle par des r` egles de normalisation. Les termes construits sont ainsi toujours en forme normale.

La signature est compil´ ee en une impl´ ementation Java ainsi qu’un ancrage permettant l’utilisation de cette structure dans les programmes Tom. Dans un premier temps, pour pr´ e- senter les constructions du langage Tom, nous ne nous pr´ eoccuperons pas de ces ancrages ni de l’impl´ ementation concr` ete Java.

1.2.2 Construction backquote « ‘ »

La construction ‘ (backquote) permet de cr´ eer la structure de donn´ ees repr´ esentant un terme alg´ ebrique en allouant et initialisant les objets en m´ emoire. Elle permet ` a la fois de construire un terme et de r´ ecup´ erer la valeur d’une variable instanci´ ee par le filtrage de motif.

Ainsi, on peut construire des termes de type Nat de l’exemple pr´ ec´ edent avec des instructions

1. Voirhttp://tom.loria.fr/.

1.2. Le langage Tom 15 backquote. L’instruction Tom+Java « Nat un = ‘suc(zero()); » d´ eclare une variable un dont le type est Nat, ayant pour valeur le repr´ esentant alg´ ebrique suc(zero()).

Un terme backquote peut aussi contenir des variables du langage hˆ ote, ainsi que des appels de fonctions. Ainsi, l’instruction Nat deux = ‘suc(un); permet de cr´ eer le terme deux ` a partir de un cr´ e´ e pr´ ec´ edemment. Le compilateur Tom n’analysant pas du tout le code hˆ ote, notons que nous supposons que la partie hˆ ote — un dans l’exemple — est conforme ` a la signature alg´ ebrique et que le terme est donc bien form´ e. L’utilisation du backquote permet

`

a l’utilisateur de cr´ eer un terme et de manipuler sa vue alg´ ebrique sans se soucier de son impl´ ementation concr` ete dans le langage hˆ ote.

1.2.3 Filtrage de motif

Dans la plupart des langages g´ en´ eralistes tels que C ou Java, on ne trouve pas les notions de type alg´ ebrique et de terme, mais uniquement celle de types de donn´ ees compos´ ees (structures C et objets Java). De mˆ eme, la notion de filtrage de motif (pattern-matching ) que l’on retrouve dans les langages fonctionnels tels que Caml ou Haskell n’existe g´ en´ eralement pas dans la plupart des langages imp´ eratifs classiques. Le filtrage permet de tester la pr´ esence de motifs (pattern) dans une structure de donn´ ees et d’instancier des variables en fonction du r´ esultat de l’op´ eration de filtrage.

Ces constructions sont apport´ ees par Tom dans des langages g´ en´ eralistes. Il devient donc possible de filtrer des motifs dans Java. En outre, les constructions de filtrage de Tom ´ etant plus expressives que dans Caml (notamment le filtrage ´ equationnel et le filtrage non lin´ eaire), il est possible de les employer aussi en son sein pour utiliser le filtrage ´ equationnel.

Le lex` eme %match introduit la construction de filtrage de Tom. Celle-ci peut ˆ etre vue comme une g´ en´ eralisation de la construction habituelle switch-case que l’on retrouve dans beaucoup de langages g´ en´ eralistes. Cependant, plutˆ ot que de filtrer uniquement sur des entiers, des caract` eres, voire des chaˆınes de caract` eres, Tom filtre sur des termes. Les motifs permettent de discriminer et de r´ ecup´ erer l’information contenue dans la structure de donn´ ees alg´ ebrique sur laquelle on filtre.

Dans le listing 1.2 suivant, nous reprenons l’exemple des entiers de Peano pour lesquels nous encodons l’addition avec Tom et Java. Pour ce premier exemple o` u les deux langages apparaissent en mˆ eme temps, nous adoptons un marquage visuel pour d´ esigner Java (noir) et Tom (gris). Cela permet de visualiser le tissage ´ etroit entre le langage Tom et le langage hˆ ote dans lequel il est int´ egr´ e. Par la suite, le principe ´ etant compris, nous n’adopterons plus ce code visuel.

1

Nat peanoPlus(Nat t1, Nat t2) {

2

%match(t1, t2) {

3

x, zero() -> { return ‘x; }

4

x, suc(y) -> { return ‘suc(peanoPlus(x,y)); }

5

}

6

}

Listing 1.2 – Exemple d’utilisation du filtrage avec l’addition des entiers de Peano.

Dans cet exemple, la fonction peanoPlus prend en arguments deux termes t1 et t2 de type Nat repr´ esentant deux entiers de Peano, et retourne la somme des deux. Le calcul est op´ er´ e par filtrage en utilisant la construction %match :

— elle prend un ou plusieurs arguments — deux dans notre exemple — entre parenth` eses ;

— elle est compos´ ee d’un ensemble de r` egles de la forme membre gauche -> {membre droit} ;

— le membre gauche est compos´ e du ou des motifs s´ epar´ es les uns des autres par une virgule ;

— le membre droit est un bloc de code mixte (hˆ ote + Tom).

Dans notre exemple, le calcul de filtrage est le suivant :

— si zero() filtre t2, alors le r´ esultat de l’´ evaluation de la fonction peanoPlus est x, instanci´ e par t1 par filtrage ;

— si suc(y) filtre t2, alors le symbole de tˆ ete du terme t2 est suc. Le sous-terme y est ajout´ e ` a x et le r´ esultat de l’´ evaluation de peanoPlus est donc suc(peanoPlus(x,y)).

L’expression de la fonction peanoPlus est donn´ ee par filtrage et d´ efinit une fonction Java qui peut ˆ etre utilis´ ee comme toute autre fonction Java dans le programme. Notons cette particularit´ e qu’a le langage Tom de compl` etement s’int´ egrer au langage hˆ ote sans pour autant ˆ

etre intrusif. Ainsi, le compilateur Tom n’analyse que le code Tom (parties gris´ ees dans le listing 1.2), les instructions hˆ otes n’´ etant pas examin´ ees et ne fournissant aucune information au compilateur. Les instructions Tom sont traduites vers le langage hˆ ote et remplac´ ees en lieu et place, sans modification du code hˆ ote existant.

Une deuxi` eme particularit´ e des constructions de filtrage du langage Tom est li´ ee ` a la composition des membres droits des r` egles : plutˆ ot qu’ˆ etre de simples termes, il s’agit en fait d’instructions du langage hˆ ote qui sont ex´ ecut´ ees lorsqu’un filtre est trouv´ e. Si aucune instruction du langage hˆ ote ne rompt le flot de contrˆ ole, toutes les r` egles peuvent potentiel- lement ˆ etre ex´ ecut´ ees. Pour interrompre ce flot lorsqu’un filtre est trouv´ e, il faut utiliser les instructions ad-hoc du langage hˆ ote, telles que break ou return, comme dans le listing 1.2.

Filtrage associatif. Dans le cas d’un filtrage non unitaire (filtrage pour lequel il existe plusieurs solutions, voir 1.1.2), l’action est ex´ ecut´ ee pour chaque filtre solution. Le filtrage syntaxique ´ etant unitaire, il n’est pas possible d’exprimer ce comportement. Le langage Tom dispose de la possibilit´ e d’op´ erer du filtrage associatif avec ´ el´ ement neutre (ou filtrage de liste, not´ e AU dans la section 1.1.2) qui n’est pas unitaire et qui permet d’exprimer ais´ ement des algorithmes op´ erant du filtrage sur des listes. Il est ainsi possible de d´ efinir des op´ erateurs variadiques (op´ erateurs d’arit´ e variable, par exemple les op´ erateurs de listes), comme nous l’avons vu dans la section pr´ ec´ edente (1.1.2). Dans le listing 1.3 suivant, nous reprenons notre exemple des entiers de Peano que nous augmentons d’un nouveau constructeur, concNat de sorte NatList et dont les sous-termes sont de type Nat.

1

module Peano

2

abstract syntax

4

Nat = zero()

5

| suc(n:Nat)

7

NatList = concNat(Nat*)

Listing 1.3 – Signature alg´ ebrique Gom avec op´ erateur variadique pour les entiers de Peano.

L’op´ erateur concNat peut ˆ etre vu comme un op´ erateur de concat´ enation de listes de Nat : concNat() repr´ esente la liste vide d’entiers naturels, concNat(zero()) la liste ne contenant que zero() et concNat(zero(),suc(zero()),suc(suc(zero()))) la liste contenant trois entiers naturels : 0, 1 et 2. La liste vide est l’´ el´ ement neutre. Tom distingue syntaxiquement les variables de filtrage repr´ esentant un ´ el´ ement — par exemple x dans le listing 1.2 — et les variables repr´ esentant une sous-liste d’une liste existante en ajoutant le caract` ere *.

Le filtrage associatif permet d’op´ erer une it´ eration sur les ´ el´ ements d’une liste comme l’illustre l’exemple du listing 1.4 :

1

public void afficher(NatList liste) {

2

int i = 0;

3

%match(liste) {

4

concNat(X1*,x,X2*) -> {

5

i = ‘X1.length();

1.2. Le langage Tom 17

6

System.out.println("liste("+i+") = " + ‘x);

7

}

8

}

9

}

Listing 1.4 – Filtrage associatif.

Dans cet exemple, liste est une liste d’entiers naturels, de type NatList impl´ ement´ e par le type Java NatList. Nous souhaitons afficher ces entiers avec leur position dans la liste.

L’action est ex´ ecut´ ee pour chaque filtre trouv´ e, et les variables de listes X1* et X2* sont ins- tanci´ ees pour chaque sous-liste pr´ efixe et suffixe de la liste liste. X1 correspond ` a un objet Java de type NatList, la m´ ethode length() retournant la longueur de la liste peut donc ˆ etre utilis´ ee pour obtenir l’indice de l’´ el´ ement x. L’´ enum´ eration s’op` ere tant que le flot d’ex´ ecution n’est pas interrompu. Dans notre exemple, nous nous contentons d’afficher l’´ el´ ement et sa po- sition. L’ex´ ecution de la proc´ edure afficher sur l’entr´ ee liste = ‘conc(zero(), zero(), suc(suc(zero())), zero()) donne :

liste(0) = zero() liste(1) = zero()

liste(2) = suc(suc(zero())) liste(3) = zero()

Le langage Tom offre aussi la possibilit´ e de proc´ eder ` a du filtrage non-lin´ eaire (motifs pour lesquels une mˆ eme variable apparaˆıt plusieurs fois). Le listing 1.5 ci-apr` es illustre ce m´ ecanisme : dans la fonction supprimerDoublon, la variable x apparaˆıt ` a plusieurs reprises dans le motif.

1

public NatList supprimerDoublon(NatList liste) {

2

%match(liste) {

3

concNat(X1*,x,X2*,x,X3*) -> {

4

return ‘supprimerDoublon(concNat(X1*,x,X2*,X3*));

5

}

6

}

7

return liste;

8

}

Listing 1.5 – Filtrage associatif non lin´ eaire.

Parmi les notations disponibles dans le langage, certaines sont tr` es couramment utilis´ ees et apparaˆıtront dans les extraits de code de ce document. Nous les illustrons dans le listing 1.6 dont le but est d’afficher un sous-terme de la liste liste ayant la forme suc(suc(y)), ainsi que sa position dans la liste, s’il existe :

1

public void chercher(NatList liste) {

2

%match(liste) {

3

concNat(X1*,x@suc(suc(_)),_*) -> {

4

System.out.println(‘x + " trouv´ e, en position " + ‘X1.length());

5

}

6

}

7

}

Listing 1.6 – Notations : alias et variable anonyme.

Les notations _ et _* pour les sous-listes d´ esignent des variables dites anonymes : c’est-` a-

dire que leur valeur ne peut ˆ etre utilis´ ee dans le bloc action de la r` egle. La notation @ permet

de cr´ eer des alias : ainsi, on peut nommer des sous-termes obtenus par filtrage. L’alias permet

de v´ erifier qu’un motif filtre — suc(suc(_)) dans notre exemple — tout en instanciant

une variable — x — avec la valeur de ce sous-terme. Si on applique la proc´ edure chercher

`

a l’entr´ ee pr´ ec´ edente d´ efinie comme liste = ‘conc(zero(), zero(), suc(suc(zero())), zero()), on obtient le r´ esultat suivant :

suc(suc(zero())) trouv´ e, en position 2

1.2.4 Notations implicite et explicite

Lorsque l’on ´ ecrit un pattern dans le membre gauche d’une r` egle, il est possible d’´ ecrire l’op´ erateur et ses champs de deux mani` eres. Ces derniers ´ etant nomm´ es, plutˆ ot qu’´ ecrire l’op´ erateur avec tous ses arguments (notation explicite ), on peut utiliser leurs noms dans le motif pour expliciter des sous-termes particuliers et en omettre d’autres. Ces derniers sont alors ignor´ es lors du filtrage. Cette notation est dite implicite et s’utilise via les lex` emes [ et ]. Il existe ´ egalement une notation ` a base de contraintes qui peut rendre l’´ ecriture implicite plus naturelle dans certains cas.

Consid´ erons un exemple simple pour illustrer ces deux notations : si on d´ efinit les personnes comme des termes construits en utilisant l’op´ erateur Personne, d’arit´ e 3 et de type Personne, ayant les arguments nomm´ es nom et prenom de type « chaˆıne de caract` eres », et age de type entier, les trois fonctions suivantes du listing 1.7 sont ´ equivalentes :

1

%gom() {

2

module Contacts

3

abstract syntax

4

Personne = Personne(nom:String, prenom:String, age:int)

5

}

6

7

public boolean peutConduireExplicite(Personne p) {

8

%match(p) {

9

Personne(_,_,a) -> { return (‘a>18); }

10

}

11

}

12

13

public boolean peutConduireImplicite(Personne p) {

14

%match(p) {

15

Personne[age=a] -> { return (‘a>18); }

16

}

17

}

18

19

public boolean peutConduireImplicite2(Personne p) {

20

%match(p) {

21

Personne[age=a] && a>18 -> { return true; }

22

}

23

return false;

24

}

Listing 1.7 – Illustration des notations explicite et implicite.

Outre l’ind´ eniable gain en lisibilit´ e du code qu’elle apporte de par l’utilisation des noms,

la notation implicite am´ eliore la maintenabilit´ e du logiciel d´ evelopp´ e. En effet, dans le cas

d’une extension de la signature (ajout d’un champ numTelephone, par exemple), l’usage de

la notation explicite impose d’ajouter un _ dans toutes les r` egles o` u l’op´ erateur Personne est

utilis´ e. Dans notre exemple, la premi` ere fonction — peutConduireExplicite() — devrait

donc ˆ etre modifi´ ee, contrairement aux deux autres — peutConduireImplicite() et peut-

ConduireImplicite2(). Avec cette notation, seuls les motifs manipulant explicitement les

champs ayant ´ et´ e chang´ es doivent ˆ etre modifi´ es, d’o` u une plus grande robustesse au change-

ment.