MOCAS : un modèle de composants basé états pour l'auto-adaptation

HAL Id: tel-00472005

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

Submitted on 9 Apr 2010

l’auto-adaptation

Cyril Ballagny

To cite this version:

Cyril Ballagny. MOCAS : un modèle de composants basé états pour l’auto-adaptation. Génie logiciel

[cs.SE]. Université de Pau et des Pays de l’Adour, 2010. Français. �tel-00472005�

TH` ESE

pr´ esent´ ee ` a

L’UNIVERSITE DE PAU ET

DES PAYS DE L’ADOUR

ECOLE DOCTORALE DES SCIENCES EXACTES ET DE LEURS APPLICATIONS

par

Cyril BALLAGNY

pour obtenir le grade de

DOCTEUR

Sp´ ecialit´ e : INFORMATIQUE

MOCAS : un mod` ele de composants bas´ e ´ etats pour l’auto-adaptation

Soutenue publiquement le : 8 mars 2010

Apr` es avis de :

M. CONSEL Charles Professeur, ENSEIRB

M. HAGIMONT Daniel Professeur, INPT-ENSEEIHT

Devant la commission d’examen form´ ee de :

M. JEZEQUEL Jean-Marc Professeur, Universit´ e de Rennes 1 (Pr´ esident) M. CRNKOVIC Ivica Professeur, Universit´ e de M¨ alardalen

M. BARBIER Franck Professeur, Universit´ e de Pau et des Pays de l’Adour

M. HAMEURLAIN Nabil Maˆıtre de Conf´ erences, Universit´ e de Pau et des Pays de l’Adour

TH` ESE

pr´ esent´ ee ` a

L’UNIVERSITE DE PAU ET

DES PAYS DE L’ADOUR

ECOLE DOCTORALE DES SCIENCES EXACTES ET DE LEURS APPLICATIONS

par

Cyril BALLAGNY

pour obtenir le grade de

DOCTEUR

Sp´ ecialit´ e : INFORMATIQUE

MOCAS : un mod` ele de composants bas´ e ´ etats pour l’auto-adaptation

Soutenue publiquement le : 8 mars 2010

Apr` es avis de :

M. CONSEL Charles Professeur, ENSEIRB

M. HAGIMONT Daniel Professeur, INPT-ENSEEIHT

Devant la commission d’examen form´ ee de :

M. JEZEQUEL Jean-Marc Professeur, Universit´ e de Rennes 1 (Pr´ esident) M. CRNKOVIC Ivica Professeur, Universit´ e de M¨ alardalen

M. BARBIER Franck Professeur, Universit´ e de Pau et des Pays de l’Adour

M. HAMEURLAIN Nabil Maˆıtre de Conf´ erences, Universit´ e de Pau et des Pays de l’Adour

Remerciements

La th` ese est une exp´ erience unique qui n´ ecessite de se remettre r´ eguli` erement en question.

Cette exp´ erience ne saurait ˆ etre compl` ete sans la stimulation ni le soutien apport´ es par l’en- semble des personnes rencontr´ ees pendant cette p´ eriode. Je tiens ici ` a les remercier pour cela et pour bien plus encore.

Tout d’abord, je remercie Charles Consel et Daniel Hagimont de m’avoir fait l’honneur de rapporter cette th` ese. Je remercie d’autant Charles Consel qu’il m’a offert l’opportunit´ e de lui exposer mes travaux avant de les rapporter. Ensuite, je remercie Jean-Marc J´ ez´ equel et Ivica Crnkovic pour avoir accept´ e de faire partie de mon jury. Especially, I would like to thank Ivica Crnkovic since my talk was in French.

J’adresse tous mes remerciements ` a Franck Barbier pour la mani` ere dont il a dirig´ e ma th` ese et pour m’avoir appris ` a ˆ etre exigeant avec moi-mˆ eme. Je remercie Nabil Hameurlain pour sa pr´ esence et pour les discussions que nous avons eu. Merci ` a tous les deux pour avoir recherch´ e la qualit´ e et m’avoir « tir´ e vers le haut ».

Un grand merci ` a tous les membres du laboratoire et du d´ epartement d’informatique de l’ Uppa : merci particuli` erement ` a Nicolas pour m’avoir aid´ e, depuis le master, ` a d´ ecrypter le monde universitaire, merci ` a Laurent pour sa disponibilit´ e et pour m’avoir fait d´ ecouvrir le vtt , le vrai (celui avec des v´ elos ` a plus de 2000 e j’entends !), merci ` a R´ egine et ` a Yvette pour leur r´ eactivit´ e et bien sˆ ur merci ` a Annig, Eric, Sophie, Bruno...

Une th` ese sans th´ esards ne serait pas une vraie th` ese ! Alors merci ` a mes copains de « ga- l` ere » : Damien, Eric, Natacha et mes copains de « chambr´ ee » et de « terrain » : les Juliens et Pierre. Courage aux suivants, Youssef et Nour !

Pour finir, je remercie mes parents qui m’ont permis de suivre d’aussi longues ´ etudes et qui,

je l’esp` ere, ne regrettent pas leur investissement ! Enfin, j’adresse un merci particulier, plein

d’´ emotions et de sentiments ` a Lydia, ma femme, qui a toujours eu foi en moi et m’a support´ e,

sans que je sache toujours la remercier ` a sa juste valeur. Ghislain, je ne t’oublie pas : j’esp` ere

ne pas t’avoir d´ egout´ e des ´ etudes longues ! Maintenant, je peux regarder vers l’avenir et vers

toi, petit ˆ etre qui grandit...

«Ce que tu veux me dire, est-ce vrai ? Est-ce bien ? Est-ce utile ? Sinon je ne veux pas l’entendre.»

Socrate.

Table des mati` eres

Table des figures 1

Liste des tableaux 3

Introduction 5

1 Contexte g´ en´ eral . . . . 7

2 Cadre de la th` ese . . . . 7

3 Objectifs de la th` ese . . . . 8

4 Organisation du document . . . . 9

Partie I Etat de l’art 11 Chapitre 1 Les composants logiciels et UML 1.1 Les composants logiciels . . . . 14

1.1.1 D´ efinition d’un composant logiciel . . . . 14

1.1.2 Service d’un composant . . . . 15

1.1.3 Composition de composants . . . . 17

1.1.4 D´ efinition d’un mod` ele de composants . . . . 20

1.2 UML et les composants . . . . 21

1.2.1 UML et l’ing´ enierie des mod` eles . . . . 21

1.2.2 Le mod` ele de composants UML . . . . 22

1.2.3 Les machines ` a ´ etats UML . . . . 23

1.3 Le mod` ele de composants PauWare . . . . 27

1.3.1 Principes . . . . 27

1.3.2 Composition des composants PauWare . . . . 28

1.4 Synth` ese . . . . 31

Chapitre 2 Les syst` emes logiciels adaptatifs 2.1 L’informatique autonomique . . . . 34

2.1.1 Les propri´ et´ es auto-* . . . . 34

2.1.2 La boucle de contrˆ ole . . . . 34

2.1.3 Coordination des boucles de contrˆ ole . . . . 35

2.1.4 Synth` ese . . . . 39

2.2 Les syst` emes adaptatifs . . . . 39

2.2.1 D´ efinition d’un syst` eme adaptatif . . . . 39

2.2.2 Les raisons de l’adaptation . . . . 41

2.2.3 Une adaptation dynamique . . . . 42

2.2.4 Le support des adaptations non anticip´ ees . . . . 42

2.3 Gestion de l’adaptation . . . . 43

2.3.1 Le moment de l’adaptation . . . . 43

2.3.2 Le transfert d’´ etat . . . . 44

2.3.3 La coh´ erence du syst` eme . . . . 46

2.4 Synth` ese . . . . 47

Chapitre 3 Auto-adaptation des syst` emes ` a base de composants 3.1 Localisation de l’adaptation . . . . 50

3.1.1 Localisation des points d’application . . . . 50

3.1.2 Localisation du support de l’adaptation . . . . 51

3.2 Techniques d’adaptation . . . . 54

3.2.1 Adaptation par reconfiguration . . . . 54

3.2.2 Patrons de conception pour l’adaptation . . . . 55

3.3.2 K-Component . . . . 59

3.3.3 SAFRAN . . . . 62

3.4 Synth` ese . . . . 66

Partie II MOCAS : un mod` ele de composants bas´ e ´ etats pour l’auto-adaptation 67 Introduction Chapitre 4 Le mod` ele de composants MOCAS 4.1 Structure d’un composant MOCAS . . . . 72

4.1.1 M´ etamod` ele UML . . . . 72

4.1.2 Les attributs du composant . . . . 74

4.1.3 Le comportement du composant . . . . 75

4.1.4 Le contexte fonctionnel du composant . . . . 77

4.2 Interaction des composants MOCAS . . . . 77

4.2.1 Composition horizontale . . . . 77

