faculté de génie - core.ac.uk · binding, librairie de librairie eﬀectuant un pont vers une...

UNIVERSITÉ DE SHERBROOKEFaculté de génie

Département de génie électrique et de génie informatique

Patrons de conception pour l’intégrationgraduelle de mécanismes d’adaptation dans

les interfaces graphiques

Mémoire de maîtrise

Spécialité : génie électrique

Samuel LONGCHAMPS

Jury : Ruben GONZALEZ-RUBIO (directeur)Philippe MABILLEAUFrédéric MAILHOT (rapporteur)

Sherbrooke (Québec) Canada Août 2017

RÉSUMÉ

Les interfaces graphiques de logiciels modernes requièrent de plus en plus de s’adapter àdiverses situations et divers utilisateurs, rendant leur développement plus complexe. Peude guides et de solutions à faible coût d’intégration dans un projet existent et sont tropsouvent dépendants d’une technologie ou d’une plateforme donnée.

Ce mémoire présente une technique pour l’implémentation graduelle de comportementsadaptatifs dans les interfaces graphiques par le biais de patrons de conception. Les patronsde conception sont des solutions formalisées répondant à des problèmes récurrents, dansce cas-ci de structuration d’un logiciel pour l’ajout de l’adaptation. Ces derniers sontprésentés dans un format normalisé et une implémentation de référence a été développéesous forme de librairie baptisée AdaptivePy. Un prototype démonstratif est utilisé pourcomparer une approche d’implémentation ad hoc à celle utilisant la librairie et donc lespatrons. Les gains observés sont au niveau de la séparation des préoccupations, de lacohésion des méthodes, de la localisation des changements pour l’ajout de l’adaptation etde l’extensibilité.

Aussi, ce mémoire présente des métriques visant la vérification de l’organisation des com-posants d’un logiciel structuré par l’application des patrons de conception. Ces métriquessont des indicateurs de la proportion des situations contextuelles du système que supporteun composant. Les métriques et leur calcul sont présentés dans un format basé sur ce-lui de l’ISO/IEC 25023 et une implémentation de référence a également été développée.Une application typique est évaluée grâce aux métriques et des actions correctives sontprésentées pour résoudre les problèmes détectés. L’utilité des métriques pour valider uneapplication développée en utilisant la structure induite par les patrons de conception estainsi mise en évidence.

La méthodologie du projet a suivi un processus itératif pour l’élaboration des patrons deconception et la recherche des métriques pour appuyer leur application dans un contextepratique. Par l’analyse de la littérature pour identifier les concepts communs de l’adapta-tion et les éléments de mesure dans le domaine de l’adaptation, des solutions plus géné-rales et adaptées à une grande variété de domaines d’application sont proposées. Parmiles contributions du projet sont trois nouveaux patrons de conceptions : Moniteur, Proxyrouteur et Composant adaptatif. Aussi, deux métriques spécifiques ont été formalisées :la couverture modélisée de l’espace d’adaptation ainsi que la couverture effective de l’es-pace d’adaptation. En plus, deux métriques générales supplémentaires sont proposées : laprofondeur de l’arbre de substitution et la stabilité de l’adaptation.

Mots-clés : adaptation, patron, conception, logiciel, composant, interface graphique, mé-trique, validation & vérification

i

TABLE DES MATIÈRES

1 Introduction 11.1 Mise en contexte et problématique . . . . . . . . . . . . . . . . . . . . . . . 11.2 Définition du projet de recherche . . . . . . . . . . . . . . . . . . . . . . . 21.3 Objectifs du projet de recherche . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Contributions originales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5 Plan du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 État de l’art 72.1 Champ de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Dynamisme et adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Modèles de composant adaptatif . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.1 Modèle pour architecture distribuée . . . . . . . . . . . . . . . . . . 102.3.2 Composant adaptatif par activation/désactivation . . . . . . . . . . 102.3.3 Paramétrisation par interfaces ajustables . . . . . . . . . . . . . . . 112.3.4 Modèle d’architecture par graphe . . . . . . . . . . . . . . . . . . . 112.3.5 Modèle MAPE-K . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.6 Amélioration des modèles dans les prototypes et frameworks . . . . 14

2.4 Patrons de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4.1 Composant virtuel . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4.2 Patrons liés aux préoccupations de l’adaptation . . . . . . . . . . . 162.4.3 Patrons pour structures spécifiques . . . . . . . . . . . . . . . . . . 18

2.5 Vérification et de validation de logiciels adaptatifs . . . . . . . . . . . . . . 192.5.1 Phase de conception . . . . . . . . . . . . . . . . . . . . . . . . . . 202.5.2 Phase d’exécution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.6 Enquêtes sur le domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.6.1 Lemos et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.6.2 Cheng et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Développement des patrons de conception 273.1 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.1 Approche générale . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.1.2 Acquisition et synthèse des concepts essentiels . . . . . . . . . . . . 283.1.3 Validation par prototypes . . . . . . . . . . . . . . . . . . . . . . . 293.1.4 Développement d’AdaptivePy . . . . . . . . . . . . . . . . . . . . . 30

3.2 Spécialisation pour les interfaces usagers graphiques . . . . . . . . . . . . . 313.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4 Article 1 : Design patterns for addition of adaptive behavior in graphicaluser interfaces 354.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2 Concepts of Software Adaptation . . . . . . . . . . . . . . . . . . . . . . . 38

iii

iv TABLE DES MATIÈRES

4.2.1 Adaptation Data Monitoring . . . . . . . . . . . . . . . . . . . . . . 384.2.2 Adaptation Schemes in Components . . . . . . . . . . . . . . . . . 384.2.3 Adaptation Strategies . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.3 Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.3.1 Monitor Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.3.2 Proxy Router Pattern . . . . . . . . . . . . . . . . . . . . . . . . . 424.3.3 Adaptive Component Pattern . . . . . . . . . . . . . . . . . . . . . 44

4.4 Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.4.1 AdaptivePy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.4.2 Case Study Application . . . . . . . . . . . . . . . . . . . . . . . . 47

4.5 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.5.1 Ad hoc Application . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.5.2 Application Using AdaptivePy . . . . . . . . . . . . . . . . . . . . . 50

4.6 Conclusion and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5 Développement de métriques d’évaluation de la qualité dans les logicielsadaptatifs 555.1 Recherche des métriques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.1.1 Métriques de la littérature . . . . . . . . . . . . . . . . . . . . . . . 565.1.2 Profondeur de l’arbre de substitution . . . . . . . . . . . . . . . . . 575.1.3 Stabilité de l’adaptation . . . . . . . . . . . . . . . . . . . . . . . . 575.1.4 Couverture de l’espace d’adaptation . . . . . . . . . . . . . . . . . . 595.1.5 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.1.6 Commentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.2 Abstraction des espaces d’états . . . . . . . . . . . . . . . . . . . . . . . . 625.3 Détails d’implémentation de la couverture de l’espace d’adaptation . . . . . 63

5.3.1 Implémentation de la couverture récurrente . . . . . . . . . . . . . 635.3.2 Pseudo-code de l’implémentation . . . . . . . . . . . . . . . . . . . 64

5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6 Article 2 : Metrics for adaptation space coverage evaluation in adaptivesoftware 676.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.2.1 Previous research work . . . . . . . . . . . . . . . . . . . . . . . . . 706.2.2 Verification and validation metrics . . . . . . . . . . . . . . . . . . 71

6.3 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.4 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.5 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7 Discussion 877.1 Atteinte des objectifs de recherche . . . . . . . . . . . . . . . . . . . . . . . 87

7.1.1 Objectif général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

TABLE DES MATIÈRES v

7.1.2 Proposition de patrons de conception . . . . . . . . . . . . . . . . . 887.1.3 Proposition de métriques . . . . . . . . . . . . . . . . . . . . . . . . 89

7.2 Choix techniques et compromis . . . . . . . . . . . . . . . . . . . . . . . . 907.2.1 Langage et plate forme . . . . . . . . . . . . . . . . . . . . . . . . . 907.2.2 Librairie pour l’adaptation . . . . . . . . . . . . . . . . . . . . . . . 90

8 Conclusion 938.1 Sommaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 938.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

8.2.1 Patrons de conception . . . . . . . . . . . . . . . . . . . . . . . . . 958.2.2 Métriques d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . 968.2.3 Métriques spécifiques formalisées . . . . . . . . . . . . . . . . . . . 97

8.3 Travaux futurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988.3.1 Éléments à approfondir dans le cadre de recherches futures . . . . . 988.3.2 Nouvelles perspectives de recherche . . . . . . . . . . . . . . . . . . 99

vi TABLE DES MATIÈRES

LISTE DES FIGURES

2.1 Composant adaptatif de Chen et al. (tiré de [7]) . . . . . . . . . . . . . . . 102.2 Modèle MAPE-K d’IBM (tiré de [20]) . . . . . . . . . . . . . . . . . . . . . 132.3 Patron « composant virtuel » (tiré de [10]) . . . . . . . . . . . . . . . . . . 162.4 Relations entre les patrons proposés par Ramirez (Tiré de [39]) . . . . . . . 17

3.1 Démarche itérative pour le développement des patrons de conception . . . 283.2 Mise en place du composant personnalisé du prototype de la section 4.5.2 . 32

4.1 Monitor pattern UML diagram . . . . . . . . . . . . . . . . . . . . . . . . 414.2 Proxy router pattern UML diagram . . . . . . . . . . . . . . . . . . . . . . 434.3 Adaptive component pattern UML diagram . . . . . . . . . . . . . . . . . 454.4 Adaptive case study application “Polarized Poll” . . . . . . . . . . . . . . . 494.5 Simplified UML diagram of ad hoc implementation of case study application 494.6 Qt Designer using plain widgets as placeholder for ad hoc implementation . 504.7 Simplified UML diagram of case study application implementation using

AdaptivePy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.8 Qt Designer using adaptive components developed with AdaptivePy . . . . 53

5.1 Arbre de substitution de composants adaptatifs . . . . . . . . . . . . . . . 585.2 Exemples des relations de dépendances entre moniteurs et composants a)

Boucle de dépendances b) Dépendances sans boucle . . . . . . . . . . . . . 58

6.1 Relationship among elements defined by the SQuaRE series of InternationalStandards [21] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.2 Coverage of substitution candidates for sample program with monitors overfull domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.3 Coverage of substitution candidates for sample program with HeatedAreasubstitution candidate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.4 Coverage of substitution candidates for sample program with monitors overconstrained domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.5 Coverage of substitution candidates for sample program with monitors overconstrained domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

vii

viii LISTE DES FIGURES

LISTE DES TABLEAUX

6.1 Adaptation state space measures . . . . . . . . . . . . . . . . . . . . . . . 746.2 Measurement functions for metrics . . . . . . . . . . . . . . . . . . . . . . 766.3 Coverage of sample program with monitors over full domain . . . . . . . . 806.4 Coverage of sample program with HeatedArea substitution candidate . . . 816.5 Coverage of sample program with monitors over constrained domain . . . . 826.6 Coverage of sample program with monitors over constrained domain . . . . 82

ix

x LISTE DES TABLEAUX

LEXIQUE

Adaptation logicielle L’adaptation logicielle est le principe selon lequel un logicielparvient à changer son comportement et/ou sa structure au moment de son exécution defaçon autonome en réponse à des stimuli provenant de son environnement (externe) ou deson propre état (interne).

Ad hoc, Solution Ad hoc vient du latin et se traduit par “pour ceci”. Une solution estdite ad hoc lorsqu’elle est spécifique au système s’y rattachant et n’est pas généralisable.

Binding, Librairie de Librairie effectuant un pont vers une librairie implémentée dansun autre langage. Dans le cas de Qt qui est une librairie C++, PyQt est un bindingfonctionnellement équivalent avec comme cible le langage Python.

Commit Transaction avec un système de versionnement de code qui représente la sou-mission d’une nouvelle version du code.

Framework Suite intégrée d’outils logiciels implémentant diverses fonctionnalités agis-sant à titre de base pour une application.

Middleware Logiciel offrant un support de fonctionnalités entre le bas et le haut niveau.Dans ce cas, le bas niveau correspond au système d’exploitation et le haut niveau auxapplications.

Modèle conceptuel Organisation des concepts d’un champ de recherche sous formed’un modèle.

Patron de conception Une solution éprouvée à un problème récurrent. Dans le cadred’un logiciel, cette solution est une façon de faire pour régler un problème qui mène à unebonne qualité logicielle.

Préoccupations, Séparation des (separation of concerns) Une préoccupation dans lecadre d’un logiciel est un concept auquel sont liées différentes fonctionnalités. La séparationdes préoccupations vise à découpler les fonctionnalités en fonction de leur préoccupation,de sorte que chaque groupement de fonctionnalités soit lié à une seule préoccupation.

Qualité de Service La qualité de service est est un indicateur visant à quantifier l’at-teinte de requis de qualité pour une préoccupation, typiquement dans le domaine destélécommunications, mais pouvant s’étendre à d’autres domaines. Un exemple est le délaide réponse d’un serveur ou la latence : la qualité de service est ici la meilleure lorsqu’elleapproche 0.

Toolkit Librairie de composants personnalisables destinée à la conception d’interfacesgraphiques.

Widget Composant dans le contexte d’un toolkit.

xi

xii LEXIQUE

LISTE DES ACRONYMES

CASC Composite Adaptation Space Coverage (couverture composite de l’espace d’adap-tation)

EASC Effective Adaptation Space Coverage (couverture de l’espace d’adaptation effec-tive)

MASC Modeled Adaptation Space Coverage (couverture de l’espace d’adaptation mo-délisé)

PASC Primitive Adaptation Space Coverage (couverture primitive de l’espace d’adap-tation)

POO Programmation Orientée-Objet

PVP Parameter Value Provider (fournisseur de valeur de paramètre)

QdS Qualité de Service

QME Quality Measure Element Élément de mesure de la qualité

RSC Recurrent State Space Coverage (couverture récurrente de l’espace d’états)

SC State space Coverage (couverture de l’espace d’états)

V&V Vérification et Validation

xiii

xiv LISTE DES ACRONYMES

CHAPITRE 1

Introduction

1.1 Mise en contexte et problématique

Depuis plus d’une décennie, les logiciels ont envahi les objets de notre quotidien. L’avène-ment de l’Internet des Objets (Internet of Things), soit l’intégration de microprocesseurs etd’inter-connectivité dans des appareils traditionnels comme des thermostats et des lampes,a grandement poussé cette vague. De plus en plus, les appareils utilisés dans la vie de tousles jours sont contrôlés et dépendent de logiciels. Ce marché émergeant vise à personnaliserces différents appareils aux préférences et contextes particuliers de chacun des foyers etdes utilisateurs.

Cette idée de personnaliser l’expérience des utilisateurs avec leurs appareils n’est pasnouvelle. En effet, il y a déjà plusieurs décennies que le domaine de l’adaptation deslogiciels se développe. La vision plus générale est de faire en sorte qu’un système puissechanger son comportement et sa structure interne pour satisfaire à certains critères. Parexemple, un système rencontrant une erreur pourrait prendre des mesures et changer lemodule fautif pour un autre. Ce principe est appelé « autoguérison » (self-healing) [17].Plus près de l’utilisateur, un logiciel pourrait personnaliser son interface en fonction dutype d’utilisateur ou de son environnement. Un exemple souvent rencontré dans les logicielsexistants est l’utilisation de différents types d’interfaces, l’une basique et l’autre avancée.Le choix de l’interface est fait en fonction des caractéristiques de l’utilisateur comme desproblèmes moteurs spécifiques ou simplement son degré de familiarité avec le logiciel. Dansce cas, on parle plutôt d’adaptation basée sur la modélisation des utilisateurs [34].

Beaucoup de chercheurs se sont penchés sur les techniques et mécanismes permettantl’atteinte de buts précis par l’adaptation. Cependant, l’intégration de ces mécanismesdans l’ensemble des logiciels reste difficile à faire puisque beaucoup proposent leur propresolution d’intégration, généralement sous forme de framework. En plus, plusieurs solutionsproposées à ce jour sont directement liées à un domaine d’application précis, typiquementles applications distribuées en réseau. Dans ce domaine, les requis sont souvent rattachésà la qualité de service (QdS) de serveurs et de services. Ainsi, les mécanismes proposéssont difficiles à mettre en place dans d’autres logiciels. Par exemple, les implémentations

1

2 CHAPITRE 1. INTRODUCTION

dans le domaine des interfaces graphiques restent relativement peu explorées et la QdS estinterprétée différemment.

Le problème central semble être l’absence de techniques générales pour la mise en place del’adaptation dans l’ensemble des logiciels et plus particulièrement les logiciels existants.Comme les logiciels deviennent plus répandus et utilisés dans une variété de contextes dif-férents, l’adaptation est devenue requise par nécessité. Il est en effet plus efficace d’adapterune solution générale à des domaines spécifiques plutôt que de développer des solutionscomplètes spécifiques à chacun des domaines. Cependant, en l’absence de techniques gé-nérales, il reste difficile de mettre en place des mécanismes d’adaptation graduellementet d’une façon qui assure la maintenabilité. En plus, comme les logiciels adaptatifs sontdifférents des logiciels traditionnels par leur organisation déterminée de façon dynamique,les techniques de vérification et de validation (V&V) existantes sont insuffisantes pourdéterminer si une implémentation n’entrera pas dans un état où son comportement estindéfini.

1.2 Définition du projet de recherche

Le présent projet de recherche propose une technique suffisamment générique pour per-mettre l’application d’une grande variété de mécanismes d’adaptation dans les logiciels etqui reste neutre au niveau des technologies utilisées. Il est important de mettre l’accentsur le but qui est de proposer une façon de mettre en place une structure de base dont lesmodules réalisent les concepts nécessaires à l’adaptation au sens large. Dans le contextedu présent projet, le domaine des interfaces graphiques a été choisi comme cible afin de ré-duire le cadre de la recherche. Ce domaine a été choisi puisqu’il est de plus en plus soumis àdes requis d’adaptation vu l’hétérogénéité des appareils. De plus, la structure typiquementpar composants des toolkits est largement répandue dans le domaine du logiciel.

Au total, trois patrons de conception sont proposés pour mettre en place une structurede base pour introduire de l’adaptation dans un logiciel. La schématisation sous formede patrons de conception est la technique choisie puisqu’elle permet de communiquer dessolutions dans un format clair et à un niveau de détail adéquat. Ces schémas montrentl’organisation d’un groupe de modules ayant des rôles précis et qui, utilisés ensemble,offrent une solution à un problème récurrent en logiciel. Dans notre cas, le problème globalest l’ajout d’un mécanisme d’adaptation à une application. Plus précisément, deux despatrons présentés répondent à un problème en lien avec une préoccupation de l’adaptation.Le troisième lie plutôt les deux premiers pour former une structure propice à l’adaptation.

1.3. OBJECTIFS DU PROJET DE RECHERCHE 3

Comme il est également nécessaire d’assurer que la mise en place de l’adaptation est struc-turellement adéquate, le présent projet inclut la proposition d’une technique de vérificationbasée sur la structure de base établie. Une technique de V&V répandue est l’utilisation demétriques de qualité pour évaluer la qualité de façon quantitative. Une métrique offre unindicateur permettant de qualifier le degré de qualité d’une implémentation en fonctiond’une préoccupation particulière, par exemple la complexité d’une fonction. Pour ce faire,une métrique permet le calcul d’une valeur et le degré de qualité peut être interprété encomparant cette valeurs à des valeurs bornes (minimales et maximales). Une « bonne »valeur dépend de la métrique et il faut généralement minimiser ou maximiser la valeur versl’une des bornes pour améliorer la qualité. Le présent projet inclut la proposition d’unenouvelle métrique spécifique aux logiciels adaptatifs. Cette métrique fournit un indicateurde la proportion des états du système qui sont supportés par la structure des composantsdepuis lesquels ce dernier est formé.

Les gains attendus par l’application de techniques générales pour la mise en place del’adaptation dans les logiciels sont une meilleure qualité des implémentations et une ap-plication des mécanismes d’adaptation dans une plus grande variété de logiciels. Plusparticulièrement, l’utilisation de telles techniques devrait minimiser l’effort requis pourl’ajout de comportements adaptatifs dans des projets qui n’en comportent initialementpas. De plus, il devrait être plus facile de comparer différents mécanismes d’adaptationainsi que différentes implémentations d’un même mécanisme. Dans le contexte des inter-faces graphiques, il est attendu que la structure rend la conception et l’implémentationd’interfaces adaptatives plus graduelles et conserve une approche similaire aux techniquesexistantes dans ce domaine.

1.3 Objectifs du projet de recherche

L’objectif principal de la recherche est la création de nouveaux patrons de conception quireprésentent des solutions suffisamment générales à des problèmes liés aux préoccupationsspécifiques de l’adaptation. De façon plus concise, on cherche à savoir et à montrer : Quelspatrons de conception permettent l’implémentation graduelle de mécanismes d’adaptationdans les interfaces graphiques ? Pour atteindre cet objectif principal, il est nécessaire d’at-teindre des objectifs secondaires. Ces derniers sont :


Proposition de patrons de conceptions

1. Relever de la littérature une banque de patrons de conception liés au domaine del’adaptation logicielle

2. Analyser les patrons et formaliser les concepts fondamentaux solutionnant les pro-blèmes communs de l’adaptation logicielle

3. Déterminer les lacunes et avantages des patrons de conceptions trouvés

4. Proposer des patrons de conceptions liant les concepts fondamentaux et adressantles lacunes trouvées dans ceux déjà existants

5. Implémenter les patrons de conceptions afin de valider leur fonctionnement dans uneapplication concrète

6. Comparer une solution ad hoc à une nouvelle utilisant les patrons de conceptionproposés

De nouveaux patrons de conception permettront de traduire les éléments récurrents quicaractérisent une implémentation de qualité dans le but d’être utilisés dans divers logiciels.Chaque patron aura comme préoccupation un aspect de l’adaptation qui favorisera unemeilleure qualité logicielle.

Proposition de métriques

1. Relever de la littérature une banque de métriques liées à la qualité des logicielsadaptatifs, particulièrement au niveau de la structure

2. Analyser les éléments liés aux métriques existantes et les pistes proposées par lesrecherches existantes

3. Extraire depuis la structure de base proposée des éléments de mesure permettant dequantifier la qualité

4. Proposer des métriques utilisant des éléments de mesure et qui quantifient un aspectde la qualité structurelle des logiciels adaptatifs

5. Implémenter le calcul des métriques et valider son utilisation avec des éléments demesure tirés d’une application concrète

6. Analyser les résultats des métriques en variant les éléments de mesure dans l’appli-cation concrète et proposer des actions correctives

1.4. CONTRIBUTIONS ORIGINALES 5

La proposition de la métrique s’inscrit dans l’objectif de proposer une solution éprouvée. Eneffet, il est nécessaire d’effectuer la vérification que le logiciel où les patrons de conceptionont été utilisés satisfait des requis de qualité hors de l’atteinte des patrons seuls. Ainsi,la métrique proposée a comme but d’identifier les implémentations qui aboutissent en unsystème contenant des problèmes.

1.4 Contributions originales

Plusieurs contributions originales sont issues de ce projet. Les trois patrons de conceptionproposés sont le Moniteur, Proxy routeur et Composant adaptatif.

- Le patron Moniteur 1 vise la modélisation, l’acquisition et la distribution de donnéespour l’adaptation

- Le patron Proxy routeur vise la réorganisation des chemins d’appels entre différentscomposants

- Le patron Composant adaptatif vise la composition d’architectures et de hiérarchiesde composants qui ont un comportement adaptatif reposant autant sur la substitu-tion que la paramétrisation

Les métriques pour la vérification de logiciels adaptatifs sont la couverture de l’espaced’adaptation modélisée et la couverture de l’espace d’adaptation effective. En plus, despistes d’analyse et des actions correctives sont proposées pour accompagner les dévelop-peurs dans l’utilisation de la métrique.

Pour mettre en pratique les différents patrons et métriques, des développements logicielsont été réalisés et rendus disponibles sous licence libre du Québec (LiLiQ-P v1.1). Cesderniers sont disponibles aux adresses suivantes :

- AdaptivePy : https://gitlab.com/memophysic/adaptive_py_lib

- Métriques : https://gitlab.com/memophysic/adaptive_py_metrics

AdaptivePy est également disponible sur PyPi, le répertoire des librairies Python, sous lenom adaptivepy2.

1Ne pas confondre avec le patron Moniteur utilisé dans le domaine de la concurrence2La librairie peut être installée grâce à l’outil pip avec la commande pip3 install adaptivepy sur

une distribution GNU/Linux


1.5 Plan du document

Ce document est découpé en différents chapitres. Le chapitre 2 présente l’état de l’art dansle domaine de l’adaptation dans les logiciels et illustre les travaux sur lesquels la présenterecherche est basée. Le chapitre 3 introduit un premier article qui a été présenté dans lecadre de la conférence Adaptive 2017 et explique en plus grands détails la méthodologieet les développements qui ont permis la proposition des trois patrons de conception. Cepremier article est reproduit au chapitre 4. Un second article est introduit au chapitre 5et les démarches pour l’élaboration des métriques et des solutions pour la vérification delogiciels adaptatifs y sont présentées. Le second article est reproduit au chapitre 6. Unediscussion sur les contributions du projet de recherche et leurs implications est le sujet duchapitre 7. Ce chapitre présente également des idées qui n’ont pas été couvertes dans lesarticles, mais qui ont tout de même fait partie de la recherche. Le mémoire se conclut avecle chapitre 8 où un sommaire des travaux est présenté ainsi que diverses propositions pourdes travaux futurs.

CHAPITRE 2

État de l’art

Le présent chapitre a pour objectif de présenter un état de l’art du domaine de l’adaptationdans les logiciels avec une attention particulière portée sur les méthodes d’intégration del’adaptation. Un aperçu du champ de recherche est d’abord présenté, suivi d’une mise encontexte de l’adaptation par rapport au dynamisme dans les logiciels. Ensuite, différentstypes de modèles de composants adaptatifs sont présentés. Les patrons de conceptionconnus qui se rapprochent du but du présent projet de recherche sont présentés par lasuite ainsi qu’un résumé des aspects de la V&V des logiciels adaptatifs. Finalement, desrésumés des enquêtes les plus récentes dans le domaine de l’adaptation dans les logicielssont présentés, suivis d’une mise en évidence des éléments de recherche qui sont représentésdans le présent projet.

À noter que les parties « champ de recherche », « dynamisme et adaptation », et « patronsde conception » sont en grande partie tirées du travail réalisé lors de la définition de projeten préparation à l’écriture de ce mémoire.

2.1 Champ de recherche

La discipline de l’adaptation logicielle est issue de divers besoins et requis auxquels fontface les systèmes informatiques modernes. Un logiciel adaptatif est généralement « un lo-giciel pouvant changer son comportement à l’exécution. » [7] Traditionnellement, le cyclede développement des logiciels est constitué de différentes phases comme la conception,l’implémentation, la validation, le support, etc. Ces phases sont aujourd’hui souvent effec-tuées de façon itérative et le logiciel est livré de façon continue. Lorsque le logiciel compteun nombre de fonctionnalités clés qui en font une solution complète, ce dernier est livrésous forme de version finale. Si aucune autre fonctionnalité n’est requise, la phase finalede support vise ensuite à corriger les bogues et problèmes survenant dans l’exécution dusystème.

