Étude et analyse des performances de l’approche d’auto-adaptation structurelle dynamique de composants

Contrairement au surcoût lié à l’adaptation structurelle par la ré-ingénierie qui est inhérent à la mise en œuvre de la distribution du composant, le surcoût lié à l’approche d’auto-adaptation structurelle dy- namique est permanent. En fait, il fait référence :

• au surcoût engendré par le format canonique du composant lors de son exécution

La génération du composant sous format canonique impose la mise en œuvre des mécanismes de communication et de synchronisation entre les composants primitifs même s’ils ne sont pas dis- tribués. Ce qui implique que, contrairement à l’adaptation statique où le surcoût nécessaire pour garantir la cohérence du comportement du composant lié à sa distribution est indispensable, dans le cas dynamique, ce surcoût doit être considéré comme permanent. Cependant, il est nécessaire afin d’assurer une grande flexibilité du composant. En fait, plus le composant auto-adaptatif contient de composants primitifs, plus le nombre de combinaisons possibles pour la reconfiguration de sa structure sera important. Donc, l’augmentation de la flexibilité de la structure d’un composant en- traîne une dégradation des performances de ce dernier qui peut être réduite par la parallélisation des services quand les composants primitifs sont distribués.

Le calcul de ce surcoût est présenté dans le chapitre précédent ;

• au surcoût engendré par l’acquisition et le traitement du contexte d’exécution pour déclencher

une phase d’adaptation et calculer une structure du composant adaptée

L’acquisition et le traitement du contexte d’exécution d’un composant entraîne un surcoût en terme d’espace mémoire occupée et de performance. Concernant l’espace mémoire occupée, celle-ci dé- pend du nombre d’éléments de contexte pris en compte et de leur taille mémoire. De plus, afin d’optimiser le comportement de l’adaptation, nous avons vu qu’il est nécessaire de conserver un historique ; ce qui peut se révéler très consommateur en terme d’espace mémoire. Il doit donc être

envisagé d’adapter le nombre d’éléments pris en compte en fonction des ressources disponibles. Par ailleurs, le contexte doit être acquis et analysé en permanence afin de pouvoir garantir la conti- nuité de service du composant en déclenchant une phase d’adaptation dès lors que les ressources disponibles sont jugées insuffisantes. Cette activité d’acquisition du contexte induit donc égale- ment un surcoût en termes de performance ;

• au surcoût engendré par la prise de décision

La prise de décisions réalisée au cours d’un processus d’auto-adaptation introduit également un surcoût en terme d’espace mémoire occupée et de performance. Ce surcoût est étroitement lié aux mécanismes mis en œuvre pour déclencher une phase d’adaptation et générer automatiquement une structure adaptée à la situation. Ces deux tâches sont réalisées par l’intermédiaire de règles que nous avons définies dans les sections précédentes. Aussi, le surcoût engendré par ces deux tâches dépend du nombre de règles utilisées et de leur complexité.

Concernant les règles de déclenchement de l’adaptation, ces règles sont de type évènement/action. De ce fait, leur complexité est négligeable. Concernant les règles de génération automatique de la spécification de l’adaptation, leur complexité dépend de leur tâche à accomplir. Les règles relatives

à la classification des services en fonction de leur priorité ont une complexité deO (log n), n cor-

respondant au nombre de services fournis par le composant. Les règles d’association des services à leur site de déploiement sont quant à elle linéaire ; les algorithmes de regroupement hiérarchique étant linéaires [72].

Cependant, afin de diminuer le surcoût lié aux prises de décisions au moment de l’adaptation, il est possible d’agir sur les règles de génération de la spécification de la nouvelle structure. En effet, certaines règles notamment liées à l’optimisation du résultat de l’adaptation telles que prise en compte du contexte applicatif pourraient être ignorées de manière à réduire la complexité de la prise de décisions et ainsi diminuer le surcoût de l’adaptation ; notre objectif premier étant d’assu- rer la continuité de service et non optimiser les performances de l’application. Le choix de la prise en compte de ces règles d’optimisation doit donc être fait en fonction des ressources disponibles ; • au surcoût lié à la réalisation de l’adaptation du composant