4.2.2 Composition verticale . . . . 79

4.2.3 Communication entre composants . . . . 81

4.3 Exemple du composant Car . . . . 82

4.4 Synth` ese . . . . 83

Chapitre 5 Adaptation des composants MOCAS 5.1 Un conteneur pour l’adaptation . . . . 85

5.1.1 Structure du conteneur . . . . 86

5.1.2 Le moment de l’adaptation . . . . 87

5.1.3 La coh´ erence de l’adaptation . . . . 89

5.1.4 Le transfert d’´ etat . . . . 90

5.2 Adaptations support´ ees . . . . 90

5.2.1 Adaptation du comportement . . . . 91

5.2.2 Adaptation de l’impl´ ementation . . . . 91

5.2.3 Remplacement du composant . . . . 92

5.3 Adaptation du composant Car . . . . 92

5.4 Synth` ese . . . . 94

Chapitre 6 Auto-adaptation des composants MOCAS 6.1 Une boucle de contrˆ ole ` a base de composants MOCAS . . . . 96

6.1.1 Les capteurs . . . . 96

6.1.2 L’´ evaluateur . . . . 99

6.1.3 Les effecteurs . . . 100

6.1.4 Le r´ epartiteur . . . 101

6.2 R´ ealisation de politiques autonomiques . . . 102

6.2.1 Auto-r´ eparation . . . 102

6.2.2 Auto-configuration . . . 104

6.3 Adaptation d’un syst` eme MOCAS . . . 106

6.3.1 Coordination par propagation . . . 106

6.3.2 Coordination par un protocole d’interaction . . . 107

6.4 Synth` ese . . . 112

Partie III Mise en œuvre de l’approche et ´ evaluation 115 Chapitre 7 Outils pour la r´ ealisation de composants MOCAS 7.1 MOCAS4TopCased : un plugiciel pour la conception et le d´ eveloppement . . 118

7.1.1 Conception . . . 118

7.1.2 D´ eveloppement . . . 118

7.2 MOCASEngine : un moteur pour l’ex´ ecution de machines ` a ´ etats UML . . . 120

7.2.1 S´ emantique . . . 120

7.2.2 Principes de fonctionnement . . . 121

7.3.2 Administration des composants . . . 124

7.4 Synth` ese . . . 124

Chapitre 8 Mise en œuvre 8.1 La boˆıte de vitesses robotis´ ee . . . 127

8.1.1 Description . . . 127

8.1.2 Conception . . . 128

8.1.3 D´ eveloppement . . . 130

8.1.4 Administration . . . 132

8.2 Evaluation quantitative . . . 135

8.2.1 Temps d’ex´ ecution . . . 136

8.2.2 Occupation m´ emoire . . . 137

8.3 Synth` ese . . . 137

Conclusion et perspectives 139 1 Bilan et contributions . . . 141

2 Perspectives . . . 142

2.1 Au niveau des outils . . . 142

2.2 Au niveau des mod` eles . . . 143

2.3 Au niveau des composants . . . 143

2.4 Au niveau de la coordination . . . 143

Bibliographie 145

Table des figures

1.1 S´ emantiques de service . . . . 16

1.2 Exemple de compositions horizontale et verticale . . . . 18

1.3 Exemple de contrainte de comportement . . . . 19

1.4 D´ emarche MDA . . . . 21

1.5 Mod` ele de composants UML [1] . . . . 22

1.6 Classifieur avec comportement [1] . . . . 23

1.7 Exemple de structure d’une machine ` a ´ etats . . . . 24

1.8 Exemple de machine ` a ´ etats . . . . 26

1.9 Sp´ ecification du composant PauWare Component [2] . . . . 29

1.10 Composition horizontale dans PauWare . . . . 30

1.11 Composition verticale dans PauWare . . . . 30

2.1 La boucle de contrˆ ole selon ibm [3] . . . . 36

2.2 Exemple de boucle de contrˆ ole . . . . 37

2.3 Relation indirecte entre deux boucles de contrˆ ole . . . . 37

2.4 Relation directe entre deux boucles de contrˆ ole . . . . 38

2.5 Le protocole entre Y : et Z : intervient dans le protocole entre X : et Y : . . . . 44

2.6 Nombre d’op´ erations de transfert d’´ etat entre trois composants . . . . 45

2.7 Conformit´ e du syst` eme apr` es adaptation . . . . 48

3.1 Sc´ enario d’adaptation structurelle . . . . 51

3.2 Sc´ enario d’adaptation comportementale . . . . 52

3.3 Patron de conception Strat´ egie . . . . 55

3.4 Patron de conception Adaptateur . . . . 56

3.5 Structure de MaDcAr [4] . . . . 58

3.6 Le mod` ele de composants support´ e par le mod` ele K-Component [5] . . . . 60

3.7 Structure d’un K-Component . . . . 61

3.8 Exemple de composants Fractal [6] . . . . 63

3.9 Structure de safran . . . . 64

4.1 M´ etamod` ele de MOCAS . . . . 72

4.2 Profil de MOCAS . . . . 73

4.3 Actions UML pour g´ erer les propri´ et´ es [1] . . . . 75

4.4 Actions UML pour g´ erer les op´ erations, les signaux et les objets [1] . . . . 76

4.5 Machine ` a ´ etats minimale d’un composant MOCAS . . . . 77

4.6 Composition horizontale dans MOCAS . . . . 78

4.7 V´ erification de la r´ esolution des d´ ependances . . . . 78

4.8 Composition verticale dans MOCAS . . . . 80

4.9 Composition verticale dynamique dans MOCAS . . . . 80

4.10 Structure et comportement du composant Car . . . . 82

5.1 Comportement du conteneur MOCAS . . . . 86

5.2 Variantes coh´ erentes d’une machine ` a ´ etats . . . . 88

5.3 Adaptation autoris´ ee entre les variantes . . . . 88

5.4 Comparaison des moments d’adaptation possibles . . . . 89

5.5 Raffinement successif d’un ´ etat . . . . 91

5.6 Raffinement du comportement du composant Car . . . . 93

6.1 Profil du mod` ele de composants autonomiques de MOCAS . . . . 96

6.2 Le conteneur autonomique MOCAS . . . . 97

6.3 Le capteur MOCAS r´ eactif . . . . 98

6.4 Le capteur MOCAS proactif . . . . 98

6.5 L’´ evaluateur MOCAS . . . . 99

6.6 Une r` egle MOCAS . . . 100

6.7 Exemple de machine ` a ´ etats d’un effecteur . . . 101

6.8 Le r´ epartiteur MOCAS . . . 101

6.9 Exemple de sc´ enario de repli d’un composant autonomique . . . 103

6.10 Exemple de sc´ enario de r´ einitialisation d’un composant autonomique . . . 104

6.11 Exemple de politique d’auto-configuration . . . 105

6.12 Exemple de politique de reconfiguration . . . 106

6.13 Un protocole pour l’adaptation . . . 109

6.14 Machines ` a ´ etats correspondant aux rˆ oles du protocole d’adaptation . . . 111

6.15 Plans d’actions de l’initiateur et des participants du protocole d’adaptation . . . 112

7.1 Sp´ ecification du profil et du template MOCAS dans TopCased . . . 119

7.2 M´ etaclasses UML li´ ees aux mod` eles d’instances et support´ ees par le moteur mo- case ngine [1] . . . 122

7.3 Gestion d’un ordre al´ eatoire de r´ eception de signaux . . . 123

7.4 Plateforme d’administration MOCASA . . . 125

8.1 Comportement du composant GearBox . . . 129

8.2 Exemple de levier de boˆıte automatique . . . 129

8.3 Sp´ ecification du capteur de vitesse dans TopCased . . . 130

8.4 Mod` ele de structure composite de la boˆıte robotis´ ee . . . 132

8.5 Politique d’auto-reconfiguration du composant GearBox . . . 133

Liste des tableaux

2.1 R´ esum´ e des propri´ et´ es et caract´ eristiques autonomiques . . . . 40

3.1 Avantages et inconv´ enients principaux de MaDcAr . . . . 59

3.2 Avantages et inconv´ enients principaux de K-Component . . . . 62

3.3 Avantages et inconv´ enients principaux de safran . . . . 64

3.4 Caract´ eristiques des syst` emes auto-adaptatifs ´ etudi´ es . . . . 65

4.1 Visibilit´ e des attributs MOCAS . . . . 74

4.2 Support de la composition dans MOCAS . . . . 83

7.1 Correspondance des visibilit´ es des propri´ et´ es MOCAS et UML . . . 121

8.1 Calcul de la circonf´ erence d’un pneu . . . 131

8.2 Invariants associ´ es aux ´ etats du composant GearBox . . . 134

8.3 Temps d’ex´ ecution moyen du composant GearBox . . . 136

8.4 Occupation m´ emoire du composant GearBox . . . 137

Introduction

1. Contexte g´ en´ eral

1 Contexte g´ en´ eral