Actuellement, il devient nécessaire pour les logiciels d’être autonomes, c’est-à-dire que leurcycle de développement ne se limite plus au procédé itératif, mais bien qu’il continue aprèsla livraison de façon autonome [43]. Cette autonomie permet aux logiciels de s’adapter àdes situations qui auraient normalement requis une intervention humaine. Un exemple de

7

8 CHAPITRE 2. ÉTAT DE L’ART

ce type d’adaptation est la capacité pour un système composé de plusieurs serveurs demodifier la façon dont ces derniers traitent les requêtes clientes pour garantir un délaide réponse maximal1. Normalement, une intervention humaine aurait été nécessaire pourconfigurer le système dès qu’il aurait été détecté que le temps de réponse des serveursétait trop long. Dans le cas des logiciels adaptatifs, ils sont en mesure d’acquérir le tempsde réponse et de modifier leur configuration pour atteindre certaines cibles définies parles concepteurs de façon autonome. C’est donc dire que le logiciel effectue lui-même unepartie de la configuration et même du développement après avoir été livré.

Évidemment, il est nécessaire de trouver des techniques pour faire l’implémentation dedifférents mécanismes d’adaptation. L’adaptation dans les logiciels est alors la recherchede ces techniques et de façons de valider que les objectifs stipulés pour un système sontatteints. Le présent projet de recherche vise plus particulièrement la façon de structu-rer les applications pour faciliter l’ajout de mécanismes d’adaptation en maximisant uneséparation des préoccupations.

2.2 Dynamisme et adaptation

Au travers des années, les outils de conception de logiciels ont connu une sophisticationqui a apporté plusieurs fonctionnalités autrefois impossible. Par exemple, la compilationpermet d’abstraire différentes spécificités liées aux architectures des processeurs et auxsystèmes d’exploitation, permettant l’écriture d’une application logicielle dans un langageunifié. Cette flexibilité accrue a également permis d’ajouter de plus en plus de comporte-ments dynamiques dans les applications. Ce type de fonctionnalité est appelé dynamismepuisqu’il réfère à la capacité de résoudre un ou plusieurs niveaux d’indirection par un pro-cédé automatisé. L’indirection, qui est le principe d’utiliser une référence vers une entitéplutôt que cette dernière directement, est par exemple utilisé dans le cas de la compilationpour résoudre vers quelle procédure concrète un appel de procédure est redirigé en fonc-tion des types de structures utilisés (acheminement dynamique ou dynamic dispatch). Ceprincipe est l’un des éléments fondamentaux de la programmation orientée-objet (POO),qui apporte un niveau d’indirection non seulement aux procédures, mais également auxstructures de données sous forme de classes.

La dynamisation des logiciels induit une complexité inhérente à ces derniers et il devientalors important de développer des méthodes et outils pour effectuer leur V&V. Dans tous

1Un délai maximal garanti implique qu’une requête ne peut prendre plus que t unité de temps à êtretraitée.

2.3. MODÈLES DE COMPOSANT ADAPTATIF 9

les cas, il s’agit alors de s’assurer que le logiciel répond à certaines exigences (ex. : per-formance, taille en mémoire, etc.), que sa structure est valide (ex. : lexeur-parseur) et soncomportement est bel et bien celui qui est attendu (ex. : tests unitaires et d’intégration).Des requis de validation plus récents sont d’assurer que le logiciel ne peut être corrompu(ex. : exécuter des procédures introduites de façon malveillante) et que lorsqu’un problèmesurvient, ce dernier peut rétablir le service qu’il offre ou se tourner vers une solution derechange [17]. Ces derniers requis sont plus difficiles à valider puisqu’ils sont globaux aulogiciel et leurs solutions sont excessivement dynamiques (sont liés à plusieurs niveaux d’in-direction). L’adaptation logicielle fait partie de ces solutions puisqu’elle vise à dynamiserjusqu’à l’architecture même du logiciel, par exemple en remplaçant un ou plusieurs compo-sants offrant un certain service par un autre de rechange ou en modifiant les algorithmesutilisés à l’intérieur de ce dernier. Les recherches dans le domaine ont initialement viséle développement de techniques pour implémenter de tels mécanismes et se sont dirigées,dans les dernières années, vers l’élaboration de stratégies d’adaptation plus spécifiques àcertains types de problèmes et de systèmes.

Une architecture logicielle populaire, particulièrement dans les systèmes distribués, estl’architecture par composants. Elle constitue également l’architecture à l’étude pour leprésent projet de recherche, à la différence que l’accent n’est pas sur les systèmes distri-bués, mais plutôt sur tout type de logiciel développé avec la POO. La programmationbasée sur les interfaces (interface-based programming) est la technique utilisée pour spé-cifier les composants et réaliser leurs connexions dans le cadre du présent projet. Afin demieux cibler le projet, les interfaces graphiques ont été choisies comme une étude de caspuisqu’elles sont typiquement réalisées avec des composants dans un contexte de POO.

2.3 Modèles de composant adaptatif

La programmation orientée composant vise à faire la conception d’une hiérarchie de com-posants simples qui ensemble forment un composant complexe. Cette approche a gagnébeaucoup en popularité depuis les années 90, entre autres avec l’arrivée de modèles commele System Object Model de IBM, le Component Object Model de Microsoft et Common Ob-ject Request Broker Architecture (CORBA) du Object Management Group. Ces derniersont été développés pour ajouter un niveau d’indirection aux composants et ainsi faciliterl’interopérabilité entre des composants développés en différents langages. Dans le cas d’unlogiciel donné, les composants servent à mettre en place une séparation des préoccupa-tions explicites de sorte que différents composants offrant un certain service peuvent êtreassemblés pour fournir un service plus complexe et donc une solution à un problème de


plus haut niveau. Effectuer la conception de composants pouvant s’adapter et créer descomposants dont la préoccupation serait uniquement l’adaptation ont alors commencé àintéresser les chercheurs.

2.3.1 Modèle pour architecture distribuée

Taylor et al. [45] ont proposé en 1996 un modèle générique de composant hautement dé-couplé servant de base à l’élaboration d’un marché des composants. Le but était alorsde supporter les systèmes du futur qui seraient « distribués, complexes, multimédias, hé-térogènes et multi-utilisateurs ». Ces caractéristiques sont les mêmes qui ont poussé ledéveloppement de l’adaptation logicielle, particulièrement lorsqu’il s’agit d’applicationsdistribuées comme des réseaux de serveurs. Une qualité intéressante de ce modèle est l’uti-lisation de messages dans un langage intermédiaire pour la communication entre tous lescomposants. De cette façon, chaque composant peut être distribué dans son propre proces-sus et sur une machine distincte. Cependant, les mécanismes nécessaires afin de mettre enplace l’adaptation comme la détection de changements et le remplacement de composantsne faisaient pas partie du modèle : l’architecture restait essentiellement statique.

2.3.2 Composant adaptatif par activation/désactivation

Chen et al. [7] proposent en 2001 un modèle de composants pour mettre en place l’adapta-tion dans un logiciel distribué (voir modèle d’un Adaptive Component (AC), figure 2.1). Ilsidentifient certains défis comme effectuer la coordination entre différentes machines afin dene pas suspendre le système lorsque l’adaptation est mise en place. Ils décrivent deux typesde sous-composants qui forment un « composant adaptatif » : un module d’adaptation

Figure 2.1 Composant adaptatif de Chen et al. (tiré de [7])


du composant ou component adaptor module (CAM) ainsi qu’un module d’algorithmeconscient de l’adaptation ou adaptation-aware algorithm module (AAM). Chaque CAMpeut activer ou désactiver un AAM et les requêtes sont envoyées uniquement à ceux quisont activés. Le processus d’adaptation est d’abord de détecter un changement dans l’envi-ronnement d’exécution, de décider des AMMs à activer et désactiver communautairementet d’effectuer les actions d’adaptation en assurant qu’il n’y aura pas d’arrêt des services encours. Dans ce modèle, une structure plus précise d’un composant adaptatif est présentéeet surtout il est question de sélection d’algorithmes optimaux. Le but de l’adaptation estalors de trouver « la meilleure solution » pour la situation qui se présente au logiciel.

2.3.3 Paramétrisation par interfaces ajustables

Chang et Karamcheti [6] proposent une approche par interface ajustable qui vise à rendredisponibles des paramètres de contrôle, similaires à des boutons de réglage, pour modifierle fonctionnement interne d’un composant. L’ensemble des valeurs des paramètres d’uncomposant est considéré comme une configuration de ce composant. En soumettant lescomposants à différentes situations liés aux ressources de l’environnement d’exécution, lesystème d’adaptation peut lier leur effet à des métriques de qualité de service (QdS) etconstruire un modèle qui permettra de satisfaire des contraintes. Plusieurs contraintespeuvent être définies et une fonction d’objectif est utilisée pour quantifier leur impor-tance relative. Il s’agit au final d’un problème d’optimisation de cette fonction qui estrésolu par son évaluation sous diverses configurations à l’initialisation du logiciel ou avant(lors d’une exécution antérieure). La contribution principale de cet article est l’idée deparamétrer des composants et de contrôler cette paramétrisation par l’identification deconfigurations appropriées de façon automatique. Plutôt que de remplacer un composantou un algorithme, on cherche plutôt à injecter à un composant un état de paramétrisationdifférent. Une attention particulière a été portée dans cette recherche à l’élaboration d’uneméthode transparente, c’est à dire qui ne nécessite pas de modification aux interfaces ex-posées. Ce souci pour la transparence permet notamment l’ajout plus facile de ce type defonctionnalités à des logiciels hérités (« legacy software ») et à des librairies (limitant lesmodifications aux applications qui en sont dépendantes).

2.3.4 Modèle d’architecture par graphe

L’idée d’un composant adaptatif s’est popularisée dans les années 2000 et plusieurs cher-cheurs ont proposé les responsabilités potentielles d’un tel composant. Des façons de fairela gestion des interactions et réorganisations entre ces composants ont également été pro-


posées. Souvent, une certaine modélisation de l’architecture d’un logiciel est utilisée pourfaciliter l’analyse de cette dernière et identifier des problèmes. Par exemple, Georgiadiset al. [14] utilise l’approche proposée par le modèle Darwin qui consiste à voir l’architec-ture d’un système sous forme de graphe orienté avec ses composants comme sommets etles liaisons entre les composants offrant un service et ceux l’utilisant comme arcs. Chaquecomposant est branché à d’autres via des ports, sortants ou entrant en fonction de lanature de la dépendance au service. Il s’agit dans ce cas de sélectionner les meilleurs com-posants dont les ports sont compatibles pour construire l’architecture. Dans ce modèle,l’entité qui a la responsabilité d’effectuer l’adaptation de l’architecture est souvent décou-plée des composants. Cette entité est appelé un « gestionnaire de composants » Georgiadiset al. [14] et met en place le contrôle externe, en opposition au contrôle interne qui at-tribue toutes les responsabilités d’adaptation au composant adaptatif [43]. Un avantagede ce type de contrôle est que la mise en place de l’adaptation ne nécessite pas de modi-fication aux composants d’un système. De plus, une vue de la configuration du systèmeest construite et permet au gestionnaire de composant d’acquérir des connaissances plusglobales du système et de son architecture. Cette vue est maintenue à jour grâce à un mé-canisme de notifications lorsque des changements d’architecture sont effectués. Le systèmeest gardé dans un état connu lorsque des opérations sont en cours et un verrou doit êtreacquis pour effectuer une adaptation (empêchant des opérations pendant l’adaptation).Tout comme pour [6], la réorganisation automatique est un problème d’optimisation basésur des contraintes.

2.3.5 Modèle MAPE-K

La compagnie IBM a introduit en 2003 puis développé dans les années suivantes un modèlecomplet visant l’implémentation d’architectures adaptatives : MAPE-K [20] (voir figure2.2). Les lettres du modèle forment un acronyme pour les mots Monitor, Analyze, Plan,Execute et Knowledge qui sont différentes préoccupations d’un système adaptatif et dontles quatre premiers forment une boucle de rétroaction. Bien que ce modèle est issu du mi-lieu commercial, il eut beaucoup d’influence sur le domaine de la recherche et beaucoup demodèles s’en sont inspirés. Notamment, un article très influent de Hinchey et Sterritt [17]cite le modèle comme une implémentation des principes de base d’un système autonome(conscient de lui-même et de son environnement, capable de détecter des changements dansces derniers et de changer son comportement en conséquence). Dans le modèle MAPE-K,un gestionnaire autonome (autonomic manager) est une entité dont la responsabilité estde coordonner les activités des différents modules de la boucle de rétroaction. Un moniteur


Figure 2.2 Modèle MAPE-K d’IBM (tiré de [20])

récupère des informations du système et détecte certains symptômes en vue d’être analysépour déterminer si des actions doivent être entreprises. Si des actions sont nécessaires, unplan est formé pour mettre en place une adaptation du système qui est finalement exécutéà un moment opportun. La boucle est complétée alors que des changements sont mis enplace dans le système et que les moniteurs peuvent obtenir de nouvelles données. Toutes lesinformations utilisées dans l’exécution des différentes fonctions de la boucle de rétroactionforment ensemble une base de connaissances qui est partagée à l’intérieur d’un même ges-tionnaire autonome. Une contribution importante de ce modèle est la séparation claire desboucles de rétroaction qui, dans les précédentes recherches, n’ont été qu’implicites. Égale-ment, la réalisation que plusieurs de ces boucles peuvent être définies de façon hiérarchiquepermet de plus facilement spécifier des comportements adaptatifs complexes. Par le faitmême, chaque composant peut ainsi être géré par un gestionnaire autonome distinct. Toutcomme [14], la gestion externe est adoptée et des points de surveillance et d’action dans lesous-système géré sont définis explicitement sous forme de capteurs et d’effecteurs. Dansce cas, les liens entre le gestionnaire et son sous-système sont donc définis à la conception.Additionnellement, plutôt que de définir un format abstrait d’un composant adaptatif, ilest possible de superposer à des composants existants des mécanismes d’adaptation sansmodifier le système initial (l’adaptation est la préoccupation exclusive des gestionnaires


autonomes). Finalement, l’applicabilité du modèle à un vaste domaine de systèmes estaccrue par sa flexibilité au niveau de la spécification des stratégies utilisées à chaque étapede la boucle de rétroaction. La formalisation de ces étapes a été une contribution massivede ce modèle.

2.3.6 Amélioration des modèles dans les prototypes et frameworks

Plusieurs recherches par prototype ont visé le développement de librairies qui appliquentdifférentes variations des modèles présentés dans les années précédentes. Plutôt que deproposer de nouvelles méthodes ou modèles, ces recherches avaient pour but l’optimisa-tion des procédés d’adaptation et le développement d’une architecture logicielle concrèteutilisable à grande échelle pour minimiser les risques rattachés à l’inclusion de l’adapta-tion dans les logiciels. Les avantages au niveau de la QdS pour des systèmes complexescomme les systèmes distribués ont certainement influencé les recherches en étant les prin-cipaux sujets de cas d’étude. Les librairies développées ont largement été influencées parles besoins spécifiques de ces applications.

Plusieurs solutions ont été développées sous forme de frameworks, soit des éléments deconception logiciels incluant souvent une librairie, un langage intermédiaire et différentsoutils supplémentaires. Ces frameworks proposent des améliorations qui sont importantespar rapport aux principes originaux qui doivent être pris en compte. Quelques exemplesde ceux-ci sont Rainbow framework proposé par Garlan et al. [13] et Accord proposépar Liu et Parashar [25]. D’autres frameworks avec un rôle connexe ont également étéproposés. Quelques exemples sont Ceylon proposé par Maurel et al. [31] qui permet laconception de gestionnaires autonomes plutôt que d’applications adaptatives ainsi que leframework conceptuel proposé par Malek et al. [29] qui permet d’effectuer la conceptionde système à architecture distribuée en vue de satisfaire à des caractéristiques précises.Bien que chacun d’entre eux apporte des améliorations, il est plus pertinent d’analyserdes travaux de synthèse de ces solutions afin de déceler les éléments récurrents et qui sontgénéralisables pour une vaste variété d’applications adaptatives.

2.4 Patrons de conception

Les patrons de conception constituent un moyen de partager des solutions à des problèmesrécurrents en informatique par le biais de schémas et d’explications dans une forme stan-dardisée. La forme la plus connue est celle utilisée par le Gang of Four dans leur livreDesign Patterns : Elements of Reusable Object-oriented Software [12]. Dans le cas du pré-

2.4. PATRONS DE CONCEPTION 15

sent projet de recherche, le problème récurrent est l’ajout graduel de l’adaptation dansune application. En général, les travaux ayant comme sujet les patrons de conceptiondans le domaine de l’adaptation dans les logiciels sont variés et touchent divers domainesd’application.

Plusieurs modèles visant la spécification d’une structure standard d’architectures de com-posants adaptatifs ont été présentés à la section 2.3 et pourraient être réinterprétés sousforme de patrons. Ces modèles manquent cependant de précision au niveau de l’implé-mentation et, vu leur âge, ne bénéficient pas de l’expérience acquise plus récemment pourle développement de logiciels adaptatifs, particulièrement poussé par le développement deframeworks (voir section 2.3.6).

La présente section a pour but de présenter les patrons de conception tirés de cette expé-rience et des défis supplémentaires qu’apportent les systèmes adaptatifs complexes. En lienavec le présent projet de recherche, il s’agit d’analyser les éléments communs et suffisam-ment généraux pour être essentiels à la mise en place de l’adaptation. Une description desconcepts essentiels retenus pour la proposition des patrons a été réalisée dans le premierarticle qui est reproduit à la section 4.2.

2.4.1 Composant virtuel

Corsaro et al. [10] proposent une solution à un problème récurrent des composants réuti-lisables : de quelle façon peut-on faire la conception d’un composant qui est réutilisable etpeut cibler plusieurs systèmes très différents sans complexifier accidentellement l’interfacequ’il expose ? La proposition est sous forme d’un patron de conception qui est appelé com-posant virtuel (illustré à la figure 2.3). Il s’agit essentiellement d’une concrétisation de latechnique décrite dans [7] : un composant logique (CAM) agi en mandataire (“proxy”) etredirige les appels vers un composant concret (AAM) qui est le mieux approprié à la situa-tion dans laquelle l’appel est exécuté (voir section 2.3.2). La contribution supplémentairede cette recherche est la proposition d’associer des stratégies de chargement et de déchar-gement à chaque composant concret et d’attribuer la responsabilité de l’exécution de cesstratégies à un module fabrique (du patron de conception “factory”). Cette plus grande sé-paration des préoccupations et le fait de fournir avec le composant tout le nécessaire pourgérer son cycle de vie permettent de régler efficacement le problème énoncé plus tôt. Il estégalement important de remarquer que l’interface initiale est gardée intacte, suivant doncles traces de [6] sur la transparence au niveau de l’interface exposée. Différentes stratégiesde chargement et de déchargement sont également explorées, principalement dans le butd’offrir un meilleur contrôle sur les ressources utilisées par une application.


Figure 2.3 Patron « composant virtuel » (tiré de [10])

2.4.2 Patrons liés aux préoccupations de l’adaptation

Les patrons de conception qui sont le plus dans l’esprit de ceux proposés à l’origine par leGang of Four sont ceux de Ramirez [39]. Ces derniers sont regroupés par préoccupationet ne sont pas liés directement à un domaine d’application précis. Les patrons proposéssont issus d’une recherche intensive basée sur des projets libres, commerciaux et de re-cherche. L’approche décrite dans les travaux de Ramirez consiste à relever des solutions àdes problèmes récurrents des logiciels adaptatifs. Ces solutions spécifiques aux domainesrespectifs des projets analysés sont généralisées et affinées afin qu’elles puissent être uti-lisées dans n’importe quel domaine d’application. Au total, 12 patrons sont proposés etprésentés dans un format standardisé qui couvre des caractéristiques comme le contexted’utilisation, la structure du patron, les éléments le composant et les contraintes pour sonimplémentation. Les patrons et leurs relations sont présentés à la figure 2.4. Cette figurereprésente une organisation des patrons qui permet la création d’un logiciel adaptatif selondifférentes stratégies. Un développeur peut ainsi choisir depuis des requis d’adaptation lespatrons les plus adéquats pour chacune des préoccupations.

Bien que les patrons proposés par Ramirez sont applicables à divers domaines, plusieursd’entre eux restent liés au type d’application développé. Par exemple, le patron serverreconfiguration reste spécifique aux systèmes client-serveur. Aussi, plusieurs artéfacts sontprésents dans plus d’un patron. Par exemple, les éléments component, inference engineet rule font partie de trois patrons de type decision-making. Ces spécificités indiquentque la structure qu’ils induisent au logiciel cible peut être très différente en fonction dudomaine tout en partageant, malgré tout, plusieurs éléments clés. Bien qu’un effort degénéralisation a été fait, aucune structure de base ne peut être identifiée. Cela impliqueque l’implémentation de chacun des patrons peut amener à une architecture largement

2.4. PATRONS DE CONCEPTION 17

Figure 2.4 Relations entre les patrons proposés par Ramirez (Tiré de [39])


différente et rendre difficile la comparaison des différentes solutions pour chacune despréoccupations. Ramirez offre tout de même une synthèse des solutions qui reste la pluscomplète à ce jour au niveau des patrons de conception.

2.4.3 Patrons pour structures spécifiques

D’autres projets de recherche ont proposé des patrons de conception pour différents pro-blèmes. Cependant, ils sont généralement plus liés à un domaine d’application ou ciblentun contexte plus spécifique que les logiciels adaptatifs. Quelques travaux de cette naturesont présentés dans la présente section.

D’abord, Mannava et Ramesh [30] ont repris l’essentiel des patrons proposés par Ramirezet ajouté trois autres : row data gateway, thread per connection et event notifier. Typi-quement, les deux premiers patrons sont utilisés pour des systèmes client-serveur tandisque la notification par évènement est utilisée accessoirement pour découpler les modulescontrôleurs des composants cibles à la façon du patron content-based routing de Ramirez.

Ensuite, Menasce et al. [33] ont proposé des patrons architecturaux pour la QdS de sys-tèmes adaptatifs. L’idée est d’améliorer la QdS en maximisant des fonctions utilitaires parle biais d’adaptations du système. Ces fonctions ont comme arguments des propriétés dusystème qui sont mesurées à l’exécution par un artéfact nommé monitor. Le but d’un telsystème adaptatif consiste donc à planifier des reconfigurations de la connexion de com-posants pour atteindre des valeurs cibles des fonctions utilitaires. Les patrons présentéssont donc en réalité des structures pour mettre en place des stratégies de QdS comme larépartition de charge (load balancing), ou la division pour régner (divide and conquer).Au final, la structure mettant en place l’adaptation est dans tous les cas une architecturepar composants dont l’organisation est choisie parmi un ensemble de configurations fonc-tionnellement équivalentes, chacune liée à une valeur de qualité induite au système. Ensoi, cette structure est une solution à l’ajout de comportement adaptatif dans un systèmeet les patrons l’utilisent pour proposer des solutions liées à la QdS. Le problème est queles patrons ne peuvent s’appliquer aux logiciels dont la structure est trop différente.

Finalement, Weyns et al. [47] ont proposé un ensemble de patrons de contrôle décentraliséde l’adaptation : coordinated control, information sharing et regional planning. Ces pa-trons supposent une structure dont les préoccupations ont été séparées suivant le modèleMAPE-K. L’application de ce modèle est cependant interprétée dans une classification despatrons réalisée par Berkane et al. [2]. Ces derniers classifient huit patrons de conceptionen fonction de leur responsabilité en lien avec les étapes du modèle MAPE-K et orthogona-

2.5. VÉRIFICATION ET DE VALIDATION DE LOGICIELS ADAPTATIFS 19

lement en niveau d’implémentation. La majorité des patrons sont tirés de [39, 40] et sontclassifiés au niveau logique, c’est-à-dire qu’ils sont plus abstraits que les patrons de concep-tion classiques (tirés de [12]), eux-mêmes classifiés à la couche technique. Cependant, ilssont moins abstraits que les étapes du MAPE-K qui sont classifiées au niveau fonction-nel. Il n’est cependant pas question d’analyser la structure induite par l’utilisation despatrons de conception et donc de déterminer si cette structure implémente correctementet complètement le modèle.

Les limitations et spécifications des patrons de conception mènent donc à l’idée de pro-poser une structure la plus standard possible pouvant servir de base et où les différentsmécanismes de l’adaptation comme ceux présentés précédemment puissent être efficace-ment ajoutés, modifiés et comparés. En d’autres mots, il devrait être facile d’assemblerdes composants présentant des propriétés d’adaptation en un système complet et de mo-difier cette adaptation en affectant le moins possible le reste du système. Cette séparationdes préoccupations est centrale à la qualité logicielle. Aussi, le niveau de granularité despatrons de conception est plus propice celui des modèles présentés à la section 2.3 pouraider les développeur dans l’implémentation de l’adaptation.

2.5 Vérification et de validation de logiciels adaptatifs

Le développement de techniques de vérification et validation (V&V) des logiciels adapta-tifs est un défi de taille. Il a été indiqué par Lemos et al. [24] qu’un des défis principauxest la recherche de moyens pour effectuer la vérification d’un logiciel adaptatif à l’exécu-tion dans un temps tout en contrôlant la complexité qui en découle inévitablement. Destechniques comme la vérification de modèles et la vérification quantitative à l’exécutionsont mentionnées par Calinescu et al. [5]. Ils expliquent également comment la sélectionde services à l’exécution peut être contrôlée par un outil de vérification quantitatif pours’assurer que les spécifications et les requis sont continuellement satisfaits.

Les métriques de qualité sont un moyen d’effectuer la vérification dans les logiciels parrapport à une préoccupation. Une métrique produit un indicateur qui peut être interprétépar rapport à un domaine de valeurs. Il est ainsi possible d’indiquer des valeurs cibleset détecter si l’implémentation présente des problématiques et pourrait être améliorée.Bien que typiquement utilisées à la conception, elles peuvent également être utilisées àl’exécution. Dans le cas d’un logiciel adaptatif, les valeurs qu’elles fournissent pourraientpar exemple être utilisées comme facteurs décisionnels dans une stratégie d’adaptation.


La présente section introduit les différentes approches actuellement utilisées pour la V&Vdes logiciels adaptatifs. Au niveau des métriques, la majeure partie de celles proposéessert à comparer différents logiciels adaptatifs et est généralement qualitative plutôt quequantitative. Plus de détails sur ces métriques sont donnés à la section 6.2.2.

2.5.1 Phase de conception

Dans les logiciels adaptatifs, plusieurs techniques de V&V ont été proposées, soit pour laphase de conception du système ou à l’exécution. À la conception, une approche populaireest la vérification d’un modèle du système. Par exemple, Liu et al. [26] propose « uneapproche hybride pour la détection efficace de fautes d’adaptation » pour les applicationsadaptatives. Leur approche suppose une stratégie d’adaptation contrôlée par des règlesd’adaptation. Pour diminuer la complexité de l’exploration de tous les états d’adapta-tion, ils utilisent une approche probabiliste : une valeur de probabilité est donnée suite àune exécution du système à chaque paire d’atomes propositionnels (chaque élément d’uncontexte qu’ils modélisent comme une valeur booléenne). La valeur de probabilité est unindicateur de confiance envers une contrainte formée des deux atomes propositionnels. Parexemple, si deux atomes a et b ont toujours le même état lors de l’exécution, le taux deconfiance est très haut. Ainsi, il est possible de spécifier une contrainte où tout état dusystème incluant cette paire à des valeurs différentes n’est jamais rencontré en pratique.

