Guider et contrôler les reconfigurations de systèmes à composants

(1)

HAL Id: tel-01967676

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

Submitted on 1 Jan 2019

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.

Jean-François Weber

To cite this version:

Jean-François Weber. Guider et contrôler les reconfigurations de systèmes à composants : Reconfig-urations dynamiques: modélisation formelle et validation automatique. Modélisation et simulation. Université de Franche-Comté (UFC), 2017. Français. �NNT : 2017UBFCD068�. �tel-01967676�

(2)

Thèse de Doctorat

é c o l e d o c t o r a l e s c i e n c e s p o u r l ’ i n g é n i e u r e t m i c r o t e c h n i q u e s

U N I V E R S I T É D E F R A N C H E - C O M T É

n

Guider et contr ˆoler les

reconfigurations de syst `emes `a

composants

Reconfigurations dynamiques: mod ´elisation formelle et

validation automatique

(3)

(4)

Thèse de Doctorat

é c o l e d o c t o r a l e s c i e n c e s p o u r l ’ i n g é n i e u r e t m i c r o t e c h n i q u e s

U N I V E R S I T É D E F R A N C H E - C O M T É

TH `

ESE pr ´esent ´ee par

J

EAN

-F

RANC

¸

OIS

WEBER

pour obtenir le

Grade de Docteur de

l’Universit ´e de Franche-Comt ´e

Sp ´ecialit ´e :Informatique

Guider et contr ˆoler les reconfigurations de syst `emes

`a composants

Reconfigurations dynamiques: mod ´elisation formelle et validation

automatique

Unit ´e de Recherche :

D ´epartement d’Informatique des Syst `emes Complexes (DISC)

Soutenue publiquement le 5 octobre 2017 devant le Jury compos ´e de :

GWEN SALAUN¨ Pr ´esident Professeur HDR au LIG, Universit ´e Grenoble Alpes

R ´EGINE LALEAU Rapporteur Professeur HDR au LACL, Universit ´e Paris-Est

Cr ´eteil

PHILIPPEMERLE Rapporteur Charg ´e de recherche HDR, Inria Lille Nord

Europe

OLGAKOUCHNARENKO Directeur de th `ese Professeur HDR au DISC, Universit ´e de

Bourgogne Franche-Comt ´e

FRED´ ERIC´ DADEAU Examinateur Maˆıtre de conf ´erence au DISC, Universit ´e de

Bourgogne Franche-Comt ´e

(5)

(6)

R

EMERCIEMENTS

Avant tout, je tiens à remercier tous les membres du jury qui ont accept é d’ évaluer mon travail. Merci à Gwen Sala ün d’avoir pr ésid é ce jury de th èse. Merci également à R égine Laleau et Philippe Merle pour m’avoir fait l’honneur de rapporter cette th èse.

Je voudrais remercier tout sp écialement Olga Kouchnarenko de m’avoir fait confiance pour mener à bien ce travail de th èse malgr é le fait que j’ai une activit é professionnelle à plein temps. Olga Kouchnarenko a ét é disponible au del à de mes attentes les plus optimistes ; en semaine et le week-end, le jour et la nuit, en cours d’ann ée universitaire et durant les vacances.

Je souhaite aussi remercier Jacques Julliand qui m’a sugg ér é de m’orienter vers un doc-torat au moment o ù je pensais avoir d éj à manqu é cette opportunit é, Pierre-Cyrille H éam et Fr éd éric Dadeau pour leur soutien, ainsi que Jean-Michel Hufflen pour l’aide spontan ée qu’il m’a propos ée à plusieurs reprises, sans oublier Julien Bourgeois, Benoˆıt Piranda, Julien Dormoy, Abderrahim Ait Wakrime et Hadrien Bride.

Un (autre) grand merci à Philippe Merle sans qui l’int égration de FraSCAti dans notre impl émentation n’aurait jamais pu avoir lieu (en tout cas, en si peu de temps) ; il a su trouver la disponibilit é pour m’assister dans cette t âche malgr é son agenda charg é. Merci aussi à Brigitte Bataillard et Dominique M én étrier qui ont toujours su me guider et m’assister dans le monde obscur des formalit és administratives, à Oscar Carrillo et Hassan Mountasir pour l’organisation des TP Fractal et à Laurent Steck pour son support technique.

Je remercie les étudiants dont j’ai suivi le travail avec Olga Kouchnarenko : Gr égori Tirsa-tine pour son travail sur les parseurs d’expressions de logique temporelle, Alexis Picard et Nicolas Lemasson pour leur travail sur l’interface graphique de notre impl émentation, Cl ément Hosotte et Florian Facchini pour leur projet de Master 2 concernant les recon-figurations dynamiques, Sonia Cr étin et Mathieu Robert pour le brouillage des traces d’adaptation et Martin B érenger pour le projet de grammaires de graphes pour syst èmes reconfigurables.

Enfin, je remercie Philippe Lutz de l’ ´Ecole Doctorale SPIM ainsi qu’Alexandrine Vieillard, S ´ebastien Pasteur et Samuel Gaston Amet pour leur bienveillance et leur aide.

(7)

(8)

S

OMMAIRE

Remerciements v

Sommaire vii

Introduction 1

Contexte scientifique . . . 2

Composants logiciels et syst `emes `a composants . . . 2

V érification des syst èmes à composants . . . 4

Politiques d’adaptation et test de syst `emes `a composants . . . 5

Probl ´ematiques et contributions . . . 6

Probl ´ematiques . . . 6

Contributions . . . 8

Organisation . . . 9

Partie I : Contexte scientifique et pr ´eliminaires . . . 10

Partie II : Mod ´elisation des reconfigurations dynamiques . . . 11

Partie III : V ´erification et test des reconfigurations dynamiques . . . 11

Partie IV : Validation exp ´erimentale . . . 12

Conclusion et perspectives . . . 13

Publications . . . 13

I Contexte scientifique et pr éliminaires 15 1 Les syst èmes à composants 17 1.1 Architectures orient ées composants . . . 18

1.1.1 Le concept de composant . . . 18

1.1.2 Architectures logicielles bas ´ees sur les composants . . . 20

1.1.2.1 Composants primitifs et composites . . . 21

1.1.2.2 Interfaces . . . 21

1.1.2.3 Assemblages de composants . . . 22

(9)

1.1.3 Quelques approches de mod `eles `a composants . . . 23

1.2 Modification dynamique des syst `emes `a composants . . . 25

1.2.1 Reconfigurations dynamiques . . . 25

1.2.2 Syst `emes r ´eflexifs et adaptatifs . . . 26

1.2.3 Boucle de contr ˆole et boucle MAPE . . . 27

1.3 Le mod `ele `a composants Fractal . . . 29

1.3.1 Composants Fractal . . . 29

1.3.2 Impl ´ementations . . . 31

1.4 Le mod `ele `a composants FraSCAti . . . 31

1.4.1 La sp ´ecification SCA . . . 32

1.4.2 L’impl ´ementation de SCA par FraSCAti . . . 32

1.4.3 Comparaison avec d’autres impl ´ementations de SCA . . . 34

1.5 Conclusion . . . 34

2 Pr ´eliminaires 35 2.1 Ensembles, relations et fonctions . . . 35

2.1.1 Ensembles . . . 35

2.1.2 Relations et fonctions . . . 36

2.2 Syst `emes de transitions . . . 38

2.3 Sp écification des propri ét és des syst èmes . . . 41

2.3.1 Propri ´et ´es d’invariance . . . 41

2.3.2 Logique du premier ordre . . . 42

2.3.2.1 Syntaxe . . . 42

2.3.2.2 S ´emantique . . . 44

2.3.3 Logiques temporelles . . . 45

II Mod ´elisation des reconfigurations dynamiques 49 3 Mod ´elisation 51 3.1 Le composantLocation . . . 51

3.1.1 Les syst `emes de g ´eolocalisation . . . 52

3.1.2 Pr ´esentation du Cycab . . . 52

3.1.3 Le composant compositeLocation . . . 53

3.2 S ´emantique op ´erationnelle . . . 55

(10)

SOMMAIRE ix

3.2.1.1 El ´ements Architecturaux . . . 56´

3.2.1.2 Relations architecturales . . . 57

3.2.1.3 Simplifications possibles . . . 60

3.2.2 S ´emantique des reconfigurations . . . 62

3.2.2.1 Reconfigurations et op ´erations d’ ´evolution . . . 62

3.2.2.2 Propri ´et ´es de configuration . . . 64

3.2.2.3 Syst `eme `a composants reconfigurable primitif . . . 65

3.3 Syst `eme `a composants reconfigurable . . . 68

