1.4. Synth`ese
1.4 Synth`ese
Un composant est con¸cu pour la r´eutilisation. Il est destin´e `a ˆetre compos´e avec d’autres
composants afin de constituer un syst`eme. Pour cela, il n´ecessite d’avoir des points
d’interac-tion clairement d´efinis. Afin de faciliter son utilisation, il doit ˆetre associ´e `a une documentation
permettant de comprendre son fonctionnement sans acc´eder `a l’impl´ementation. Il est n´
eces-sairement associ´e `a un mod`ele de composants permettant de caract´eriser et de borner l’espace
auquel il appartient.
Un langage de mod´elisation comme uml sp´ecifie un mod`ele de composants g´en´erique afin
de concevoir des composants. Il propose un ensemble de notation pour sp´ecifier la structure
et le comportement de ces derniers. Le comportement d’un composant peut notamment ˆetre
sp´ecifi´e avec des machines `a ´etats. Le mod`ele de composants pauware utilise ces derni`eres
comme support `a la composition.
Un concepteur de composants ne peut pas envisager toutes les situations dans lesquelles sera
utilis´e un composant. Ce dernier doit de ce fait ˆetre personnalisable, ou encore adaptable par
celui qui va l’utiliser. Afin de limiter les interventions humaines, un composant doit id´ealement
ˆ
etre adaptatif, c.-`a-d. capable de s’adapter lui-mˆeme.
Les syst`emes, ind´ependamment du fait qu’ils soient ou qu’ils ne soient pas con¸cus avec des
composants, ont eux-mˆeme besoin d’ˆetre adapt´es. Nous introduisons dans le chapitre suivant
les raisons qui motivent le besoin de construire des syst`emes adaptables et adaptatifs dans le
contexte de l’informatique autonomique et nous d´etaillons les sp´ecificit´es li´ees `a ces syst`emes.
Chapitre 2
Les syst`emes logiciels adaptatifs
Sommaire
2.1 L’informatique autonomique . . . . 34
2.1.1 Les propri´et´esauto-* . . . . 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
La complexit´e atteinte par les syst`emes informatiques actuels entrave leur int´egration, leur
´
evolution et leur gestion. Ces activit´es normalement d´evolues `a des int´egrateurs, d´eveloppeurs
ou administrateurs syst`emes tendent `a ˆetre assur´ees par les syst`emes eux-mˆemes. Cette vision
de syst`emes informatiques qui s’autog`erent a ´et´e d´evelopp´ee en 2001 par ibm lorsque Paul
Horn a introduit l’informatique autonomique [8]. Le terme « autonomique » a ´et´e choisi par
analogie avec le syst`eme nerveux autonome (autonomic nervous system) qui assure entre autres,
la r´egulation de notre fr´equence cardiaque, de notre glyc´emie, de notre respiration, « sans
conscience ni effort»de notre part. Lessyst`emes autonomiquessont donc des syst`emes capables
d’autogestion (self-management) sur lesquelles les interventions humaines sont limit´ees afin
d’accroˆıtre la r´eactivit´e et la disponibilit´e.
La section 2.1 introduit l’informatique autonomique : elle pr´esente les propri´et´es qui lui sont
li´ees, elle d´efinit le concept de « boucle de contrˆole » et elle sensibilise au besoin de
coordina-tion n´ecessaire au maintien de la coh´erence d’un syst`eme autonomique. La section 2.2 d´efinit
les syst`emes adaptatifs, montre qu’ils sont une base n´ecessaire `a la r´ealisation des syst`emes
autonomiques et justifie le besoin de dynamisme et d’ouverture de ces syst`emes. La section
2.3 pr´esente les probl`emes li´es au d´eroulement d’un processus d’adaptation en s’int´eressant au
moment o`u l’adaptation doit ˆetre appliqu´ee, `a la gestion de la coh´erence du syst`eme adapt´e
ainsi qu’`a la continuit´e de l’ex´ecution du syst`eme apr`es son adaptation.
2.1 L’informatique autonomique
2.1.1 Les propri´et´es auto-*
Lors de la pr´esentation de l’informatique autonomique,ibma mis en avant quatre propri´et´es
fondamentales des syst`emes autonomiques [8,49],les self-chop(self-configuration, self-healing,
self-optimization, self-protection) [50]. Ces propri´et´es ont pour but de maintenir les services
assur´es par le syst`eme :
– l’auto-configuration : un syst`eme autonomique assure ses services quel que soit
l’environ-nement dans lequel il ´evolue et quelle que soit l’´evolution de cet environnement ;
– l’auto-r´eparation: un syst`eme autonomique minimise l’impact de ses dysfonctionnements
sur les services qu’il fournit ;
– l’auto-optimisation: un syst`eme autonomique assure ses services avec la meilleure qualit´e
possible `a chaque instant ;
– l’auto-protection : un syst`eme autonomique s’immunise face aux attaques men´ees contre
lui.
Ces propri´et´es constituent la base historique de l’informatique autonomique. Elles ont depuis
´
et´e largement d´eclin´ees et raffin´ees (l’auto-organisation, l’auto-r´ecup´eration, l’auto-assemblage,
l’auto-simulation...) [51–53]. Par ailleurs, elles sont associ´ees `a quatre caract´eristiques n´
eces-saires pour les r´ealiser [8] :
– la conscience de soi : un syst`eme autonomique ne peut g´erer que ce qu’il connaˆıt de
lui-mˆeme ;
– la conscience de son environnement: un syst`eme autonomique est d´eploy´e au milieu d’un
environnement qu’il partage avec d’autres syst`emes. Il doit connaˆıtre cet environnement
et sa place dans cet environnement pour mieux l’appr´ehender ;
– l’ouverture : un syst`eme autonomique est ouvert sur les autres syst`emes pr´esents dans
l’environnement. Il est capable de communiquer avec eux ;
– l’anticipation : un syst`eme autonomique se pr´epare `a traiter des ´ev´enements avant leur
occurrence afin de mieux y r´epondre.
2.1. L’informatique autonomique
contrˆole [50,51,54,55]. La proc´edure pr´ec´edemment effectu´ee par l’administrateur est ainsi
au-tomatis´ee. Ce dernier devient alors le superviseur de la boucle dont le comportement est guid´e
par des politiques de gestion qu’il ´etablit.
Dans son architecture de r´ef´erence pour les syst`emes autonomiques [3], ibm pr´esente des
´
el´ements distincts pour r´ealiser les diff´erentes fonctions de la boucle. Cette derni`ere comprend
(cf. figure 2.1) :
– un ensemble de capteurs (alias sondes, d´etecteurs...) attach´es au syst`eme `a surveiller. Les
sondes peuvent v´erifier les valeurs des param`etres fonctionnels (taux de perte de paquets
sur un r´eseau [56]), la lev´ee d’exceptions [57], la violation d’invariants [58],
l’introduc-tion de nouveaux composants [36], les ressources (taux d’utilisation du processeur, de la
m´emoire), etc. ;
– un surveillant qui collecte les informations aupr`es des capteurs, les aggr`ege, les filtre ;
– un analyseur (alias ´evaluateur, d´ecideur...) qui corr`ele les informations re¸cues du
sur-veillant et mod´elise les ph´enom`enes observ´es ;
– un planificateur qui, en fonction des ´el´ements rapport´es par l’analyseur, produit la liste
des actions `a r´ealiser ;
– un ex´ecuteur qui r´ealise le plan des actions pr´ec´edemment ´etabli ;
– un ensemble d’effecteurs (alias actionneurs...) pour agir sur le syst`eme ;
– une base de connaissances qui regroupe toutes les informations n´ecesaires au contrˆole
(mod`eles math´ematiques, historique des ´ev´enements, plans r´ealis´es, connections...) ;
– une politique qui guide la prise de d´ecision de l’analyseur. Trois types se distinguent [59] :
• une politique `a base d’actions, la plus simple, est un ensemble de r`egles ´ev´
enement-condition-actions o`u la condition se rapporte `a l’´etat courant du syst`eme sur lequel la
r`egle s’applique. L’action permet d’atteindre un nouvel ´etat ;
• une politique `a base de buts dans laquelle, `a partir d’un ´etat courant, un ensemble
d’´etats-cibles est sp´ecifi´e. Le syst`eme est charg´e de d´eterminer les actions qui permettent
de les atteindre ;
• une politique `a base de fonctions d’utilit´e dans laquelle les ´etats-cibles sont ordonn´es
par ordre de satisfaction. La fonction d’utilit´e calcule alors `a partir de l’´etat courant
du syst`eme un indice de satisfaction pour chaque ´etat cible.
L’exemple de la figure 2.2, inspir´e de [55], r´ealise une boucle contrˆolant la temp´erature d’une
pi`ece. Un capteur mesure p´eriodiquement la temp´erature de la pi`ece et envoie la valeur `a un
thermostat. Le thermostat comporte une politique d’actions :
– si la temp´erature est sup´erieure `a 20
oC, le thermostat commande la mise en marche de
la climatisation afin de refroidir la pi`ece ;
– si la temp´erature est inf´erieure `a 18
oC, la climatisation est arrˆet´ee.
2.1.3 Coordination des boucles de contrˆole
Une boucle de contrˆole peut exister `a plusieurs niveaux dans un syst`eme autonomique :
– `a un niveau global : le syst`eme dispose d’une unique boucle de contrˆole. Le contrˆole
est ainsi centralis´e et n´ecessite une connaissance globale du syst`eme pour l’appr´ehender.
Cette approche permet d’avoir un interlocuteur unique et connu pour orchestrer le
Dans le document
MOCAS : un modèle de composants basé états pour l'auto-adaptation
(Page 45-50)