L’idée derrière cette technique ainsi qu’une multitude d’autres est de minimiser le pluspossible l’espace d’états devant être vérifié. En d’autres mots, les zones de l’espace d’étatdu système où les contraintes sont violées n’ont pas besoin d’être vérifiées ce qui accélèrela vérification.

2.5.2 Phase d’exécution

Cette phase est celle qui concerne le plus les logiciels adaptatifs, car le dynamisme qu’induitl’adaptation rend les méthodes de V&V traditionnelles insuffisantes. Il est nécessaire dedifférencier les éléments qui sont la cible de la V&V. En effet, un développeur pourraitvouloir vérifier l’atteinte de buts d’adaptation, typiquement relié à la QdS, mais aussivouloir vérifier si l’implémentation du logiciel adaptatif garanti que tous les états atteintslors de l’exécution seront supportés. Beaucoup de travaux proposent des métriques pourles propriétés de performance et de QdS [22, 38].

Pour certains, l’adaptation est en soi un moyen de mettre en place une assurance qualitédans les systèmes. Par exemple, Rushby [42] propose que la certification de systèmes

2.6. ENQUÊTES SUR LE DOMAINE 21

puisse être atteinte par l’utilisation de mécanismes effectuant des vérifications à l’exécutionet détectant des anomalies. La définition d’une anomalie est cruciale à la validation dusystème. En fait, une anomalie peut être une déviation du comportement par rapport àun modèle généré lors de tests [42], mais comme à la phase de conception une anomaliepourrait être un état d’adaptation qui viole des spécifications ou un état pour lequel lecomportement du système n’est pas défini.

L’analyse de la zone de viabilité (l’ensemble des états du système qui permettent l’atteintedes requis et spécifications) est une forme de vérification de modèle similaire à celle utiliséeà la conception puisque cette zone doit être définie depuis un modèle représentatif dusystème à l’exécution. Cependant, contrairement à la phase de conception, la zone deviabilité peut changer en fonction de l’état d’adaptation du système [24, 44], rendantpossible l’atteinte d’états hors de cette zone. Des techniques sont donc nécessaires pourévaluer la zone de viabilité pour chacun des états du système. Surtout, il est nécessaire depouvoir indiquer au système si ce dernier ne se trouve pas dans la zone de viabilité afinque des actions adaptatives puissent permettre à ce dernier de le redevenir.

2.6 Enquêtes sur le domaine

Les enquêtes scientifiques sont utiles pour obtenir un aperçu d’un domaine ainsi que lesdéfis auxquels ce dernier fait face à un moment. Surtout, il est important de considérerles défis identifiés pour centrer les recherches effectuées dans le domaine. Pour le présentprojet de recherche, les enquêtes ont servi à mieux préciser les éléments de recherche. Danscette section, deux enquêtes principales sont présentées et les aspects qui touchent le plusle présent projet de recherche sont résumés. Elles sont également utilisées pour expliquerla façon dont les contributions sont utiles pour l’avancement du domaine.

D’abord, l’enquête réalisée en 2013 qui constitue la plus récente est présentée à la section2.6.1. Par la suite, une enquête réalisée en 2009 est présentée à la section 2.6.2.

2.6.1 Lemos et al.

Dans l’enquête de Lemos et al. [24], quatre sujets principaux sont relevés comme étantd’intérêt pour les recherches futures : « conception des solutions adaptatives, procédésd’ingénierie des logiciels adaptatifs, décentralisation des boucles de contrôle et V&V pra-tique à l’exécution des logiciels adaptatifs » Lemos et al. [24]. Deux de ces aspects sont en


liens étroits avec le présent projet de recherche : procédé d’ingénierie et V&V. Ces dernierssont résumés depuis [24] :

Procédé d’ingénierie

Les logiciels adaptatifs sont différents des logiciels traditionnels puisqu’ils opèrent dans« un monde hautement dynamique et doivent ajuster automatiquement leur comportementen réponse aux changements dans leur environnement, leurs buts ou dans le système lui-même. » Lemos et al. [24] Dans le cycle de vie traditionnel d’un logiciel, les développeursont le rôle de transformer un logiciel pour atteindre les requis d’un client. Une fois lelogiciel déployé, le comportement du logiciel est fixé et des changements dans les requisimpliquent inévitablement le travail des développeurs. Dans le cas des logiciels adaptatifs,le rôle des développeurs est modifié, passant « d’opérationnel à stratégique » Lemos et al.[24]. L’impact de cette modification est que les phases de développement traditionnelles nesont plus aussi représentatives du travail à entreprendre. En effet, comme les requis sontanalysés à l’exécution, le défi des développeurs est d’effectuer l’ingénierie des élémentsmettant en place l’adaptation et les mécanismes pour effectuer le contrôle du système.Pour ce faire, la modélisation du système et de son environnement doit faire partie ducycle de vie du logiciel. Une partie de cette modélisation peut se faire en partie à laconception et ce modèle peut être modifié de façon autonome pour reproduire le systèmephysique tel qu’il est dans son environnement à l’exécution.

Le lien principal avec la technique d’ajout de comportement adaptatif proposée dans leprésent projet de recherche est au niveau de la planification. En effet, l’évolution d’unlogiciel qui s’adapte à son environnement doit se faire conjointement à la modélisation dece même environnement. Plus particulièrement, la phase d’implémentation d’une fonction-nalité peut inclure ou non un comportement adaptatif. Il faut, cependant, bien différen-cier les requis liés à une fonctionnalité de ceux liés à l’adaptation comme l’autoguérison.Avec l’utilisation des patrons de conception, les composants sont d’abord développés pourune fonctionnalité spécifique et un espace de contextes défini. Un composant peut doncêtre développé avec un comportement adaptatif contraint à l’intérieur de cet espace, maisl’utilisation de mécanismes comme la substitution de composants est gérée dans une phaseultérieure. Cette approche de développement permet donc un développement en intégra-tion continue où l’espace de contextes que le système est attendu de supporter est couvertgraduellement. Le modèle développé est également fait en deux phases qui peuvent êtreintégrées séparément dans les phases de développement : à la conception initiale (mo-délisation des paramètres) et à la spécialisation pour une plateforme (modélisation desmoniteurs).


Vérification et Validation

Un problème important dans le domaine de l’adaptation est le développement de laconfiance des utilisateurs envers les décisions prises de façon autonome par le système.La certification par des techniques de V&V est alors utilisée comme façon de prévoir lavalidité du comportement d’un logiciel adaptatif et d’améliorer la confiance des utilisa-teurs. De telles techniques sont difficiles à élaborer. La tâche est encore plus ardue lorsqu’unprocédé traditionnel impose une assurance de la satisfaction des requis de façon explicite àla conception. L’inclusion des techniques de V&V à l’exécution comme information utiliséedans les décisions du système est une piste envisagée pour faire en sorte, par exemple, quel’atteinte d’états jugés problématiques soient prévenue de façon automatique. L’ensembledes états du système qui permettent à ce dernier d’atteindre ses buts (ses « requis et pro-priétés désirées » Lemos et al. [24]) est appelée une « zone de viabilité » Aubin et al. [1].Au final, il est donc question de vérifier si le système est dans cette zone de viabilité. Si cen’est pas le cas, il serait alors désirable de reconfigurer le système pour tenter d’atteindreun état dans la zone de viabilité. Tout comme d’autres phases de développement, le V&Vpasserait ainsi partiellement de la conception à l’exécution.

Les métriques qui sont proposées dans le présent projet de recherche sont une tentatived’offrir un outil de vérification pour la structure de base livrée par l’utilisation des patronsde conception proposés. La différence majeure avec les défis et solutions potentielles rele-vés dans le paragraphe précédent concerne le niveau d’assurance que nous visons. Plutôtque de vérifier l’atteinte de propriétés désirées au niveau du système, l’hypothèse pro-posée est de réaliser cette vérification au niveau des composants. Par la composition dedifférents composants offrant un même service, l’argument utilisé dans le présent projetest que les zones de viabilité de chacun des composants peuvent être combinées. Ainsi, lazone de viabilité d’un composant agglomérant ces différents « candidats » est représentéepar l’union des contextes de ces derniers. Les métriques proposées servent à calculer laproportion des états qui sont couverts par un composant de sorte que les situations où unétat indéfini existe puissent être détectées. Les métriques proposées se veulent donc desoutils pour assurer qu’un système respecte ses spécifications en termes de zone de viabilitételle que modélisée. De plus, chacune des phases de conception et d’exécution utilise unemodélisation de la zone de viabilité différente. Le V&V n’est donc pas entièrement remisà l’exécution : il est appliqué aux différentes phases.


2.6.2 Cheng et al.

L’enquête de Lemos et al. [24] est la suite d’une enquête réalisée par Cheng et al. [8]quatre ans plus tôt. Cette première enquête contenait une analyse de quatre grands aspectsdu domaine : les dimensions de modélisation, les requis, l’ingénierie et l’assurance deslogiciels adaptatifs. L’ingénierie et l’assurance sont les deux aspects qui rejoignent ceuxdiscutés précédemment dans la section 2.6.1. Les défis qui y sont reliés sont tout de mêmed’actualité. En lien avec les aspects présentés à la section 2.6.1, des défis qui avaient étérelevés par cette enquête sont présentés.

Ingénierie

Ré-ingénierie : « Explorer les techniques pour l’évolution des systèmes existantset l’injection de l’adaptation dans de tels systèmes » Cheng et al. [8].Ce défi est relevé par les patrons qui offrent une façon d’ajouter graduellement descomportements adaptatifs tout au long du cycle de vie d’un logiciel adaptatif.

Support middleware : Le développement d’une implémentation incluant « desinterfaces standardisées pour les fonctionnalités reliées à l’adaptation » Cheng et al.[8].Ce défi est relevé par le développement de la librairie de référence AdaptivePy oùles artéfacts et leur interface sont standardisés dans les patrons de conception.

Interaction personne-machine : Inclure les utilisateurs dans les boucles de rétro-action pour « assurer la confiance » Cheng et al. [8] envers le système.Ce défi est abordé grâce à l’application de l’adaptation dans le contexte des interfacesgraphiques. Ceci est réalisé concrètement par le biais d’une étude de cas. Cette der-nière prévoit l’utilisation des interactions de l’utilisateur comme données contrôlantl’adaptation. Cependant, la boucle de rétroaction n’est pas modifiable par l’utilisa-teur directement et le prototype de l’étude de cas simule les interactions précédentesd’utilisateur pour faciliter l’observation de l’adaptation.

Vérification et Vérification

Environnements contrôlés par modèles qui sont spécifiques à l’adapta-tion : Le développement par modèles est une piste pour permettre « l’applicationde méthodes de V&V pendant le processus de développement et le support de l’adap-tation à l’exécution. » Cheng et al. [8] L’idée est d’utiliser ce modèle pour prévoirles impacts sur le système qu’aura l’adaptation.Ce défi est en partie relevé par la proposition du modèle par espace d’états pour


spécifier les domaines de viabilité et leur utilisation dans les composants adaptatifset dans les artéfacts du patron moniteur. Particulièrement, ce patron permet la sur-veillance des changements dans le système lors de l’exécution. Les métriques peuventégalement être utilisées à l’exécution pour détecter des états non définis et donc sontune forme de vérification du modèle à l’exécution.

Assurance à l’exécution agile : « Le requis clé pour la vérification à l’exécutionest l’existence de solutions algorithmiques agiles efficaces qui ne requièrent pas unehaute complexité temps/espace. » Cheng et al. [8]Ce défi est abordé par la méthode de calcul liée aux métriques développées. En dimi-nuant le domaine de calcul à deux niveaux de composition et en utilisant une struc-ture abstraite d’espace d’états, la vérification d’architectures complexes est possiblede façon pratique. Cependant, l’implémentation au niveau du calcul d’états récur-rents n’est pas optimale. Or, plus de travail est requis pour développer une solutionencore plus performante.

CHAPITRE 3

Développement des patrons de conception

Un premier objectif secondaire identifié à la section 1.3 vise la proposition de patrons deconception afin de mettre en place des comportements adaptatifs de façon graduelle. Envue de la rédaction d’un premier article à ce sujet, plusieurs étapes ont été nécessairespour analyser et élaborer les patrons de sorte que ceux-ci soient le plus universels possible.De plus, le développement de la librairie de référence AdaptivePy fut partie intégrante dutravail de test et de validation des solutions. Ce chapitre vise à introduire tous les élémentsde développement qui entourent la réalisation des patrons de conception qui sont présentésdans l’article 1, reproduit intégralement au chapitre 4.

3.1 Méthodologie

Le présent projet de recherche a nécessité la recherche et la synthèse de concepts généralisésdans le domaine de l’adaptation des logiciels ainsi que la recherche de patrons de conceptionutilisant ces concepts. Cette section présente la méthodologie de recherche qui a mené àla rédaction du premier article.

3.1.1 Approche générale

L’approche générale appliquée à ce projet de recherche est basée sur une démarche ité-rative, autant au niveau de l’analyse que des développements. Cette démarche permetde mettre en pratique les concepts identifiés séparément et d’analyser les limites de leurimplémentation. Au fur et à mesure que les concepts sont identifiés dans la littérature,ils sont utilisés dans un contexte réel comme solution partielle et les avantages relevéspeuvent alors guider la solution générale qui formera le patron. Un schéma résumant lesétapes d’une itération est donné à la figure 3.1.

Pendant une période donnée d’environ deux semaines, un prototype était développé afinde mettre en place une préoccupation de l’adaptation ou pour en améliorer une déjà miseen place précédemment. Les artéfacts qui sont liés à cette préoccupation peuvent ainsiêtre ajoutés ou améliorés pour mitiger une lacune identifiée précédemment. Un artéfactfait ici référence à un élément de solution modélisé qui compose un patron. Par exemple,un élément de solution permettant de traduire en langage contextuel de plus haut niveau le

27

28 CHAPITRE 3. DÉVELOPPEMENT DES PATRONS DE CONCEPTION

Identi cation d'une préoccupation

Identi cation des concepts communs

Implémentation d'un prototype

démonstratif

Critique et propositions

d'amélioration

Début de l'itération

Nouvelleitération

Dernièreitération

Figure 3.1 Démarche itérative pour le développement des patrons de concep-tion

contexte actuel depuis des données brutes de capteurs serait considéré comme un artéfact.Pour chaque fin de période, une mise à jour de la synthèse des concepts était produite etutilisée comme base pour proposer une version des patrons de conception. L’essentiel desconcepts était considéré comme couvert lorsqu’il était possible de produire une applicationcomplète sans nécessairement spécifier un mécanisme d’adaptation précis. Une implémen-tation de référence des artéfacts tirés des concepts a été faite dans la librairie AdaptivePy,en partie en se basant sur les prototypes des itérations précédentes. Pour mieux évaluerles patrons finaux, une application adaptative graphique a été développée avec et sans lalibrairie. Les sections suivantes précisent un peu plus chaque point énoncé précédemment.

3.1.2 Acquisition et synthèse des concepts essentiels

Pour proposer des patrons de conception, il est nécessaire d’identifier des concepts fon-damentaux qui sont partagés par beaucoup de systèmes adaptatifs. Ces concepts doiventêtre suffisamment généraux pour être inclus sous forme d’artéfacts logiciels qui serontutilisés pour implémenter différents comportements adaptatifs. Ainsi, des types de com-portements adaptatifs doivent être également identifiés et liés aux concepts pour s’assurerque leur implémentation est possible avec les artéfacts en question.

3.1. MÉTHODOLOGIE 29

Comme l’approche générale est itérative, l’acquisition et l’analyse de l’état de l’art se sontfaites par préoccupation et en même temps que les développements. La première itérationa été dédiée à la lecture des enquêtes dans le domaine et des travaux principaux surla question des patrons de conception, par exemple le mémoire de Ramirez [39]. Par lasuite, une préoccupation cible a été identifiée avant chaque itération afin de concentrer lesrecherches pendant ces périodes. Les types de travaux analysés inclus les propositions depatrons de conception, de frameworks, de modèles, de concepts d’adaptation ainsi que deprototypes présentant des mécanismes d’adaptation.

Pour le premier article uniquement, près de 80 documents ont été analysés et 24 d’entre euxont été retenus comme apportant des concepts généralisables et originaux. La synthèse desconcepts est présentée dans l’article à la section 4.2. Trois préoccupations sont retenuescomme générales : la surveillance des données d’adaptation, les méthodes d’adaptationdans les composants et les stratégies d’adaptation. Il est à noter que les patrons visentprincipalement les applications graphiques, ainsi il est question plus spécifiquement decomposants pour les méthodes d’adaptation.

Aussi, ce que la littérature identifie généralement comme mécanismes d’adaptation estidentifié comme stratégies d’adaptation. Cette distinction a été faite pour mettre en évi-dence la différence entre mécanisme et méthode d’adaptation : une méthode représentela maniabilité de la structure tandis que le mécanisme est la stratégie utilisée par le sys-tème pour atteindre ses buts d’adaptation. En effet, une stratégie tire parti des méthodesd’adaptation disponibles pour atteindre les buts d’adaptation.

Pour déterminer si un concept est généralisable, il devait se souscrire aux requis suivants :

- Être neutre par rapport aux mécanismes/stratégies d’adaptation

- Être neutre par rapport au domaine d’application

- Couvrir une préoccupation de l’adaptation partagée par la majorité des modèlescomme MAPE-K et des frameworks

3.1.3 Validation par prototypes

Afin d’assurer un lien cohérent entre les concepts identifiés et leur application, des pro-totypes mettant à exécution des préoccupations de l’adaptation ont été produits pourchacune des itérations. Les préoccupations abordées sont :

- Spécification des données d’adaptation


- Surveillance (monitoring) de données d’adaptation depuis

1. Un fichier XML

2. Un générateur pseudo-aléatoire

3. Un fournisseur abstrait

- Spécification du domaine d’adaptation d’un composant

- Substitution de composants (via un composant adaptatif)

- Filtrage des candidats de substitution

- Gestion des instances de candidats de substitution

- Intégration de l’adaptation dans une librairie graphique et son éditeur graphique (Qtet Qt Designer, respectivement)

Les prototypes ont été développés séparément de la librairie de référence.

3.1.4 Développement d’AdaptivePy

AdaptivePy a été développé en deux temps : d’abord dans une phase exploratoire puisdans une phase de formalisation. Pour la réalisation des prototypes, les artéfacts nécessairesà leur réalisation ont été développés dans une version préliminaire d’AdaptivePy. Cetteversion avait comme but d’être une implémentation rudimentaire et possiblement instabledes concepts identifiés puisqu’elle ne comptait pas de tests unitaires.

Une fois les limitations identifiées et les problèmes d’implémentation mieux compris, lalibrairie a été complètement réécrite depuis les patrons de conception formalisés. Cettenouvelle version inclut des tests unitaires ainsi que de la documentation pour la plupartdes classes et méthodes. Ainsi, des tests unitaires ont été configurés sur le site de dépôten ligne de sorte que ces derniers soient exécutés pour chaque commit. De plus, commela librairie est distribuée publiquement, la configuration pour PyPi (base de données depaquets Python) a été ajoutée.

Le développement de cette librairie a participé à l’analyse des concepts lors du procédéitératif du projet de recherche puisque certaines limitations d’implémentations, autant auniveau de la performance que de la structure imposée par la POO, ont influencé l’orga-nisation des patrons de conception. Les lacunes au niveau des artéfacts n’ont donc passeulement été identifiées au niveau conceptuel, mais également au niveau pratique. Cette

3.2. SPÉCIALISATION POUR LES INTERFACES USAGERS GRAPHIQUES 31

approche a permis de produire des patrons de conception qui sont plus facilement appli-cables et liés aux bonnes pratiques de programmation.

3.2 Spécialisation pour les interfaces usagers graphiques

Comme le projet de recherche vise directement le développement des interfaces usagersgraphiques, il est important que certaines clarifications soit apportées aux choix effectuéspour favoriser ce domaine d’application. Bien que beaucoup d’importance est apportée à lagénéralisation des patrons de conception, certains systèmes se prêtent moins à la structureproduite par l’utilisation des patrons.

Par exemple, le patron Proxy routeur nécessiterait un support explicite de transactionspour des systèmes distribués en réseau pour effectuer l’opération de routage. Bien qu’untransfert d’état est prévu dans ce patron, ce dernier n’a pas été pensé pour supporterla redondance ou le balancement de charge, typiques à ce genre de systèmes. Dans cesapplications, il peut exister plusieurs instances de candidats de substitutions issues d’unemême classe. Comme ces types d’adaptation ne sont pas rencontrés dans le contexte desinterfaces usagers graphiques, les concepts qui y sont reliés ont été laissés de côté. Malgréce compromis, le patron demeure une bonne base où les concepts manquants peuvent êtreajoutés.

Un autre aspect qui est induit par l’application dans le contexte d’interfaces usagers gra-phiques est la liaison à un toolkit comme Qt. En effet, le prototype présenté dans lepremier article dépend de certains éléments fournis par Qt et la librairie de binding PyQt.Principalement, la solution rendant possibles la création de widgets personnalisés et leurchargement dynamique dans l’éditeur graphique Qt Designer est spécifique à ce toolkit.Comme chaque toolkit a sa propre structure, il aurait été nécessaire de créer une couchesupplémentaire d’abstraction pour rendre le prototype de l’étude de cas neutre à ce niveau.De plus, AdaptivePy n’inclut aucun artéfact spécifique aux interfaces graphiques. Ainsi, ila été jugé qu’une telle fonctionnalité aurait compliqué inutilement le prototype présenté.Le compromis choisi a été de simplifier les diagrammes représentant les implémentations(figures 4.5 et 4.7) en enlevant les éléments trop spécifiques à Qt de sorte que l’idée géné-rale derrière soit portable, peu importe le toolkit et même hors du domaine des interfacesusagers graphiques.

Il est tout de même adéquat de spécifier l’approche empruntée pour réaliser le composantadaptatif sous forme de widget personnalisé. La figure 3.2 présente la façon dont le proto-type démonstratif avec AdaptivePy (voir section 4.5.2) rend visible le widget à l’éditeur gra-


phique Qt Designer. Un plug-in fourni par la librairie de binding PyQt introspecte le codede l’application en vue d’une classe concrète dérivée de QPyDesignerCustomWidgetPlugin.Une telle classe est une classe fabrique qui génère une instance d’un QWidget. Dans le casdu prototype, ce widget est le composant adaptatif qui supporte la sélection d’options. QtDesigner peut ensuite charger dynamiquement le widget lorsque ce dernier est inséré dansl’espace de travail.

Qt Designer

Plugin"libpyqt5"

Code del'application QPyDesignerCustomWidgetPlugin

OptionsSelectorQtPlugin

Introspection

OptionsSelectorQt

QWidgetAdaptiveOptionsSelector

<< génère >>

chargédynamiquement

Figure 3.2 Mise en place du composant personnalisé du prototype de la section4.5.2

3.3 Conclusion

Dans ce chapitre, les étapes qui ont mené à la rédaction d’un premier article dont le sujetest les patrons de conception pour l’ajout de comportements adaptatifs dans les interfacesusagers graphiques ont été présentées.

La méthodologie de recherche des concepts et d’élaboration d’une synthèse des solutionsdepuis laquelle les patrons de conception ont été élaborés a été présentée. Brièvement, ils’agit d’un procédé itératif où la recherche des concepts est concentrée sur une préoccu-pation précise de l’adaptation tirée des enquêtes du domaine pendant la période d’uneitération. Pendant cette même période, ces concepts ont été appliqués dans des prototypeset, une fois formalisés après plusieurs itérations, implémentés en tant qu’artéfacts dansune librairie de référence nommée AdaptivePy.

3.3. CONCLUSION 33

Comme les patrons de conception visent directement les interfaces usagers graphiques,certains choix ont été faits pour mieux servir ce domaine d’application. Plus particulière-ment, certains types d’adaptation qui ne sont pas rencontrés dans le contexte des interfacesgraphiques ont vu leurs concepts spécifiques omis, par exemple dans le cas des systèmes dis-tribués en réseau. Aussi, la neutralité au niveau des toolkits n’a pas été considérée commeune fonctionnalité clé, mais les détails spécifiques à Qt ont été omis pour que l’étude decas soit la plus portable possible tout en restant représentative de l’implémentation réelle.

Le chapitre suivant est une reproduction du premier article introduit dans le présentchapitre. Les concepts retenus sont expliqués en détail, les patrons de conception sontprésentés et le prototype développé pour l’étude de cas montre leur utilisation dans uncontexte réel. Ce dernier a été réalisé avec la version 0.1.2 d’AdaptivePy telle que distribuéesur PyPi1.

1https://pypi.python.org/pypi/adaptivepy/0.1.2

CHAPITRE 4

Article 1 : Design patterns for addition of adap-tive behavior in graphical user interfaces

Avant-propos

Auteurs et affiliation :

S. Longchamps : étudiant à la maîtrise, Université de Sherbrooke, Faculté de génie,Département de génie électrique et de génie informatique.

R. Gonzalez-Rubio : professeur, Université de Sherbrooke, Faculté de génie, Dépar-tement de génie électrique et de génie informatique.

Date d’acceptation : 4 décembre 2016

État de l’acceptation : version finale publiée1

Revue : Proceedings of the Ninth International Conference on Adaptive and Self-AdaptiveSystems and Applications

Référence : [Longchamps et Gonzalez-Rubio, 2017]

Titre français : Patrons de conception pour l’ajout de comportements adaptatifs dansles interface usagers graphiques

Contribution au document : Cet article présente les trois patrons de conception quienglobent les concepts fondamentaux extraits de la littérature et des frameworks existantsà ce jour. Cet article vise l’atteinte du premier objectif secondaire qui est la propositionde patrons de conception. Chaque sous-objectif discuté à la section 1.3 est abordé dansl’article. Notamment, l’utilisation d’un cas d’étude sous forme de prototype d’applicationgraphique est utilisé pour démontrer l’utilisation des patrons et comparer le code résul-tant à une implémentation ad hoc. L’utilisation de la librairie de référence développée,AdaptivePy, est également expliqué en détails.

Résumé français : Les interfaces usagers graphiques dans les logiciels modernes re-quièrent de plus en plus à s’adapter à diverses situations et utilisateurs, ce qui rend leur

1https://www.thinkmind.org/index.php?view=article&articleid=adaptive_2017_1_20_50006

35

36CHAPITRE 4. ARTICLE 1 : DESIGN PATTERNS FOR ADDITION OF ADAPTIVE

BEHAVIOR IN GRAPHICAL USER INTERFACES