L’informatique est fondamentalement destin´ ee au traitement automatique de l’information.

Les syst` emes informatiques traitent des donn´ ees dans un volume et dans un temps qui sur- passent les capacit´ es humaines. Dans ce but, les syst` emes mat´ eriels, les syst` emes logiciels, les infrastructures de t´ el´ ecommunication sont interconnect´ es pour construire et garantir un flot continu de donn´ ees. La mise en place de ces syst` emes de syst` emes n´ ecessite beaucoup de temps, de moyens et de personnes issues de domaines diff´ erents (informatique, automatique, t´ el´ ecom- munication...)

. De ce fait, plus les syst` emes sont amen´ es ` a traiter d’informations, plus leur conception et leur administration se complexifient.

ibm , ` a travers la voix de Paul Horn [8], n’h´ esite pas ` a parler d’une industrie des technologies de l’information en crise face ` a cette complexit´ e croissante. A tel point que les avantages apport´ es par de tels syst` emes seraient largement amoindris. La r´ eduction de la complexit´ e de leur mise en œuvre doit alors passer par une augmentation de leur propre complexit´ e. ibm ouvre ainsi la voie vers un nouveau type de syst` emes qualifi´ es d’autonomiques. De tels syst` emes assurent des fonctions annexes – telles que leur d´ eploiement dans un environnement quelconque, la d´ ecouverte de cet environnement, la mise en relation avec les autres syst` emes d´ ej` a pr´ esents, le maintien de leur fonctionnement – qui d´ epassent les fonctions « applicatives » pour lesquelles ils ont ´ et´ e con¸cus. Toutes ces tˆ aches qui normalement incombent aux administrateurs sont assur´ ees par des syst` emes qui s’auto-g` erent.

Dans la vision d’ ibm , la complexit´ e pr´ ec´ edemment g´ er´ ee par l’administrateur se retrouve donc transf´ er´ ee au niveau du syst` eme. Du point de vue humain, elle est transf´ er´ ee au niveau du concepteur du syst` eme autonomique. Le concepteur doit donc disposer de moyens facilitant la r´ ealisation d’un tel syst` eme. Les m´ ethodes de conception descendantes (par ex. le raffinement et la d´ ecomposition modulaire) atteignent leur limite dans ce contexte car elles n´ ecessitent une connaissance globale du syst` eme. La complexit´ e des syst` emes rend cette connaissance difficile

`

a acqu´ erir. De ce fait, les m´ ethodes ascendantes, en pr´ econisant la construction des syst` emes par assemblage de sous-syst` emes existants, pr´ esentent un atout majeur dans le contexte de l’informatique autonomique.

2 Cadre de la th` ese

Les syst` emes autonomiques disposent de nombreuses propri´ et´ es, qualifi´ ees d’auto-*

telles que l’auto-configuration (par exemple la « conscience » de l’environnement pr´ ec´ edemment ´ enon- c´ ee) et l’auto-r´ eparation. Une propri´ et´ e est d’un int´ erˆ et tout particulier car primordiale dans la r´ ealisation de propri´ et´ es autonomiques de haut-niveau : l’auto-adaptation. Un syst` eme auto- adaptable, ou adaptatif, a la particularit´ e de pouvoir modifier son comportement et sa structure en r´ eponse ` a des ´ ev´ enements internes et externes, dans le but de maximiser la disponibilit´ e et les performances de ses fonctions. L’auto-adaptation pose entre autres le probl` eme de la coh´ e-