4 Reconfigurations gard ´ees 71 4.1 Contraintes de consistance . . . 71

4.2 Reconfigurations gard ´ees . . . 74

4.3 Propagation de consistance . . . 75

4.4 Mod èle d’architecture interpr ét ée . . . 76

4.4.1 Configurations et reconfigurations interpr ´et ´ees . . . 76

4.4.2 Interpr ´etation compatible . . . 77

4.4.3 Pr éservation des propri ét és . . . 79

5 Propri ´et ´es temporelles 81 5.1 Syntaxe de la logique FTPL . . . 81

5.2 S ´emantique de la logique FTPL . . . 83

5.2.1 Domaine de v ´erit ´e . . . 83

5.2.2 S ´emantique . . . 84

5.2.2.1 Les propri ´et ´es de configuration . . . 84

5.2.2.2 Les ´ev ´enements . . . 84

5.2.2.3 Les propri ´et ´es de trace . . . 85

5.2.2.4 Les propri ´et ´es temporelles . . . 86

5.3 Satisfaction d’une propri ´et ´e FTPL . . . 86

III V érification et test des reconfigurations dynamiques 89 6 Evaluation de propri ét és temporelles à l’ex écution´ 91 6.1 Evaluation à l’ex écution de traces incompl ètes . . . 92´

(11)

6.1.1 V érification de propri ét és à l’ex écution . . . 92

6.1.1.1 Concept de l’ évaluation à l’ex écution . . . 92

6.1.1.2 Enforcement et r éflexion à l’ex écution . . . 93

6.1.1.3 Domaine de v ´erit ´e . . . 94

6.1.2 S émantique pour l’ évaluation de propri ét és FTPL à l’ex écution . . . 95

6.1.2.1 Propri ´et ´es de configuration . . . 95

6.1.2.2 Ev ´enements . . . 95´

6.1.2.3 Propri ´et ´es de trace . . . 96

6.1.2.4 Propri ´et ´es temporelles . . . 97

6.2 Evaluation progressive de propri ´et ´es FTPL . . . 99´

6.2.1 Notations . . . 99

6.2.2 Propri ´et ´es de traces . . . 100

6.2.3 Listes d’ ´ev ´enements . . . 101

6.2.4 Propri ´et ´es temporelles . . . 101

7 Evaluation d écentralis ée à l’ex écution´ 105 7.1 Conventions utilis ées pour l’ évaluation d écentralis ée . . . 105

7.2 Progression et urgence d’expressions FTPL . . . 106

7.2.1 Progression d’expressions FTPL . . . 107

7.2.2 Forme de progression normalis ´ee et urgence . . . 110

7.3 Probl ème de l’ évaluation d écentralis ée . . . 111

7.3.1 Algorithme d’ évaluation d écentralis ée . . . 112

7.3.2 R ´esultats de correction et de terminaison . . . 114

8 Politiques d’adaptation 119 8.1 Int ´egration de FTPL dans des politiques d’adaptation . . . 120

8.1.1 D ´efinition des politiques d’adaptation . . . 121

8.1.2 Restriction par politiques d’adaptation . . . 123

8.2 Application des politiques d’adaptation `a l’ex ´ecution . . . 124

8.2.1 Probl `eme de l’adaptation . . . 124

8.2.2 L’algorithme AdaptEnfor . . . 125

8.2.3 Correction de l’adaptation . . . 128

8.3 Usage du fuzzing pour le test de politiques d’adaptation . . . 131

(12)

SOMMAIRE xi

8.3.2 Mise en place et utilisation . . . 131

IV Validation exp ´erimentale 135 9 Structure logicielle 137 9.1 Impl ´ementation . . . 137

9.1.1 Description de notre impl ´ementation . . . 138

9.1.2 Interactions entre les entit ´es de notre impl ´ementation . . . 139

9.1.3 Fonctionnement des contr ˆoleurs de notre impl ´ementation . . . 140

9.1.4 Conformit ´e architecturale . . . 143

9.2 Fichiers de log et interface graphique . . . 144

9.2.1 Fichier de log du contr ˆoleur de politiques d’adaptation (APC) . . . . 144

9.2.2 Interface graphique . . . 145

9.3 Impl ´ementation du fuzzing . . . 147

10 Exp ´erimentations 151 10.1 Application de politiques d’adaptation . . . 152

10.1.1 Description du comportement attendu . . . 152

10.1.2 Ex ´ecution . . . 155

10.1.3 R ´esultats obtenus . . . 156

10.2 Autres cas d’ ´etudes . . . 157

10.2.1 Machines virtuelles et environnement cloud . . . 158

10.2.2 Serveur HTTP . . . 159

10.3 Utilisation de grammaires de graphes . . . 161

10.3.1 Impl ´ementation sous GROOVE . . . 161

10.3.2 Le composantvirtualMachine repr ´esent ´e sous GROOVE . . . 163

10.4 Évaluation d écentralis ée simul ée sous GROOVE . . . 165

10.4.1 Repr ésentation des propri ét és FTPL sous GROOVE . . . 166

10.4.2 Simulation de l’ évaluation d écentralis é . . . 167

(13)

Conclusion et perspectives 175

Synth `ese et bilan . . . 175

Mod ´elisation des reconfigurations dynamiques . . . 175

V ´erification et contr ˆole des reconfigurations dynamiques . . . 176

Contributions pratiques . . . 176

Perspectives . . . 177

´ Evaluation d ´ecentralis ´ee et politiques d’adaptation . . . 177

Impl ´ementation . . . 178

Passage `a l’ ´echelle et test . . . 179