développement plus complexe. Pour gérer cette complexité, nous présentons dans cet ar-ticle trois patrons de conceptions, Moniteur, Proxy routeur et Composant adaptatif, entant que solutions au problème d’implémentation graduelle de comportement adaptatifdans les interfaces usagers graphiques et en général dans tout logiciel basé sur des com-posants. Plutôt que de proposer de nouveaux mécanismes d’adaptation, notre objectif estde formaliser une structure de base pour l’ajout progressif de différents mécanismes toutau long du cycle de développement. Pour ce faire, les travaux existants sur le sujet despatrons de conception orienté vers l’adaptation ont été explorés et les concepts reliés àdes préoccupations similaires sont extraits et généralisés dans de nouveaux patrons. Cespatrons ont été implémentés dans une librairie de référence en langage Python baptiséeAdaptivePy, elle-même utilisée dans une étude de cas sous forme d’application graphique.Cette étude de cas montre une utilisation concrète des patrons et est comparée à une im-plémentation ad hoc fonctionnellement équivalente. Nous observons que la séparation despréoccupations est promue par les patrons de conception et le potentiel de testabilité estamélioré. De plus, l’adaptation des composants graphiques peut être prévisualisée depuisl’éditeur graphique de l’interface. Cette approche est plus près du flux de travail standardutilisé dans le développement d’interfaces usagers graphiques et n’est pas réalisable avecla solution ad hoc.

Design Patterns for Addition of Adaptive Behavior in

Graphical User Interfaces

Samuel Longchamps, Ruben Gonzalez-Rubio

Sherbrooke University,Sherbrooke, Québec, Canada

Email: {samuel.longchamps, ruben.gonzalez-rubio}@usherbrooke.ca

Abstract—Graphical user interfaces (GUI) in modern softwareare increasingly required to adapt themselves to various situationsand users, rendering their development more complex. To handlecomplexity, we present in this paper three design patterns,Monitor, Proxy router and Adaptive component, as solutions tothe gradual implementation of adaptive behavior in GUI andgeneral component-based software. Rather than proposing newadaptation mechanisms, we aim at formalizing a basic structurefor progressive addition of different mechanisms throughout thedevelopment cycle. To do so, previous work on the subjectof design patterns oriented toward adaptation is explored andconcepts related to similar concerns are extracted and generalizedin the new patterns. These patterns are implemented in areference Python library called AdaptivePy and used in a GUIapplication case study. This case study shows concrete usage ofthe patterns and is compared to a functionally equivalent adhoc implementation. We observe that separation of concerns ispromoted by the patterns and testability potential is improved.Moreover, adaptation of widgets can be previewed within agraphical editor. This approach is closer to the standard workflowfor GUI development which is not possible with the ad hocsolution.

Keywords–adaptive; design pattern; graphical user interface;context; library.

I. INTRODUCTION

As applications become increasingly complex and dis-tributed, adaptive software has become a research subject ofgreat interest to tackle related challenges. One area of modernapplications where adaptation requirements have flourished isgraphical user interfaces (GUI). Because they are generallyengineered using a descriptive language and oriented towardspecific platforms, it is hard to produce a single GUI whichautomatically adapts itself to its multiple usage contexts.

Many researchers have proposed models and frameworksto implement adaptive behavior in a generic manner forcomponents-based software [1]–[4]. These solutions typicallyrequire significant effort to modify an existing software archi-tecture and make many technological choices and assumptions.They are limited both in terms of gradual integration to thesoftware and in portability, for a framework usually targets acertain application domain (e.g. distributed client-server sys-tems). As a more portable approach, we propose to use designpatterns for formalizing structures of components which can beeasily composed to produce specialized adaptive mechanisms.While some work has been done to propose design patterns forthe implementation of common adaptive mechanisms [5]–[8],the present work aims at generalizing widespread concepts

used in these patterns. In doing so, their integration in existingsoftware is expected to be easier and more predictable.

As a proof-of-concept, a reference implementation of thedesign patterns has been done as a Python library calledAdaptivePy. An application was built as a case study using thelibrary to validate the gains provided by the patterns comparedto an ad hoc solution. Special attention was paid to thecompatibility to modern GUI design workflow. In fact, ratherthan create a specialized toolkit or create a custom designertool which would include the design patterns’ artifacts, the Qtcross-platform toolkit along with the Qt Designer graphicaleditor was used. The application workflow is presented andcompared to original methods and advantages are highlighted.We expect that through the case study, the patterns’ usage andadvantages will be clearer and offer hints on how to structurean adaptive GUI.

The remainder of this paper is organized as follows.Fundamental concepts of software adaptation extracted fromprevious work are described in Section II. The design patternsinspired from the concepts are presented in Section III. Theprototype application with adaptive GUI is presented in SectionIV and an analysis of the gains procured by the use of theproposed design patterns are presented in Section V. The paperconcludes with Section VI and some future work is discussed.

II. CONCEPTS OF SOFTWARE ADAPTATION

This section presents major concepts of adaptation fromrelated work classified in three concerns: data monitoring,adaptation schemes and adaptation strategies.

A. Adaptation Data MonitoringContextual data on which customization control rely, re-

ferred to as adaptation data in this paper, can come fromvarious sources, both internal (for “self-aware” applications[9]) and external (for “self-situated” [9] or “context-aware”applications). The acquisition of contextual data to be usedas adaptation data is part of a primitive level, which isnecessary for other more complex adaptation capabilities tobe implemented [10]. Contextual data is usually acquired bya monitoring entity (sensors/probes/monitors) responsible forquantizing properties of the physical world or internal state ofan application [7], [11]–[15]. Multiple simple sensors can becomposed to form a complex sensor, which provide higher-level contextual data (Sensor Factory pattern [15]). Internalcontextual data can be acquired simply by using a component’sinterface, but when the interface does not provide the necessarymethods, introspection can be used (Reflective Monitoring

8Copyright (c) IARIA, 2017. ISBN: 978-1-61208-532-6

ADAPTIVE 2017 : The Ninth International Conference on Adaptive and Self-Adaptive Systems and Applications

[15]). When a variety of adaptation data is monitored, itprovides a modeled view of the software context, sometimesshared within a group of components. Some event-based mech-anism with registry entities can be used to propagate adaptationdata to interested components (Content-based Routing [15]).Quantization can be done on multiple abstraction levels andthresholds can be used to trigger adaptation events (AdaptationDetector [15]).

B. Adaptation Schemes in ComponentsMany researchers aimed at defining a design pattern for

an adaptive component that would allow for various schemesof adaptation in a generic way. Two main approaches canbe extracted from previous work: component substitution andparametric adaptation.

a) Component substitution: The underlying principleof component substitution is to replace a component by afunctionally equivalent one with regard to a certain set offeatures. This can also be done by adding an indirectionlevel to the dispatching of requests and forwarding them tothe appropriate component. The first pattern applying thisconcept is probably the Virtual Component pattern by Corsaro,Schmidt, Klefstad, et al. [5]. It is similar to the adaptivecomponent proposed by Chen, Hiltunen, and Schlichting [16],but adds the principle of dynamic (un)loading of substitutioncandidates. In both cases, an abstract proxy is used to dispatchrequests to a concrete component, which is kept hidden fromthe client. This approach is also used by Menasce, Sousa,Malek, et al. [17], who proposed architectural patterns toimprove quality of service on a by-request dispatch to oneor many components. To maintain the software in a valid statebefore, during and after the substitution, many techniques havebeen proposed, such as transiting a component to a quiescentstate [18], [19] and buffering requests [20]. State transferbetween components can be used when possible, otherwisethe computing job must be restarted [16], [19].

b) Parametric adaptation: Rather than substituting awhole component by a more appropriate one, parametricadaptation is when a component can adapt itself to be moreappropriate to a situation. This is usually done by tuningknobs, configurable units in a component (e.g. variables usedin a computation). Knobs can be exposed in a tunabilityinterface [1] for use by external control components, eitherincluded by design or automatically generated at the meta-programming level (e.g. with special language constructs, suchas annotations [10]). The tunability domain of each knobis explicit and may vary over time. For example, if a newalgorithm is discovered in the middle of a large computingjob, an adaptation mechanism that is kept aware of the knob’spossible values is able to switch to it if it judges that it willperform better overall [21].

C. Adaptation StrategiesNo single adaptation strategy is universal for all software.

Most past work has been done on applying component substi-tution using various strategies. For example, many researchershave explored rule-based constraints along with an optimiza-tion engine to devise architectural reconfiguration plans [1],[13]. This popular approach has tainted proposed frameworksthat tend to be limited to this strategy only. An importantprinciple is that strategies are separate from the component’s

implementation and can be easily changed. In fact, it isdesirable to externalize adaptation strategies in order to be ableto easily develop, modify and test them separately. Ramirez [7]calls this class of design patterns “decision-making”, since theyrelate to when and how adaptation is performed. Because thesedesign patterns are concrete adaptation strategies, their artifactsare mainly related to specific strategies (e.g. inference engines,rules, satisfaction evaluation functions). The approach of thisclass of patterns is typically related to rule-based constraintssolving, but a more general goal is to select which plan orcomponents from a set to reconfigure the system with.

III. DESIGN PATTERNS

This section presents design patterns which realize theconcepts presented in Section II with some improvements.When used together, we believe they provide the soughtstructure for adaptive software. Unified modeling language(UML) diagrams are used to show the structure of the patternsin a standardized way.

A. Monitor PatternClassification: Monitor and analyze.Intent: A monitor provides a value for one type of adaptationdata to interested entities.Motivation: There is a need to quantize raw contextual data asparameters of adaptation data with explicitly defined domainand in specialized modules decoupled from the rest of theapplication. Adaptation data needs to be reasoned about inarbitrarily high abstraction level and be proactive in the adap-tation detection process. Agreement for monitored data shouldbe implied by design in order to allow for safe informationsharing among interacting components.Structure: Fig. 1 shows the structure of the monitor patternas a UML diagram.

+observed_update(observable, value)Observer