1. 40% des investissements dans les technologies de l’information sont utilis´ es juste pour l’int´ egration des diff´ erentes technologies utilis´ ees un sein d’un mˆ eme syst` eme [7].

2. La litt´ erature anglo-saxonne qualifie ces propri´ et´ es de « self-star » ou « self-* » [9].

faire en g´ enie logiciel afin de proposer des m´ ethodes de conception et de d´ eveloppement des syst` emes adaptatifs qui soient simples ` a mettre en place, garantissent la coh´ erence du syst` eme et satisfassent les besoins des syst` emes autonomiques.

Ces derni` eres ann´ ees, deux grandes tendances ont ´ emerg´ e au sein de la communaut´ e du g´ enie logiciel afin de diminuer le coˆ ut et le temps de r´ ealisation et d’augmenter la qualit´ e des syst` emes informatiques :

1. l’utilisation des composants logiciels, avec l’« ing´ enierie des composants logiciels » (Component-Based Software Engineering, cbse ) ;

2. l’utilisation des mod` eles, avec l’« ing´ enierie des mod` eles » (Model-Driven Engineering, mde ).

La premi` ere est connue pour favoriser la r´ eutilisation [10] grˆ ace ` a une conception modulaire

. La seconde permet la v´ erification et la validation d’un syst` eme d` es la phase de conception ; acc´ el` ere la r´ ealisation du syst` eme en exploitant les mod` eles de conception dans le processus de d´ eveloppement (g´ en´ eration de code, ex´ ecution de mod` eles...) ; enfin, facilite la communication entre les personnes intervenant tout au long de la vie du syst` eme (concepteurs, d´ eveloppeurs, testeurs, administrateurs...).

3 Objectifs de la th` ese

Dans cette th` ese, nous traitons des syst` emes adaptatifs pour l’informatique autonomique.

Nous proposons de nous appuyer sur les concepts de composant logiciel et de mod` ele afin de r´ eduire la complexit´ e de conception, de d´ eveloppement et d’administration de ces syst` emes.

Du point de vue m´ ethodologique, nous nous concentrons particuli` erement sur les trois crit` eres suivants :

1. r´ eutilisation : capitaliser le travail de conception de ces syst` emes en r´ eutilisant les mod` eles de conception pour leur ex´ ecution et leur administration ;

2. utilisabilit´ e : proposer une approche pratique de conception et d’administration des sys- t` emes adaptatifs qui soit rapide ` a prendre en main et ` a appliquer ;

3. ind´ ependance : minimiser le couplage entre les composants pour permettre de d´ evelopper individuellement chaque composant du syst` eme.

Du point de vue conceptuel, nous nous focalisons sur les crit` eres suivants : 1. transparence des m´ ecanismes d’adaptation pour le concepteur ;

2. flexibilit´ e du processus de contrˆ ole r´ ealis´ e par un syst` eme autonomique ;

3. coh´ erence de l’adaptation au niveau d’un composant logiciel autonomique et du syst` eme

4. Organisation du document Nous proposons pour cela le mod` ele de composants mocas (Model Of Components for Adap- tive Systems). mocas permet de concevoir un syst` eme adaptatif ` a base de composants logiciels.

Un composant mocas est sp´ ecifi´ e avec le langage de mod´ elisation uml . Son comportement est d´ ecrit par une machine ` a ´ etats uml . Cette mˆ eme machine est ex´ ecut´ ee par le composant pour r´ ealiser son comportement. Un composant mocas est install´ e dans un conteneur respectant ce mˆ eme mod` ele pour devenir adaptable. Une boucle de contrˆ ole ` a base de composants mocas permet de r´ ealiser des composants adaptatifs et de les doter de propri´ et´ es autonomiques.

L’originalit´ e majeure de cette approche r´ eside dans son utilisation des mod` eles : alors que les approches actuelles exploitent des mod` eles d’architecture repr´ esentant les liaisons entre les composants du syst` eme, mocas les exploite diff´ eremment. Dans mocas , les mod` eles sont utilis´ es pour la repr´ esentation interne et comportementale des composants, tout au long de leur r´ ealisation, et sont le support pour r´ ealiser les propri´ et´ es auto-*.

La pr´ esente th` ese regroupe les contributions th´ eoriques et pratiques suivantes :

– le mod` ele de composants mocas , bˆ ati sur celui d’ uml , supportant la mise ` a jour et l’adaptation du comportement des composants ;

– la sp´ ecification d’une boucle de contrˆ ole dont un composant mocas est dot´ e pour s’auto- adapter afin de lui conf´ erer des propri´ et´ es auto-* ;

– le module d’extension mocas4T op c ased permettant de g´ en´ erer un composant mocas d´ eployable ` a partir de sa sp´ ecification dans la plateforme t opcased

;

– la librairie mocase ngine

permettant d’ex´ ecuter les machines ` a ´ etats uml ; – la plateforme mocasa de d´ eploiement et d’administration de composants mocas .

4 Organisation du document

Ce document s’articule autour de huit chapitres s´ epar´ es en trois parties :

– la partie I pr´ esente les concepts g´ en´ eraux n´ ecessaires ` a la caract´ erisation d’un syst` eme adaptatif ` a base de composants logiciels :

– le chapitre 1 introduit les composants logiciels. Il explique notamment la mani` ere dont les composants peuvent ˆ etre assembl´ es afin de r´ ealiser des syst` emes. Le langage de mod´ elisation uml est ensuite pr´ esent´ e en tant que langage permettant la sp´ ecification de la structure et du comportement des composants. Le concept de composant logiciel est illustr´ e avec le mod` ele de composants p au w are, qui est une des bases de nos travaux, – le chapitre 2 d´ ecrit les syst` emes adaptatifs. Il pr´ esente l’informatique autonomique qui justifie notre int´ erˆ et pour ces syst` emes. Apr` es avoir distingu´ e les diff´ erents types d’adaptation, l’accent est mis sur l’adaptation dynamique et les probl` emes qu’elle en- gendre,

– le chapitre 3 expose les approches pratiques ` a l’auto-adaptation des syst` emes ` a base de composants. Il s’int´ eresse ` a la localisation des supports de l’adaptation dans les syst` emes ainsi qu’aux techniques permettant de rendre un syst` eme adaptable. Finalement, des syst` emes adaptatifs ` a base de composants sont ´ etudi´ es afin de mettre en ´ evidence les

4. http ://www.topcased.org/

5. http ://mocasengine.sourceforge.net/

des syst` emes adaptatifs :

– le chapitre 4 d´ etaille le mod` ele de composants mocas . Il pr´ esente ses liens avec le mo- d` ele p au w are et sa formalisation avec le langage uml . La mani` ere dont les composants mocas sont compos´ es est notamment expliqu´ ee,

– le chapitre 5 d´ ecrit le conteneur de composants permettant de rendre adaptable un composant mocas . Il montre la mani` ere dont les probl` emes de l’adaptation dynamique sont g´ er´ es,

– le chapitre 6 pr´ esente les composants mocas autonomiques. Il d´ etaille les compo- sants permettant de r´ ealiser une boucle de contrˆ ole. Il expose ensuite des politiques autonomiques permettant de rendre auto-configurable et auto-r´ eparable un composant mocas . Enfin, il pr´ esente la mani` ere dont les composants d’un syst` eme mocas sont coordonn´ es afin d’assurer la coh´ erence globale du syst` eme.

– la partie III pr´ esente les diff´ erentes r´ ealisations ayant permis la validation du mod` ele de composants mocas :

– le chapitre 7 expose les outils et la m´ ethode permettant de r´ ealiser des composants mocas . Il d´ etaille notamment le moteur d’ex´ ecution de machines ` a ´ etats mocase ngine avec la s´ emantique uml adopt´ ee. Il pr´ esente aussi la plateforme mocasa permettant de d´ eployer les composants,

– le chapitre 8 pr´ esente un exemple utilisant mocas . Il d´ etaille la conception d’une boˆıte

de vitesse robotis´ ee et comprend une ´ etude quantitative de mocas . Il ´ etudie notamment

l’impact d’une approche par conteneur et par mod` eles sur les temps d’ex´ ecution et sur

la m´ emoire occup´ ee.

Premi` ere partie

Etat de l’art

Chapitre 1

Les composants logiciels et UML

Sommaire

1.1 Les composants logiciels . . . . 14 1.1.1 D´ efinition d’un composant logiciel . . . . 14 1.1.2 Service d’un composant . . . . 15 1.1.3 Composition de composants . . . . 17 1.1.4 D´ efinition d’un mod` ele de composants . . . . 20 1.2 UML et les composants . . . . 21 1.2.1 UML et l’ing´ enierie des mod` eles . . . . 21 1.2.2 Le mod` ele de composants UML . . . . 22 1.2.3 Les machines ` a ´ etats UML . . . . 23 1.3 Le mod` ele de composants PauWare . . . . 27 1.3.1 Principes . . . . 27 1.3.2 Composition des composants PauWare . . . . 28 1.4 Synth` ese . . . . 31 D` es sa naissance en 1968 en tant que discipline de recherche [11], le g´ enie logiciel a eu pour but d’augmenter la qualit´ e des syst` emes informatiques tout en r´ eduisant leur coˆ ut et leur temps de r´ ealisation. Dans cette optique, diff´ erentes m´ ethodes de conception se sont succ´ ed´ ees (conception structur´ ee, conception orient´ ee objet...). N´ eanmoins, l’id´ ee d’appliquer les principes de conception des circuits ´ electroniques, reposant sur la r´ eutilisation de composants ´ el´ ementaires catalogu´ es, est apparue tr` es tˆ ot [10]. Ce principe s’est formalis´ e seulement dans les ann´ ees 90 avec l’av` enement du g´ enie logiciel bas´ e composant (Component-Based Software Engineering, cbse ) [12].

Nous introduisons dans la section 1.1 les concepts fondamentaux de la conception ` a base de

composants ( cbc ) : nous y d´ efinissons les composants, les services, les principes de composition

et les mod` eles de composants. Nous nous int´ eressons dans la section 1.2 ` a la mani` ere de sp´ ecifier

la structure et le comportement d’un composant avec le langage de mod´ elisation uml (Unified

Modeling Language) [1]. Nous pr´ esentons dans la section 1.3 le mod` ele de composants p au w are

qui repose sur les machines ` a ´ etats uml pour sp´ ecifier le comportement des composants.

1.1 Les composants logiciels

La cbc favorise la r´ eutilisation en accentuant la modularit´ e prescrite par la conception orient´ ee objet [13]. La cbc doit permettre d’atteindre trois objectifs majeurs [14] :

– assembler un syst` eme ` a partir de composants r´ ealis´ es ind´ ependamment les uns des autres ; – r´ ealiser des composants de mani` ere ` a ce qu’ils soient r´ eutilisables ;

– maintenir un syst` eme en permettant le remplacement et la personnalisation des compo- sants.

Pour atteindre ces objectifs, la conception d’un composant repose sur les principes : – d’abstraction, ` a travers la s´ eparation de sa sp´ ecification et de son impl´ ementation ; – de composition, ` a travers l’explicitation de ses points d’interaction ;

– et d’adaptabilit´ e, ` a travers sa personnalisation/configuration [15].

Ces principes visent ` a maximiser la r´ eutilisabilit´ e d’un composant en minimisant les d´ epen- dances, en facilitant l’assemblage tout en satisfaisant les besoins d’un maximum d’utilisateurs.

1.1.1 D´ efinition d’un composant logiciel

« A software component is a unit of composition with contractually specified inter- faces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties. » [12].

Cette d´ efinition d’un composant logiciel, propos´ ee par Szyperski [12] ` a la fin des ann´ ees 90, fait consensus. Un composant est ainsi d´ ecrit comme ayant des points d’interaction clairement d´ efinis dans des interfaces, pouvant ˆ etre compos´ e avec d’autres composants et ˆ etre mis en production par des personnes ne l’ayant pas con¸cu. Le point le plus discutable dans la vision de Szyperski est qu’un composant ne doit pas avoir d’´ etat observable [16] : les instances d’un mˆ eme type de composant ne doivent pas ˆ etre distinguables. Si cette vision simplifie l’administration des composants (notamment le maintien de la coh´ erence des composants), elle ne refl` ete pas les besoins : de ce fait des composants industriels comme les ejb (Enterprise JavaBeans) [17]

existent en deux types : les composants sans-´ etat (stateless session beans) pour lesquels les clients ne peuvent distinguer les instances auxquelles ils s’adressent (rien n’empˆ eche ce type de composants d’ˆ etre impl´ ement´ e avec des objets ayant eux un ´ etat), et les composants avec-´ etat (stateful session beans) pour lesquelles les instances sont sp´ ecifiques d’un client.

« Reusable software components are self-contained, clearly identifiable artefacts that describe and/or perform specific functions and have clear interfaces, appropriate documentation and a defined reuse status. » [18]

Dans la mˆ eme p´ eriode, Sametinger [18] met la r´ eutilisabilit´ e au cœur de sa d´ efinition. Un

composant peut ˆ etre une simple sp´ ecification de fonctionnalit´ es, il n’est pas oblig´ e de fournir

1.1. Les composants logiciels

« A software component is a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard. » [19]

Plus r´ ecemment, Councill et Heineman [19] font intervenir dans leur d´ efinition le principe de conformit´ e ` a un mod` ele de composant

, que nous d´ eveloppons dans la section 1.1.4. De plus, ils pr´ ecisent qu’un composant doit ˆ etre utilisable sans modification, ce qui va ` a l’encontre de la vision de Sametinger pour qui le composant est personnalisable. Effectivement, dans un monde id´ eal, un composant n’a pas ` a ˆ etre personnalisable. En effet, il devrait ˆ etre suffisament bien con¸cu pour convenir ` a toutes les situations. De fa¸con plus r´ ealiste, le fait que le composant doive ˆ etre personnalisable peut ˆ etre vu comme une cons´ equence du fait que le concepteur n’est pas capable d’envisager toutes les utilisations possibles.

« A component is a software element (modular unit) satisfying the following three conditions : (1) it can be used by other software elements, its “clients”; (2) it pos- sesses an official usage description, which is sufficient for a client author to use it ; (3) it is not tied to any fixed set of clients. » [20]

Enfin, la d´ efinition de Meyer [20] confirme la vision d’un composant composable, document´ e et ind´ ependant. Oussalah [15] approfondit la notion de documentation en rajoutant qu’un com- posant doit disposer d’« un m´ ecanisme d’introspection permettant de connaˆıtre et modifier dynamiquement ses caract´ eristiques ». Il rappelle aussi l’importance d’avoir des composants adaptables afin de satisfaire des contextes d’ex´ ecution particuliers.

De notre point de vue, un composant logiciel n’est r´ eutilisable que s’il est compr´ ehensible par une personne qui ne l’a pas con¸cu. Pour cela, nous retiendrons les quatre caract´ eristiques suivantes :

1. un composant est li´ e ` a un mod` ele, servant ` a borner l’espace des composants possibles ; 2. un composant est li´ e ` a une forme de documentation, servant ` a comprendre son fonction-

nement en s’affranchissant des d´ etails d’impl´ ementation ;

3. un composant a des points d’interaction clairement d´ efinis, pour savoir comment l’int´ egrer dans un environnement ;

4. un composant est personnalisable, afin de convenir ` a des cas d’utilisation vari´ es.

1.1.2 Service d’un composant

En ´ economie, un service se caract´ erise comme ´ etant un acte propos´ e par une entit´ e ` a une autre, sans que cette derni` ere ne dispose des moyens de production de cet acte [21]. En infor- matique, la d´ efinition d’un service varie suivant le domaine :

– dans les syst` emes distribu´ es, l’intergiciel [22] offre de nombreux services pour rendre in- terop´ erable des syst` emes h´ et´ erog` enes (des syst` emes s’ex´ ecutant sur des environnements

6. Szyperski parle dans [12] de « component world » alors que dans la deuxi` eme ´ edition du mˆ eme livre [16],

il utilise « component model ».

mat´ eriels et logiciels diff´ erents). Chaque service est standardis´ e et est donc acc´ ed´ e uni- form´ ement par les diff´ erents syst` emes. Par exemple, l’intergiciel corba [23] comporte dix-sept services : un service de gestion de cycle de vie pour cr´ eer/supprimer/copier/d´ e- placer des objets, un service d’annuaire pour nommer/retrouver des objets, un service transactionnel pour assurer l’atomicit´ e d’un ensemble d’op´ erations, un service d’horloge pour synchroniser des syst` emes, etc ;

– dans les architectures orient´ ees services [24], un service est un m´ ecanisme offrant ` a un consommateur des fonctionnalit´ es propos´ ees par un fournisseur. Le fournisseur ne connait pas obligatoirement les futurs consommateurs et le consommateur ne sait pas comment est r´ ealis´ e le service. Le consommateur peut utiliser le service de mani` ere non pr´ evue par le fournisseur. L’acc` es au service se fait via une interface d´ etermin´ ee contenant les d´ etails des fonctionnalit´ es. Le consommateur connaˆıt ainsi le comportement du service et peut d´ eterminer si ce dernier est appropri´ e ` a ses besoins.

– dans les syst` emes ` a base de composants, un service est r´ ealis´ e par un composant. Un com- posant est donc un fournisseur de services. Un composant peut requ´ erir d’autres services pour r´ ealiser ceux qu’il fournit. Dans ce cas, il est ` a la fois fournisseur et consommateur.

Figure 1.1 – S´ emantiques de service

La mani` ere dont un service est rattach´ e ` a un composant diff` ere suivant les auteurs (cf. figure 1.1) :

a) un service correspond ` a une interface expos´ ee par un composant. Cette interface liste les op´ erations du service. Le service correspond alors ` a un ensemble coh´ erent d’op´ erations r´ ealis´ ees par un composant et expos´ e dans une interface [12, 25] ;

b) une interface expose des services, chaque service correspond ` a une op´ eration [26]. La granularit´ e du service est alors faible ;

c) un service a plusieurs interfaces, chaque interface liste les op´ erations du service. Il est