Syst `emes cyber-physiques et microm ´ecatroniques . . . 179

Bibliographie 181 Table des figures 191 Liste des tables 195 Liste des d éfinitions 197 Liste des th éor èmes 201 Liste des corolaires 203 Liste des propositions 205 Liste des exemples 207 V Annexes 209 A S émantique des reconfigurations primitives 211 A.1 Notations et conventions . . . 211

(14)

SOMMAIRE xiii

A.2 S ´emantique des op ´erations primitives . . . 213

A.2.1 S ´emantique de l’op ´eration primitive new . . . 213

A.2.2 S ´emantique de l’op ´eration primitive destroy . . . 214

A.2.3 S ´emantique de l’op ´eration primitive add . . . 215

A.2.4 S ´emantique de l’op ´eration primitive remove . . . 215

A.2.5 S ´emantique de l’op ´eration primitive start . . . 218

A.2.6 S ´emantique de l’op ´eration primitive stop . . . 219

A.2.7 S ´emantique de l’op ´eration primitive bind . . . 219

A.2.8 S ´emantique de l’op ´eration primitive unbind . . . 220

A.2.9 S ´emantique de l’op ´eration primitive update . . . 221

B Pr ´eservation de la consistance 223 B.1 Op ´eration primitive new . . . 224

B.2 Op ´eration primitive add . . . 224

B.2.1 Pr ´eservation de (CC.2) par add. . . 224

B.3 Op ´eration primitive remove . . . 228

B.3.1 Pr ´eservation de (CC.2) par remove. . . 228

B.4 Op ´eration primitive bind . . . 235

B.4.1 Pr ´eservation de (CC.5) par bind. . . 236

B.4.4 Pr ´eservation de (CC.8) et (CC.9) par bind. . . 237

(15)

(16)

I

NTRODUCTION

D

ans le monde actuel, les syst èmes embarqu és traditionnels sont de plus en plus rem-plac és par des syst èmes cyber-physiques, ou CPS (Cyber-Physical Systems). Intuiti-vement, de tels syst èmes peuvent être vus comme des r éseaux de syst èmes embarqu és o ù un grand nombre de composants logiciels sont d éploy és au sein d’environnements physiques [Du et al., 2016, Lee, 2008]. Comme leurs environnements sont susceptibles de changer, ces syst èmes doivent pouvoir évoluer au cours du temps tout en continuant à fonctionner correctement. Bien s ûr, ces évolutions doivent permettre aux syst èmes de s’am éliorer (d’un point de vue quantitatif et/ou qualitatif) ou, tout du moins, de minimiser d’ éventuelles d égradations. Il est donc n écessaire de pouvoir v érifier ces syst èmes du-rant leurs ex écutions afin de guider au mieux leurs évolutions pour qu’ils puissent rester adapt és à leurs environnements.

Les syst èmes à composants sont constitu és d’un ensemble de “briques de base” (i.e., des composants) pouvant être assembl ées pour construire des applications. Ces syst èmes peuvent être modifi és (e.g., ajout ou suppression de composants) au moyen de reconfi-gurations, dites dynamiques, sans devoir être arr êt és ou cesser de fonctionner. Lorsque de telles reconfigurations sont effectu ées dans le but de permettre au syst ème concern é de s’adapter à son environnement, on parle d’adaptation.

Dans le cadre de l’adaptation des syst èmes à composants, les reconfigurations dyna-miques ne peuvent pas être effectu ées à n’importe quel moment ou de n’importe quelle façon. La fiabilit é de ces reconfigurations doit permettre de garantir qu’elles soient ef-fectu ées comme pr évu ou bien pr évoir un m écanisme de retour en arri ère (rollback) en cas de probl ème. De plus, certaines propri ét és de s ûret é doivent être maintenues malgr é l’application de reconfigurations dynamiques ; par exemple, on n’imagine pas que le syst ème de navigation d’un avion puisse cesser de fonctionner suite à l’application d’une reconfiguration dynamique. La s écurit é doit aussi être prise en compte dans le cadre des reconfigurations dynamiques afin qu’elles ne puissent être effectu ées que par les entit és autoris ées à les appliquer. En outre, dans le contexte actuel de consommation d’ énergie responsable, les reconfigurations dynamiques peuvent permettre d’ économiser de l’ énergie en retirant des composants non n écessaires au fonctionnement du syst ème. Ces composants pourraient bien s ûr être rajout és dynamiquement s’ils s’av éraient à nouveau n écessaires. Enfin, ces reconfigurations doivent aussi être appliqu ées dans le respect des usagers ; si des passagers sont pr ésents dans un v éhicule autonome, la temp érature int érieure devrait être maintenue à un niveau confortable m ême si cela consomme de l’ énergie.

L’adaptation des syst èmes à composants via l’application de reconfigurations dyna-miques se doit donc de respecter des propri ét és de s ûret é, d’ être fiable et s écuris ée tout en respectant l’environnent et les usagers. C’est pourquoi nous nous int éressons au guidage et au contr ôle des reconfigurations des syst èmes à composants dans leur évolution au sein de leur environnement. Nous devons aussi d éterminer comment v érifier les propri ét és de tels syst èmes lors de leurs reconfigurations et trouver les moyens de

(17)

tester les m écanismes de l’adaptation et les reconfigurations dynamiques. La v érification à l’ex écution est une technique utilis ée pour s’assurer de la correction du comportement d’un syst ème au cours de son ex écution. Il est aussi envisageable d’utiliser cette tech-nique pour valider la satisfaction de certaines propri ét és du syst ème. Ainsi, en fonction de l’ évaluation de ces propri ét és, il est possible de d éterminer comment guider l’ évolution d’un syst ème pour contr ôler son adaptation vis- à-vis de son environnement. Ce concept de l’adaptation est au cœur de nos travaux sur les syst èmes à composants. Nous allons d’abord établir le contexte scientifique, les concepts et les id ées qui vont nous permettre, dans un second temps, d’exposer nos probl ématiques et contributions. Ensuite, nous d étaillerons l’organisation de ce m émoire en pr ésentant le contenu de chaque chapitre. Enfin, nous indiquerons o ù nos diverses contributions ont ét é publi ées.

C

ONTEXTE SCIENTIFIQUE

Dans cette section, nous introduisons les concepts et id ées qui nous permettrons de pouvoir exposer les probl ématiques li ées au travail pr ésent é dans ce document. Plu-sieurs concepts se sont succ éd és, au cours des derni ères d écennies, pour la conception et le d éveloppement d’applications. Les langages machines, tr ès performants mais ne permettant pas de s éparer le d éveloppement en diverses unit és r é-utilisables, ont ét é d élaiss és au profit des langages proc éduraux, puis des langages objets, qui autorisent une plus grande modularit é et une r éutilisation du code. Comme il est difficile de mettre en évidence les liens entre les diff érents objets au sein d’une application lorsque leur nombre devient important, les architectures logicielles à base de composants sont de plus en plus pr éf ér ées aux approches purement objet.

Les syst èmes à composants sont des syst èmes modulaires compos és de divers compo-sants pouvant êtres assembl és pour former des applications. On peut faire évoluer de tels syst èmes via des op érations de reconfiguration permettant, par exemple, de supprimer ou d’ajouter un composant. Lorsque ces op érations de reconfiguration peuvent être ef-fectu ées sans avoir à arr êter le syst ème, on parle de reconfigurations dynamiques. Ainsi, il est possible de modifier les syst èmes à composants en cours d’ex écution afin de leur permettre de s’adapter à leur environnement.

De telles adaptations sont d étermin ées par des r ègles, regroup ées en politiques, ayant la possibilit é de v érifier des propri ét és du syst ème durant sont ex écution afin de pou-voir juger de la pertinence des actions à effectuer. Ces politiques d’adaptation peuvent s’av érer complexes à mettre en place, c’est pourquoi il est vital de pouvoir les tester. Nous commençons par nous int éresser aux id ées de composants logiciels et de syst èmes à composants, puis nous explicitons le concept de v érification pour ces syst èmes. En-fin, nous pr ésentons les notions de politique d’adaptation et de test dans le cadre des syst èmes à composants.

COMPOSANTS LOGICIELS ET SYSTEMES` A COMPOSANTS`

Un composant est g én éralement d écrit comme un él ément, d’une structure plus com-plexe, pouvant être int égr é dans diff érentes applications. Afin qu’ils soient utilisables, les composants doivent exposer les fonctionnalit és qu’ils fournissent mais aussi les fonction-nalit és dont ils ont besoin pour s’ex écuter.

(18)

CONTEXTE SCIENTIFIQUE 3

Les concepts de modularit é et de r é-utilisabilit é permettent de structurer et de faciliter le d éveloppement d’applications bas ées sur les composants. La modularit é permet d’ex-traire les diff érentes fonctionnalit és n écessaires à la construction d’une application et de chacune les encapsuler au sein de briques logicielles. Celles-ci peuvent alors être as-sembl ées pour construire l’application d ésir ée. Le concept de r é-utilisabilit é permet de pouvoir utiliser la m ême brique dans diff érentes applications.

On peut distinguer les composants primitifs qui encapsulent du code m étier et les compo-sants composites qui contiennent des sous-compocompo-sants (primitifs ou composites). Ainsi, plusieurs composants peuvent être assembl és et li és au moyen de liens logiques pour former un syst ème à composants. Un tel assemblage repr ésente une configuration du syst ème à composants. Intuitivement, si cette configuration correspond à un assemblage de composants capable de s’interconnecter entres-eux et de fonctionner sans erreur, on dit qu’elle est consistante.

Un syst ème à composants peut évoluer d’une configuration à une autre au moyen d’op érations de reconfiguration, comme l’ajout ou la suppression d’un composant ou d’un lien entre deux composants. Cependant, l’application d’une reconfiguration à une configuration donn ée ne garantit pas que la configuration r ésultante sera consistante. Consid érons un ensemble de configurations et un ensemble de reconfigurations permettant d’ évoluer d’une configuration à une autre. On peut ainsi, comme dans [Dormoy, 2011], d éfinir un mod èle de syst ème à composants comme l’ensemble des s équences de configurations pouvant d ébuter par une configuration choisie dans un ensemble de configurations initiales pour évoluer de configuration en configuration au moyen des reconfigurations qu’il est possible d’effectuer.

Fractal [Bruneton et al., 2004, Bruneton et al., 2006] et FraSCAti [Seinturier et al., 2009, Seinturier et al., 2012] sont des mod èles à composants supportant l’utilisation de recon-figurations dynamiques, qui permettent de reconfigurer un syst ème à composants durant son ex écution.

Dans le cadre du d éveloppement classique utilisant la programmation objet, les choix concernant l’architecture d’une application sont fait au moment de la conception. Le fait de pouvoir utiliser des reconfigurations dynamiques pour pouvoir modifier (sans avoir à le stopper) un syst ème durant son ex écution permet de diff érer de tels choix au moment de l’ex écution. Ainsi, il est possible de faire aussi évoluer le syst ème pour qu’il reste adapt é

`a son environnement lorsque celui-ci ´evolue.

De telles possibilit és posent de nouveaux probl èmes auxquels nous nous efforcerons de r épondre dans ce m émoire de th èse :

— Quelle(s) reconfiguration(s) effectuer et `a quel moment ?

— Comment d éterminer lorsque le syst ème n’est plus (suffisamment) adapt é à son environnement ?

— Comment s’assurer que l’application de reconfiguration(s) ne va pas nuire au bon fonctionnement du syst `eme ?

(19)

V ´ERIFICATION DES SYSTEMES` A COMPOSANTS`