+register_monitor(parameter, monitor)+unregister_monitor(parameter)+observed_update(observable, value, kwargs+subscribe(subscriber, parameter)+unsubscribe(subscriber, parameter)+snapshot(parameters = None)

MonitorEventManager

+value()+possible_values()

Monitor#set_latest_value(value)+latest_value()+start()+stop()+register(observer)+unregister(observer)+update()

DynamicMonitor

+register(observer)+unregister(observer)+notifyObservers(value)

Observable

+possible_values()Parameter

+updated_monitored_value(parameter, old_value, new_value)ParameterValueSubscriber

<<depends>>

Figure 1. Monitor pattern UML diagram

Participants:

• Parameter: A parameter is one type of adaptationdata as defined in Section II-A. Its possible valuesdomain is explicitly defined and forms a state space.Many range types can be used to model a parameter’sdomain.

• (Static) Monitor: Provides a stateless (further referredto as “static”) means of acquiring a value within



a subset of a certain parameter’s domain. Formally,ΩM ⊆ ΩP for possible values Ω of monitor M andparameter P . A monitor can be an aggregation of otherstatic monitors, but not of dynamic monitors.

• Dynamic monitor: Additionally to providing a valuefor a parameter, schedules the acquisition of the valueand alerts an observer that a new value has beenacquired. Some form of polling or interrupt-basedthread awakening needs to be employed along witha previous value to know if the value has changedcompared to the latest value, in which case an eventnotification is triggered to interested entities. Thismakes it inherently stateful. Like a static monitor, itcan be an aggregation of other monitors. The particu-larity is that it can aggregate both static and dynamicmonitors.

• Monitor event manager: Registry entity which al-lows for a client component to subscribe to a param-eter and be alerted when a new value is acquired.Similarly, a dynamic monitor can be registered withinthe manager and provide a value to any subscriberof the corresponding parameter. In such manager,monitors and parameters are related by a one-to-onerelationship; a given parameter can only be monitoredby a single monitor.

• Observable/Observer: See Gang of Four observerpattern [22]. Used for monitor registering mechanism.

• Parameter value subscriber: Provides a means tobe notified when a new value of a parameter it hassubscribed to has been acquired.

Behavior: An adaptation data type can be formalized as aparameter in terms of the quantized values the system expectsto use. A static monitor provides a means to concretelyquantize raw contextual data from a sensor or introspection toa value within a defined domain expected by the system. Thequantization can be done using fixed or variable thresholds.A dynamic monitor adds scheduling behavior, which allowsto provide a value based on accumulated data over timeand apply filtering. The monitor event manager is alerted bymonitors and dispatches the new value to related subscribers.The dependency regarding subscribers is with the parametersfor which they requested to be notified, but actual monitoringis done separately.Consequences: As monitors are hierarchically built, higher-level abstraction information can be provided. This patternallows the analysis step of a MAPE-K loop [12] to be donethrough hierarchical construction of monitors: a parametercan define high-level domain values which are provided bya monitor composed from lower-level ones and componentscan use this to simplify their adaptation strategies. High-leveladaptivity logic is reusable in that parameters are abstract andcan easily be shared among projects. Monitors can be chainedsuch that only the concrete data acquisition has to be redonebetween projects, keeping scheduling and filtering as reusableentities.Constraints: To assure agreement between interacting compo-nents, it is necessary for adaptive components which dependon a common parameter to also subscribe to the same monitorevent manager. These components are therefore part of thesame monitoring group. This can be checked statically or be

assumed by contract. The need for a one-to-one relationshipbetween a monitor and a parameter within a monitoring groupis based on this agreement requirement. A monitoring groupcan be thought of as a single entity that cannot have duplicateor contradicting attributes, e.g., it cannot be at two positions atonce. In this example, an attribute is a parameter and a monitoris the entity providing the value for this attribute.Related patterns: Sensor factory, reflective monitoring,content-based routing, adaptation detector [7], informationsharing, observer [22].

B. Proxy Router PatternClassification: Plan and execute.Intent: A proxy router allows to route calls of a proxyto a component chosen among a set of candidates using adesignated strategy.Motivation: When implementing component substitution, away to clearly separate concerns relating to the adaptationlogic (substitution by which component) and the execution ofsubstitution (replacing a component or forwarding calls to it)are difficult to implement in an extensible way. The proxypattern [22] allows to forward calls to a designated instance,but does not specify how control of the routing process shouldbe implemented. Candidate components need to be specifiedin a way that does not necessitate immediate loading or instan-tiation and which is mutable (to allow runtime discovery). Tomaximize reusability, strategies should be devised externally.Structure: Fig. 2 shows the structure of the proxy routerpattern as a UML diagram.

+candidates()+proxy()+route(target)+choose_route()

ProxyRouter +delegate()+update_delegate()

Proxy

+proxy()InternalProxyRouter

+proxy()ExternalProxyRouter

+choose_route(candidates)ChooseRouteStrategy DelegateComponent

+create(args)CandidateFactory

<<uses>>

Figure 2. Proxy router pattern UML diagram

Participants:

• Proxy: Gang of Four [22] proxy pattern, with theexception that the interface is not necessarily speci-fied (e.g. forwarding to introspected methods). It isresponsible for making sure no calls are lost when anew delegate is set.

• Delegate component: Concrete component which isproxied. It must be specified as part of the proxyrouter’s candidates set.

• Proxy router: Keeps a set of component candidatesand allows to control the routing of the calls a proxyreceives to the appropriate candidate chosen by somestrategy. The proxy router is responsible for ensuringany state transfer and initialization of candidate in-stances.

• Candidate factory: Gang of Four [22] factory patternfor a candidate. Used as part of candidates definition.



Can do local loading/unloading for external candi-dates.

• Choose route strategy: Concrete strategy to choosewhich candidate among a set to use, based on Gang ofFour [22] strategy pattern. It uses accessible informa-tion from the application, candidates (e.g. adaptationspace, descriptor, static methods) or any inferenceengine available to make a choice.

• External/Internal proxy router: Depending on theuse, a proxy router can use an external proxy (asa member) or internally be a proxy (through inheri-tance). To allow for both schemes, a means to acquirethe proxy is provided and returns either the memberobject (external) or a reference to the proxy routeritself (internal).

Behavior: A set of candidates is either statically specifiedor discovered at runtime (e.g. looking for libraries providingcandidates). The proxy router is then initialized by choosinga candidate using the strategy and controls the proxy to setan instance of the chosen candidate as active delegate. At anytime, a new candidate can be chosen and set as active delegateof the proxy.Consequences: The proxy router pattern allows for flexibleand extensible specification of component substitution. Thestrategies to choose a candidate to route to can be reused in anyproject with consistent information acquisition infrastructure,such as the one provided by the monitor pattern. Candidatesneed not be specified statically and control related to routingcan be done both internally and externally.Constraints: Strategies might rely on certain project specificinformation which is not portable. Separating specific fromgenerally applicable strategies and composing them shouldhelp with this constraint.Related patterns: Adaptive component [16], virtual com-ponent [5], master-slave [23], component insertion/removal,server reconfiguration [7], proxy [22].

C. Adaptive Component PatternClassification: Analyze and plan.Intent: Use monitored adaptation data to control parametricadaptation and component substitution by making adaptationspaces explicit.Motivation: A basic structure is needed to easily add adaptivebehavior in the form of parametrization or substitution. Com-ponents need a way to explicitly provide means for adaptationstrategies to reason about their adaptation space in order toformulate plans. This information should be external to a basecomponent if the adaptation is to be added gradually. Mostimportantly, an adaptive component must behave like any non-adaptive component and be used among them without anyimpact on the rest of the system.Participants:

• Adaptive: An adaptive component which definesmeans for acquiring the adaptation space. It can beused as a subscriber to a parameter value provider.

• Monitor event manager: Parameter value providerrealized with the monitor pattern (see Section III-A).

• Parameter value subscriber: Provides a means tobe notified when a new value of a parameter it hassubscribed to has been acquired (see Section III-A).

• Proxy router: Proxy router pattern (see Section III-B)• Adaptive proxy router: Adaptive version of a proxy

router allowing to drive the routing process (substitu-tion) using monitored data.

Structure: Fig. 3 shows the structure of the adaptive compo-nent pattern as a UML diagram.

+adaptation_space()+parameter_value_provider()+updated_monitored_value(parameter, old_value, new_value)

Adaptive

+candidates()+proxy()+route(target)+choose_route()

ProxyRouter

AdaptiveProxyRouter

+register_monitor(parameter, monitor)+unregister_monitor(parameter)+observed_update(observable, value, kwargs)+subscribe(subscriber, parameter)+unsubscribe(subscriber, parameter)+snapshot(parameters = None)

MonitorEventManager

+updated_monitored_value(parameter, old_value, new_value)ParameterValueSubscriber

Figure 3. Adaptive component pattern UML diagram

Behavior: A component to be made adaptive can inherit theadaptive interface or a specific decorator can be created ifthe component’s code should remain unchanged. The adaptiveimplementation defines what base adaptation space it willsupport. Then, knobs can be defined within the component andused as variables to compute, for example, its size or lay outingspecifications. Tuning can be done when an updated parametervalue is received. For substitution, the process is the same, butuses the AdaptiveProxyRouter interface. Specific strategies canbe created, using as many generic filters as possible (e.g. filterout candidates which adaptation space does not overlap witha snapshot of the current state).Consequences: Because of the explicit declaration of adapta-tion space, strategies can easily reason about how a componentcan behave in a situation. For example, a strategy can usethe fact that a component’s space is too specific or too wide.Any component can be made adaptive and does not requiremodifications to other components. Because of the supportfor both parametric adaptation and component substitution,the basic structure proposed in this pattern is suitable forvirtually any adaptive mechanism based on monitored data andcomponents adaptation spaces.Constraints: Like stated in Section III-A, interacting adap-tive components must subscribe to the same monitor eventmanager to assure consistency in decision-making processes.While arbitrarily large hierarchies of adaptive componentscan be composed, there is an inherent overhead induced inthe adaptation and routing process. Because a componentsubscribing to some parameter value provider such as themonitor event manager has no guarantee that this parameter isbeing actively monitored, adaptive components need to definea default behavior or immediately request a snapshot of thecurrent state. To minimize this effect, it is preferable to registermonitors prior to creating any adaptive component.Related patterns: Monitor (III-A), proxy router (III-B), adap-tive component [16], virtual component [5].

IV. PROTOTYPE

This section presents AdaptivePy, a reference library im-plementing the three design patterns presented in this paper,



along with a prototype as a case study for analyzing the gainsthey procure compared to an ad hoc implementation.

A. AdaptivePyAdaptivePy implements artifacts from all three design pat-

terns described in this paper. The Python language was chosenbecause it is reflective, dynamically typed and many toolkitbindings are freely available. Beyond the patterns, AdaptivePyprovides some useful implementations, such as enum-baseddiscrete-value parameters, push/pull dynamic monitor decora-tors, operations over adaptation spaces (extend, union, filter)and an adaptation strategy based on substitution candidates’adaptation space restrictiveness. The library is freely availablefrom the PyPi repository under the name “adaptivepy” and isdistributed under LiLiQ-P v1.1 license.

B. Case Study ApplicationThe case study application is a special poll designed to fa-

vor polarization. Five yes/no questions are asked to a user andanswered by selecting the most appropriate response among alist of options. The options provided include yes, no, mostlyyes, mostly no and 50/50. To favor polarization, statisticsfrom the previous answers are used to restrict the range ofoptions provided to the user. If the polarization is judgedinsufficient because of mixed responses (low polarization),fewer options are provided. On the contrary, if virtually allusers have answered yes (high polarization), more options inbetween will be given. The workflow of the application is tostart the “quiz” using a Start button, choose appropriate optionsand send the form using a Submit button. If some optionsremain unselected, a prompt alerting the user is shown andthe form can be submitted again once all options are selected.

The adaptation type used is a form of alternative elements[24]. The GUI is made plastic by replacing control widgetsdisplaying the available options at runtime, conserving theoption selection feature in any resulting interface. Becausethere is a varied number of options, some widgets are moreappropriate than others to display them, while some cannotdisplay certain amounts of options. A checkbox can handletwo options, radio buttons could be used for ranges of two tofour options and a combo box for five and more options. Ofcourse, radio buttons can hold more options and the combobox less, but the amounts suggested represent the ranges theyare subjectively considered most appropriate for. These can bechosen by a designer and further refined through user testing,which means they must be easy to edit.

Polarization levels act as adaptation data to drive adapta-tion. An appropriate solution would allow to design the GUIwithin Qt’s graphical editor “Qt Designer” and to preview ofthe adaptation directly, rather than having to add the businesslogic beforehand. It would also allow for gradual additionand modification of control widget types without necessitatingchanges in unaffected modules.

The toolkit used for this application is Qt 5 through thePyQt5 wrapper library. It is a cross-platform toolkit librarywhich provides implementations of widgets like checkboxes,combo boxes are radio buttons groups. The concrete workis therefore limited to implementing how these componentscan replace each other at the appropriate time and how theyare included in a main user interface. We are therefore moreinterested in the underlying structure of adaptation within the

Figure 4. Adaptive case study application “Polarized Poll”

+set_text(text)+text()+set_options(options)+options()+value()+set_selection()+state_transfer(source)

<<Interface>>OptionsSelector

lowmediumhigh

<<enumeration>>Polarization

ComboboxQt

CheckboxQt

RadioboxQt

-questions_widgets : List<QWidget>-candidates : Map<class, List<OptionsSelector>>-timer : QTimer-quiz_started : Boolean

+on_start()+on_submit()+initialize_widgets()+set_option_selector_components(component)+update_option_selectors()

QuizMainWIndow

<<use>>

Figure 5. Simplified UML diagram of ad hoc implementation of case studyapplication

application than specific adaptation strategies and their user-perceived effectiveness. Once an appropriate structure is inplace, we expect these can be more easily devised, tested andimproved.

V. RESULTS

The windows shown on Fig. 4 are the resulted GUI for theapplication in all three polarization states. Because this casestudy’s focus is on GUI, the monitoring of past responses wassimulated and a random monitor is used instead which updatesits value by means of a polling dynamic monitor every second,allowing to easily observe adaptation.

A. Ad hoc ApplicationA simplified UML diagram of the ad hoc implementation

is shown on Fig. 5. The chosen approach is to add placeholderwidgets in QuizMainWindow which will be substituted byan appropriate component instance at runtime: CheckboxQt,ComboboxQt or RadioboxQt. A polarization level defined inthe enum Polarization is bound to each of these types. A timerwithin QuizMainWindow polls the polarization value and callsset_options_selector_components with the appro-priate type. Adaptation control, along with any customizationnecessary, is entirely done in QuizMainWindow.



Figure 6. Qt Designer using plain widgets as placeholder for ad hocimplementation

Fig. 6 shows Qt Designer as the main window is createdfor the ad hoc implementation. Notice that because placeholdercomponents are blank, no feedback is given to the designer.It is therefore not possible to test the controls or set thequestion label. This makes the approach incompatible withthe usual GUI design workflow, which involves previewingthe application in the graphical editor before adding businesslogic.

When analyzing the ad hoc code, it is obvious that separa-tion of concerns is not respected since the option selectionlogic is tangled to its owner element, the main window.Concerns such as scheduling for recomputing polarization andcomponent substitution are mixed with GUI setup and handlingof the business flow. This leads to a lack of extensibility, atangling of concerns and limits unit testing of components.A method is used to select which control component to usebased on the polarization, but this solution remains inflexible.The knowledge of adaptation is hidden and cannot be used todevise portable strategies.

One of our goals is to gradually add adaptation mechanismsto GUI implementations, but this is difficult since modificationof important classes will add risk of introducing defects. Also,there is no easy way to work on adaptation mechanismsseparately from the application. In fact, we cannot separatelytest the adaptation logic and integrate it after. Generally, thelack of cohesion induced by the inadequate separation ofconcerns is a sign of low code quality. Because no adaptationmechanism can easily be introduced, modified and reused inother projects, the ad hoc implementation works for its specificapplication case, but is subject to major efforts in refactoringwhen requirements and features will be added throughout itsdevelopment cycle.

B. Application Using AdaptivePyA simplified UML diagram of the application is shown

on Fig. 7. From it, we see that the polarization is a discreteparameter and is used by AdaptiveOptionsSelector, specificallyto define its adaptation space based on the ones providedby its substitution candidates: CheckboxQt, ComboboxQt andRadioboxQt. Additionally to adaptation by substitution, Ra-dioboxQt can parametrically adapt to changes of polarizationlevels {low, medium}, since they respectively correspond to 2and 4 options. Its behavior is that the appropriate number ofoptions is shown depending on the polarization level. Adap-tiveQuizMainWindow is free of adaptation implementation

+set_text(text)+text()+set_options(options)+options()+value()+set_selection()+state_transfer(source)

<<Interface>>OptionsSelector

+adaptation_space()ComboboxQt

+adaptation_space()CheckboxQt

+adaptation_space()RadioboxQt

+choose_route()+route(target)+candidates()

AdaptiveOptionsSelector

AdaptiveInternalProxyRouter

<<enumeration>>DiscreteParameterlow

mediumhigh

<<enumeration>>QuizOptionPolarization

PollingDynamicMonitorDecoratorQt

+route(target)OptionsSelectorQt

Adaptive

-questions : List<OptionsSelector>-quiz_started : Boolean

+on_start()+on_submit()

AdaptiveQuizMainWindow

DynamicMonitorDecoratorMonitorEventManager

<<bind>>

<<bind>>

<<use>>

Classes provided by AdaptivePy

Figure 7. Simplified UML diagram of case study application implementationusing AdaptivePy

details and simply uses the AdaptiveOptionsSelector instancesas a normal OptionsSelector. OptionsSelectorQt is a subclass toAdaptiveOptionsSelector which is used as a graphical proxyto candidate widgets. It also defines properties used in Qt’sgraphical editor Qt Designer, in this case the question label.

Every AdaptiveOptionsSelector instance is made a sub-scriber to the QuizOptionPolarization parameter at initializa-tion. They are updated when a change in the monitored valueis detected, i.e., when a monitor detects a value is differentfrom the previous one. This is because identical subsequentparameter values are expected by default to lead to the samestate, so they are filtered out. In the case of AdaptiveOp-tionsSelector, because it is a proxy router, choose_routeis called to determine which substitution candidate to routeto. Prior to using an adaptation strategy to select the mostappropriate candidate, inappropriate ones can be filtered outusing filter_by_adaptation_space. This function,provided by AdaptivePy, takes a list of candidates along witha snapshot of the current monitoring state and only returnsthose with adaptation space supporting the current context.Then, a strategy like choose_most_restricted is usedto choose among valid components. If no component is valid,an exception is raised. With a candidate chosen, all thatremains is configuring the proxy router by calling the routemethod with the chosen candidate. This method must also takecare of state transfer between the previous and new proxiedcomponents. This feature is already defined in the commoninterface OptionsSelector as state_transfer.

Fig. 8 shows Qt Designer as the main window is createdwith the AdaptivePy-based implementation. When comparedto Fig. 6, we notice that the designer has a full view of howthe application will look. Moreover, the currently displayedadaptation can be controlled through the setup of the monitors.For example, it is possible to replace the random value byone acquired from a configuration file and trigger adaptationmanually. Also, each question is simply a OptionsSelectorQtcomponent rather than a placeholder component and the ques-tion is entered directly from the graphical editor using the labelproperty (bottom-right). A major advantage is that adaptive



Figure 8. Qt Designer using adaptive components developed with AdaptivePy

components can be reused in other interfaces because theyare provided as standalone components. The need for easyedition of adaptation spaces is also addressed by modifyingor overriding the adaptation_space method of adaptivecomponents.

The adaptation logic is essentially located in the adaptiveproxy router class: AdaptiveOptionsSelector. Because adapta-tion is separated from the rest of the business logic, the mainwindow class can use the adaptive components without theknowledge of adaptation. The only logic remaining is withregard to buttons handling (Start and Submit buttons). It isclear in this implementation that the knowledge of adaptationspace which was hidden in the ad hoc implementation isused to efficiently choose a substitution candidate. Self-healingaction such as replacing a failing component can be easilyrealized by monitoring the components and including this logicas a strategy. This is not easily realizable in the ad hoc imple-mentation. In the prototype, a radio box could safely replacea checkbox since it parametrically covers its full adaptationspace, overlapping on {low} polarization. Also, from this casestudy, we can see that arbitrarily large hierarchies of adaptiveand non-adaptive components can be built without tanglingcode or affecting other components when adding new adaptivebehavior.

VI. CONCLUSION AND FUTURE WORK

Design patterns presented in this paper can be used asa basic structure to accomplish various levels of adapta-tion in GUI. Adaptive components can be used with othermodules such as recommendation engines to provide moreor less automation and proactive adaptation. Monitors canalso be extended and even implemented as adaptive compo-nents themselves, relying on other more primitive monitors.Proxy routers allow to simplify hierarchical development ofarbitrarily large sequences of component substitutions. Thepatterns form together an effective approach for the integrationof various adaptation mechanisms and, in the case of GUI,can be used to provide a more usual workflow than the adhoc implementation. AdaptivePy, as a reference library, is anexample of the viability of the patterns when used in a concreteimplementation. Even though a simple application was used

to observe gains, the solution is applicable to more complexscenarios where multiple parameters, monitoring groups andlarge hierarchies of adaptive components. The patterns aregeneral enough that they can be used for adding adaptivebehavior based on user, environment and platform variations.

Future work will focus on exploring parameters types withmore complex value domains and try to formalize a structureto express them. Also, the lack of adaptation quality metricsfor verification and validation methods limits the evaluation ofgains. To alleviate this limitation, new metrics using conceptsof the design patterns presented in this paper will be explored.The goal is to better quantify the quality level of prototypeswith regard to adaptation.

REFERENCES

[1] F. Chang and V. Karamcheti, “A framework for au-tomatic adaptation of tunable distributed applications,”Cluster Computing, vol. 4, no. 1, pp. 49–62, 2001, ISSN:1573-7543.

[2] E. Bruneton, T. Coupaye, M. Leclercq, V. Quéma, andJ.-B. Stefani, “The fractal component model and itssupport in java,” Software: Practice and Experience, vol.36, no. 11-12, pp. 1257–1284, 2006.

[3] Y. Maurel, A. Diaconescu, and P. Lalanda, “Ceylon:A service-oriented framework for building autonomicmanagers,” in 2010 Seventh IEEE International Confer-ence and Workshops on Engineering of Autonomic andAutonomous Systems, Mar. 2010, pp. 3–11.

[4] M. Peissner, A. Schuller, and D. Spath, “A designpatterns approach to adaptive user interfaces for userswith special needs,” in Proceedings of the 14th Inter-national Conference on Human-computer Interaction:Design and Development Approaches - Volume PartI, ser. HCII’11, Orlando, FL: Springer-Verlag, 2011,pp. 268–277.

[5] A. Corsaro, D. C. Schmidt, R. Klefstad, and C. O’Ryan,“Virtual component - a design pattern for memory-constrained embedded applications,” in In Proceedingsof the Ninth Conference on Pattern Language of Pro-grams (PLoP, 2002.

[6] G. Rossi, S. Gordillo, and F. Lyardet, “Design patternsfor context-aware adaptation,” in 2005 Symposium onApplications and the Internet Workshops (SAINT 2005Workshops), Jan. 2005, pp. 170–173.

[7] A. J. Ramirez, “Design patterns for developing dynami-cally adaptive systems,” Master’s thesis, Michigan StateUniversity, 2008.

[8] T. Holvoet, D. Weyns, and P. Valckenaers, “Patterns ofdelegate mas,” in 2009 Third IEEE International Con-ference on Self-Adaptive and Self-Organizing Systems,Sep. 2009, pp. 1–9.

[9] M. G. Hinchey and R. Sterritt, “Self-managing soft-ware,” Computer, vol. 39, no. 2, pp. 107–109, 2006.

[10] M. Salehie and L. Tahvildari, “Self-adaptive software:Landscape and research challenges,” ACM Transactionson Autonomous and Adaptive Systems (TAAS), vol. 4,no. 2, p. 14, 2009.

[11] M. L. Berkane, L. Seinturier, and M. Boufaida, “Us-ing variability modelling and design patterns for self-adaptive system engineering: Application to smart-home,” Int. J. Web Eng. Technol., vol. 10, no. 1, pp. 65–93, May 2015, ISSN: 1476-1289.



[12] IBM, “An architectural blueprint for autonomic com-puting,” IBM Corporation, Tech. Rep., 2005.

[13] S. Malek, N. Beckman, M. Mikic-Rakic, and N. Med-vidovic, “A framework for ensuring and improvingdependability in highly distributed systems,” in Archi-tecting Dependable Systems III, R. de Lemos, C. Gacek,and A. Romanovsky, Eds. Berlin, Heidelberg: SpringerBerlin Heidelberg, 2005, pp. 173–193.

[14] V. Mannava and T. Ramesh, “Multimodal pattern-oriented software architecture for self-optimization andself-configuration in autonomic computing system usingmulti objective evolutionary algorithms,” in Proceedingsof the International Conference on Advances in Com-puting, Communications and Informatics, ser. ICACCI’12, Chennai, India: ACM, 2012, pp. 1236–1243.

[15] A. J. Ramirez and B. H. Cheng, “Design patterns for de-veloping dynamically adaptive systems,” in Proceedingsof the 2010 ICSE Workshop on Software Engineeringfor Adaptive and Self-Managing Systems, ACM, 2010,pp. 49–58.

[16] W.-K. Chen, M. A. Hiltunen, and R. D. Schlichting,“Constructing adaptive software in distributed systems,”in Distributed Computing Systems, 2001. 21st Interna-tional Conference on., Apr. 2001, pp. 635–643.

[17] D. A. Menasce, J. P. Sousa, S. Malek, and H. Gomaa,“Qos architectural patterns for self-architecting soft-ware systems,” in Proceedings of the 7th InternationalConference on Autonomic Computing, ser. ICAC ’10,Washington, DC, USA: ACM, 2010, pp. 195–204.

[18] H. Liu and M. Parashar, “Accord: A programmingframework for autonomic applications,” IEEE Trans-actions on Systems, Man, and Cybernetics, Part C(Applications and Reviews), vol. 36, no. 3, pp. 341–352,May 2006, ISSN: 1094-6977.

[19] J. Zhang and B. H. C. Cheng, “Model-based develop-ment of dynamically adaptive software,” in Proceedingsof the 28th International Conference on Software Engi-neering, ser. ICSE ’06, Shanghai, China: ACM, 2006,pp. 371–380.

[20] H. Gomaa, K. Hashimoto, M. Kim, S. Malek, and D. A.Menascé, “Software adaptation patterns for service-oriented architectures,” in Proceedings of the 2010 ACMSymposium on Applied Computing, ser. SAC ’10, Sierre,Switzerland: ACM, 2010, pp. 462–469.

[21] P. Kang, M. Heffner, J. Mukherjee, N. Ramakrishnan, S.Varadarajan, C. Ribbens, and D. K. Tafti, “The adaptivecode kitchen: Flexible tools for dynamic applicationcomposition,” in 2007 IEEE International Parallel andDistributed Processing Symposium, Mar. 2007, pp. 1–8.

[22] E. Gamma, R. Helm, R. Johnson, and J. Vlissides,Design Patterns: Elements of Reusable Object-orientedSoftware. Boston, MA, USA: Addison-Wesley LongmanPublishing Co., Inc., 1995.

[23] H. Gomaa and M. Hussein, “Software reconfigurationpatterns for dynamic evolution of software architec-tures,” in Software Architecture, 2004. WICSA 2004.Proceedings. Fourth Working IEEE/IFIP Conference on,Jun. 2004, pp. 79–88.

[24] M. Bezold and W. Minker, Adaptive multimodal interac-tive systems. Springer Science & Business Media, 2011.



CHAPITRE 5

Développement de métriques d’évaluation dela qualité dans les logiciels adaptatifs

Dans le premier article, il a été question de patrons de conception pour l’ajout de compor-tement adaptatif dans les interfaces usagers graphiques. Cependant, il a été relevé qu’unmanque existait pour qualifier l’implémentation effectuée avec les patrons de conceptionde « supérieure ». Bien qu’une implémentation avec les patrons semble qualitativementmeilleure, il n’est pas clair par rapport à quelles mesures quantitatives cette dernière per-met d’atteindre une qualité supérieure et surtout d’assurer que ce qui a été développésupporte bien les cas requis.

Ainsi, le sujet de la deuxième partie du présent projet de recherche est la proposition demétriques pour évaluer une implémentation adaptative. Il a été proposé de développer desmétriques pour mesurer la qualité de la structure induite par l’application des patrons deconception. Ce deuxième article, reproduit au chapitre 6, a comme but de présenter dela façon la plus complète possible les nouvelles métriques proposées. Le présent chapitrevise plutôt à présenter un portrait plus large de la V&V liée à la structure induite par lespatrons de conception. D’abord, un ensemble de métriques potentielles est présenté. Puis,des détails additionnels concernant le développement de la métrique choisie sont présentésen vue de compléter la description faite dans le deuxième article.

5.1 Recherche des métriques

La structure de base que procure l’application des patrons de conception présentés à lasection 4.3 permet l’atteinte de certaines qualités du logiciel comme la séparation despréoccupations, l’extensibilité et la réutilisation. Cependant, l’implémentation faite parles développeurs peut varier d’une application à une autre et certains éléments peuventinduire une mauvaise qualité à l’égard de certaines préoccupations.

Un premier travail a été d’identifier les métriques de logiciels traditionnels et vérifier sides analogies peuvent être faites dans le contexte de logiciel adaptatif. Les conclusionsde ce travail sont présentées à la section 5.1.1. Par la suite, la structure elle-même a étéanalysée pour déceler les limitations de l’implémentation qui ne sont pas évidentes pour

55

56CHAPITRE 5. DÉVELOPPEMENT DE MÉTRIQUES D’ÉVALUATION DE LA

QUALITÉ DANS LES LOGICIELS ADAPTATIFS

les développeurs. Trois métriques ont été identifiées. La première est la profondeur del’arbre de substitution qui est présentée à la section 5.1.2, la deuxième est la stabilité del’adaptation qui est présentée à la section 5.1.3 et finalement la couverture de l’espaced’adaptation qui est présentée à la section 5.1.4. Cette dernière métrique est celle qui aété retenue et qui constitue le sujet du deuxième article.

5.1.1 Métriques de la littérature

L’enquête sur l’évaluation de la qualité dans les systèmes adaptatifs de Raibulet et al. [38]est la plus récente qui tente de réunir les métriques connues à ce jour. La constatation prin-cipale qui émerge de l’analyse des métriques réunies dans cette enquête est la subjectivitéqui est nécessaire pour le calcul des métriques. Par exemple, plusieurs métriques visent àqualifier le niveau d’adaptation d’un système en vue de le comparer à d’autres. Il est alorsinféré qu’une présence forte de l’adaptation implique une meilleure qualité puisque cettedernière permet d’atteindre des buts d’adaptation comme la tolérance aux fautes ou lareconnaissance de comportement problématique. Cependant, une qualification subjectivedes composants du logiciel est souvent utilisée. Ainsi, un développeur doit juger si uncomposant est considéré « adaptatif » et de la granularité des composants au niveau dusystème.

Dans d’autres cas, il est cependant question d’un nombre de reconfigurations ou de tempspassé à effectuer des opérations d’adaptation qui peuvent être déterminées de façon ob-jective. Une approche hybride qui modélise une certaine subjectivité sous forme objectiveest le calcul du bénéfice ou du coût d’une adaptation : il est alors nécessaire de mesurerles éléments de performance ou de qualité qui peuvent indiquer si le plan d’adaptationmis en place a eu un impact positif ou négatif sur le système. Comme il est nécessairede spécifier ces éléments manuellement et que la relation d’importance entre ces dernierspeut être spécifique à une application et à son domaine, la métrique n’est cependant pasentièrement objective.

Le plus grand constat de la situation actuelle est l’absence de métriques permettant devérifier si la structure est, indépendamment des mécanismes d’adaptation utilisés, de bonnequalité. Plutôt, les travaux existants focalisent sur la quantification de l’atteinte de butsd’adaptation et de la performance d’un système, peu importe la structure mise en placesupportant l’adaptation. Cela permet de comparer deux systèmes, mais pas les mécanismesde façon indépendants. Il est donc adéquat de proposer de nouvelles métriques pour essayerde mieux découpler ces éléments et surtout d’effectuer l’assurance qualité de la structure

5.1. RECHERCHE DES MÉTRIQUES 57

permettant l’adaptation. Pour une analyse plus en profondeur des travaux analysés dansl’enquête de Raibulet et al. [38], voir la section 6.2.2.

5.1.2 Profondeur de l’arbre de substitution

Une métrique connue des logiciels traditionnels est la profondeur de l’arbre d’héritage(depth of inheritance tree). Cette métrique mesure le chemin d’héritage le plus long dansun système donné. Plus le chemin est long, plus la complexité de l’arbre d’héritage estgrande, mais plus le potentiel de réutilisation est élevé, et inversement pour un chemincourt. Une métrique similaire peut être identifiée pour les composants adaptatifs. Eneffet, ces derniers ayant des candidats de substitution, il est possible de mesurer unedistance entre un composant adaptatif qui constitue la racine d’un arbre et le candidat desubstitution le plus loin y étant reliée.

Par exemple, pour la situation simple où un composant adaptatif a M candidats de sub-stitution, la distance est 1 puisqu’il n’existe qu’un niveau de substitution. Cependant, sil’un d’entre eux a à son tour N candidats de substitution, on calcule que la distance est 2,car il existe un niveau additionnel. Un exemple d’arbre est présenté à la figure 5.1. Dansce cas, la profondeur est 2 pour le composant L0. Si on calcule la profondeur de L00, ils’agirait alors de 1 puisqu’un seul niveau de substitution existe sous ce composant. CommeL01 et L02 n’ont aucun candidat de substitution, la profondeur pour ces composants est 0.

Les implications d’une telle métrique sont plus que de contrôler le niveau de complexité.En effet, plus de niveaux de substitution impliquent un plus grand nombre de stratégies àutiliser pour effectuer les adaptations en cascade. Ainsi, tout dépendant de la complexitéde performance des stratégies, il est possible qu’un nombre de niveaux trop élevé de substi-tution induise un délai trop grand pour être viable. Ainsi, cette métrique pourrait s’avérerutile pour mesurer à quel point une hiérarchie de composants est complexe. Aussi, ellepourrait permettre de déterminer une cause de basse performance dans une applicationdonnée et avec les stratégies utilisées.

5.1.3 Stabilité de l’adaptation

Les composants adaptatifs peuvent réagir à des changements dans les données d’adap-tation. Ces changements sont détectés par des moniteurs qui émettent une notification.Cette dernière est distribuée aux composants intéressés par un gestionnaire d’évènements.Cependant, des données d’adaptation peuvent être issues des composants eux-mêmes dulogiciel, et donc lorsqu’un composant s’adapte, il est possible que les changements in-



L0

L00

L01

L02

L000

L001

Top level(0)

Second level(1)

Bottom (third) level(2)

Figure 5.1 Arbre de substitution de composants adaptatifs

M1

C1

M2

C2

<< uses >><< monitors >>

<< uses >> << monitors >>

a bM1

C1

M2

C2

<< uses >><< monitors >>

<< uses >> << uses >>

Figure 5.2 Exemples des relations de dépendances entre moniteurs et compo-sants a) Boucle de dépendances b) Dépendances sans boucle


duisent un changement dans une autre donnée d’adaptation. Dans un cas idéal, cettechaîne d’évènements se stabilise éventuellement et le système ne s’adapte pas continuel-lement en réaction à une adaptation précédente. Dans un cas problématique, un cycle deréaction d’adaptation existe et le système ne se stabilise jamais. Ainsi, il est nécessairede prévoir une façon de mesurer la stabilité d’adaptation d’un système en fonction de lafaçon dont les adaptations peuvent impacter les données d’adaptation.

Une façon de pallier ce problème est de détecter les boucles dans un graphe directionneloù les noeuds sont les composants et leurs moniteurs et où les liens sont les relations dedépendances. Un moniteur dépend d’un composant s’il utilise l’état du composant pourproduire une valeur. Un composant dépend d’un moniteur s’il est abonné au paramètreauquel le moniteur est rattaché. Le nombre de boucles indique donc à quel point le systèmepeut être instable. En principe, il serait préférable d’anéantir toute boucle du système(valeur idéale = 0) afin que l’adaptation ne puisse jamais être instable. Cependant, enpratique, certaines boucles ne peuvent être retirées et il s’agit alors d’assurer la stabilitépar d’autres moyens.

La figure 5.2 montre deux exemples de graphes de dépendances entre les composants etles moniteurs. En a), on voit qu’une boucle existe pour {M1, C1,M2, C2}. Cependant, enb), cette boucle n’est pas présente, même si un lien de dépendance existe entre chacun deséléments. En effet, un changement à C1 pourrait avoir un impact sur la valeur fournie parM1, puis sur C2 puisque ce dernier l’utilise. Cependant, la chaîne ne continuerait pas plusloin, car aucun élément ne dépend de l’état de C2.

5.1.4 Couverture de l’espace d’adaptation

Un composant adaptatif a comme requis d’exposer le domaine qu’il supporte pour chacundes paramètres qu’il connait. Si chaque domaine est modélisé comme une dimension d’unespace d’états, on peut donc identifier une zone dans cet espace que le composant supporteet qui est appelé espace d’adaptation. L’espace contextuel, soit l’espace d’états dans lequelle système peut être au niveau contextuel, est l’ensemble des états définis pour chacunedes dimensions. Ces dimensions sont définies soit à la conception par les paramètres, soit àl’exécution par les moniteurs. La proportion de l’espace contextuel connu d’un composantque couvre son espace d’adaptation est un indicateur de l’étendue de son support pour lavariabilité du système. Une couverture C < 1.0 implique donc qu’une proportion 1.0− C

d’états induit un comportement indéfini lorsque le composant en question est utilisé.



Les candidats de substitution d’un composant adaptatif ayant chacun leur espace d’adap-tation, on peut déduire que l’espace d’adaptation du composant adaptatif est par défautl’union de tous les états supportés par l’un ou l’autre des candidats. Ainsi, il est possibled’obtenir une couverture C = 1.0 si les espaces d’adaptation de chacun des candidats desubstitution se complémentent. En d’autres mots, si l’union des espaces d’adaptations estégale à l’espace contextuel du système, la couverture sera totale (C = 1.0).

5.1.5 Résumé

L’objectif de chacune des métriques potentielles qui ont été proposées dans les sectionsprécédentes était de quantifier un niveau de qualité par rapport à une propriété du logicielinduite par la structure en place. Ces métriques sont résumées ici :

- La profondeur de l’arbre de substitution permet de quantifier la complexité del’architecture de composition des composants adaptatifs. Utilisé conjointement à uneanalyse de complexité algorithmique des stratégies d’adaptation, il serait possible dequantifier la performance de la mise en place d’une adaptation. Ce genre d’ana-lyse demanderait d’exprimer sous forme de notation asymptotique la complexité destratégies et de les joindre suivant les liens de composition.

- La stabilité de l’adaptation permet d’indiquer si des cycles existent au niveau desdépendances entre les composants et les moniteurs. Un cycle induit une suite d’adap-tations possiblement sans fin, ce qui est indésirable et est qualifié « d’instable ». Unetelle situation pourrait entrainer un gel complet d’environnement d’exécution. Aussi,une accumulation de la mémoire due à une suite d’appels récursifs pour la mise enplace de l’adaptation pourrait remplir complètement la mémoire de la machine.

- La couverture de l’espace d’adaptation d’un composant est un indicateur dela proportion d’états supportés par un composant adaptatif. Ce dernier peut avoirdes candidats de substitution et la couverture peut être calculée pour n’importequel composant d’une hiérarchie de composition. Une couverture inférieure à 100%indique que certains états que le système peut atteindre ne sont pas couverts parle composant analysé. L’atteinte de tels états entraine un comportement indéfini.Ainsi, une application pourrait terminer son exécution avec une erreur ou produirede mauvais résultats de façon silencieuse (si l’état non couvert n’est pas détecté).


5.1.6 Commentaires

Dans les sections précédentes, les propriétés de diverses métriques ont été présentées. Plusparticulièrement, dans la section 5.1.1, il a été noté que les métriques de la littératureactuelle sont souvent basées sur un jugement subjectif de caractéristiques des composantsd’un logiciel et souvent utilisées pour comparer des systèmes en termes de niveau d’adapta-tivité. Dans les sections suivantes, des métriques dont les calculs sont basés sur la structureinduite par les patrons de conception du présent projet de recherche sont proposées commedes solutions pouvant aider à quantifier la qualité de façon pleinement objective. Tel querésumé à la section 5.1.5, les métriques proposées approchent des aspects différents de laqualité, mais conservent le but de rester dans un domaine objectif.

Dans les trois métriques proposées, il a été décidé de dédier un article complet à unemétrique afin de permettre une description la plus complète possible. Le choix s’est arrêtésur la métrique couverture de l’espace d’adaptation, car elle est une métrique difficile àcalculer manuellement et constitue un indicateur de problèmes critiques. Un problèmecritique a comme conséquence l’arrêt du système ou la violation de ses spécifications. Ledéfi entourant son calcul est au niveau de la spécification des espaces d’états : la couverturedoit pouvoir être calculée depuis une fonction générique qui supporte plusieurs types dedomaines (énuméré et discret). L’explosion combinatoire qui existe lorsqu’un contexte estmodélisé par la combinaison des états possibles des différents paramètres doit être abordéeet possiblement résolue par l’utilisation d’une interface commune pour ces domaines.

En ordre, il serait nécessaire, dans le futur, de se pencher sur la métrique de stabilité del’adaptation puisque l’existence d’instabilité peut également induire l’arrêt du système. Ce-pendant, l’effort d’implémentation apparaît inférieur, car il ne nécessite pas de nouveauxdéveloppements au niveau des artéfacts présents dans les patrons de conception (en oppo-sition aux nouveaux types d’espaces d’états implémentés pour la métrique de couverturede l’espace d’adaptation). Ensuite, la profondeur de l’arbre de substitution est une mesurede complexité et de performance. Son impact est un peu plus superficiel puisqu’il se trouveau niveau de la qualité à l’utilisation du logiciel, soit la qualité perçue par l’utilisateur.Néanmoins, une trop grande complexité peut induire un arrêt apparent du système. Dansce cas, le système pourrait ne plus répondre pendant un long moment du point de vue del’utilisateur.



5.2 Abstraction des espaces d’états

Dans le premier article, les espaces d’états utilisés pour définir les espaces d’adaptation descomposants et le domaine de valeurs possibles pour les paramètres et moniteurs étaientbasés sur des ensembles (sets). Cette structure de données définit un ensemble de valeursnon ordonné. Cependant, cette structure n’est pas pratique pour la définition de largesdomaines de valeurs, par exemple les valeurs entières entre 1 et 10000. En effet, il se-rait nécessaire de mettre en mémoire toutes les valeurs alors qu’elles suivent une règleet pourraient être générées (ex. : valeurs de 1 à 10000 avec un intervalle de 1). De plus,les opérations sur des ensembles comportant un nombre élevé d’éléments sont peu perfor-mantes.

Pour mieux travailler avec les espaces d’états, une abstraction a été créée. Les implémen-tations de différents types d’espaces d’états permettent la déclaration d’espaces énumérés(basé sur les ensembles, tout comme pour le premier article) et d’espaces discrets. Cettedernière implémentation permet de spécifier un nombre de début et de fin ainsi qu’un écartet d’obtenir un domaine de valeurs comme l’exemple précédent. Les opérations effectuéessur cette structure de données comme l’union et l’intersection ne nécessitent pas d’itérer àtravers toutes les valeurs possibles comme pour les ensembles, et la mémoire est limitée àtrois nombres. Un gain en performance est donc attendu pour de grands ensembles, maisle principal avantage est surtout que l’abstraction des espaces d’état offre une interface gé-nérique pour leur manipulation dans la librairie AdaptivePy. Les parties de la librairie quitenaient pour acquise l’utilisation d’ensemble ont été révisées pour utiliser les opérationsgénériques.

Le développement d’une abstraction pour les espaces d’états est également dû au faitque les calculs au niveau de la métrique de couverture des espaces d’adaptation doiventpouvoir être faits pour tout type d’espaces d’états. Ainsi, en utilisant des opérations abs-traites fournies définies dans l’interface de l’espace d’états, une seule méthode de calcul estnécessaire pour tout composant adaptatif. L’implémentation du calcul, dérivée des équa-tions présentées au tableau 6.2, peut donc prendre en argument n’importe quel composantadaptatif défini par AdaptivePy. En plus, pour des implémentations d’espace d’états sup-plémentaires, aucune modification à l’implémentation des métriques n’est requise, tant etaussi longtemps qu’elles supportent les opérations de l’interface commune.