1.1. Les composants logiciels vice »

.

La typologie service requis/ service fourni caract´ erise les flux de services entrant dans le composant et sortant du composant mais ne diff´ erencie pas l’utilit´ e d’un service. A cet effet, les services d’un composant sont r´ epartis en deux cat´ egories :

– les services fonctionnels, propres ` a un composant et correspondant aux fonctionnalit´ es pour lesquelles il a ´ et´ e cr´ e´ e ;

– les services non fonctionnels, communs ` a un ensemble de composants, correspondant ` a des probl´ ematiques g´ en´ erales de la cbc . Ces services permettent par exemple de g´ erer les liaisons, le cycle de vie, le comportement du composant. Ils sont souvent propres ` a un mod` ele de composants (cf. section 1.1.4).

L’autre point concerne le nombre de services qu’un composant fournit. Si un composant n’offre qu’un service, alors ce composant aura une granularit´ e faible : de ce fait, le syst` eme devra comporter de nombreux composants pour assurer toutes ses fonctionnalit´ es et il sera plus difficile ` a « manipuler ». En revanche, autoriser un composant ` a offrir plusieurs services permet d’agglom´ erer les services. Le composant propose alors un point d’acc` es centralis´ e ` a plusieurs services. Cette probl´ ematique rejoint celle de la composition que nous d´ etaillons ci-apr` es.

1.1.3 Composition de composants

Un composant, en tant qu’« unit´ e de composition », est destin´ e ` a faire partie d’un assem- blage. Cet assemblage, ` a travers les liaisons entre les composants d’un syst` eme, caract´ erise l’architecture de ce syst` eme.

1.1.3.1 Typologie de composition

En se limitant ` a des aspects architecturaux, la composition de composants est possible suivant deux directions [27] :

– la composition horizontale met en relation deux composants de mˆ eme granularit´ e. Elle permet de r´ esoudre les d´ ependances d’un composant en faisant correspondre ses inter- faces de service requis avec les interfaces de service fourni d’autres composants. Les deux composants sont distincts dans le syst` eme ;

– la composition verticale (ou hi´ erarchique) permet ` a un composant, dit alors composite, d’encapsuler d’autres composants (simples ou eux-mˆ eme d´ ej` a composites). Ces derniers sont des sous-composants du composite. Le composite est alors de plus forte granularit´ e que ses sous-composants. Le composite peut ainsi proposer un point d’acc` es unique aux services offerts par ses sous-composants. De plus, il peut r´ esoudre en interne ses d´ epen- dances et ainsi cacher au reste du syst` eme les services qu’il requiert.

Ainsi, sur la figure 1.2, le composant Engine est compos´ e horizontalement avec le composant Wheel via l’interface IWheel ; le composant Car est un composite dont l’interface de service fourni ICar est r´ ealis´ e par le composant Engine.

La composition, qu’elle soit horizontale ou verticale, consiste de fa¸con traditionnelle ` a une composition structurelle, c.-` a-d. ` a la mise en correspondance syntaxique d’interfaces de deux

7. « service » est au singulier car une interface expose un service, ce service est soit requis, soit fourni.

Figure 1.2 – Exemple de compositions horizontale et verticale

composants distincts. Ce type de composition n’est pas suffisant car il ne tient pas compte des contraintes comportementales des composants compos´ es. En effet, la composition des com- portements individuels de chaque composant doit former un nouveau comportement global coh´ erent. Les caract´ eristiques de ce nouveau comportement d´ ependent des caract´ eristiques de chacun des comportements combin´ es et de la mani` ere dont ces comportements sont combi- n´ es. La composition structurelle est alors associ´ ee ` a une composition comportementale. Cette derni` ere fait intervenir des contraintes de s´ equentialit´ e ou de concurrence sur les op´ erations relatives ` a un service [28–30]. Par exemple, consid´ erons le syst` eme, d´ eriv´ e de [30], comportant les trois composants suivants :

– le composant Gestionnaire de stockage, qui propose un service de stockage avec les op´ erations charger et sauvegarder ;

– le composant Gestionnaire de cryptage, qui propose un service de cryptage avec les op´ erations crypter et decrypter ;

– le composant Gestionnaire de stockage crypt´ e, qui propose un service de stockage crypt´ e et qui est compos´ e horizontalement avec les deux composants pr´ ec´ edents.

Nous ne voulons autoriser que le stockage de fichiers crypt´ es. De ce fait, le composant Stockage crypt´ e ne doit invoquer l’op´ eration sauvegarder qu’apr` es avoir invoqu´ e l’op´ eration crypter et invoquer l’op´ eration d´ ecrypter qu’apr` es avoir invoqu´ e l’op´ eration charger (cf.

fig. 1.3). La simple mise en correspondance des interfaces ne permet pas d’obtenir ce type de comportement qui introduit une contrainte sur la s´ equence des op´ erations. Le composant Stockage crypt´ e doit donc impl´ ementer la s´ equence correcte d’invocations.

1.1.3.2 Moment de la composition

Les composants sont des briques logicielles r´ eutilisables et d´ eployables ind´ ependamment.

Dans l’ing´ enierie des composants logiciels, les m´ ethodes de conception ascendante sont privil´ e-

gi´ ees : un syst` eme est un assemblage de composants pr´ eexistants. Si un service n´ ecessaire au

syst` eme n’est fourni par aucun composant pr´ eexistant, un composant doit ˆ etre con¸cu sp´ eciale-

ment pour l’assurer. Dans ce contexte, la composition intervient ` a diff´ erents moments :

1.1. Les composants logiciels

Figure 1.3 – Exemple de contrainte de comportement

compos´ es horizontalement entre eux. En revanche, lier des composants horizontalement en dehors de la formation d’un composite empˆ eche le d´ eploiement ind´ ependant des compo- sants, ce qui est contraire ` a la d´ efinition retenue (cf. la d´ efinition de Councill et Heineman

`

a la section 1.1.1) ;

