Propriétés des systèmes de reconfiguration

Plusieurs propriétés doivent être vérifiées par un système de reconfiguration. Ces propriétés, qui vont permettre d’évaluer et de comparer les systèmes, sont discutées dans cette sous-section.

3.3.1 La cohérence de l’application reconfigurée

Le système de reconfiguration chargé de lancer l’opération de reconfiguration, a naturellement des privilèges par rapport à l’application qu’il est en charge de reconfigurer. Cependant, ceci ne lui donne pas le droit de tout faire de cette application. Le système de reconfiguration doit préserver la cohérence de l’application :

la reconfiguration doit être lancée à des moments adéquats,

le système de reconfiguration ne doit pas forcer l’application à se reconfigurer brusquement,

il ne doit agir sur cette application que si elle est dans un état stable, c'est-à-dire une situation à partir de laquelle elle peut reprendre normalement son exécution. Dans une application à base de composants, la cohérence peut être locale ou globale [Dep01].

Cohérence locale : elle concerne une seule instance de composant indépendamment des autres instances de l’application. Par exemple, lorsqu’une instance est altérée au moment où elle modifie l’une de ses ressources (base de données, fichier…), elle peut ne pas pouvoir revenir dans un état stable.

Cohérence globale : elle concerne l’application dans sa globalité. Par exemple, les messages ou les données transitant dans l’application ne doivent pas être perdus. Dans [Hic01], la cohérence d’une application a été caractérisée par les propriétés suivantes:

Sécurité : le système de reconfiguration ne doit pas, par exemple, créer des trous de sécurité ou causer le blocage de l’application.

Complétude : après un temps fini, le système de reconfiguration doit terminer les opérations qu’il entreprend sur l’application.

"Well-timedness" : la reconfiguration ne doit être lancée qu’à des points temporels bien précis où l’application est considérée dans un état stable. Les points temporels de stabilité sont souvent appelés les points de reconfiguration [Tan00, Dep01].

Possibilité de retour en arrière : il est nécessaire de prévoir des mécanismes permettant d’annuler les modifications introduites par le système de

reconfiguration en cas de problèmes, et de rétablir l’application dans un état cohérent.

3.3.2 Performance de reconfiguration

Les opérations réalisées par le système de reconfiguration doivent être efficaces : leur durée doit être la plus courte possible. Dans le même sens, le nombre de composants et d’instances de composants affectés par les opérations de reconfiguration doit être le plus faible possible.

3.3.3 Degré d’automatisation

Le degré d’automatisation représente la capacité du système de reconfiguration à décider et à lancer des opérations de reconfiguration. Ceci peut être possible si en exécution, le système de reconfiguration a toutes les informations et la logique lui permettant de décider qu’une reconfiguration est nécessaire, et également, tous les mécanismes nécessaires à réaliser une telle reconfiguration sans l’intervention d’un acteur externe.

3.3.4 Facilité d’utilisation

Raisonner sur une certaine situation particulière, découvrir même cette situation, décider les opérations adéquates à lancer, lancer effectivement ces opérations et raisonner à nouveau sur la nouvelle situation est un long cycle de tâches complexes et non triviales. Le système de reconfiguration doit être intuitif, facile à utiliser, automatisé au maximum et doit permettre aux administrateurs de comprendre et d’agir facilement sur les applications administrées.

Kramer et Magee [KM90] proposent plusieurs propriétés à respecter pour la reconfiguration dynamique des applications modulaires. Ces propriétés sont résumées dans les points suivants :

Les changements doivent être spécifiés en termes de la structure de l’application : les changements au niveau de la programmation d’un composant sont considérés de très bas niveau. Ils sont complexes et trop détaillés à cause du fort couplage entre les éléments de programmation du même composant.

Les changements doivent être spécifiés d’une manière déclarative : le programmeur peut potentiellement spécifier les changements nécessaires à l’application et sous quelles conditions. Il appartient au système de reconfiguration de décider des actions qu’il faut appliquer et de l’ordre dans lequel elles sont appliquées. Ceci permet de séparer la spécification des besoins des solutions qu’il faut mettre en oeuvre pour les satisfaire.

Le système de reconfiguration doit être séparé des applications à reconfigurer. Ceci permet d’obtenir un système de reconfiguration générique (indépendant d’une application particulière).

Les changements doivent garantir la cohérence de l’application reconfigurée : un état cohérent est un point à partir duquel l’application peut continuer à s’exécuter normalement pour fournir des résultats corrects.

L’application reconfigurée doit être affectée le moins possible : le système de reconfiguration doit être capable de localiser l’ensemble des composants concernés par la reconfiguration. Le reste de l’application doit continuer à s’exécuter normalement.

La réflexion, qui se traduit par la capacité d’un système à raisonner et à agir sur lui-même, a prouvé depuis de longues années son importance pour le développement de systèmes flexibles et facilement adaptables [CCL00]. La section suivante est consacrée à l'étude des systèmes réflexifs.

4

4 SS

Les systèmes réflexifs ont la propriété d’être capables d’utiliser leur propre représentation pour étendre et adapter leur comportement [OGB98]. Ils incorporent des structures représentant leurs propres aspects, et grâce à ces structures, ils accèdent et manipulent leurs comportements et structures internes. Dans [Mae87], la réflexion a été définie comme une activité réalisée par un agent quand il réalise des calculs sur lui-même.

La réflexion est donc l’une des solutions permettant de créer des applications qui sont capables de maintenir, d’utiliser et de changer la représentation de leur propre conception structurelle et comportementale. Son intégration dans les langages de programmation date des travaux déterminants de B. Smith [Smi82,Smi84] au début des années 80. B. Smith a introduit la notion des tours réflexives, en considérant qu’un système réflexif peut être structuré en un nombre infini de tours, où chacune d’elles représente un niveau logique du système.

Dans une vue simplifiée des tours réflexives, il est possible de considérer qu’un système réflexif réunit, en général, deux niveaux principaux :

Le niveau de base représente le système concret, responsable de fournir les fonctionnalités de base attendues du système.

Le méta-niveau constitue une représentation abstraite du système.

A partir des définitions que nous avons présentées, trois notions principales peuvent être identifiées : la réification, l’introspection et l’intercession.