5.3. DÉTAILS D’IMPLÉMENTATION DE LA COUVERTURE DE L’ESPACED’ADAPTATION 63

5.3 Détails d’implémentation de la couverture de l’es-

pace d’adaptation

Comme le deuxième article couvre uniquement la définition formalisée et l’utilisation desmétriques de couverture de l’espace d’adaptation, la présente section vise à présenter desinformations additionnelles concernant leur implémentation. Pour des détails plus précissur les calculs eux-mêmes, se référer à la section 6.3.

5.3.1 Implémentation de la couverture récurrente

Dans l’article, l’implémentation de référence de la couverture récurrente (voir tableau 6.1,ligne « RSC ») n’est pas discutée en profondeur. L’implémentation actuelle est considéréecomme non optimale, ainsi il est opportun de présenter la solution actuelle et les pistespour proposer une approche plus performante.

La stratégie actuellement utilisée pour effectuer le calcul est d’itérer dans tous les étatsdéfinis au moins une fois. Pour ce faire, un espace d’états est généré comme étant l’uniondes espaces d’adaptation des candidats de substitution. La fonction itère dans les états dece dernier et, pour chaque état, vérifie le nombre de composants qui le définissent. Si lenombre de composants le définissant est supérieur à 1, le nombre de définitions récurrentes(le nombre total de définitions, moins un) est ajouté à un compteur. Une fois tous les étatsvisités, la couverture récurrente est obtenue en effectuant le ratio entre le compteur et lenombre d’états possibles.

On suppose que cette approche n’est pas optimale puisqu’il est nécessaire d’effectuer lavisite par force brute de tous les états définis. Comme une implémentation abstraite desespaces d’états a été faite, il est attendu que des opérations sur ces structures de don-nées puissent fournir une réponse sans nécessiter de visiter chaque état explicitement. Parexemple, une solution pour deux composants serait d’abord d’effectuer l’intersection deleur espace d’états respectif. Ensuite, il suffirait d’effectuer le produit des ratios correspon-dants au nombre d’états résultant de l’intersection par rapport au nombre d’états possiblesde chacun des paramètres définis. Cependant, les calculs pour un nombre n de composantsne sont pas aussi simples. Comme la performance du calcul de la métrique n’a pas été pro-blématique et que le projet de recherche actuel n’avait pas comme but l’optimisation ducalcul des métriques, l’exploration d’une méthode de calcul plus efficace a été réalisée,mais n’a pas donné les résultats escomptés. Il advient donc de travaux futurs à optimiser



le calcul de la couverture récurrente qui est le goulot d’étranglement de l’implémentationactuelle.

5.3.2 Pseudo-code de l’implémentation

Un pseudo-code permet de démontrer la façon dont un algorithme est implémenté sansêtre lié à un langage en particulier. Le pseudo-code de l’implémentation des métriques estdonné à l’algorithme 1. L’algorithme 2 présente l’obtention d’un espace d’adaptation avecdes moniteurs à la place des paramètres. L’algorithme 3 présente le calcul de la couvertured’un espace d’adaptation.

Il est à noter que lorsque l’algorithme 1 est utilisé pour effectuer un calcul de couvertureeffective (le drapeau effective est à True), le même algorithme de calcul (algorithme 3)est utilisé. Cependant, les paramètres, qui constituent les clés dans adaptationSpace, sontéchangés dans l’algorithme 2 pour les moniteurs correspondants, de sorte que le calcul decouverture reste le même. Dans l’algorithme 3, la ligne 4 est générique et fonctionne dansles deux cas, dans la mesure où la classe moniteur est dérivée de la classe paramètre1.

1Alternativement, pour un langage supportant le duck typing comme Python, la méthodepossible_values définie par les artéfacts Parameter et Monitor du patron Moniteur (voir figure 4.1) nenécessite pas de relation d’héritage explicite. Le duck typing permet d’utiliser deux classes partageant desdéfinitions de méthodes de la même façon sans nécessiter un lien d’héritage. Dans le cas présent, commela seule méthode utilisée est possible_values et que les deux classes définissent une méthode de ce nom,les deux classes peuvent être utilisées dans le contexte du calcul de la métrique.

5.3. DÉTAILS D’IMPLÉMENTATION DE LA COUVERTURE DE L’ESPACED’ADAPTATION 65

Algorithme 1 Couverture modélisée et effective de l’espace d’adaptation1: function CompositeASCoverage(component, effective, asPrimitive)2: coverage ← 0.03: if not asPrimitive and component has substitution candidates then4: if effective then5: candidates ← instances of candidates of component6: else7: candidates ← classes of candidates of component

8: recurrentCoverage ← recurrent coverage of candidates9: sumCoverage ← 0.0

10: for all candidate in candidates do11: sumCoverage ← sumCoverage+ ASCoverage(candidate, effective, True)12: coverage ← sumCoverage− recurrentCoverage13: else if component has adaptation space then14: space ← adaptation space of component15: if effective then16: space ← monitor space corresponding to parameters in space � See algo 217: coverage ← adaptation space coverage of space � See algo 3

return coverage

Algorithme 2 Espace d’adaptation avec moniteurs1: function GetMonitorSpace(adaptationSpace, parameterValueProvider)2: monitorSpace ← map of (monitor, state space)3: for all parameter, monitor provided by parameterV alueProvider do4: space ← adaptationSpace[parameter]5: if adaptationSpace has parameter as key then6: monitorSpace[monitor] ← adaptationSpace[parameter]

return monitorSpace

Algorithme 3 Calcul de la couverture d’espace d’adaptation pour un composant primitif1: function PrimitiveASCoverage(adaptationSpace)2: coverage ← 1.03: for all parameter, space do4: possibleV alues ← parameter’s possible values5: definedStates ← intersection between possibleV alues and space6: numerator ← size of definedStates7: denominator ← size of possibleV alues8: coverage ← coverage ∗ (numerator/denominator)

return coverage



5.4 Conclusion

Dans ce chapitre, différentes métriques potentielles ont été présentées qui avaient pourbut de participer à la V&V d’un logiciel dont les éléments adaptatifs ont été implémentésavec les patrons présentés à la section 4.3. La réalisation que la structure mise en placepar l’utilisation des patrons de conception ne garantit pas une implémentation sans failleindique que le développement de nouvelles méthodes de V&V est nécessaire.

La métrique choisie pour le présent projet de recherche est la couverture de l’espace d’adap-tation. Cette métrique apporte une aide importante pour minimiser les situations de com-portements indéfinis. Comme les patrons de conception se concentrent uniquement sur lastructure pour l’adaptation, l’utilisation d’une telle métrique offre une façon d’augmenterla confiance des développeurs en la réalisation d’une application qui utilise cette struc-ture. Comme le chapitre 6 focalise sur la formalisation et l’utilisation concrète des deuxversions de la métrique, plusieurs détails d’implémentation sont omis. Dans le présent cha-pitre, le pseudo-code de la fonction implémentant la métrique est donné à la section 5.3ainsi que des détails sur les stratégies de calculs utilisés. Une critique de l’implémentationest également présentée, particulièrement au niveau de l’implémentation de la couverturerécurrente qui est fonctionnelle, mais considérée non optimale.

CHAPITRE 6

Article 2 : Metrics for adaptation space cove-rage evaluation in adaptive software

Avant-propos

Auteurs et affiliation :

S. Longchamps : étudiant à la maîtrise, Université de Sherbrooke, Faculté de génie,Département de génie électrique et de génie informatique.

R. Gonzalez-Rubio : professeur, Université de Sherbrooke, Faculté de génie, Dépar-tement de génie électrique et de génie informatique.

Date de soumission : 13 mars 2017

Revue : Proceedings of the Tenth International C* Conference on Computer Science &Software Engineering

Titre français : Métriques pour l’évaluation de la couverture de l’espace d’adaptationdans les logiciels adaptatifs

Contribution au document : Les métriques présentées sont issues de l’une des mé-triques proposées à l’étape de recherche (voir section 5.1). Elles sont des spécialisationsde la métrique de couverture de l’espace d’adaptation présentée à la section 5.1.4. Lesmétriques présentées servent à vérifier que l’application utilisant la structure induite parl’utilisation des patrons de conception supporte bien les situations atteignables par lesystème. Une présentation formalisée et leur utilisation dans une situation concrète per-mettent une excellente compréhension de la métrique et supportent les sous-objectifs del’objectif secondaire présentés à la section 1.3.

Résumé français : Les logiciels adaptatifs sont typiquement complexes et l’assurancequalité interne est difficile à effectuer. Les métriques constituent des outils pour évaluerla qualité logicielle de façon quantitative et pour aider les développeurs dans l’identifica-tion de régions qui nécessitent des améliorations par rapport à diverses préoccupations.Une préoccupation spécifique aux logiciels adaptatifs est le support par les composantsdu nombre élevé d’états contextuels qu’un système peut atteindre. Lorsque modélisé sous

67

68CHAPITRE 6. ARTICLE 2 : METRICS FOR ADAPTATION SPACE COVERAGE

EVALUATION IN ADAPTIVE SOFTWARE

forme d’espace d’états, cet ensemble d’états contextuels est appelé un espace contextuel.Des composants adaptatifs démontrent leur support pour une région de l’espace contextueld’une application par le biais d’un espace d’adaptation. Le présent article propose deuxmétriques afin d’aider à cette tâche : la couverture modélisée de l’espace d’adaptation et lacouverture effective de l’espace d’adaptation. Ces métriques sont utilisées, respectivement,à la conception et à l’exécution. Elles offrent une valeur entre 0.0 et 1.0, indiquant la pro-portion des états supportés par rapport à ceux atteignables par le système. Les métriquessont présentées dans un format inspiré de l’ISO/IEC 25023. Elles sont utilisées pour ana-lyser une application typique dans le cadre d’une étude de cas et une interprétation desrésultats est offerte. Trois types d’actions correctives sont présentées et leur impact surla valeur des métriques est expliqué. Une implémentation du calcul des métriques fut dé-veloppée dans le langage Python et rendue disponible librement. Dans cet article, nousmontrons comment les métriques peuvent être utilisées pour identifier les problèmes etmettre en place des actions pour les corriger afin d’obtenir une implémentation de l’adap-tation de qualité. L’étude de cas et les actions correctives présentées mettent en lumièreles gains offerts par l’utilisation des métriques. Sans les métriques, les problèmes présentéspeuvent être négligés et amener à des comportements indéfinis dans le logiciel adaptatif.

6.1. INTRODUCTION 69

6.1 Introduction

Adaptive software is typically complex and internal quality assurance is difficult to achieve.While diverse work exists on qualitative and quantitative means of analyzing the quality ofadaptive software [38], the structural aspect of software implementation is rarely discussed.Many researchers have proposed metrics to compare adaptive systems and to provide hintsto developers regarding which implementation is “better” than the other with regards tovarious concerns. Another proposed solution is the evaluation of the degree of adaptabilityof an application such that quantitative requirements can be expressed and checked [37].The current work takes a different direction by assisting developers in the evaluation ofstructural support of contexts an adaptive application can encounter.

Adaptive software is different from traditional software in that their architecture can bedynamic and large arrays of contexts lead to large arrays of possible behaviors. To supportall of these contexts, developers can create components and modules which take intoaccount the variability provided by the contextual information. For example, a system canbe required to exhibit a different behavior depending on the time of the day. A developercan design a component which will behave in some way, valid for 9AM to 5PM, and anotherwhich will behave in another way, valid from 6PM to 9AM. From this situation, we caninstinctively see that the hour between 5PM and 6PM is not supported by any component.The identification of more complex contexts with many more variables and/or componentswould lead to even more complex unsupported cases. There is a need to help developersverify that their design supports the ranges of contexts the system can encounter.

Our proposal is to devise metrics to express the proportion of contexts covered by an adap-tive component. Because components can be composed into more complex components,components at any level of a components hierarchy can be analyzed. The idea is to assistdevelopers in verifying that components have adequate coverage of contexts such that anapplication will not exhibit undefined behavior for contexts part of its specifications. Weexpect this assistance to be especially useful for complex adaptive components architec-tures where the number of contexts is beyond computational capacity. It must be stressedthat the metrics we proposed do not aim at verifying that adaptation mechanisms andadaptive behavior of an application fulfill adaptation requirements. In fact, we assumethat these concerns are verified separately by specialized means, such as dedicated tests.Using this assumption, we aim to verify instead if components are assembled in a hierarchywhich supports specified contexts. We also use specifications introduced in our previouswork [27] on the way adaptive components are expected to be composed to efficientlycompute the metrics.



The remainder of this paper is organized as follows. Related work is presented in Section6.2. The proposed metrics are presented in Section 6.3. A case study with a sample programis presented in Section 6.4. Results and analysis of the sample program with some actionsto help developers are presented in Section 6.5. The usage and limitations of the metricsare discussed in Section 6.6. Finally, a conclusion with future work is presented in Section6.7.

6.2 Related work

This section presents related work, starting with previous research efforts. Then, otherwork related to adaptive software verification is presented and compared to the currentwork.

6.2.1 Previous research work

Previous work [27] focused on identifying and unifying common solutions to express anduse adaptation contexts in a scalable manner. For example, we used state spaces to expressdomains of contexts (a “context space”) adaptive software can encounter. In a contextspace, each contextual variable is a dimension and each contextual variable define a set ofpossible values. A context is a combination of one value per dimension which representsthe contextual state of the system. For example, for contextual variables A and B withpossible values A = {1, 2} and B = {2, 3}, the context space would be {(1, 2), (1, 3),(2, 2), (2, 3)}. The idea was to use state spaces to express information about contexts fordifferent concerns of adaptive software. To do so, some artifacts which use state spaceswere proposed :

- Parameter : Represents a contextual variable as modeled at design time. Its statespace is used to define all the possible values of a contextual variable.

- Monitor : Represents a means of obtaining values for a parameter. It provides asubset of values defined by a parameter. This subset is also defined as a state space.

- Adaptive component : Represents a component which exhibits adaptation. Itadapts itself to context variations detected when monitors provide different valuesfor parameters it is aware of. These parameters and the domain of values the com-ponent supports are defined in a state space called “adaptation space”. An adaptivecomponent can be composite, that is, it can be substituted by other adaptive compo-nents with each their own adaptation space. The adaptation space of the composite

6.2. RELATED WORK 71

adaptive component is then the union of the substitution candidates’ adaptationspaces.

These artifacts were formalized in design patterns and implemented in a reference library,AdaptivePy1. While a case was made to show how their use increases quality in adaptivesoftware, previous work lacked metrics to quantitatively analyze their use in concretesituations. Moreover, composite adaptive components could lead to large hierarchies ofadaptive components supporting a subset of the context space which could not be easilyanalyzed. For the current work, we identified the need to verify that adaptive components,composite or not, support a specified proportion of contexts.

Our proposal is that this verification can be realized with the help of metrics like theadaptation space coverage of each adaptive component. Concretely, the idea is to verifythat components of an application support the necessary contextual states that can bereached. By composing adaptive components with different adaptation spaces, a greatercoverage of reachable states is attained. This allows to concentrate quality assurance effortson small ranges of specific contexts defined in specialized components. The alternativewould be to test each component in all possible contexts using every parameter, leadingto combinatorial explosion.

6.2.2 Verification and validation metrics

Developing quality software is a challenge which relies on the ability to evaluate quality andto devise ways to improve solutions to attain higher quality. Verification and validation(V&V) techniques are used to assess the quality of software applications. One type ofV&V technique is the use of metrics, which are quantitative indicators of the quality of asoftware component with regards to a concern.

When it comes to adaptive software, additional metrics are needed. Raibulet et al. [38] haveinvestigated the evaluation of “self-adaptive systems”. The analyzed approaches served asinspirations for the current work, but we consider our focus is different in that it aimsto provide verification of the support for a system’s context space by its components.Existing literature focuses either on the comparison between adaptive systems [32, 35] oron evaluation of mechanisms [46] to attain adaptation goals. What we want to verify isindependent of specific adaptation mechanisms. Also, instead of evaluating the degree atwhich a system is adaptable or adaptive, we wish to quantify the degree of support for asystem’s context space components offer.

1https://gitlab.com/memophysic/adaptive_py_lib



Kaddoum et al. [22] proposed metrics for the evaluation of adaptive systems with themotive to be able to better compare applications in terms of adaptiveness. Metrics aredivided in three categories : “methodological”, “intrinsic” and “runtime evaluation” criteria.The first two criteria are closest to our goal, but they are limited to the evaluation at acomponent level (count number of components) and therefore do not quantify adaptationwithin components. The biggest downside is that they rely heavily on qualitative inspectionof components to judge if they are considered adaptive. Nevertheless, interesting metricsare proposed and seem compatible with the conceptual framework defined in our previouswork.

Perez-Palacin et al. [37], like Kaddoum et al. [22], proposed metrics for the evaluationof adaptive systems, but with the focus on the relationship with quality of service. Theadaptability of a system is presented as the ability to reconfigure connections betweencomponents of compatible provider/consumer service. The granularity level is at the ser-vice level and the goal is to quantify how adaptable are specific services or on average inthe system. Our previous work proposed that components offering the same service canbe “substitution candidates” for a composite adaptive component. Perez-Palacin et al. [37]propose the “absolute adaptability of a service” as the number of substitution candidatesfor a service. This design-time metric is used to express the degree of adaptability of aservice. At runtime, they propose the “relative adaptability of a service” as the ratio of sub-stitution candidates concretely used over the number of existing substitution candidates.The differentiation between design-time and runtime leads us to propose a version of theadaptation coverage metric for each phase. The main downside of the work presented isthe granularity level since the ability for the substitution candidates to provide the serviceis assumed, regardless of the contextual state the system is in.

Another interesting research not mentioned in [38] is the work of Tamura et al. [44] withregards to runtime verification of self-adaptive systems. Their goal was to look at thechallenges of providing certifiable V&V techniques aimed specifically at adaptive systems.An important concept in their work is the identification and modeling of a “viabilityzone” during the lifecycle of an application, but particularly at runtime. They define aviability zone “as the set of possible system states in which the system operation is notcompromised” [44]. They show how variations in this variability zone at runtime needsto be monitored and corrective actions taken to ensure the system stays within it. In ourconceptual framework, a component’s adaptation space represents the viability zone withinthe application’s context space. So far, our work has looked solely at fixed adaptationspaces, but our conceptual framework does not forbid them to change at runtime. The

6.3. METRICS 73

most interesting link we can do with our work is that the runtime version of our metricscould be used at runtime to detect if the viability zone of a component is incompatiblewith the context space of the system. While many concepts are analyzed in their work,no V&V metrics are proposed. We expect that our work will help alleviate some of thementioned challenges, for example by reducing the verification space which is subject tocombinatorial explosion when all parameters are considered during the evaluation of acomplete system.

Raibulet et al. [38] offer some interesting insights to the problems the work they analyzedpresented. For example, they mention how important a case study and tool support are tothe application of the proposed methods. In fact, many papers did not provide tools andlimited their case study to the application of their approach without further informationon how to interpret the results. They also mention that no work includes a complete setof evaluation mechanisms. It is then indicated that new mechanisms and refinements ofprevious ones are needed.

The current work aims at providing all these important elements such that the metricscan be widely understood and used for V&V of various applications. An implementationof the metrics is freely available as open source software 2 and Section 6.5 provides a fullpicture of how the results can be interpreted and corrective actions taken.

6.3 Metrics

This section introduces two new metrics based on state space coverage for adaptive soft-ware : modeled and effective adaptation space coverage. Both are measures ofstate space coverage, but are based on different sources of reachable values. These metricsare described in a format inspired by ISO/IEC 25023. This standard is part of the Sys-tems and software Quality Requirements and Evaluation (SQuaRE) series of InternationalStandards. As shown in Fig. 6.1, various elements are defined in the context of SQuaRE,with ISO/IEC 25023 focusing on “provid[ing] measures including associated measurementfunctions for the quality characteristics in the product quality model” [21]. To providea complete picture of the scope of the proposed metrics, each element of the SQuaREseries is addressed directly. While modeled and effective adaptation coverage are differentmetrics, they are similar and therefore will be presented conjointly.

2https://gitlab.com/memophysic/adaptive_py_metrics



Tableau 6.1 Adaptation state space measuresName Description Measurement functions and QMEs

Statespacecoverage(SC)

What proportion ofthe state space isvalid ?

X = A/BA = number of valid statesB = number of possible states

Recurrentstatespacecoverage(RSC)

What proportion ofa state space isrecurrently definedby a set of statespaces ?

X = (∑

max[0, Ai − 1]) /BAi = number of times the i-th state is definedB = number of possible states

NOTE : The notation max[a, b] indicates the maximum value between a and b.Primitiveadaptationspacecoverage(PASC)

What proportion ofcontextual statespace is supportedby a primitivecomponent ?

X = A/BA = number of states defined in a primitive com-ponent’s adaptation spaceB = number of possible states the component isaware of

Compositeadaptationspacecoverage(CASC)

What proportion ofcontextual statespace is supportedby a compositecomponent ?

X = (∑

Ai)− BAi = substitution candidates’ adaptation space co-verage, that is the measured value of PASC for thei-th substitution candidateB = substitution candidates’ recurrent adaptationspace coverage, that is the measured value of RSCfor the substitution candidates

Because the focus of the current work is also on quality measurements, table 6.1 wasproduced with the goal of presenting generic metrics. The base metric is the state spacecoverage, which is adequate for computing the coverage over the complete system. However,there exists an assumption for the adaptation space defined by adaptive components :any parameter not explicitly defined is considered entirely supported. In this case, thecomponent is said “agnostic” to the parameter. From this, the primitive adaptation spacecoverage uses the number of possible states that a component is aware of, that is onlythose originating from parameters explicitly defined in its adaptation space. For adaptivecomponents with substitution candidates (“composite” components), instead of computingthe adaptation space by unionizing those of the candidates, we make use of the PASCto compute their respective coverage. That way, we can obtain the composite adaptationspace coverage (CASC) simply by summing up the PASC of the candidates and subtractingthe coverage related to the states defined multiple times by each candidate. This lastmetric is formalized as the recurrent state space coverage, applicable to a set of statespaces. With this scheme, it is possible to compute the coverage of any component within

6.3. METRICS 75

Quality characteristics Quality sub-characteristics

Measurement function

Measurement methodTarget entity

Quality measure elements1..*

Property to quantify

Quality measure

1

*

<< produces >>

is measured by

Figure 6.1 Relationship among elements defined by the SQuaRE series of In-ternational Standards [21]

a composition hierarchy by requesting the primitive coverage of its substitution candidates.This is possible because all adaptive components are required to provide the adaptationspace they support explicitly. Therefore, all substitution candidates are considered blackboxes and each composition layer can be analyzed independently from each other.

In the remainder of this section, the elements defined in the SQuaRE series are addressedwith a description for each of the metrics’ context and properties.

Quality characteristic The quality characteristic being measured is the structural sup-port for adaptation contexts of an application. We seek to determine if an application hasthe capability to support ranges of contexts it is expected to encounter.

Quality sub-characteristic When verifying component-based software, the structuralsupport of contexts of an application relies on the support provided by each of its com-ponents. In adaptive software, the structure of components can change depending on thecontext. A quality sub-characteristic is therefore the structural support for adaptationcontexts offered by components in a dynamic environment.

Measure definition The structural support of contexts will be measured using adap-tation space coverage, that is, state space coverage of components’ adaptation space. It isdefined as the proportion of the number of states supported by a component as definedin its adaptation space compared to the number of reachable states, either defined by



parameters as a modeled space or by monitors as an effective space. This last distinction isreflected in variable B for the state space coverage function (see table 6.1) : the “numberof possible states” can be those provided by parameters or by their bound monitors. Fromthis fact, the proposed coverage metrics are labeled “modeled coverage” when based onparameters and as “effective coverage” when based on monitors.

Measurement functions The functions for modeled adaptation space coverage (MASC)and effective adaptation space coverage (EASC) are given in table 6.2. A few definitionsof terms are needed to understand the functions.

An adaptive component c has an adaptation space σc defined as a subspace of a contextspace where every contextual variable is a dimension. The states of each contextual va-riables are defined at design-time using parameters and at runtime by monitors. There-fore, two types of context spaces respectively exist : modeled context space Ω and effectivecontext space ω. A composite component has n substitution candidates s with each anadaptation space σsi . When looking at a context space constrained to the parametersknown by a set of components c0...n, the modeled context space is Ωc0...n and the effectivecontext space ωc0...n .

The terms found in table 6.2 are summarized below.

- σsi : Adaptation space of substitution candidate si for a given component

- Ωsi/ωsi : modeled/effective context space of substitute candidates for a given com-ponent

- Ωs0...n/ωs0...n : modeled/effective context space of all substitute candidates for a givencomponent

- c(x) : Number of states in the state space x (where x could be the state spacecorresponding to σ, Ω or ω)

- r(s0...n) : Number of recurrent states for all substitute candidates (obtained with analgorithm)

Tableau 6.2 Measurement functions for metricsMetric FunctionMASC CASC( Ai = PASC(A = c(σsi), B = c(Ωsi)),

B = RSC (Aj = r(σs0...n), B = c(Ωs0...n)))EASC CASC( Ai = PASC(A = c(σsi), B = c(ωsi)),

B = RSC (Aj = r(σs0...n), B = c(ωs0...n)))

6.3. METRICS 77

We can see that the functions from table 6.2 are implemented using the generic measure-ment functions presented in table 6.1. More specifically, both MASC and EASC metricsuse the CASC measurement function. Note that when using this measure on a primitivecomponent instead, the equation is equivalent to PASC since RSC = 0 and there areno substitution candidates, therefore the only primitive for the sum of PASC is itself.Resulting values range from 0.0 to 1.0, where 1.0 is the ideal value. Values < 1.0 indicatethat there are unsupported contextual states by the component.

Quality measure elements (QMEs) QMEs are the number of states defined in statespaces of different artifacts.

- Number of modeled context states as defined by parameters. They represent thereachable contexts as modeled at design time. Each parameter provides a dimensionof the state space.

- Number of effective context states as defined by monitors. They represent thereachable contexts which can be encountered at runtime for a given set of monitors.Like parameters, each monitor provides a dimension of the state space.

- Number of component adaptation states as defined by an adaptive component.They represent the viability zone of the component, that is, the contexts it supports.The states are a subset of those defined by the parameters.

Measurement method The method used is the same for all QMEs : acquisition andinspection of state spaces from artifacts (parameters, monitors and adaptive components).At design time, the state space of the parameters the component is aware of can be stati-cally acquired, rendering static analysis of modeled adaptation space coverage possible. Atruntime, the state space of the monitors can be acquired by obtaining the list of monitorscorresponding to the list of parameters the adaptive component is aware of (e.g. from amonitoring manager entity).

Property to quantify The property to quantify is the adaptation space coverage of anadaptive component. This quality property indicates what proportion of contexts that anapplication can encounter a certain component explicitly supports.

Target entities Adaptive components, parameters and monitors.



6.4 Development

The computation of the metrics was implemented to demonstrate its application. Becausethe necessary artifacts were implemented as part of our previous work in the libraryAdaptivePy, it was reused and improved to support more state space operations necessaryfor the calculations. Originally, the library only supported enumerated state spaces. Thenew version adds the abstract handling of state spaces along with basic operations suchas unions and intersections.