Le but de la v érification d’un syst ème est de s’assurer que sa sp écification v érifie les pro-pri ét és qu’il doit respecter. Il est donc possible de proc éder à la v érification d’un syst ème avant qu’il ne soit impl ément é car la v érification est effectu ée en utilisant seulement une sp écification. Deux approches formelles de v érification peuvent être distingu ées : la v érification algorithmique (model-checking) et la vérification par preuve (theorem pro-ving). Le model-checking consiste à explorer de manière exhaustive l’ensemble des états du syst ème, afin de s’assurer que celui-ci satisfait une certaine propri ét é. Le principe de la v érification par preuve consiste à prouver math ématiquement la validit é d’un ensemble de formules (nomm ées obligations de preuve) engendr ées par une sp écification formelle d écrivant le syst ème et ses propri ét és. Ces deux approches peuvent être combin ées comme c’est le cas dans [Lanoix et al., 2011].

Dans le cadre du model-checking appliqué au modèle à composants Frac-tal [Bruneton et al., 2006], les travaux de [Merle et al., 2008, Tiberghien et al., 2010] ont permis de repr ésenter ce mod èle de façon à pouvoir utiliser Al-loy [Jackson, 2012], un logiciel de checking (ou checker). Le model-checker CADP1 _{[Garavel et al., 2007, Garavel et al., 2011, Garavel et al., 2013] a}

pu aussi être utilis é pour v érifier des syst èmes à composants bas és sur Fractal dans [Barros et al., 2007]. Nous pouvons aussi citer les travaux [Simonot et al., 2008] qui utilisent Focal [Dubois et al., 2006] pour v érifier de tels syst èmes à composants. Ces approches utilisent les fonctionnalit és d’outils existants mais elles ne sont pas toutes bien adapt ées aux concepts de composants logiciels, c’est pourquoi d’autres approches donnent la possibilit é d’enrichir les sp écifications des composants avec des él éments et des concepts qui seront ensuite v érifi és. Nous pouvons citer ConFract [Collet et al., 2005, Collet et al., 2007] qui est une extension du mod èle à composants Fractal v érifiant des Pr é et Post-conditions [Hoare, 1969]. Le paradigme d’hypoth èses/garanties [Misra et al., 1981, Lamport, 1983] est utilis é pour effectuer la v érification compositionnelle des syst èmes à composants dans [Andrade et al., 2002]. Enfin, l’approche propos ée dans [Chouali et al., 2010] utilise des automates d’interfaces pour sp écifier des contrats au niveau comportemental.

Dans le cadre des syst èmes à composants supportant les reconfigurations dynamiques, les travaux propos és dans [David et al., 2009] d éfinissent une extension du mod èle à composants Fractal dans laquelle il est possible de sp écifier des invariants sur la structure du mod èle à composants. Cette approche v érifie que ces invariants architecturaux sont pr éserv és lors de l’ex écution des reconfigurations dynamiques.

Afin d’exprimer des contraintes architecturales et temporelles sur des syst èmes à com-posants, la logique FTPL a ét é introduite dans [Dormoy et al., 2012a]. Cette logique qui se base sur les travaux de Dwyers sur les sch émas de sp écification [Dwyer et al., 1999], permet d’ évaluer des propri ét és temporelles dans B2 (en utilisant les valeurs ‘faux” et

“vrai”) sur des traces d’ex écution. On notera que la structure composite des syst èmes à composants se pr ête à une approche d écentralis ée ; l’ évaluation d écentralis ée de for-mules LTL pr ésent ée dans [Bauer et al., 2012] en est un exemple.

La v érification à l’ex écution [Havelund et al., 2005, Bauer et al., 2010] est une tech-nique permettant de s’assurer de mani ère efficace de la satisfaction d’exigences par un syst ème lors de son ex écution. Ceci n écessite l’ évaluation de propri ét és à

(20)

CONTEXTE SCIENTIFIQUE 5

l’ex écution, ce qui implique de consid érer des traces d’ex écution incompl ètes. C’est le cas dans [Dormoy et al., 2011] o ù des propri ét és temporelles sont évalu ées dans B4, en

utilisant les valeurs ‘faux” et “vrai”, d’une part et “potentiellement faux” et “potentiellement vrai”, d’autre part, pour la potentielle (non) satisfaction d’une propri ´et ´e.

POLITIQUES D’ADAPTATION ET TEST DE SYSTEMES` A COMPOSANTS`

Dans le cadre des syst èmes à composants, les politiques d’adaptation peuvent être vues comme un ensemble de r ègles pouvant guider et contr ôler les reconfigurations dyna-miques. Pour un syst ème à composants donn é, ces r ègles contiennent des propri ét és concernant le syst ème et son environnement. En se basant, au cours de l’ex écution du syst ème, sur l’ évaluation de ces propri ét és on peut alors d éterminer comment le syst ème devrait évoluer. De telles r ègles peuvent s’av érer difficiles à élaborer dans la cas de syst èmes à composants de grandes tailles. C’est pourquoi il est n écessaire de pouvoir les tester.

Afin d’appr éhender des comportements du syst ème ne se limitant pas à un instant donn é, mais prenant en compte son évolution au cours du temps, l’usage d’une logique tempo-relle pour exprimer les propri ét és utilis ées par les politiques d’adaptation est un choix qui s’impose. Des informations sur l’environnement du syst ème peuvent être obtenues en utilisant des capteurs externes (du point de vue du syst ème) de façon à d étecter des changements. Ces changements de l’environnement correspondent à des év énements externes pouvant être pris en compte par les propri ét és utilis ées par les r ègles incluses dans les politiques d’adaptation. Un mod èle de syst ème à composants pouvant évoluer sur la base de politiques d’adaptation utilisant des sch émas temporels (bas és sur la lo-gique qMEDL [Gonnord et al., 2009]) prenant en compte des év énements externes a ét é introduit dans [Dormoy et al., 2010].

L’enforcement d’une propri ét é à l’ex écution [Schneider, 2000, Falcone et al., 2008, Ligatti et al., 2009, Delaval et al., 2010] consiste à utiliser la v érification des propri ét és à l’ex écution pour essayer d’anticiper l’apparition d’une ex écution non d ésir ée qui pour-rait rendre le syst ème d éfaillant. Cette approche est en fait une extension de l’approche de v érification à l’ex écution qui permet de r épondre au besoin de pr évenir et de corri-ger un comportement non-d ésir é. La r éflexion à l’ex écution [Bauer et al., 2008] est une approche utilisant aussi la v érification de propri ét és lors de l’ex écution du syst ème. Cette m éthode a non seulement pour but d’observer le comportement du syst ème mais aussi de donner un diagnostic de l’ex écution. Lorsque le diagnostic est assez d étaill é et non-ambig ü, celui-ci peut être utilis é pour faire r éagir le syst ème en ex écutant des commandes, telles que des reconfigurations dynamiques par exemple, pour r établir le syst ème dans un état bien d éfini. Ainsi, en compl ément des propri ét és utilis ées par les r ègles composant les politiques d’adaptation, on peut d éfinir d’autres propri ét és que l’on peut a) préserver par le mécanisme d’enforcement, ou b) utiliser, via la réflexion, pour d éclencher des actions correctrices lorsque ces propri ét és ne sont pas satisfaites. Lorsqu’on cherche à s’assurer que l’impl émentation d’un syst ème v érifie les propri ét és qu’il doit respecter en analysant un ensemble d’ex écutions pass ées, on parle de test plut ôt que de v érification. Les premiers travaux th éoriques sur le test logiciel datent des ann ées 1970 avec l’apparition des notions de tests “fiables” [Howden, 1976] (reliable) et “id éaux” [Goodenough et al., 1975] (ideal) qui permettent d’établir que le test ne peut que montrer la pr ésence d’erreur, mais jamais leur absence [Dijkstra, 1970].

(21)

Le concept d’hypoth èse de test, qui d éfinit les pr é-suppositions faites sur le syst ème à tester, a ét é formalis é dans [Bernot et al., 1991]. Le test de syst ème à compo-sants, qui a émerg é à la fin des ann ées 1990, permet de s’assurer que de nou-veaux assemblages de composants se comportent correctement dans leur nouvel en-vironnement [Weyuker, 1998]. En effet, bien que chaque composant ait pu être test é ind épendamment avec succ ès, leur combinaison peut engendrer des comportements impr évus.