Ce surcoût fait référence au surcoût engendré par la réalisation de la reconfiguration de la structure interne du composant en fonction de la spécification générée lors de la prise de décisions et au redéploiement des composants créés lors de la reconfiguration.

Concernant le surcoût de la reconfiguration du composant, il est étroitement lié au modèle de composants utilisé.

Creconf iguration= λ ∗ Cencapsulation+ µ ∗ Ceclatement (4.15)

Cencapsulation= (α + β) ∗ CBD+ CCC+ (2 ∗ α + β + γ) ∗ CBC (4.16)

Ceclatement= (2 ∗ α + β + γ) ∗ CBD+ CCD+ (α + β) ∗ CBC (4.17)

λ : nombre d’opérations d’encapsulations de composants primitifs nécessaires pour l’obtention de la nouvelle structure µ : nombre d’opérations d’éclatements de composites nécessaires pour l’obtention de la nouvelle structure

α : nombre de services encapsulés

β : nombre de fois où un services requis par l’un des composants encapsulés n’est pas fourni par le composite γ : nombre de services requis par le composite

CBC: coût de création d’une liaison

CCC: coût de création d’un composite par encapsulation

CCD: coût de destruction d’un composite par encapsulation

Le surcoût lié au redéploiement des sous-composants générés lors de la reconfiguration de la structure du composant dépend quant à lui des paramètres suivants :

1. des performances de l’infrastructure distribuée utilisée (bande passante, taux d’occupation du réseau, etc.),

2. de temps de chargement du composant transféré sur la machine distante,

3. du coût du transfert d’état du composant initial vers le nouveau composant déployé sur la machine distante.

Bilan Le surcoût lié à notre modèle de composants dynamiquement auto-adaptatifs étant relativement important comme nous avons pu le constater, il parait relativement peu envisageable de doter tous les composants d’une même application de tels mécanismes. Ainsi, une stratégie de gestion de l’adapta- tion au niveau de l’application s’impose. En effet, une centralisation de l’acquisition et du stockage du contexte d’exécution de l’application ainsi que des mécanismes de prises de décisions, sur un site permet de réduire fortement le coût de l’adaptation en terme d’espace mémoire occupé et de performances. Une telle affirmation renforce donc la nécessité de gérer l’adaptation au niveau macro comme nous l’avons proposé dans la section précédente.

4.9

Conclusion

Nous avons présenté dans ce chapitre une approche permettant à un composant de logiciel d’adapter automatiquement sa structure en fonction de son contexte d’exécution. Pour posséder une structure auto- adaptative, un composant doit être conforme à un modèle canonique particulier. Ce modèle est basé sur la réification d’interfaces fournies par le composant et l’intégration de mécanismes lui permettant de réaliser lui même son adaptation. Ces mécanismes sont chargés d’une part d’acquérir et d’analyser son contexte d’exécution afin de déclencher des phases d’adaptation et de déterminer une structure adaptée, lui garantissant une continuité et une qualité de service ; et d’autre part de modifier automatiquement sa structure afin de la rendre conforme à la spécification obtenue. Nous avons appliqué notre stratégie d’adaptation sur des composants destinés à être exécutés dans des environnements ubiquitaires.

Par ailleurs, nous avons constaté que l’adaptation structurelle d’un composant logiciel dans une ap- plication pouvait avoir des impacts sur les autres composants de l’application. De ce fait, nous avons proposé une approche permettant de coordonner les adaptations de composants contenus dans une ap- plication et ainsi généraliser notre approche pour l’adaptation d’architectures logicielles. Pour cela, nous avons proposé un modèle et deux stratégies permettant de coordonner l’adaptation de composants logi- ciels à différents niveaux. Le choix de la meilleure stratégie dépend fortement de l’application concernée. Ainsi, ce choix est laissé à l’appréciation de l’administrateur de l’adaptation.

Afin de mettre en œuvre notre approche sur des composants existants, nous avons proposé un pro- cessus de ré-ingénierie permettant d’obtenir un composant conforme à notre modèle d’auto-adaptation à partir d’un composant existant. Ce processus est basé sur notre approche d’adaptation structurelle par la ré-ingénierie, que nous avons présentée dans le chapitre précédent.