Using discrete state spaces, it is possible to efficiently define parameters which have avery large state space. One example is how temperature is represented for measurementsranging from -40° to 60° Celcius at the precision of 0.5°, expressed as [-40, 60, 0.5]. Thisleads to a state space of 60−(−40)

0.5= 200 states. Additionally, a second parameter could

be used to reinterpret these values in more human-readable terms such as {cold, normal,hot} by using thresholds within a monitor. Since monitors can define values subset of theirparameter, precision could be lower (e.g., 1°) and limited to a smaller range (e.g., -30°to30°).

The metrics’ computation is done through a single function which takes as input an adap-tive component and returns a value in the domain [0, 1], representing a percentage bet-ween 0 and 100%. The proposed solution in our previous work to simplify construction ofcomplex adaptive component hierarchies was to assume complete support of state spacesdefined by substitution candidates. This means that there is no need to query furtherthan the direct substitution candidates to obtain a complete definition of the adaptivecomponent’s adaptation space. This assumption was used to automatically compute thedefault adaptation space of a composite adaptive component as the union of its substitu-tion candidates’.

For the metrics’ computation, this means that substitution candidates are consideredprimitive components because they are expected to support the complete adaptation spacethey provide. Any undefined states can be manually supported by parametrization withinthe composite adaptive component or by further constraining its adaptation space. Thisreduces the problem of state space size explosion by only requiring the computation ofrecurring coverage to a single set of primitive components for any composite adaptivecomponent.

Computation of modeled coverage is done without the need to instantiate components byusing statically defined possible values for both parameters and components. For effectivecoverage, there is a need to instantiate components because monitors are registered to one

6.5. RESULTS 79

or many parameter value providers (PVP) and a component can be bound to only onePVP. This constraint was proposed in our previous work [27] to enable agreement withregards to context between collaborating components. An implication of this constraint isthat depending on which PVP the component is bound to, different monitors can be setand cover equally different regions of the viability zone. Two sets of monitors can thereforeprovide different coverage values.

A sample program was written to demonstrate the use of the metrics. The program re-presents an adaptive caging system for a zoo which allows the zookeepers to distributeand transfer animals to appropriate cages. Two contextual variables are used to makeadaptation decisions and are modeled as parameters :

- AnimalSize (AS) : {small, medium, large, gigantic}

- Temperature (T) : [-40, 60, 0.5]

An AnimalContainer interfaces describes what is expected to be accomplished by theadaptive component : an animal can be set in the container, it can be checked for emptinessand it can be cleaned. An adaptive component using substitution therefore needs to adaptto the various animal sizes and temperatures. Three types of animal containers are definedas three adaptive components with the following adaptation spaces :

- Cage : AS={small, medium}, T=[10, 60, 0.5]

- Barn : AS={small, medium, large}, T=[-40, 30, 0.5]

- VirtualEcosystem (ES) : AS={gigantic}

Note that since VirtualEcosystem doesn’t define any adaptation over the temperatureparameter, it is agnostic to it, meaning it supports any temperature and isn’t expected toadapt to temperature changes.

6.5 Results

The sample program presented in 6.4 has been implemented using AdaptivePy. The threeprimitive adaptive components along with a composite adaptive component have been usedas input for the metrics computation function, both as modeled and effective. Monitorswere created to provide a single random value among the possible values of their parameter.The results are presented in table 6.3. From these results, we can see that each substitutioncandidate has partial coverage, with Barn being the most flexible since it supports morethan half of the states compared to a quarter for Cage and VE. Interestingly, Composite



has a coverage of 92.5%, while the sum of its candidates yields 25 + 52.5 + 25 = 102.5%.This means that there is 102.5−92.5 = 10% of recurrent coverage. This recurrent coverageis due to cumulative overlap of substitution candidates’ adaptation space. This propertycan be visualized by using parameters as dimensions on a graph. Because we have onlytwo parameters, we obtain a 2D graph shown in Fig. 6.2. We see from this figure thatBarn and VE overlap from 10° to 30° and {small, medium} animal sizes. It can alsobe seen that the remaining 7.5% percent to be defined in Composite to attain 100% istemperatures between 30° and 60° for {large} animal size.

Tableau 6.3 Coverage of sample program with monitors over full domainCage Barn VE Composite

Modeled 25% 52.5% 25% 92.5%Effective 25% 52.5% 25% 92.5%

AnimalSize

Temperature

SmallMedium

LargeGigantic

-40 -30 -20 -10 0 10 20 30 40 50 60

CageBarnVirtualEcosystem

Figure 6.2 Coverage of substitution candidates for sample program with mo-nitors over full domain

The results of the analysis of the sample program provide information regarding the cor-rectness of the composite adaptive component. Such analysis is also a way for developersto evaluate the validity of their implementation. Table 6.3 shows that there is a need foraction to be taken in order to make the composite component comply with the assump-tion of supporting the full adaptation space of its parts. Some actions are discussed in thefollowing.

Add substitution candidate The undefined part could be supported by an additio-nal substitution candidate, for example a “HeatedArea” which would support AS={large,gigantic}, T=[10, 60, 0.5]. This would lead to the results in table 6.4. We see that thecoverage for the composite reaches 100%, while the additional HeatedArea adaptive com-ponent has 20% coverage. Modeled and effective coverage are still equal since monitors’

6.5. RESULTS 81

possible values have not been changed. Figure 6.3 shows how the HeatedArea fills the gapand leads to a complete support of the context space.

Tableau 6.4 Coverage of sample program with HeatedArea substitution candi-date

Cage Barn VE HeatedArea CompositeModeled 25% 52.5% 25% 20% 100%Effective 25% 52.5% 25% 20% 100%

AnimalSize

Temperature

SmallMedium

LargeGigantic

-40 -30 -20 -10 0 10 20 30 40 50 60

CageBarnVirtualEcosystemHeatedArea

Figure 6.3 Coverage of substitution candidates for sample program with Hea-tedArea substitution candidate

Reduce the effective context space The undefined part could be made unreachableat runtime by reducing the monitors’ possible values to a smaller viability zone. In thiscase, the temperature monitor could be limited to a maximum of 30°. An alternate solutionis to limit the animal sizes to {small, medium, gigantic}. Using the first solution leads tothe results in table 6.5. We see that effective coverage has changed in different ways foreach component. Specifically, Cage and VE have decreased in effective coverage since partsof the state they defined overlapped with the constrained states. On the other hand, Barn’seffective coverage has increased because the reachable state has been decreased and themonitor’s constrained states were not part of the Barn’s adaptation space. Note that themodeled coverage remains the same, meaning that there are still undefined states by thecomposite, but that they won’t be reached at runtime when using the currently providedmonitors. Figure 6.4 shows the reduced context space where the semi-transparent region onthe right illustrates the remaining modeled space. We see that the reduced context spaceis fully covered without modification to the components when interpreted for runtime.

Extend a substitution candidate’s adaptation space Support for the undefinedpart could be added to a substitution candidate by subclassing one of them and redefining



Tableau 6.5 Coverage of sample program with monitors over constrained do-main

Cage Barn VE CompositeModeled 25% 52.5% 25% 92.5%Effective 14.28% 75% 14.28% 100%

AnimalSize

Temperature

SmallMedium

LargeGigantic

-40 -30 -20 -10 0 10 20 30 40 50 60

CageBarnVirtualEcosystem

Figure 6.4 Coverage of substitution candidates for sample program with mo-nitors over constrained domain

its adaptation space. For example, a “JumboCage” could be created as a subclass of Cageand support the large animal size. Results are shown in table 6.6. We see that the Jum-boCage now covers 37.5% instead of 25% and that the composite attains 100% coverage.Figure 6.5 shows how the entire modeled state space is covered by the extension of thecage component’s adaptation space.

Tableau 6.6 Coverage of sample program with monitors over constrained do-main

JumboCage Barn VE CompositeModeled 37.5% 52.5% 25% 100%Effective 37.5% 52.5% 25% 100%

6.6 Discussion

The results presented in Section 6.5 show a simple case of how the metrics can be usedto verify and improve an implementation. The ideal value is 100% coverage, which can beobtained by applying one or many of the proposed corrective actions. Because there existmultiple corrective actions which can be taken to obtain larger coverage, developers arefree to tune their implementation to best fit their needs.

The application of corrective actions appears to be quite obvious for the presented sampleprogram because the parameters form a 2D space which can be displayed graphically. A

6.6. DISCUSSION 83

AnimalSize

Temperature

SmallMedium

LargeGigantic

-40 -30 -20 -10 0 10 20 30 40 50 60

JumboCageBarnVirtualEcosystem

Figure 6.5 Coverage of substitution candidates for sample program with mo-nitors over constrained domain

display limitation occurs when a component is aware of more than three parameters sincethey can no longer be visualized within a Euclidian space. While the actions presentedcan be taken with any number of parameters, identifying appropriate parameters, monitorsand components to modify would remain a challenge when components are aware of a largenumber of parameters.

A limitation of the metrics is that it cannot be used to ensure that adaptation goalsare reached. It is important to stress that the correctness of components with regards tosupport for their adaptation space is assumed. What is verified is that the adaptation spacesupport assumption holds when components are assembled into an architecture. Also, thisverification remains valid only within the specifications of the conceptual framework usedin this study [27]. A main assumption brought from previous work is that substitutioncandidates must provide an adaptation space which is expressed as the combination ofall the states resulting from the combinations of states derived from defined parameters.This allows any substitution candidates’ coverage to be computed as primitive componentsand greatly simplifies the computational load for computing the coverage of a compositecomponent in a large architecture.

An additional use of the metrics is to indicate progress of an implementation with regardsto a set of supported contexts. By measuring the proportion of supported context atfrequent points in time of a product’s development cycle, developers can obtain indicationsof their progression to support all the modeled context space or the effective context spacewhen the deployment target is known. This could be helpful to improve effort and costprevisions of context space regions support. This would be especially valid for groupsof often-used parameters as experience with the implementation of their context domaincould be analyzed and used for prevision.



While the implementation presented in 6.4 necessitates some artifacts to be present, theonly requirement is the ability for a developer to extract state spaces related to monitoringand components/modules. Table 6.1 is a generic definition of the measures used for themetrics and can be applied with any state spaces. For very simple cases, this can also bedone by hand.

6.7 Conclusion

The paper presented two metrics for the evaluation of adaptation space coverage in adap-tive software : modeled adaptation space coverage and effective adaptation space coverage.Each of these metrics provide a value in the domain [0.0, 1.0] which is interpreted as thepercentage of the states supported by an adaptive component over the relevant contextspace of the system. A value of 1.0 indicates complete support by the adaptive componentand prevents assures the developer that no undefined behavior is expected from a contextstate to be reached by the system.

A modeled coverage is based on the reachable contexts as inferred using defined parame-ters, independently from the deployment environment. An effective coverage is based onthe reachable contexts as inferred using monitors bound to the defined parameters. Be-cause these bindings depend on the runtime environment, effective coverage is a runtimemeasure as opposed to design-time for modeled coverage.

Metrics such as adaptation space coverage allow developers to verify that their system’scontext space will be fully supported from a high-level point of view. When developing aspecific component, it allows them to quantify the proportion of the component’s viabilityzone compared to the one that has been modeled. Unsupported states can be identifiedand handled, both in the design phase when the environment is modeled by parametersand at runtime when the environment is probed by monitors. This leads to a qualityimplementation for each layer of component substitutions.

We defined these metrics in a standardized way [21] with the inclusion of all necessarycalculations and definitions. We have also shown how they are expected to be used ina case study application and how to apply various corrective actions depending on thevalues obtained from the metrics. Additionally, source code for the metrics’ computationwas made freely available. We think that these elements are sufficient to address concernsraised by [38] with regards to existing literature on the subject of quality metrics foradaptive software. We think that the metrics are easy to understand, calculate and usefor adaptive software development.

6.7. CONCLUSION 85

Beyond this paper is the subject of tradeoff analysis which could help developers choosewhich corrective actions presented in Section 6.5 to apply. Such an analysis would requirean understanding of non-functional requirements with regards to internal quality of thesystem. For example, one could prefer reducing the effective context space to achieve a lessadaptive, but safer system given a certain target, while another might prefer developingan additional component to make the system as adaptive as possible. Knowing their pre-ferences, a tool could assist them with the application of corrective actions by suggestingchanges and identifying where exactly to make changes.

CHAPITRE 7

Discussion

Le présent chapitre a comme objectif d’analyser les contributions en portant un regardcritique sur ces dernières. D’abord, une argumentation justifiant l’atteinte des objectifs duprojet de recherche définis à la section 1.3 est présentée. Pour un résumé plus condensédu projet de recherche, consulter le chapitre 8. Ensuite, les compromis faits dans le cadredu projet de recherche sont présentés et justifiés.

7.1 Atteinte des objectifs de recherche

Pour considérer le projet de recherche comme complet, il est nécessaire de revoir les ob-jectifs émis à la section 1.3 à la lumière des contributions et des résultats obtenus. Uneargumentation au niveau de l’atteinte de l’objectif général est d’abord présentée, suivied’une discussion sur l’atteinte des objectifs secondaires qui s’inscrivent dans l’objectif gé-néral.

7.1.1 Objectif général

Suivant l’atteinte des objectifs secondaires, il est attendu que l’objectif général qui était detrouver quels patrons de conception permettent l’implémentation graduelle de mécanismesd’adaptation dans les interfaces graphiques soit atteint. Par la proposition des patronsde conception visant des préoccupations précises de l’adaptation et leur utilisation dansun prototype démonstratif d’application graphique, on peut considérer que les patronspermettent au moins la mise en place d’une structure viable pour ce genre d’applications.

Dans les patrons, les mécanismes d’adaptation (l’artéfact « ChooseRouteStrategy » dans lepatron Proxy routeur, voir figure 4.3.2) sont spécifiés séparément de sorte que ces dernierspuissent être ajoutés graduellement et comparés dans le contexte d’une même structure.Aussi, comme il est possible de transformer un composant en version adaptative sansimpacter les autres composants, le côté graduel de l’objectif est considéré comme atteint.

L’objectif général ne fait mention que des patrons de conception, mais il est nécessaire deconstater que les patrons en soi ne peuvent assurer une structure valide pour une applica-tion donnée. Ainsi, pour compléter les patrons et réellement atteindre l’objectif général,

87

88 CHAPITRE 7. DISCUSSION

des métriques ont été proposées pour effectuer la vérification de la structure produite parles patrons. De cette façon, il est valide de considérer que ces patrons permettent l’implé-mentation graduelle de mécanismes d’adaptation dans les interfaces graphiques et que lastructure de support est vérifiée et considérée comme valide.

7.1.2 Proposition de patrons de conception

Dans le cadre du projet de recherche, trois patrons de conception ont été proposés : Mo-niteur, Proxy routeur et Composant adaptatif. Ces patrons de conception sont issus d’unprocessus itératif où des préoccupations de l’adaptation ont été identifiées, des conceptsessentiels relevés de la littérature puis implémentés dans le cadre de prototypes démons-tratifs. De nouvelles préoccupations étaient par la suite relevées depuis les lectures ef-fectuées pendant l’itération et des propositions d’amélioration émises. L’exécution de cesétapes, tirées directement des sous-objectifs, a permis le développement des patrons deconception et de leur implémentation de référence qui sont les sujets du premier article(voir chapitre 4). En plus, l’analyse des gains par rapport à une implémentation ad hoc apermis d’identifier que la séparation des préoccupations d’adaptation (stratégies d’adap-tation, surveillance des données d’adaptation, reconfiguration) était accrue. De plus, leséléments reliés à l’adaptation étaient également eux-mêmes découplés des implémentationsnon adaptatives.

Pour les interfaces usagers graphiques qui constituent les cibles pour l’ajout de compor-tements adaptatifs dans le cadre du projet de recherche, cette dernière séparation permetainsi de développement de widgets adaptatifs depuis ceux fournis par le toolkit. Ces widgets,les composants dans le contexte des interfaces usagers graphiques, deviennent alors deséléments pouvant être utilisés dans la conception d’une interface graphique avec l’éditeurgraphique.

Suite à ces résultats, il est donc valide d’affirmer que les patrons de conception proposéssont issus de l’état de l’art en matière de structure pour l’adaptation puisque ces dernierssont le résultat d’un vaste recensement des concepts du domaine (voir section 4.2). Lespatrons de conception proposés sont inspirés de ceux disponibles dans la littérature et enfont la synthèse (voir les paragraphes « Related patterns » dans les définitions de patronsà la section 4.3). Finalement, les patrons remédient à certaines lacunes identifiées (ex. : laséparation de la modélisation à la conception et à l’exécution des données d’adaptation,l’utilisation collaborative de la substitution et de la paramétrisation). Leur utilisationreprésente un gain par rapport à l’implémentation ad hoc (voir section 4.5.2) dans lecontexte des interfaces usagers graphiques.

7.1. ATTEINTE DES OBJECTIFS DE RECHERCHE 89

7.1.3 Proposition de métriques

Dans le cadre du projet de recherche, deux métriques ont été proposées : la couverturemodélisée de l’espace d’adaptation et la couverture effective de l’espace d’adaptation. Cesmétriques visent un même but : quantifier la proportion des états atteignables par le sys-tème qu’un composant adaptatif supporte de façon explicite. Avant de pouvoir proposerces métriques, des sous-objectifs d’analyse devaient être atteints au niveau de la recherchede métriques proposées dans la littérature. Aussi, un objectif visait l’identification d’élé-ments de mesure rendus disponibles par la structure induite par l’application des patronsde conception proposés dans le présent projet de recherche.

Grâce à une revue de littérature détaillée à la section 6.2.2, il a été constaté que les mé-triques existantes sont principalement axées sur la comparaison de systèmes adaptatifsou sur la caractérisation de la performance de l’adaptation. Un manque notable se situedonc au niveau de l’évaluation de la structure supportant l’adaptation. Comme plusieursapplications contiennent des implémentations potentiellement différentes de mécanismesd’adaptation similaires, les différences structurelles pourraient biaiser la comparaison pourl’atteinte de buts d’adaptation et de performance. Ainsi, en évaluant séparément la struc-ture, les résultats de l’évaluation des mécanismes d’adaptation pourraient être mieux in-terprétés lorsque les systèmes à l’étude partagent une structure considérée équivalente.

Au niveau des éléments de mesure tirés de la structure induite par les patrons, les espacesd’adaptation utilisés pour déclarer les états valides des composants adaptatifs ont étéidentifiés comme des éléments de mesure importants. En effet, ces derniers sont utiliséségalement pour définir l’espace contextuel du système où chaque dimension est constituéedes valeurs possibles des paramètres à la conception et des moniteurs à l’exécution.

Un autre élément de mesure identifié est l’arbre de composition des composants adaptatifs.Comme les composants adaptatifs peuvent avoir des candidats de substitution, ces dernierspeuvent être considérés comme les enfants du composant adaptatif dans un arbre. Commechaque candidat de substitution peut à son tour être un composant adaptatif, ces relationspeuvent être modélisées en un arbre de taille arbitraire. Les caractéristiques de cet arbresont donc un autre élément de mesure.

Il existe des relations de dépendance qui ciblent un composant adaptatif et débutentdepuis les moniteurs qui fournissent les valeurs des paramètres que ce dernier connait.Aussi, comme un moniteur peut baser ses valeurs sur un état interne au système, cet étatpeut être lié à des propriétés d’un composant, adaptatif ou non. Une telle situation créealors un lien de dépendance depuis le moniteur vers le composant en question.


Ces derniers éléments de mesure ont été utilisés pour proposer des métriques de qualité po-tentielles (voir sections 5.1.2, 5.1.3 et 5.1.4). L’espace d’adaptation a permis la propositiondes métriques citées précédemment et qui sont le sujet du chapitre 6. Leur implémentationest détaillée à la section 5.3. Finalement, elles sont appliquées à une application concrèteet des actions correctives sont proposées à la section 6.5. Ainsi, il est valide de considé-rer que les objectifs de proposer et d’implémenter les métriques ainsi que de les utiliserpour analyser une application concrète sont atteints. L’atteinte des sous-objectifs est ainsicomplète et il est également valide d’affirmer que l’objectif secondaire de proposition desmétriques est atteint.

7.2 Choix techniques et compromis

Pour la réalisation du projet de recherche, certains choix ont dû être faits pour faciliterl’atteinte des objectifs et contrôler l’effort requis pour la réalisation des différents proto-types. La justification de ces choix est abordée pour chacun d’entre eux dans la présentesection.

7.2.1 Langage et plate forme

Le langage choisi pour le projet de recherche est Python en version 3.4. Un tel langage aprocuré de nombreux avantages dans le cadre du projet de recherche. D’abord, la focalisa-tion du projet de recherche sur la portabilité des solutions implique que l’implémentationproposée des patrons de conception devait être également le plus portable possible. CommePython est un langage interprété et qu’un interpréteur est disponible pour toutes les platesformes majeures (GNU/Linux, Windows et MacOS), ce langage remplissait ce critère. Unautre critère de base est que le langage doit supporter le POO, ce qui est le cas de Python.En plus, au niveau de l’implémentation des patrons eux-mêmes, le fait que Python soit unlangage dynamique rend spécialement faciles la reconfiguration et la mise en place d’unproxy. Finalement, comme il ne s’agit pas d’un langage fortement typé (une variable peutaccueillir n’importe quel type à n’importe quel moment), le développement de prototypesest facilité. Au niveau de l’assurance qualité, l’intégration des tests unitaires permet d’offrirun niveau acceptable de confiance aux utilisateurs envers l’implémentation des patrons.

7.2.2 Librairie pour l’adaptation

À l’origine, il avait été envisagé de baser les développements sur une librairie d’adaptationexistante. La librairie envisagée était ContextPy, une implémentation de la méthode de

7.2. CHOIX TECHNIQUES ET COMPROMIS 91

programmation orientée-contexte (context-oriented programming) proposée par Hirschfeldet al. [18]. La programmation orientée-contexte permet l’activation et la désactivation decouches dans lesquelles des méthodes sont réimplémentées. Ainsi, en fonction de l’étatd’activation d’une couche, les méthodes appelées diffèrent. La mise en place de méca-nismes d’adaptation est donc centralisée dans la logique d’activation et de désactivationdes couches, tandis que des classes peuvent spécifier les comportements spécifiques à uncontexte par le biais de la réimplémentation de leurs méthodes. Une analyse de l’utilisationde cette librairie a été faite et une version fonctionnant avec Python 3 a été produite.

La principale raison pour laquelle la programmation orientée-contexte a été mise de côtéest que le principe des couches était trop contraignant. En effet, bien que la redirectiondes appels de fonction est un principe largement partagé dans le domaine de l’adaptation,une couche ne peut représenter qu’un état booléen d’une propriété ou d’une condition.Ainsi, pour couvrir un spectre plus large et complexe de contextes, beaucoup de couchesseraient nécessaires et seulement des combinaisons booléennes sont possibles.

Ainsi, l’idée de développer des patrons de conception inspirés d’une large variété de travauxet où les méthodes d’adaptation seraient plus générales a poussé le développement d’unelibrairie indépendante. Le choix de ne pas se baser sur des développements existants adonc été fait pour contraindre le moins possible la mise en place d’artéfacts génériques etde se différencier des développements existants.

CHAPITRE 8

Conclusion

8.1 Sommaire

Le présent projet de recherche s’inscrit dans le domaine de l’adaptation dans les logiciels.Avec l’essor de l’Internet des Objects, les logiciels sont désormais présents dans une multi-tude d’appareils et l’automatisation de tâches de façon personnalisée. Cependant, mettreen place l’adaptation, particulièrement dans les interfaces personne-machine, reste un défide taille. Il s’agit ainsi de chercher des techniques pour structurer un logiciel de sorteque l’adaptation puisse facilement et graduellement être ajoutée. De plus, il est nécessaired’utiliser une façon adéquate de communiquer cette structure afin qu’elle soit utilisabledans une grande variété de logiciels, le plus indépendamment possible des technologiesutilisées.

Les patrons de conception sont une formalisation d’une solution logicielle à un problèmerécurrent d’implémentation. Ces derniers sont largement utilisés dans le domaine du dé-veloppement logiciel. Ainsi, l’objectif pour le présent projet de recherche était de trouverquels sont les patrons de conception qui permettent l’implémentation graduelle de méca-nismes d’adaptation dans les interfaces graphiques. Pour atteindre cet objectif, une analyseen profondeur de la littérature sur le sujet de l’adaptation dans les logiciels a été faite afinde déceler les concepts et approches que partagent les travaux de l’état de l’art. Depuisceux-ci, des patrons de conception ont été développés dans le contexte d’un processusitératif où des préoccupations de l’adaptation étaient abordées et implémentés depuis lessolutions dans l’état de l’art dans des prototypes démonstratifs. Les approches utiliséespouvaient alors être critiquées et des lacunes identifiées de sorte que des améliorationspuissent être apportées. Une fois que les préoccupations essentielles à la réalisation d’uneapplication graphique furent couvertes, des patrons de conception ont été produits depuisune généralisation des solutions explorées.

Ces patrons de conception ont ensuite été implémentés dans une librairie de référence nom-mée AdaptivePy. Cette dernière fut utilisée afin de développer un prototype d’applicationgraphique adaptative pour une étude de cas. Cette application est un jeu-questionnaire oùles réponses passées influencent le nombre d’options proposées à l’utilisateur pour favoriserla polarisation des résultats. Une version de ce prototype utilisant une approche ad hoc

93

94 CHAPITRE 8. CONCLUSION

(sans la librairie) a été implémentée et utilisée pour comparaison. Les gains observés sesituent principalement au niveau de la séparation des préoccupations, de la cohésion desméthodes, de la localisation des changements pour l’ajout de l’adaptation et de l’extensibi-lité. Ces propriétés induisent une meilleure maintenabilité. En plus, comme les composantsadaptatifs formant l’application sont des instances autonomes, il est possible de les utiliserpour faire la conception de l’interface dans un éditeur graphique, ce qui n’était pas pos-sible pour l’implémentation ad hoc. Pour les développeurs, cela représente un avantage,car le déroulement du travail (workflow) se rapproche plus de ce qui est habituel dans ledomaine du développement d’interfaces graphiques.

Une fois les patrons formalisés et utilisés dans une application concrète, il a été réalisé queces derniers ne suffisent pas à assurer une structure optimale ou valide à l’exécution del’application. Pour mieux évaluer la structure induite par les patrons de conception, desmétriques traditionnelles ont été analysées afin de déceler des analogies avec les élémentsà évaluer d’un logiciel adaptatif. Par la suite, la structure induite elle-même a été analyséeafin d’identifier des éléments de mesure pouvant servir à l’élaboration de métriques. Troismétriques potentielles ont été proposées et une d’entre elles, la couverture de l’espaced’adaptation, a été sélectionnée pour être formalisée.