D’apr ès [Bertolino, 2007], il subsiste deux d éfis à relever dans le cadre du test de syst ème à composants. Le premier est un d éfi technique qui consiste à trouver les moyens de pou-voir tester les composants au sein des diff érents contextes dans lesquels ils peuvent être d éploy és. Le second d éfi, plus th éorique, est de pouvoir obtenir davantage d’informa-tions sur les composants à tester que ce qui est propos é par les diff érents mod èles de syst èmes à composants. Ces informations additionnelles pourraient être utilis ées pour la g én ération de test. Il s’agirait, par exemple, de tests int égr és dans les composants eux-m êmes (built-in testing) ou de données permettant l’élaboration de tests pertinents.

P

ROBLEMATIQUES ET CONTRIBUTIONS

´

Dans cette section, nous pr ésentons les probl ématiques auxquelles nous souhaitons r épondre. Ensuite, nous d étaillons nos contributions en indiquant les probl ématiques adress ées.

PROBLEMATIQUES´

Le but du travail pr ésent é dans ce document est de pouvoir guider et contr ôler les syst èmes à composants dans leur évolution.

Le mod èle de syst ème à composants pr ésent é dans [L éger, 2009, L éger et al., 2010, Dormoy, 2011] peut évoluer d’une configuration à une autre au moyen d’op érations de reconfiguration pouvant être des s équences de reconfigurations primitives. De plus lors de l’ évolution vers une configuration donn ée, celle-ci peut ne pas être dans un état consis-tant. C’est pourquoi nous proposons la probl ématique suivante :

(1) “Définir un modèle permettant de garantir la consistance des configurations “cibles” sans se limiter à des reconfigurations définies comme des séquences de

reconfigurations primitives.”

La logique FTPL introduite dans [Dormoy et al., 2012a] permet d’exprimer des contraintes architecturales et temporelles des syst èmes à composants. Cette logique re-pose sur des sch émas de sp écifications [Dwyer et al., 1999] et permet d’exprimer des propri ét és en prenant en compte le d éclenchement des reconfigurations dynamiques g én ér ées par le syst ème. Ces propri ét és peuvent alors porter sur la pass é ou sur le futur de l’ex écution. La logique propos ée permet d’exprimer des exigences sur l’en-chainement des reconfigurations dynamiques d’un syst ème à composants qui doivent être v érifi ées pendant l’ex écution. Dans [Dormoy et al., 2011], des propri ét és temporelles sont évalu ées à l’ex écution de façon centralis ées. On notera que, souvent, l’ évaluation

(22)

PROBL ´EMATIQUES ET CONTRIBUTIONS 7

de propri ét és temporelles à l’ex écution n écessite de maintenir un long historique des in-formations concernant les évaluation pass ées car elles peuvent être n écessaires pour les évaluations futures. De plus, dans [Dormoy et al., 2010], des politiques d’adaptation utilisant des sch émas temporels (bas és sur la logique qMEDL) prennent en compte des év énements externes. Malheureusement, qMEDL ne permet pas d’exprimer de contraintes architecturales sur des syst èmes à composants. Il serait souhaitable d’avoir une seule et m ême logique pour d éfinir des politiques d’adaptation et exprimer des contraintes architecturales, c’est la raison pour laquelle nous proposons cette seconde probl ématique :

(2) “Choisir ou établir une logique temporelle prenant en compte des événements internes et externes afin d’exprimer des politiques d’adaptation et des contraintes architecturales ; évaluer, de façon centralisée ou décentralisée, les propriétés basées sur cette logique à l’exécution sur des traces incomplètes, sans avoir à maintenir un long

historique ; et intégrer ces propriétés dans des politiques d’adaptation.”

La probl ématique suivante concerne la mise en place d’une impl émentation du mod èle mentionn é ci-dessus :

(3) “Développer une application permettant de contrôler et guider les reconfigurations au moyen de politiques d’adaptation pour un système à composants

basé sur Fractal ou sur un autre modèle à composants ; et utiliser cette application sur différents cas d’étude.” Enfin, cette derni ère probl ématique concerne le test de notre mod èle :

(4) “Avoir la possibilité de tester le modèle à composants reconfigurable en testant des politiques d’adaptation ; et en simulant le modèle de reconfiguration, ainsi que

l’évaluation décentralisée de propriétés temporelles.”

Nous pr ésentons ci-dessous ces probl ématiques de façon plus structur ée. La num érotation écrite en caract ères gras sera utilis ée par la suite pour d ésigner des

él éments de ces probl ématiques.

(1) D ´efinir un mod `ele permettant

(1.1) de garantir la consistance des configurations “cibles” ; et

(1.2) de ne pas se limiter à des reconfigurations d éfinies comme des s équences de reconfigurations primitives.

(2) Choisir ou ´etablir une logique temporelle

(2.1) prenant en compte des ´ev ´enements internes et externes afin d’exprimer des politiques d’adaptation et des contraintes architecturales ;

(2.2) telle que l’on puisse évaluer les propri ét és bas ées sur cette logique (2.2.1) à l’ex écution sur des traces incompl ètes,

(2.2.2) sans avoir à maintenir un long historique, et (2.2.3) de façon d écentralis ée ; et

(23)

(2.3) int égrer ces propri ét és dans des politiques d’adaptation. (3) D évelopper une application permettant

(3.1) de contr ôler et guider les reconfigurations au moyen de politiques d’adaptation pour un syst ème à composants bas é sur Fractal ou sur un autre mod èle à composants ; et

(3.2) utiliser cette application sur diff érents cas d’ étude. (4) Avoir la possibilit é de tester notre mod èle en

(4.1) testant des politiques d’adaptation ; et en (4.2) simulant

(4.2.1) notre mod `ele de reconfiguration, ainsi que

(4.2.2) l’ évaluation d écentralis ée de propri ét és temporelles.

CONTRIBUTIONS

Nous pr ésentons nos contributions en indiquant, au moyen de la num érotation pr éc édemment établie, à quels él éments des probl ématiques ci-dessus elles corres-pondent.

Nous d éfinissons un mod èle abstrait en utilisant la logique du premier ordre. Ceci permet d’introduire la notion de reconfiguration gard ée afin de garantir la consistance des confi-gurations d’un syst ème à composants sous la condition que les conficonfi-gurations initiales de notre mod èle soient consistantes. Cette propagation de la consistance est étendue à un mod èle interpr ét é(1.1).

Ces reconfigurations gard ées utilisent les op érations de reconfiguration primitives en tant que “briques de base” pour construire des reconfigurations non-primitives impliquant des constructions, non seulement, s équentielles, mais aussi alternatives ou r ép étitives(1.2). Nous étendons la logique FTPL introduite dans [Dormoy et al., 2012a] avec des

év énements externes. Ceci permet de pouvoir utiliser la m ême logique pour exprimer les politiques d’adaptation et les contraintes architecturales sur les syst èmes à composants sans perdre en expressivit é(2.1).

Nous d éfinissons la s émantique FTPL ( étendue aux év énements externes) en utilisant les quatre valeurs de B4 pour l’ évaluation de propri ét és FTPL à l’ex écution sur des

traces d’ex écution incompl ètes (2.2.1). De plus, afin de pouvoir évaluer ces propri ét és à l’ex écution sans avoir à maintenir un historique des évaluations, nous introduisons une m éthode d’ évaluation progressive permettant dans la plupart des cas d’ évaluer une pro-pri ét é FTPL à une configuration donn ée en se basant seulement sur son évaluation à la configuration pr éc édente(2.2.2).

Nous proposons une m éthode pour l’ évaluation d écentralis ée de propri ét és FTPL en utilisant les notions de progression et d’urgence. Une fonction de progression permet de r é écrire une formule repr ésentant l’ évaluation d’une propri ét é à une configuration donn ée de façon qu’elle soit toujours pertinente à la configuration suivante. Dans ce contexte, nous d écomposons les formules en sous-formules auxquelles nous attribuons un niveau d’urgence pour d éterminer l’ordre dans lequel les évaluer. Nous posons aussi formellement le probl ème de l’ évaluation d écentralis ée et proposons un algorithme pour le r ésoudre ainsi que des r ésultats de correction et de terminaison(2.2.3).

(24)

ORGANISATION 9

Nous d éfinissons des politiques d’adaptation int égrant la logique FTPL(2.3). Nous pro-posons aussi une relation de simulation sur les mod èles de syst èmes à composants re-configurables et nous d éfinissons le probl ème de l’adaptation. En utilisant cette relation, nous établissons que le probl ème de l’adaptation est semi-d écidable et pr ésentons un algorithme pour l’enforcement des politiques d’adaptation de syst èmes à composants re-configurables. De plus, nous d écrivons l’utilisation du fuzzing [Takanen et al., 2008], une technique de test que nous appliquons au cas sp écifique du test de politiques d’adapta-tion(4.1).