– au d´ eploiement, la composition consiste ` a instancier un assemblage particulier de compo- sants (composition horizontale et verticale) : ` a partir d’un mˆ eme jeu de composants, des assemblages diff´ erents peuvent ˆ etre d´ eploy´ es ;

– ` a l’ex´ ecution, la composition consiste ` a modifier les liaisons existant entre composants : des instances diff´ erentes d’un mˆ eme assemblage vont ´ evoluer de fa¸con ind´ ependante ; dans le cas d’une modification de la composition horizontale, la litt´ erature parle de reconfiguration dynamique (cf. 3.1.1). La modification d’une composition verticale n´ ecessite d’avoir acc` es

`

a la structure interne du composite. Ceci d´ epend alors du niveau de visibilit´ e offert par le composant.

1.1.3.3 Visibilit´ e du composant

La composition soul` eve le probl` eme de la visibilit´ e du composant, c’est-` a-dire des informa- tions dont a besoin un consommateur pour utiliser un composant. La litt´ erature distingue trois niveaux de visibilit´ e [12, 15, 31] :

– la visibilit´ e boˆıte noire : le composant n’est compr´ ehensible que par ce qu’il expose dans ses

interfaces. L’interface pr´ ecise la syntaxe pour invoquer les op´ erations du service. Elle peut

aussi pr´ eciser la s´ emantique du service ` a l’aide de pr´ econditions (c.-` a-d. les conditions de

fonctionnement du service), d’invariants (c.-` a-d. des conditions vraies ` a tout instant de la vie du composant) et de postconditions (c.-` a-d. le r´ esultat de l’invocation du service) ; – la visibilit´ e boˆıte blanche : tous les d´ etails d’impl´ ementation du composant sont accessibles,

au risque de violer le principe d’encapsulation et de limiter les possibilit´ es de substitution du composant. Avec ce type de visibilit´ e, le consommateur est amen´ e ` a d´ ependre de l’im- pl´ ementation. Il peut alt´ erer l’impl´ ementation afin de personnaliser le composant. Mˆ eme si l’impl´ ementation n’est pas modifi´ ee, le consommateur va s’appuyer sur des d´ etails peut- ˆ etre non pertinents pour le fournisseur mais qui peuvent l’ˆ etre pour le consommateur ; – la visibilit´ e boˆıte grise, introduite par Buchi et Weck [31], offre un compromis des visibilit´ es

pr´ ec´ edentes. Elle doit permettre une meilleure compr´ ehension du fonctionnement d’un composant sans rentrer dans les d´ etails d’impl´ ementation. Buchi et Weck arguent qu’il est entre autres n´ ecessaire de connaˆıtre la s´ equence des interactions d’un composant lors de l’invocation des op´ erations (cf. composition comportementale, section 1.1.3.1).

Si l’impl´ ementation r´ ev` ele tous les d´ etails d’un composant, nous savons d’exp´ erience que sa compr´ ehension n´ ecessite de nombreuses investigations. De plus, l’acc` es ` a l’impl´ ementation ne permet pas de prot´ eger un savoir-faire. De ce fait, d’autres informations sur le composant doivent ˆ etre exploit´ ees : la structure interne, les s´ equences d’invocation, la documentation, l’´ etat courant, le mod` ele, etc.

1.1.4 D´ efinition d’un mod` ele de composants

Un mod` ele est une abstraction d’un syst` eme autorisant les pr´ edictions ou les inf´ erences [32].

Grˆ ace ` a son pouvoir d’abstraction, un mod` ele permet de faire face ` a la complexit´ e du syst` eme qu’il repr´ esente et permet ainsi d’en faciliter la compr´ ehension. Pour r´ eduire la complexit´ e, un mod` ele se focalise sur un nombre r´ eduit d’aspects du syst` eme (structure, comportement, interactions...). Un ensemble de mod` eles permet alors de d´ ecrire un syst` eme sous diff´ erents angles. De plus, un mod` ele est souvent exprim´ e ` a l’aide d’un langage graphique afin de favoriser la communication entre les personnes intervenants sur le syst` eme.

Dans le contexte de la cbc , un mod` ele de composants d´ efinit la mani` ere dont un composant doit ˆ etre construit. Le mod` ele de composants standardise la structure, les interactions et les principes de composition que les composants doivent respecter pour ˆ etre conformes au mod` ele [19]. Le composant ´ etant ainsi standardis´ e, sa production de masse, syst´ ematique, est facilit´ ee.

Tous les composants respectant un mˆ eme mod` ele de composants ont une « forme » commune et peuvent interop´ erer.

D’apr` es Lau et Wang [26], un mod` ele de composants logiciels est caract´ eris´ e par :

– une s´ emantique d´ ecrivant les composants (d´ efinition des interfaces, services fournis/requis, op´ erations, etc) ;

– une syntaxe (graphique ou textuelle) servant ` a d´ ecrire la structure du composant, ind´ e-

pendamment de la syntaxe d’impl´ ementation ;

1.2. UML et les composants rapport ` a son mod` ele de composants. De ce fait, un composant devrait ˆ etre syst´ ematiquement associ´ e ` a son mod` ele afin de r´ epondre au besoin de documentation (cf. section 1.1.1).

1.2 UML et les composants

1.2.1 UML et l’ing´ enierie des mod` eles

L’ing´ enierie des mod` eles (Model Driven Engineering, mde ) promeut l’utilisation des mod` eles dans le cycle de vie d’un syst` eme logiciel. Pour cela, le mde cherche ` a rationaliser leur utilisation en d´ efinissant, d’une part, les abstractions n´ ecessaires ` a la description d’un syst` eme et, d’autre part, les m´ ethodes exploitant ces abstractions. L’ing´ enierie des mod` eles a ainsi pour but :

1. de faciliter la description d’un syst` eme avec ses probl` emes et ses solutions ;

2. de maintenir la synchronisation d’un syst` eme entre sa sp´ ecification et son impl´ ementation ; 3. de tester et de valider un syst` eme au plus tˆ ot de son cycle de conception.

L’essor du mde dans la cbc [14, 33–37] est en grande partie dˆ u ` a l’initiative de l’Object Management Group ( omg ) avec la standardisation du langage de mod´ elisation graphique uml (Unified Modeling Language) [1] et de leur approche mda (Model-Driven Architecture) [38].

uml regroupe un ensemble de mod` eles pour d´ ecrire la structure, le comportement, l’in- t´ egration d’un syst` eme et pour organiser ces mod` eles. Leur « forme » est contrainte par le m´ etamod` ele d’ uml , qui est lui-mˆ eme un mod` ele. Un mod` ele doit ainsi ˆ etre conforme ` a son m´ etamod` ele pour ˆ etre valide. Le m´ etamod` ele d’ uml est extensible grˆ ace ` a la cr´ eation de pro- fils. Un profil regroupe un ensemble de st´ er´ eotypes s’appliquant ` a des ´ el´ ements du m´ etamod` ele d’ uml et modifiant ainsi leur interpr´ etation.

Le mda est une m´ ethode de conception it´ erative exploitant les mod` eles uml . Il propose de partir de mod` eles fonctionnels abstraits d’un syst` eme (Platform Independent Model, pim , cf. fig.

1.4) pour obtenir une implantation ex´ ecutable du syst` eme sur une plate-forme de r´ ealisation sp´ ecifique (Platform Specific Model, psm , cf. fig. 1.4). Le passage du pim au psm se fait par des

´

etapes successives d’enrichissements et de transformations de mod` eles (cf. figure 1.4) pour ` a la fin g´ en´ erer du code sp´ ecifique ` a un environnement d’ex´ ecution. Ces ´ etapes de transformation garantissent par construction la correction et la conformit´ e de l’impl´ ementation d’un syst` eme avec sa sp´ ecification.

Figure 1.4 – D´ emarche MDA

Dans le but de valider le comportement d’un syst` eme d` es la phase de conception, les mod` eles ont vocation ` a ˆ etre directement ex´ ecut´ es, plutˆ ot que transform´ es en du code ex´ ecutable. Un