En fonction des situations supportées par les composants adaptatifs, une situation n’étantsupportée par aucun composant offrant un certain service induira un comportement in-défini au logiciel nécessitant ce service. Comme les composants adaptatifs doivent définirexplicitement les situations qu’ils supportent sous forme « d’espace d’adaptation », unemétrique visant l’évaluation de la couverture de cet espace a été proposée pour quantifierla proportion des situations atteignables supportées par un composant. De cette façon, ilest possible pour un développeur de déterminer si un composant adaptatif peut induire descomportements indéfinis. Aussi, un développeur peut évaluer l’impact des actions qu’il aentreprises pour mieux couvrir les situations pouvant être rencontrées par le logiciel (aug-mentation, diminution ou aucun changement de la couverture). Deux versions de cettemétrique ont été proposées : l’une basée sur les situations atteignables de façon théorique,soit en fonction de la modélisation faite du contexte, et l’autre sur les situations concrète-ment atteignables, soit en fonction des valeurs qui peuvent être rencontrées à l’exécution.Ces métriques ont été nommées respectivement « couverture modélisée de l’espace d’adap-tation » et « couverture effective de l’espace d’adaptation ». Elles ont été formalisées dansun format similaire au standard ISO/IEC 25023 et appliquées dans le cadre d’une applica-tion typique. Les actions correctives sujettes à améliorer la couverture ont également étéproposées et leur impact démontré.

8.2. CONTRIBUTIONS 95

Le projet de recherche a été organisé de sorte que les deux grands objectifs de recherche(la proposition de patrons de conception et la proposition de métriques pour la validation)soient abordés directement dans des articles séparés. Les détails additionnels fournis dansce mémoire au niveau de la méthodologie et des approches connexes explorées permettentde démontrer la façon dont les travaux ont été réalisés. L’ensemble de ces éléments ren-contrent donc la totalité des objectifs de recherche et les résultats obtenus forment uneavancée notable de l’état de l’art au niveau des techniques de structuration de l’adaptationdans les logiciels de domaines variés.

Au final, la réponse à la question de recherche est donnée par la proposition des patronsde conception Moniteur, Proxy router et Composant adaptatif conjointement à la valida-tion par les métriques de couverture modélisée et effective de l’espace d’adaptation. Lastructure de base mise en place par l’application des patrons de conception permet bienl’implémentation de différents mécanismes d’adaptation pendant le cycle de développe-ment d’un logiciel adaptatif. Les mécanismes d’adaptation étant implémentés sous formede stratégies, il est facile d’en comparer et d’en ajouter de façon graduelle.

8.2 Contributions

Les contributions originales au projet de recherche sont les patrons de conception et lesmétriques proposées. Une description plus détaillée de chacun est donnée dans cette sec-tion.

8.2.1 Patrons de conception

Les patrons de conception sont des formalisations de solutions à des problèmes récurrents,dans ce cas-ci au niveau de la structuration de préoccupation de l’adaptation. Les patronsproposés sont originaux, car ils sont une généralisation de solutions plus spécifiques àdivers domaines. Ils sont composés de certains patrons existants plus primitifs, mais leurstructure telle que présentée est originale. Surtout, leur utilisation commune pour mettreen place une structure alliant la paramétrisation et la substitution de composants dansune optique de collaboration est une avancée notable de l’état de l’art.

- Moniteur : Le patron de conception moniteur met en place une structure qui permetl’utilisation de données d’adaptation pour le contrôle de l’adaptation d’un ensemblede composants. Une approche basée sur des évènements permet d’émettre des no-tifications lorsque des changements de valeurs sont détectés. Ces notifications sont


envoyées aux composants intéressés et peuvent induire une adaptation. Les donnéesd’adaptation sont fournies par des entités dédiées qui ont la responsabilité d’offrir unevaleur dans un domaine connu, modélisé pour un type de données à la conception. Ilest donc possible d’avoir plusieurs façons d’obtenir un type de données d’adaptation.

- Proxy routeur : Le patron de conception proxy routeur permet de rediriger les ap-pels de fonction envers un composant concret en fonction d’une stratégie de routage.Ce patron est une utilisation collaborative des patrons proxy qui réalise un déléguépour un service et routeur qui redistribue un flux en fonction de stratégies spécifiquesau domaine. Ce patron de conception met donc en place une structure supportantla substitution de composants et le découplage de mécanismes d’adaptation.

- Composant adaptatif : Le patron de conception composant adaptatif tire partides deux autres patrons en ajoutant une structure générale pour un composant quipermet d’effectuer de l’adaptation par paramétrisation et par substitution. Le pa-tron impose la divulgation par une interface commune d’un espace d’adaptation quistipule les situations contextuelles supportées par le composant par l’une ou l’autredes méthodes d’adaptation. Aussi, un lien de dépendance sur un gestionnaire d’évè-nements pour l’obtention de notification de changement de données d’adaptationest imposé. De cette façon, l’ensemble des composants partageant ce gestionnairepeuvent participer de façon collaborative à un plan d’adaptation puisque ces der-niers s’entendent alors sur l’état du système à tout moment. Le fait qu’un candidatde substitution tel que défini dans le patron Proxy routeur puisse être un composantadaptatif, il est également possible de créer des hiérarchies d’une taille arbitraire decomposants adaptatifs. Cette structure se prête particulièrement bien aux applica-tions graphiques.

8.2.2 Métriques d’évaluation

Bien que trois métriques générales aient été proposées, une formalisation de seulement uned’entre elles en deux versions spécifiques a été effectuée dans le cadre du présent projetde recherche. Cependant, il est adéquat de les mentionner ici puisqu’elles sont, en effet,originales dans le contexte des logiciels adaptatifs.

Profondeur de l’arbre de substitution

Comme un arbre peut être généré depuis les liens de candidature de substitution pour lescomposants adaptatifs, la profondeur de cet arbre peut être considéré comme une mesurede la complexité d’exécution de l’adaptation. Plus le nombre de niveaux de l’arbre est

8.2. CONTRIBUTIONS 97

grand, plus l’exécution d’une reconfiguration, par exemple, a un potentiel de complexitéélevé.

Stabilité de l’adaptation

Les relations de dépendance entre les moniteurs et les composants adaptatifs peuvent don-ner lieu à un cycle d’adaptation potentiellement infini. Une telle situation est indésirable,or le nombre de tels cycles dans une architecture peut être considérée une mesure de lastabilité d’adaptation. La valeur idéale est 0, soit l’absence complète de cycles.

Couverture de l’espace d’adaptation (retenue)

L’espace d’adaptation est l’ensemble des situations contextuelles que supporte un compo-sant. Ainsi, la proportion de cet ensemble sur l’ensemble des situations atteignable par lesystème, sa « couverture », est un indicateur de la présence de situations qui ne sont passupportées par ce composant. Il s’agit également d’un indicateur de la spécialisation d’uncomposant ; un composant supportant toutes les situations est « général », tandis qu’uncomposant supportant peu de situations est « spécifique ». On peut donc comparer deuxcomposants et indiquer que l’un est plus spécifique ou général que l’autre.

8.2.3 Métriques spécifiques formalisées

La métrique de couverture de l’espace d’adaptation a été spécialisée en deux versions. Cesversions sont synthétisées ici.

Couverture modélisée de l’espace d’adaptation

Cette couverture est basée sur l’espace contextuel que forment les valeurs possibles desparamètres. Les paramètres définissent un type de donnée d’adaptation ainsi que sondomaine de valeurs théorique. Ainsi, un composant adaptatif peut être développé poursupporter un ensemble de situations qui pourraient être rencontrées dans n’importe le-quel des environnements d’exécution. La métrique indique la proportion sur l’ensemblede ces situations potentielles, neutre de l’environnement d’exécution, que supporte uncomposant. Cette propriété permet d’être calculée à la conception sans connaissance desenvironnements de déploiement.

Couverture effective de l’espace d’adaptation

Cette couverture est basée sur l’espace contextuel que forment les valeurs possibles desmoniteurs. Un moniteur a la responsabilité de fournir une valeur parmi celles définiespar un et un seul paramètre. Comme ces valeurs sont fournies à l’exécution, la méthode


de surveillance et de collecte des données peut être dépendante de l’environnement de dé-ploiement. Les moniteurs offrent donc un domaine de valeurs pratique pour l’ensemble desdonnées d’adaptations. La métrique indique la proportion sur l’ensemble des situations quipourraient être rencontrées à l’exécution que supporte un composant. Comme ni l’identitédes moniteurs ni même les valeurs qu’ils peuvent fournir ne sont pas fixes à la conception,cette métrique ne peut être calculée qu’à l’exécution. Il est cependant possible de calculerla métrique à la conception en spécifiant un ensemble de moniteurs.

8.3 Travaux futurs

Les travaux du présent projet de recherche sont concentrés sur l’identification de conceptsfondamentaux pour la structure d’un logiciel adaptatif et des méthodes pour mettre enplace cette structure dans une grande variété de logiciels, mais particulièrement pour lesapplications graphiques. Cependant, certains éléments n’ont pas été entièrement couvertsou simplement omis pour préciser les éléments de recherche ou faciliter l’obtention derésultats. Le sujet de cette section est donc de clarifier les éléments qui n’ont pas étécouverts par le présent projet de recherche et d’indiquer des pistes pour les travaux futurs.

8.3.1 Éléments à approfondir dans le cadre de recherches futures

Le présent projet de recherche atteint tous les objectifs fixés initialement dans la défi-nition de projet. Cependant, l’attention particulière du projet de recherche a été sur ledéveloppement d’une structure pour le développement d’interfaces graphiques. Ainsi, enfocalisant sur ce domaine, certains concepts inapplicables comme le support de transac-tions simultanées envers plusieurs délégués (pour les systèmes distribués en réseau) ontété mis de côté. L’étendue du domaine de l’adaptation dans les logiciels étant beaucoupplus large que les limites fixées pour le projet de recherche, certains aspects pourraientêtre approfondis dans le futur.

Par exemple, comme la structure de base mise en place par l’application de patrons deconception est neutre de mécanismes d’adaptation, il serait intéressant de démontrer parle biais de plusieurs prototypes l’utilisation de différents mécanismes avec une même struc-ture. Par exemple, l’utilisation d’un moteur d’inférence par règles pour l’adaptation est unmécanisme populaire et son implémentation dans le cadre de la structure de base pourraitservir de guide pour des développeurs désirant l’utiliser.

8.3. TRAVAUX FUTURS 99

Dans le premier article, des métriques étaient utilisées de façon qualitative pour effectuerune analyse des gains en qualité apportés par l’utilisation des patrons de conception.Dans des travaux futur, il pourrait être intéressant de quantifier ces métriques (cohésiondes méthodes, séparation des préoccupations) et d’automatiser leur calcul afin qu’ellespuissent être utilisées plus facilement dans le cadre de prototypes complexes.

Dans le cas des métriques, il serait intéressant de formaliser les autres métriques poten-tielles qui ont été proposées (profondeur de l’arbre de substitution, stabilité de l’adaptation)dans le format ISO/IEC 25023. Un élément qui aurait pu être plus couvert par rapport à lamétrique formalisée est son utilisation dans une vaste gamme d’applications, soit des appli-cations simples et d’autres très complexes. Ainsi, dans un projet futur, il serait possible demieux évaluer la difficulté d’application des actions correctives et de proposer des pistespour accompagner les développeurs dans leur application. Il a déjà été indiqué qu’unequantité importante de paramètres (plus de trois) empêchait la représentation graphiquede l’espace contextuel et donc la détermination et l’application des actions correctives pro-posées. Aussi, les impacts possiblement négatifs (effets secondaires) qu’aurait l’applicationde chacune des actions correctives pourraient être explorés. Il serait notamment utile demieux comprendre les impacts de choisir une action corrective par rapport à une autre enfonction du manque de couverture détecté.

8.3.2 Nouvelles perspectives de recherche

Étant donné que le projet de recherche visait spécifiquement les interfaces graphiques,il serait intéressant d’explorer les avenues apportées par l’adaptation dans ce domaine.Plusieurs travaux existants visent à mettre en place des mécanismes d’adaptation dans lesinterfaces graphiques (« plastic ui » [9, 11, 28]), mais aucune structure de base n’est misede l’avant pour supporter une grande variété de mécanismes. Un aspect qui pourrait êtreétudié est la façon dont une interface peut adapter son comportement en fonction du mé-dium d’entrée (souris, clavier, stylet, écran capacitif). En théorie, l’utilisation des patronsde conception permettrait de mettre en place une structure adéquate pour le développe-ment d’une telle interface, mais les éléments de conception dans le domaine des interfacespersonne-machine ne sont pas spécifiquement adressés dans la présente recherche. Ainsi,une avenue serait de créer une banque de contrôles pour les interfaces graphiques quis’adaptent au médium d’entrée. La fonctionnalité de prévisualisation de l’adaptation quiest rendue possible dans l’éditeur graphique permettrait de faciliter la conception de telscomposants. Un type de composant complexe à développer pour ce domaine de contexte


serait des « layouts », soit des widgets qui disposent d’autres widgets dans une région del’interface.

Un autre aspect qui serait à explorer est l’expansion de la librairie AdaptivePy pour sup-porter par défaut les transitions d’états intermédiaires pour composants lors du transfertd’état. Ainsi, les transactions concurrentielles pourraient être supportées et la librairieserait mieux adaptée aux systèmes distribués en réseau. Une extension de la librairiespécifique à l’utilisation pour la création d’interfaces pourrait également être créée poursimplifier son utilisation pour ce genre d’applications.

Finalement, une perspective de recherche intéressante serait d’automatiser l’applicationdes patrons de conception afin qu’une application puisse être générée depuis des requishaut niveau d’adaptation et une modélisation de l’espace contextuel. Ainsi, il serait enthéorie possible de générer une base d’application qui pourrait alors être utilisée commeun framework. Cela pourrait permettre de régler en partie le problème de spécialisation desframeworks et permettrait de minimiser les problèmes liés à une mauvaise implémentationdes patrons. Dans le cas des interfaces graphiques, il serait intéressant de considérer si lamajeure partie de l’interface pourrait être générée automatiquement depuis la spécificationd’un appareil, plate forme, type d’utilisateur et méthodes d’entrée et d’affichage.

LISTE DES RÉFÉRENCES

[1] Aubin, J., Bayen, A. et Saint-Pierre, P. (2011). Viability Theory : New Directions.Modern Birkhèauser classics, Springer Berlin Heidelberg.

[2] Berkane, M. L., Seinturier, L. et Boufaida, M. (2015). Using variability modelling anddesign patterns for self-adaptive system engineering : Application to smart-home. Int.J. Web Eng. Technol., volume 10, numéro 1, p. 65–93.

[3] Bezold, M. et Minker, W. (2011). Adaptive multimodal interactive systems. SpringerScience & Business Media.

[4] Bruneton, E., Coupaye, T., Leclercq, M., Quéma, V. et Stefani, J.-B. (2006). Thefractal component model and its support in java. Software : Practice and Experience,volume 36, numéro 11-12, p. 1257–1284.

[5] Calinescu, R., Ghezzi, C., Kwiatkowska, M. et Mirandola, R. (2012). Self-adaptivesoftware needs quantitative verification at runtime. Commun. ACM, volume 55, nu-méro 9, p. 69–77.

[6] Chang, F. et Karamcheti, V. (2001). A framework for automatic adaptation of tunabledistributed applications. Cluster Computing, volume 4, numéro 1, p. 49–62.

[7] Chen, W.-K., Hiltunen, M. A. et Schlichting, R. D. (2001). Constructing adaptivesoftware in distributed systems. Dans Distributed Computing Systems, 2001. 21stInternational Conference on. p. 635–643.

[8] Cheng, B. H. C., Lemos, R., Giese, H., Inverardi, P., Magee, J., Andersson, J., Becker,B., Bencomo, N., Brun, Y., Cukic, B., Marzo Serugendo, G., Dustdar, S., Finkelstein,A., Gacek, C., Geihs, K., Grassi, V., Karsai, G., Kienle, H. M., Kramer, J., Litoiu,M., Malek, S., Mirandola, R., Müller, H. A., Park, S., Shaw, M., Tichy, M., Tivoli,M., Weyns, D. et Whittle, J. (2009). Software Engineering for Self-Adaptive Systems,chapitre Software Engineering for Self-Adaptive Systems : A Research Roadmap.Springer Berlin Heidelberg, Berlin, Heidelberg, p. 1–26.

[9] Collignon, B., Vanderdonckt, J. et Calvary, G. (2008). Model-driven engineering ofmulti-target plastic user interfaces. Dans Fourth International Conference on Auto-nomic and Autonomous Systems (ICAS’08). p. 7–14.

[10] Corsaro, A., Schmidt, D. C., Klefstad, R. et O’Ryan, C. (2002). Virtual component -a design pattern for memory-constrained embedded applications. Dans in Proceedings

101

102 LISTE DES RÉFÉRENCES

of the Ninth Conference on Pattern Language of Programs (PLoP.

[11] Coutaz, J. (2010). User interface plasticity : Model driven engineering to the limit !Dans Proceedings of the 2Nd ACM SIGCHI Symposium on Engineering InteractiveComputing Systems. EICS ’10. ACM, New York, NY, USA, p. 1–8.

[12] Gamma, E., Helm, R., Johnson, R. et Vlissides, J. (1995). Design Patterns : Elementsof Reusable Object-oriented Software. Addison-Wesley Longman Publishing Co., Inc.,Boston, MA, USA.

[13] Garlan, D., Cheng, S.-W., Huang, A.-C., Schmerl, B. et Steenkiste, P. (2004). Rain-bow : Architecture-based self-adaptation with reusable infrastructure. Computer,volume 37, numéro 10, p. 46–54.

[14] Georgiadis, I., Magee, J. et Kramer, J. (2002). Self-organising software architecturesfor distributed systems. Dans Proceedings of the First Workshop on Self-healing Sys-tems. WOSS ’02. ACM, New York, NY, USA, p. 33–38.

[15] Gomaa, H., Hashimoto, K., Kim, M., Malek, S. et Menascé, D. A. (2010). Soft-ware adaptation patterns for service-oriented architectures. Dans Proceedings of the2010 ACM Symposium on Applied Computing. SAC ’10. ACM, New York, NY, USA,p. 462–469.

[16] Gomaa, H. et Hussein, M. (2004). Software reconfiguration patterns for dynamicevolution of software architectures. Dans Software Architecture, 2004. WICSA 2004.Proceedings. Fourth Working IEEE/IFIP Conference on. p. 79–88.

[17] Hinchey, M. G. et Sterritt, R. (2006). Self-managing software. Computer, volume 39,numéro 2, p. 107–109.

[18] Hirschfeld, R., Costanza, P. et Nierstrasz, O. (2008). Context-oriented programming.Dans Journal of Object Technology, March-April 2008, ETH Zurich, Citeseer. vo-lume 7.

[19] Holvoet, T., Weyns, D. et Valckenaers, P. (2009). Patterns of delegate mas. Dans 2009Third IEEE International Conference on Self-Adaptive and Self-Organizing Systems.p. 1–9.

[20] IBM (2005). An architectural blueprint for autonomic computing (Rapport tech-nique). IBM Corporation.

[21] ISO/IEC (2016). Systems and software engineering – Systems and software Qua-lity Requirements and Evaluation (SQuaRE) – Measurement of system and software

LISTE DES RÉFÉRENCES 103

product quality (Standard 25023).

[22] Kaddoum, E., Raibulet, C., Georgé, J.-P., Picard, G. et Gleizes, M.-P. (2010). Criteriafor the evaluation of self-* systems. Dans Proceedings of the 2010 ICSE Workshop onSoftware Engineering for Adaptive and Self-Managing Systems. SEAMS ’10. ACM,New York, NY, USA, p. 29–38.

[23] Kang, P., Heffner, M., Mukherjee, J., Ramakrishnan, N., Varadarajan, S., Ribbens,C. et Tafti, D. K. (2007). The adaptive code kitchen : Flexible tools for dynamicapplication composition. Dans 2007 IEEE International Parallel and DistributedProcessing Symposium. p. 1–8.

[24] Lemos, R., Giese, H., Müller, H. A., Shaw, M., Andersson, J., Baresi, L., Becker, B.,Bencomo, N., Brun, Y., Cukic, B., Desmarais, R., Dustdar, S., Engels, G., Geihs, K.,Goeschka, K. M., Gorla, A., Grassi, V., Inverardi, P., Karsai, G., Kramer, J., Litoiu,M., Lopes, A., Magee, J., Malek, S., Mankovskii, S., Mirandola, R., Mylopoulos, J.,Nierstrasz, O., Pezzè, M., Prehofer, C., Schäfer, W., Schlichting, R., Schmerl, B.,Smith, D. B., Sousa, J. P., Tamura, G., Tahvildari, L., Villegas, N. M., Vogel, T.,Weyns, D., Wong, K. et Wuttke, J. (2013). Software engineering for self-adaptivesystems : A second research roadmap. Dans de Lemos, R., Giese, H., Müller, H. A. etShaw, M., Software Engineering for Self-Adaptive Systems II, volume 7475. Springer-Verlag, p. 1–32.

[25] Liu, H. et Parashar, M. (2006). Accord : a programming framework for autonomicapplications. IEEE Transactions on Systems, Man, and Cybernetics, Part C (Appli-cations and Reviews), volume 36, numéro 3, p. 341–352.

[26] Liu, Y., Xu, C. et Cheung, S. (2013). Afchecker : Effective model checking for context-aware adaptive applications. Journal of Systems and Software, volume 86, numéro 3,p. 854 – 867.

[27] Longchamps, S. et Gonzalez-Rubio, R. (2017). Design patterns for addition of adap-tive behavior in graphical user interfaces. Dans Proceedings of the Ninth InternationalConference on Adaptive and Self-Adaptive Systems and Applications.

[28] Majrashi, K., Hamilton, M. et Uitdenbogerd, A. (2015). Multiple user interfaces andcross-platform user experience : Theoretical foundations. Dans CCSEA 2015, AIRCCPublishing Corporation. p. 43–57.

[29] Malek, S., Beckman, N., Mikic-Rakic, M. et Medvidovic, N. (2005). A Frameworkfor Ensuring and Improving Dependability in Highly Distributed Systems. Springer


Berlin Heidelberg, Berlin, Heidelberg, p. 173–193.

[30] Mannava, V. et Ramesh, T. (2012). Multimodal pattern-oriented software archi-tecture for self-optimization and self-configuration in autonomic computing systemusing multi objective evolutionary algorithms. Dans Proceedings of the InternationalConference on Advances in Computing, Communications and Informatics. ICACCI’12. ACM, New York, NY, USA, p. 1236–1243.

[31] Maurel, Y., Diaconescu, A. et Lalanda, P. (2010). Ceylon : A service-oriented fra-mework for building autonomic managers. Dans 2010 Seventh IEEE InternationalConference and Workshops on Engineering of Autonomic and Autonomous Systems.p. 3–11.

[32] McCann, J. A. et Huebscher, M. C. (2004). Evaluation Issues in Autonomic Compu-ting. Springer Berlin Heidelberg, Berlin, Heidelberg, p. 597–608.

[33] Menasce, D. A., Sousa, J. a. P., Malek, S. et Gomaa, H. (2010). Qos architecturalpatterns for self-architecting software systems. Dans Proceedings of the 7th Interna-tional Conference on Autonomic Computing. ICAC ’10. ACM, New York, NY, USA,p. 195–204.

[34] Montague, K., Hanson, V. L. et Cobley, A. (2012). Designing for individuals : Usabletouch-screen interaction through shared user models. Dans Proceedings of the 14th In-ternational ACM SIGACCESS Conference on Computers and Accessibility. ASSETS’12. ACM, New York, NY, USA, p. 151–158.

[35] Motti, V. G. et Vanderdonckt, J. (2013). A computational framework for context-aware adaptation of user interfaces. Dans IEEE 7th International Conference onResearch Challenges in Information Science (RCIS). p. 1–12.

[36] Peissner, M., Schuller, A. et Spath, D. (2011). A design patterns approach to adaptiveuser interfaces for users with special needs. Dans Proceedings of the 14th InternationalConference on Human-computer Interaction : Design and Development Approaches -Volume Part I. HCII’11. Springer-Verlag, Berlin, Heidelberg, p. 268–277.

[37] Perez-Palacin, D., Mirandola, R. et Merseguer, J. (2014). On the relationships bet-ween qos and software adaptability at the architectural level. Journal of Systems andSoftware, volume 87, p. 1 – 17.

[38] Raibulet, C., Arcelli Fontana, F., Capilla, R. et Carrillo, C. (2016). An overview onquality evaluation of self-adaptive systems. Dans Mistrik, I., Ali, N., Kazman, R.,

LISTE DES RÉFÉRENCES 105

Grundy, J. et Schmerl, B., Managing Trade-Offs in Adaptable Software Architectures,1re édition. Morgan Kaufmann, Boston, p. 325 – 352.

[39] Ramirez, A. J. (2008). Design patterns for developing dynamically adaptive systems.Mémoire de maîtrise, Michigan State University.

[40] Ramirez, A. J. et Cheng, B. H. (2010). Design patterns for developing dynamicallyadaptive systems. Dans Proceedings of the 2010 ICSE Workshop on Software Engi-neering for Adaptive and Self-Managing Systems, ACM. p. 49–58.

[41] Rossi, G., Gordillo, S. et Lyardet, F. (2005). Design patterns for context-aware adap-tation. Dans 2005 Symposium on Applications and the Internet Workshops (SAINT2005 Workshops). p. 170–173.

[42] Rushby, J. (2008). Runtime Certification. Springer Berlin Heidelberg, Berlin, Heidel-berg, p. 21–35.

[43] Salehie, M. et Tahvildari, L. (2009). Self-adaptive software : Landscape and researchchallenges. ACM Transactions on Autonomous and Adaptive Systems (TAAS), vo-lume 4, numéro 2, p. 14.

[44] Tamura, G., Villegas, N. M., Müller, H. A., Sousa, J. P., Becker, B., Karsai, G., Man-kovskii, S., Pezzè, M., Schäfer, W., Tahvildari, L. et Wong, K. (2013). Towards Prac-tical Runtime Verification and Validation of Self-Adaptive Software Systems. SpringerBerlin Heidelberg, Berlin, Heidelberg, p. 108–132.

[45] Taylor, R. N., Medvidovic, N., Anderson, K. M., Whitehead Jr, E. J., Robbins, J. E.,Nies, K. A., Oreizy, P. et Dubrow, D. L. (1996). A component-and message-basedarchitectural style for gui software. Software Engineering, IEEE Transactions on,volume 22, numéro 6, p. 390–406.

[46] Villegas, N. M., Müller, H. A., Tamura, G., Duchien, L. et Casallas, R. (2011). Aframework for evaluating quality-driven self-adaptive software systems. Dans Procee-dings of the 6th International Symposium on Software Engineering for Adaptive andSelf-Managing Systems. SEAMS ’11. ACM, New York, NY, USA, p. 80–89.

[47] Weyns, D., Schmerl, B., Grassi, V., Malek, S., Mirandola, R., Prehofer, C., Wuttke,J., Andersson, J., Giese, H. et Göschka, K. M. (2013). On patterns for decentralizedcontrol in self-adaptive systems. Dans Software Engineering for Self-Adaptive SystemsII. Springer, p. 76–107.


[48] Zhang, J. et Cheng, B. H. C. (2006). Model-based development of dynamically adap-tive software. Dans Proceedings of the 28th International Conference on SoftwareEngineering. ICSE ’06. ACM, New York, NY, USA, p. 371–380.

faculté de génie - core.ac.uk · binding, librairie de librairie eﬀectuant un pont vers une...

Documents