Nous d écrivons notre impl émentation permettant de guider et contr ôler les reconfi-gurations de syst èmes à composants via des politiques d’adaptation bas ées sur la logique temporelle FTPL. Cette impl émentation supporte les mod èles à composants Fractal et FraSCAti (3.1). Nous pr ésentons les diff érentes entit és qui composent notre impl émentation et d étaillons leur fonctionnement ainsi qu’un r ésultat de conformit é ar-chitecturale en nous basant sur le mod èle interpr ét é pr éc édemment d éfini. Ensuite, nous montrons une partie des informations contenues dans les logs g én ér és par notre impl émentation et la façon dont elles sont utilis ées pour produire les sorties pour notre interface graphique et pour la g én ération de tests bas és sur le fuzzing. Enfin, nous d écrivons l’int égration de la fonctionnalit é de fuzzing permettant de tester des politiques d’adaptation(4.1).

Nous appliquons les politiques d’adaptation que nous avons d écrites pr éc édemment à un cas d’ étude en utilisant notre impl émentation qui permet de contr ôler et guider les recon-figurations de syst èmes à composants en utilisant les m écanismes d’enforcement et de r éflexion pour obtenir les r ésultats attendus(3.2). Deux autres cas d’ étude ayant ét é cha-cun impl ément és en utilisant les mod èles de syst èmes à composants Fractal et FraSCAti sont aussi pr ésent és(3.2). De plus notre mod èle a ét é impl ément é avec l’outil de trans-formation de graphes GROOVE [Ghamarian et al., 2012]. Une exp érimentation de cette impl émentation est pr ésent ée (4.2.1). En outre, nous d écrivons la façon dont nous si-mulons l’ évaluation d écentralis ée sous GROOVE(4.2.2). Nous montrons comment nous repr ésentons les propri ét és FTPL sous GROOVE et pr ésentons l’impl émentation (tou-jours sous GROOVE) de l’algorithme permettant l’ évaluation d écentralis ée de propri ét és FTPL(4.2.2).

O

RGANISATION

La figure 1 repr ésente la structure du pr ésent document (sans tenir compte des cha-pitres 1 et 2 qui proposent respectivement une introduction aux syst èmes à composants et un recueil des d éfinitions et notations utilis ées). Sur cette figure, les fl èches pleines indiquent l’ordre de lecture des chapitres de ce m émoire, tandis que les fl èches discon-tinues montrent les chemins possibles pour une lecture coh érente. Il est ainsi possible de lire dans l’ordre les chapitres 3, 5, 6, 8 et 10 et de revenir plus tard à la lecture des chapitres 4, 7 et 9. La suite du document est organis ée en quatre parties de la façon suivante :

— La partie I pr ésente le contexte scientifique et d éfinit les notions et notations uti-lis ées dans ce document,

— la partie II d écrit notre mod èle de reconfiguration, d éfinit les reconfigurations gard ées et étend la logique FTPL pour supporter les év énements externes,

(25)

— la partie III pr ésente l’ évaluation centralis ée et d écentralis ée des propri ét és FTPL à l’ex écution ainsi que leur int égration dans des politiques d’adaptation,

— La partie IV d écrit notre impl émentation ainsi que plusieurs cas d’ étude et simula-tions, et

— la conclusion nous permet de dresser un bilan et d’envisager les perspectives des travaux pr ésent és dans ce m émoire.

Chapitre 3 Mod élisation Chapitre 4 Reconfigurations gard ées Chapitre 5 Propri ét és temporelles

Chapitre 6 ´

Evaluation de pro-pri ét és tempo-relles à l’ex écution

Chapitre 7 ´

Evaluation d écentralis ée à l’ex écution Chapitre 8 Politiques d’adaptation Chapitre 9 Structure logicielle Chapitre 10 Exp érimentations

FIGURE1 – Structure du m ´emoire

PARTIE I : CONTEXTE SCIENTIFIQUE ET PRELIMINAIRES´

Dans le chapitre 1 nous introduisons le concept de composant en explicitant la notion d’architectures orient ées composants, puis nous exposons l’id ée de recon-figuration dans le cadre des syst èmes à composants. Pour finir, nous pr ésentons les deux impl émentations de syst èmes à composants que nous utilisons pour illus-trer les contributions de cette th èse ; c’est- à-dire les mod èles à composants Frac-tal [Bruneton et al., 2004, Bruneton et al., 2006] et FraSCAti [Seinturier et al., 2009, Seinturier et al., 2012].

(26)

ORGANISATION 11

Le chapitre 2 est consacr é aux d éfinitions et notations utilis ées dans la suite du docu-ment. Nous nous int éressons à la sp écification et la v érification des syst èmes ainsi qu’ à l’expression de leurs propri ét és.

PARTIE II : MODELISATION DES RECONFIGURATIONS DYNAMIQUES´

Au chapitre 3, nous proposons, comme dans [Dormoy, 2011] de d écrire la s émantique d’un syst ème à composants en utilisant un syst ème de transition. Pour ce faire, nous pr ésentons dans un premier temps, pour servir de base aux exemples utilis és, le compo-sant compositeLocation utilis é pour le positionnement du Cycab, un v éhicule autonome. Ensuite, nous d éfinissons une s émantique op érationnelle permettant de d écrire l’archi-tecture des syst èmes à composants ainsi que les reconfigurations primitives qui sont des op érations d’ évolution basiques permettant de passer d’une configuration architecturale à une autre pour d éfinir les syst èmes à composants reconfigurables primitifs. Enfin, nous abordons la notion de reconfiguration non primitive pour d éfinir les syst èmes à compo-sants reconfigurables (non primitifs).

Nous proposons dans le chapitre 4 de d écrire des contraintes sur les él éments et re-lations des configurations de syst èmes à composants reconfigurables afin de pouvoir garantir que le syst ème à composants consid ér é soit dans un état permettant son bon fonctionnement. En outre, en nous basant sur les pr é/post-conditions des op érations pri-mitives de reconfiguration, nous introduisons les reconfigurations gard ées qui permettent d’utiliser les op érations primitives en tant que “briques de base” pour construire des re-configurations non-primitives impliquant des constructions, non seulement, s équentielles, mais aussi alternatives ou r ép étitives. Ensuite, nous montrons que l’utilisation de recon-figurations gard ées garantit la consistance des conrecon-figurations d’un syst ème à compo-sants sous la condition que les configurations initiales soient consistantes. Enfin, nous d éfinissons un mod èle interpr ét é en partant du mod èle abstrait pr ésent é au chapitre 3. Le chapitre 5 pr ésente la logique FTPL introduite dans [Dormoy et al., 2012a] qui est uti-lis ée pour exprimer des contraintes architecturales et temporelles sur des syst èmes à composants mais ne permet pas la prise en compte d’ év énements externes. C’est pour-quoi nous étendons cette logique avec des év énements externes afin de pouvoir utiliser la m ême logique pour exprimer les politiques d’adaptation et les contraintes architectu-rales sur les syst èmes à composants sans perdre en expressivit é. Nous pr ésentons la syntaxe de la logique FTPL étendue aux év énements externes, puis nous d écrivons sa s émantique et la notion de satisfaction d’une propri ét é FTPL par un syst ème à compo-sants.

PARTIE III : V ´ERIFICATION ET TEST DES RECONFIGURATIONS DYNAMIQUES

Nous proposons au chapitre 6, apr ès avoir introduit le concept g én éral d’ évaluation à l’ex écution, une logique à quatre valeurs (“faux”, “potentiellement faux”, “potentiellement vrai” et “vrai”) pour évaluer les propri ét és FTPL à l’ex écution sur des traces d’ex écution incompl ètes. En outre, pour pouvoir évaluer les propri ét és FTPL à l’ex écution sans avoir à maintenir un historique des évaluations, nous introduisons une m éthode d’ évaluation progressive des propri ét és FTPL permettant dans la plupart des cas d’ évaluer une pro-pri ét é FTPL à une configuration donn ée en se basant seulement sur son évaluation à la configuration pr éc édente.

(27)