« moteur d’ex´ ecution » est alors charg´ e d’interpr´ eter le mod` ele. Il est ainsi possible d’obtenir rapidement un prototype du syst` eme pour v´ erifier son comportement de fa¸con exp´ erimentale ou formelle. L’ex´ ecution de mod` eles n´ ecessite alors que le mod` ele dispose d’une s´ emantique for- melle. Malheureusement, celle d’ uml est ambigu¨e et poss`ede de nombreux « points de variation s´ emantique » [1]. De ce fait, il ne peut exister un unique moteur d’ex´ ecution lui ´ etant stricte- ment conforme. A cet effet, plusieurs initiatives r´ ecentes ( m odel w are [39], t op c ased [40], e clipse m odel e xecution f ramework [41]) proposent des architectures g´ en´ eriques pour d´ evelopper des moteurs d’ex´ ecution dans lesquels la s´ emantique d’ex´ ecution est param´ etrable.

1.2.2 Le mod` ele de composants UML

Figure 1.5 – Mod` ele de composants UML [1]

uml dispose dans son m´ etamod` ele d’une partie relative ` a la mod´ elisation des composants

logiciels. La figure 1.5 pr´ esente cette partie qui d´ ecrit le mod` ele de composants support´ e. Ce

mod` ele se veut g´ en´ erique et permet donc de mod´ eliser des composants ejb , ccm ( Corba Com-

ponent Model) et Microsoft .net [1]. Un composant uml r´ ealise la s´ eparation entre sp´ ecification

et r´ ealisation des services. Le composant (Component) dispose d’un ensemble d’interfaces four-

nies (association provided) et requises (association required) pour pr´ esenter les services qu’il

1.2. UML et les composants – les connecteurs de d´ el´ egation sont utilis´ es pour la composition verticale. Un tel connecteur permet de d´ el´ eguer un service d’un composant ` a un autre. Lorsque le connecteur relie une interface de service fourni d’un composite ` a celle d’un de ses sous-composants, cela signifie que le service est r´ ealis´ e par le sous-composant. Lorsque le connecteur relie une interface de service requis d’un sous-composant ` a celle du composite, cela signifie que le service requis du sous-composant devient un service requis du composite ;

– les connecteurs d’assemblage sont utilis´ es pour la composition horizontale. Ils servent

`

a relier un consommateur de service ` a un fournisseur. Le connecteur d’assemblage relie l’interface de service requis d’un composant avec l’interface de service fourni du composant en charge de la r´ ealisation du service.

Figure 1.6 – Classifieur avec comportement [1]

uml autorise le classifieur qui r´ ealise un composant ` a avoir un comportement (cf. fig. 1.6, association classifierBehavior). Nous nous int´ eressons ci-apr` es ` a la sp´ ecification de ce com- portement ` a l’aide de machines ` a ´ etats.

1.2.3 Les machines ` a ´ etats UML

Une machine ` a ´ etats uml permet de d´ ecrire le comportement d’un classifieur uml , qui peut lui-mˆ eme servir ` a la r´ ealisation des services d’un composant. Ces machines ` a ´ etats reposent sur le formalisme des Statecharts de Harel [42] qui sont eux-mˆ emes une ´ evolution des automates ` a

´

etats finis [43].

1.2.3.1 Structure des machines ` a ´ etats

Une machine ` a ´ etats est une structure arborescente (cf. l’exemple de la figure 1.7, partie gauche) ayant les caract´ eristiques suivantes :

– la racine est la machine elle-mˆ eme ;

– les nœuds des niveaux impairs sont des r´ egions ;

– les nœuds des niveaux pairs sont des ´ etats ;

Figure 1.7 – Exemple de structure d’une machine ` a ´ etats

– les feuilles sont des ´ etats : la machine ` a ´ etats poss` ede au moins une r´ egion et une r´ egion poss` ede au moins un ´ etat ;

– un des ´ etats d’une r´ egion est l’´ etat initial de cette r´ egion ;

– une r´ egion peut poss´ eder un ´ etat final, distinct de l’´ etat initial de cette r´ egion ; – un ´ etat final est toujours une feuille.

La terminologie suivante s’applique alors :

– un ´ etat qui poss` ede au moins une r´ egion est dit composite ;

– un ´ etat qui ne poss` ede pas de r´ egion est dit simple, une feuille est donc un ´ etat simple ; – un ´ etat qui r´ ef´ erence la racine d’une autre machine ` a ´ etats est dit de sous-machine, ses

fils sont alors les r´ egions de la machine r´ ef´ erenc´ ee (sur la figure 1.7, les sous-arbres de l’´ etat de sous-machine ont ´ et´ e omis) ;

– deux ´ etats sont dits orthogonaux lorsque leur ancˆ etre commun est un ´ etat ; – deux ´ etats sont dits exclusifs lorsque leur ancˆ etre commun est une r´ egion.

Deux ´ etats exclusifs peuvent ˆ etre connect´ es par une transition : un des ´ etats est l’´ etat- source de la transition, l’autre est l’´ etat-cible

. Une transition est ´ etiquet´ ee suivant la syntaxe [<d´ eclencheur>][<garde>][“/” <effet>] pour laquelle :

– le d´ eclencheur sp´ ecifie l’´ ev´ enement (cf. section ci-apr` es) auquel la transition est sensible.

Une transition qui n’a pas de d´ eclencheur est une transition d’ach` evement ; – la garde est une condition bool´ eenne ;

– l’effet est une suite d’actions (par ex. invocation d’op´ erations, envoi de signal...) r´ ealis´ ees lorsque la transition est franchie.

Par ailleurs, un ´ etat peut poss´ eder :

– des transitions dites « internes », qui sont des transitions n’ayant pas d’´ etat-cible et, par cons´ equent, n’entraˆınant pas de changement d’´ etats ;

– une action d’entr´ ee et une action de sortie ;

1.2. UML et les composants 1.2.3.2 Fonctionnement des machines ` a ´ etats

Une instance de machine ` a ´ etats poss` ede une configuration d’´ etats actifs. La configuration initiale d’´ etats actifs est l’arbre de la machine ` a ´ etats pour lequel chaque r´ egion ne poss` ede que le fils ´ etant l’´ etat initial de cette r´ egion (cf. fig. 1.7, partie droite). Les feuilles de la configuration d’´ etats actifs sont alors des ´ etats simples, orthogonaux entre eux.

Une fois que la configuration initiale a ´ et´ e construite, la machine est prˆ ete ` a r´ eagir ` a des

´

ev´ enements. Ces ´ ev´ enements sont de plusieurs types :

– les ´ ev´ enements de signal : une machine ` a ´ etats communique de fa¸con asynchrone avec une autre machine en lui envoyant un signal. La r´ eception du signal constitue un ´ ev´ enement pour la machine destinataire. La machine ´ emettrice n’attend pas que le signal soit trait´ e pour poursuivre son propre fonctionnement. La machine ´ emettrice peut ˆ etre son propre destinataire. C’est le type d’´ ev´ enement utilis´ e dans les Statecharts ;

– les ´ ev´ enements d’appel : une op´ eration est appel´ ee sur le classifieur dont la machine d´ ecrit le comportement. L’invocation de l’op´ eration constitue un ´ ev´ enement pour la machine du destinataire. L’appelant attend que la machine ait trait´ e l’´ ev´ enement pour poursuivre son fonctionnement [44] ;

– les ´ ev´ enements de changement : le d´ eclencheur d’une transition est exprim´ e avec une condition bool´ eenne (ind´ ependamment de celle correspondant ` a la garde de la transition).

Le fait que cette condition devienne vraie, lorsque l’´ etat-source de la transition associ´ ee est actif, constitue un ´ ev´ enement pour la machine ` a ´ etats. Pour des raisons de performance, ce type d’´ ev´ enement est ` a utiliser avec prudence. En effet, il n´ ecessite souvent une attente active monopolisant les ressources du syst` eme ;

– les ´ ev´ enements temporels : absolus, lorsqu’un moment particulier vient de passer, ou re- latifs, lorsqu’une certaine dur´ ee vient de s’´ ecouler. La dur´ ee ´ ecoul´ ee est alors relative au moment de l’activation de l’´ etat qui est la source de la transition sp´ ecifiant l’´ ev´ enement comme d´ eclencheur ;

– des ´ ev´ enements d’ach` evement : un ´ ev´ enement d’ach` evement est g´ en´ er´ e :

• lorsqu’un ´ etat simple est activ´ e, s’il ne poss` ede ni activit´ e ni action d’entr´ ee,

• apr` es que l’action d’entr´ ee et l’activit´ e d’un ´ etat simple se soient toutes les deux ter- min´ ees,

• lorsque l’activit´ e d’un ´ etat composite se termine et que les ´ etats finaux de ses r´ egions sont actifs.

Cet ´ ev´ enement est prioritaire par rapport aux autres et permet de d´ eclencher une transi- tion d’ach` evement (cf. section 1.2.3.3).