En s’inspirant de l’ évaluation d écentralis ée de formules LTL pr ésent ée dans [Bauer et al., 2012], nous proposons au chapitre 7 une m éthode pour l’ évaluation d écentralis ée de propri ét és FTPL. Nous d éfinissons dans un premier temps les conven-tions utilis ées pour l’ évaluation d écentralis ée. Ensuite, nous pr ésentons les noconven-tions de progression et d’urgence. Une fonction de progression nous permet de r é écrire une formule repr ésentant l’ évaluation d’une propri ét é FTPL à une configuration donn ée de façon qu’elle soit toujours pertinente à la configuration suivante. Dans le contexte de l’ évaluation d écentralis ée, nous d écomposons les formules en sous-formules auxquelles nous attribuons un niveau d’urgence pour d éterminer l’ordre dans lequel les évaluer. Enfin, nous posons formellement le probl ème de l’ évaluation d écentralis ée et proposons un algorithme pour le r ésoudre ainsi que des r ésultats de correction et de terminaison. Le chapitre 8 montre comment nous int égrons la logique FTPL étendue aux év énements externes d éfinie au chapitre 5 dans des politiques d’adaptation que nous d éfinissons. Nous proposons aussi une relation de simulation sur les mod èles de syst èmes à compo-sants reconfigurables et d éfinissons le probl ème de l’adaptation. En utilisant cette rela-tion, nous établissons que le probl ème de l’adaptation est semi-d écidable. De plus, nous fournissons un algorithme pour l’impl émentation de politiques d’adaptation pour l’enfor-cement de propri ét és FTPL sur des syst èmes à composants reconfigurables. Enfin, nous pr ésentons l’usage du fuzzing pour le test de politiques d’adaptation.

PARTIE IV : VALIDATION EXPERIMENTALE´

Le chapitre 9 pr ésente l’impl émentation que nous avons d évelopp ée pour les reconfi-gurations dynamiques de syst èmes à composants guid ées par des politiques d’adapta-tion bas ées sur des sch émas temporels. Dans un premier temps, nous d écrivons notre impl émentation, avec les entit és qui la composent et leur fonctionnement, puis nous énonçons un r ésultat de conformit é architecturale. Ensuite, nous d étaillons une partie des informations contenues dans les logs g én ér és par notre impl émentation et comment nous les utilisons pour en extraire les él éments permettant de produire une interface gra-phique. Enfin nous pr ésentons l’int égration de la fonctionnalit é de fuzzing permettant de tester des politiques d’adaptation.

Au chapitre 10, nous montrons comment l’ex écution de notre impl émentation permet de contr ôler et guider les reconfigurations du composantLocation, pr ésent é au chapitre 3, en utilisant les m écanismes d’enforcement et de r éflexion. Deux autres cas d’ étude ayant ét é chacun impl ément és en utilisant les mod èles de syst èmes à composants Fractal et FraSCAti sont pr ésent és. Le premier mod élise des machines virtuelles au sein d’un en-vironnement cloud et le second s’inspire du serveur HTTP Comanche Http Server uti-lis é dans [Chauvel et al., 2009]. De plus notre mod èle a ét é impl ément é avec l’outil de transformation de graphe GROOVE [Ghamarian et al., 2012]. Une exp érimentation de cette impl émentation utilisant comme cas d’ étude une machine virtuelle de l’environne-mentcloud est présentée. Enfin, nous décrivons la façon dont nous simulons l’évaluation d écentralis ée sous GROOVE. Nous montrons comment nous repr ésentons les propri ét és FTPL sous GROOVE et pr ésentons l’impl émentation sous GROOVE de l’algorithme établi pour l’ évaluation d écentralis ée de propri ét és FTPL à l’ex écution sur le mod èle du syst ème à composantsLocation.

(28)

PUBLICATIONS 13

CONCLUSION ET PERSPECTIVES

Dans cette partie, nous dressons le bilan et pr ésentons les perspectives du travail r éalis é au cours de cette th èse.

P

UBLICATIONS

Les travaux pr ésent és dans cette th èse ont ét é soutenus en partie par le projet Labex AC-TION, ANR-11-LABEX-0001-01. Par ailleurs, les diff érentes contributions de cette th èse, list ées ci-dessous, ont ét é publi ées dans une revue nationale et diff érentes conf érences internationales :

— Les contributions des chapitres 5 et 6 et une partie de celles des chapitres 8, 9 et 10 ont ét é publi ées dans [Kouchnarenko et al., 2014a].

— Les contributions du chapitre 7 et une partie de celles des chapitres 9 et 10 ont ét é publi ées dans [Kouchnarenko et al., 2014b].

— Les contributions du chapitre 4 et une partie de celles des chapitres 9 et 10 ont ét é publi ées dans [Kouchnarenko et al., 2015].

— Les contributions du chapitres 3 et une partie des contributions des chapitres 9 et 10 ont ét é publi ées dans [Kouchnarenko et al., 2016].

(29)

(30)

I

C

ONTEXTE SCIENTIFIQUE ET PR

ELIMINAIRES

´

(31)

(32)

1 L

ES SYST

EMES

`

A COMPOSANTS

`

B

ien que le terme de composants avait d éj à ét é utilis é dans les ann ées 1960 pourd ésigner des fragments de code, ce concept utilis é dans le cadre de l’ing énierie logicielle à base de composants est relativement r écent. Intuitivement, cette technique de d éveloppement utilise un ensemble de briques logicielles (i.e., des composants) pou-vant être assembl ées pour construire une application. Cette m éthodologie repose sur des composants r éutilisables et favorise la mise en place de syst èmes modulaires qui peuvent être appr éhend és et d évelopp és plus simplement. Dans ce chapitre, nous introduisons le concept de composant en explicitant la notion d’architectures orient ées composants, puis nous exposons l’id ée de reconfiguration dans le cadre des syst èmes à composants. Pour finir, nous pr ésentons les deux impl émentations de syst èmes à composants que nous utilisons pour illustrer les contributions de cette th èse ; c’est- à-dire les mod èles à composants Fractal et FraSCAti.

Sommaire

1.1 Architectures orient ées composants . . . . 18 1.1.1 Le concept de composant . . . 18 1.1.2 Architectures logicielles bas ées sur les composants . . . 20 1.1.2.1 Composants primitifs et composites . . . 21 1.1.2.2 Interfaces . . . 21 1.1.2.3 Assemblages de composants . . . 22 1.1.3 Quelques approches de mod èles à composants . . . 23 1.2 Modification dynamique des syst èmes à composants . . . . 25 1.2.1 Reconfigurations dynamiques . . . 25 1.2.2 Syst èmes r éflexifs et adaptatifs . . . 26 1.2.3 Boucle de contr ôle et boucle MAPE . . . 27 1.3 Le mod èle à composants Fractal . . . . 29 1.3.1 Composants Fractal . . . 29 1.3.2 Impl émentations . . . 31 1.4 Le mod èle à composants FraSCAti . . . . 31 1.4.1 La sp écification SCA . . . 32 1.4.2 L’impl émentation de SCA par FraSCAti . . . 32 1.4.3 Comparaison avec d’autres impl émentations de SCA . . . 34 1.5 Conclusion . . . . 34

(33)

1.1/

A

RCHITECTURES ORIENTEES COMPOSANTS

´

Les architectures orient ées composants sont souvent mentionn ées en utilisant les acro-nymes CBD (Component-Based software Development), CBSE (Component-Based Soft-ware Engineering) [Szyperski, 1995, Council et al., 2001] ou SCA (Service Component Architecture). Les principaux avantages de ces approches r ésident dans la modula-rit é rendue possible par l’utilisation de composants et dans la r é-utilisabilit é de ceux-ci. Ces aspects permettent notamment de faciliter le d éveloppement de logiciels com-plexes. Dans cette section, nous d étaillons le concept de composant, puis nous nous int éresserons aux architectures logicielles bas ées sur les composants. Enfin, pour finir, nous pr ésentons bri èvement quelques approches existantes de mod èles à composants.

1.1.1/ LE CONCEPT DE COMPOSANT

L’examen de l’ évolution des concepts utilis és par les technologies de l’information tend à montrer une constante volont é de simplification du d éveloppement au cours de la-quelle les concepts manipul és sont de plus en plus abstraits au fur et à mesure que la complexit é des syst èmes augmente. La programmation pour les syst èmes complexes et distribu és a rendu n écessaire un type d’architecture logicielle bas ée sur des entit és au-tonomes pouvant interagir avec leur environnement et entre-elles. Il est à noter que le terme d’architecture logicielle, bien qu’utilis é depuis les ann ées 1960 [Naur et al., 1969], ne s’est impos é qu’ à partir des ann ées 1990 [Kruchten et al., 2006].

La figure 1.1 extraite de [Ait Wakrime, 2015] montre l’ évolution des architectures logi-cielles depuis les ann ées 1960 qui ont vu l’ émergence d’une architecture bas ée sur la programmation structur ée [Warnier et al., 1974]. Par la suite, l’architecture bas ée sur la d écomposition fonctionnelle et celle bas ée sur le mode de communication client-serveur [Dahl et al., 1972, Shapiro, 1969]1 sont apparues. L’architecture 3-tiers, qui est une extension de l’architecture client-serveur [Eckerson, 1995], a vu le jour durant la d écennie 1980-1990.