La machine ` a ´ etats traite les occurrences d’´ ev´ enement suivant le mode run-to-completion, c.-` a-d. qu’elle ne consid` ere qu’une occurrence ` a la fois. Lorsqu’un ´ ev´ enement est re¸cu, il est mis

`

a la fin de la file d’attente des ´ ev´ enements de la machine ` a ´ etats (sauf pour les ´ ev´ enements

d’ach` evement qui sont trait´ es prioritairement). Cette derni` ere pr´ el` eve l’´ ev´ enement en tˆ ete de

file et regarde s’il constitue un d´ eclencheur pour une transition. Cette derni` ere est franchissable

si sa garde est vraie et que son ´ etat-source est actif. Le franchissement s’effectue toujours selon

l’ordre suivant : l’activit´ e de l’´ etat-source est arrˆ et´ ee si elle n’est pas termin´ ee, l’action de sortie

de l’´ etat-source, puis l’effet de la transition, ensuite l’action d’entr´ ee et enfin l’activit´ e de l’´ etat- cible sont ex´ ecut´ es. Le franchissement d’une transition interne ne provoque pas de changement d’´ etat. Seul l’effet de la transition est alors ex´ ecut´ e.

Deux transitions sont franchissables en mˆ eme temps seulement si leurs ´ etats-sources sont orthogonaux. Deux transitions franchissables dont les ´ etats-sources sont exclusifs sont soumis

`

a un m´ ecanisme de priorit´ e : la transition dont l’´ etat-source est un sous-´ etat de l’´ etat-source de l’autre transition est la transition qui sera effectivement franchie. Si les deux ´ etats-sources sont identiques, alors la transition dont le d´ eclencheur est le plus sp´ ecialis´ e (dans le cas d’une hi´ erarchie de signaux) sera effectivement franchie. Si le choix ne peut ˆ etre fait entre les deux transitions, la machine est ind´ eterministe et par cons´ equent mal form´ ee. Notons que le m´ e- canisme de priorit´ e rend possible la red´ efinition d’une transition dans un sous-´ etat, masquant ainsi celle contenue dans le super-´ etat.

1.2.3.3 Exemple de machine ` a ´ etats

Figure 1.8 – Exemple de machine ` a ´ etats

La figure 1.8 pr´ esente la syntaxe graphique utilis´ ee pour les machines ` a ´ etats avec l’exemple de la machine ` a ´ etats Car. Cette derni` ere d´ ecrit le comportement d’une voiture. Elle com- prend deux r´ egions (mat´ erialis´ ees par le trait discontinu les s´ eparant) dont les ´ etats Stopped et TankIsFullEnough sont les ´ etats initiaux (d´ esign´ es par le disque noir et la fl` eche qui en sort).

L’´ etat Moving est un ´ etat composite comportant une r´ egion qui contient deux sous-´ etats simples.

1.3. Le mod` ele de composants PauWare Backward et TankIsFullEnough sont actifs, la configuration active comprend les ´ etats Moving, Backward et TankIsFullEnough.

L’´ etat TankIsFullEnough ex´ ecute l’activit´ e mesure() (d´ esign´ ee par do/), qui mesure le niveau du r´ eservoir de la voiture, tant qu’il est actif et que la mesure n’est pas termin´ ee. Lorsque cette derni` ere se termine, la transition d’ach` evement dont la garde est vraie est franchie. Si le niveau du r´ eservoir devient inf´ erieur ou ´ egal ` a 20%, l’´ etat FuelIsLow est activ´ e. Le signal Alarm, indiquant que le niveau du r´ eservoir est bas, est ´ emis ` a l’entr´ ee dans cet ´ etat (d´ esign´ e par entry/). Ce signal est envoy´ e ` a la machine ` a ´ etats monitor (l’envoi de signal s’exprime avec la notation destinaire^signal qui correspond ` a l’op´ erateur ocl hasSent). L’activit´ e mesure() est ensuite ex´ ecut´ ee dans cet ´ etat.

1.3 Le mod` ele de composants PauWare

p au w are

[2] est un mod` ele de composants issu de l’ing´ enierie des mod` eles. Un composant p au w are a la particularit´ e d’associer ` a sa sp´ ecification structurelle une sp´ ecification comporte- mentale ` a base de machines ` a ´ etats. Il propose des principes de composition horizontale et de composition verticale bas´ es sur le comportement des composants, plutˆ ot que sur la structure comme le font les mod` eles de composants ejb [17], ccm [45] et f ractal [46].

1.3.1 Principes

Un composant p au w are utilise une machine ` a ´ etats uml pour d´ ecrire son comportement et le r´ ealiser. La machine ` a ´ etats est alors embarqu´ ee dans le composant et est ex´ ecut´ ee par un moteur d’ex´ ecution respectant la s´ emantique d’ uml

. Le composant fournit un ensemble de services fonctionnels list´ es dans son interface de services fournis. Chaque service fourni corres- pond ` a un signal ´ etiquetant une transition dans la machine ` a ´ etats du composant. Les actions correspondent ` a l’invocation d’op´ erations dans la classe d’impl´ ementation et ` a des requˆ etes de services. Les services requis correspondent ` a des signaux envoy´ es ` a d’autres composants. Un composant p au w are fournit aussi un ensemble de services non fonctionnels list´ es dans son in- terface de configuration. Ces services permettent par exemple d’agir directement sur la machine

`

a ´ etats en for¸cant un ´ etat particulier. Cette structure simple permet d’int´ egrer les principes de p au w are ` a d’autres mod` eles, comme cela a ´ et´ e fait pour les ejb dans [47].

La figure 1.9 pr´ esente en exemple les sp´ ecifications structurelle et comportementale d’un composant p au w are nomm´ e PauWare Component. L’interface PauWare component functio- nal interface expose les services fournis du composant (go(), request_b(), etc.). L’interface PauWare component configuration interface propose le service reset() pour r´ einitialiser le composant en activant la configuration initiale de sa machine ` a ´ etats. La classe PauWare component implementation class liste les op´ erations invoqu´ ees (a(), w(), etc.) par les ac- tions de la machine ` a ´ etats. Le comportement repr´ esent´ e par la machine ` a ´ etats est ex´ ecut´ e par

9. http ://www.pauware.com/

10. Comme pr´ ecis´ e ` a la section 1.2.1, ce respect est limit´ e par les points de variation s´ emantique et par

l’ambigu¨ıt´ e d’ uml .

le moteur Statechart_monitor int´ egr´ e au composant.

A son initialisation, le composant est dans l’´ etat Idle. Seule l’invocation du service go() provoque une r´ eaction de la part du composant. La machine ` a ´ etats transite en cons´ equence vers l’´ etat Busy et active ses ´ etats initiaux (S11, S22, S31 et S32). L’action w() est ainsi ex´ ecut´ ee

`

a l’entr´ ee dans l’´ etat S11. Le service requis request_h() est appel´ e ` a l’entr´ ee dans l’´ etat S22.

A partir de cette configuration active, seule l’invocation de l’un des services request_b(), request_c(), request_d() et request_e() provoque une r´ eaction de la part du composant.

1.3.2 Composition des composants PauWare

Les composants p au w are supportent une forme de composition horizontale en communi- quant de mani` ere asynchrone par envoi de signaux. La figure 1.10 montre les machine ` a ´ etats d’un composant Car et d’un composant GearBox. Lorsque le service shift() est invoqu´ e sur le composant Car, ce dernier passe de l’´ etat Stopped ` a Moving et invoque le service up() du composant GearBox. Celui-ci d´ eclenche en r´ eponse l’action interne moveUp().

Les composants p au w are supportent de plus la composition verticale en composant les machines ` a ´ etats via les ´ etats de sous-machine [48]. Un ´ etat de sous-machine orthogonal au comportemement du composite est alors rajout´ e pour chaque sous-composant. Cet ´ etat est destin´ e ` a accueillir la machine ` a ´ etats du sous-composant. Ainsi, lorsque le composite re¸coit un signal, il est diffus´ e dans les machines ` a ´ etats des sous-composants.

Sur la figure 1.11, le composant Car est maintenant compos´ e verticalement avec le compo-

sant GearBox et avec un composant Tank Monitor. Lorsque le service shift() est invoqu´ e,

le composant Car transite toujours de l’´ etat Stopped ` a Moving mais cette fois-ci s’envoie ` a

lui-mˆ eme (self^) le signal up(). Ce signal est alors diffus´ e dans sa machine ` a ´ etats qui atteint

directement celle du composant GearBox et aussi celle du composant Tank Monitor. Le signal

up() ne correspondant ` a aucun service du composant Tank Monitor, il n’a pas de cons´ equence

sur ce dernier.

1.3. Le mod` ele de composants PauWare

Figure 1.9 – Sp´ ecification du composant PauWare Component [2]

Figure 1.10 – Composition horizontale dans PauWare

Figure 1.11 – Composition verticale dans PauWare