Au fil des ann ées, les recherches acad émiques ont fait apparaˆıtre des architectures dis-tribu ées orient ées objets [Clarke et al., 1999, Nierstrasz, 1995]. La programmation ob-jet a ét é une évolution majeure de la programmation proc édurale en permettant un ni-veau d’abstraction plus élev é et davantage de modularit é, notamment gr âce aux no-tions d’h éritage et de polymorphisme. Enfin, la technologie des architectures logicielles à base de composants est progressivement devenue plus puissante et a facilit é le d éveloppement des syst èmes [Council et al., 2001]. En effet, l’approche objet n’appa-raissait pas suffisamment abstraite et souffrait du manque de m écanismes permettant la composition des objets [Meyer, 1988]. Il s’av érait difficile de mettre en évidence les liens entre les diff érents objets au sein d’une application lorsque leur nombre devenait important. En bref, la programmation objet était encore trop proche du code pour per-mettre le d éveloppement ais é d’applications tirant pleinement partie de concepts tels que lar éutilisationet lasubstitutiond’objets.

Les composants peuvent être consid ér és comme des boˆıtes noires (black boxes) dont l’impl émentation ou la structure interne n’est pas connue a priori. Ceci favorise la r éutilisation, l’interchangeabilit é et la s éparation des pr éoccupations (separation of

(34)

1.1. ARCHITECTURES ORIENT ´EES COMPOSANTS 19

22 Chapitre 2. Architecture par composants

Figure 2.1 – L’historique des architectures logicielles.

2.3.1 Composant logiciel

Un composant logiciel est un élément architectural qui encapsule la partie métier de l’application. Il existe plusieurs déﬁnitions dans la littérature d’un composant mais la plupart sont intuitives car elles se concentrent sur les aspects généraux d’un compo-sant comme la déﬁnition donnée par Microsoft [68] :

« . . . a piece of compiled software, which is offering a service . . . »

D’autres détaillent la caractérisation d’un composant comme celle donnée par Sa-metinger dans [176] :

« Reusable software components are self-contained, clearly identifiable pieces that describe and/or perform specific functions, have clear interfaces, appropriate docu-mentation, and a defined reuse status. »

par D’Souza et Wills dans [84] :

« A coherent package of software artifacts that can be independently developed and delivered as a unit and that can be composed, unchanged, with other components to build something larger. »

FIGURE1.1 – Historique des architectures logicielles (extrait de [Ait Wakrime, 2015])

concerns). On notera qu’il peut aussi être possible, suivant les informations dont on dis-pose, de consid érer les composants comme des boˆıtes blanches (white boxes — dans le cas o ù l’on connaˆıt la totalit é de l’impl émentation et de la structure interne) ou grises (grey boxes — dans le cas où l’on ne dispose que d’une partie des informations).

Il n’existe pas de d éfinition unique d’un composant et la plupart de celles qu’on trouve dans la litt érature sont intuitives. La d éfinition donn ée par Micro-soft [MicroMicro-soft Corporation, 1995] est tr ès g én érale :

“ . . . a piece of compiled software, which is offering a service . . . ”

D’Souza et Wills, dans [D’Souza et al., 1998], proposent une d éfinition plus pr écise ; les auteurs insistent sur la notion de composition entre composants qui doit pouvoir se faire sans avoir à effectuer le moindre changement au niveau des composants eux-m êmes :

“A coherent package of software artifacts that can be independently developed and delivered as a unit and that can be composed, unchanged, with other components to

build something larger.”

La d éfinition donn ée par Sametinger dans [Sametinger, 1997] contient la notion de r é-utilisabilit é et mentionne que les interfaces (des composants) doivent être clairement d éfinies :

(35)

“Reusable software components are self-contained, clearly identifiable pieces that describe and/or perform specific functions, have clear interfaces, appropriate

documentation, and a defined reuse status.”

C’est aussi le cas de la d ´efinition qui se trouve dans la sp ´ecification UML 1.3 (OMG 1999) [Rayner et al., 2005] :

“A physical, replaceable part of a system that packages implementation and provides the realization of a set of interfaces. A component represents a physical piece of implementation of a system, including software code (source, binary or executable) or

equivalents such as scripts or command files.”

Enfin, la d ´efinition la plus utilis ´ee est celle de Szyperski dans [Szyperski, 1995] :

“A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed

independently and is subject to composition by third parties.”

Nous pouvons nous inspirer de ces d éfinitions (en particulier de la derni ère) pour expri-mer trois propri ét és des composants :

— Les composants sont des unit és de composition qui peuvent être assembl ées pour former une application,

— les services fournis ainsi que les d ´ependances requises par un composant sont exprim ´es sous la forme de contrats explicites, et

— les composants sont ind épendants entres-eux et peuvent donc être d éploy és ind épendamment.

On peut donc concevoir un composant comme un él ément architectural, encapsulant une partie m étier d’une application, qui fournit des services et peut requ érir des d épendances. Lors de l’assemblage de plusieurs composants, des m écanismes de communication ap-paraissent avec la sp écification de contrats entre les composants. Ces contrat peuvent s’av érer plus complexes que ceux utilis és dans le cas de la programmation objet mais apportent une modularit é plus fine tout en facilitant la r éutilisation des él éments d’un syst ème. Cette modularit é permet aussi de renforcer l’encapsulation des parties m étier d’une application au sein de composants. Ces notions de modularit é et d’encapsulation permettent de rendre un assemblage de composants adaptable à son environnement. Nous d étaillerons cet aspect dans la section 1.2.

1.1.2/ ARCHITECTURES LOGICIELLES BASEES SUR LES COMPOSANTS´

Nous avons vu qu’il n’y a pas de d éfinition unique de ce qu’est un composant ; c’est pour-quoi les mod èles à composants sont souvent d éfinis en fonction d’un domaine particulier. Nous pouvons n éanmoins d éfinir les principaux concepts communs à la plupart des ap-plications utilisant des composants. Dans cette section, nous pr ésentons les notions de composants primitifs et composites, puis nous int éressons à la façon dont les compo-sants sont li és entres-eux en explicitant le concept d’interface. Enfin, nous montrerons comment s’effectue l’assemblage d’un syst ème à composants en utilisant la notion de composition.

(36)

1.1. ARCHITECTURES ORIENT ´EES COMPOSANTS 21

1.1.2.1/ COMPOSANTS PRIMITIFS ET COMPOSITES

La plupart des d éfinitions s’accordent sur le fait qu’un composant soit une entit é au-tonome capable de fournir un service. De plus, le d éveloppement et l’assemblage des composants étant ind épendants, un m ême composant peut être utilis é, dans diff érents contextes, au sein de diverses applications. C’est pourquoi, dans les approches à base de composants, deux types de composants existent :

— Les composants composites, qui sont des composants qui contiennent d’autres composants appel ´es sous-composants, et

— les composantsprimitifs, qui sont des composants qui ne contiennent pas de sous-composants et qui, par exemple, peuvent ex écuter du code ou être li és à un objet.

La figure1.2 illustre ces deux notions. Les composants C3, C4, C5 sont des composants primitifs. Le composant C2 est un composant composite qui contient C3 et C4. Le com-posant C1 est un comcom-posant composite qui contient C2 et C5.

Composant compositeC1 Composant compositeC2 Composant primitif C3 Composant primitif C4 Composant primitif C5

FIGURE1.2 – Exemple de composant composite

Ainsi, les composants composites encapsulent des composants primitifs ou d’autres composants composites, ce qui permet de masquer certains d étails dans une architec-ture logicielle. La notion de modularit é en est renforc ée puisque ce concept permet la r éutilisation directe d’assemblages de composants. Ces composants composites peuvent alors être “mis sur une étag ère” selon le principe de COTS (Component Off The Shelf ) qui permet la mise à disposition de composants pr êts à l’emploi. Cet aspect li é aux compo-sants facilite aussi la compr éhension du syst ème en permettant de consid érer le syst ème

`a un haut niveau d’abstraction.

1.1.2.2/ INTERFACES

Les interfaces d’un composant sont les seuls points d’acc ès du programme encapsul é dans ce composant depuis ou vers l’ext érieur. Les seules informations n écessaires à l’utilisation du composant sont les sp écifications de ses interfaces ; cela peut prendre la forme d’une description des propri ét és et d épendances fonctionnelles ou des services offerts par le composant [Bergner et al., 1998]. Ainsi, il n’est pas n écessaire de connaˆıtre le contenu d’un composant (qu’il s’agisse de code dans le cas d’un composant primitif ou d’autres composants dans le cadre d’un composant composite) pour pouvoir l’utiliser.