N d ordre : 2010telb0166 Sous le sceau de l Université européenne de Bretagne Télécom Bretagne En habilitation conjointe avec l Université de Rennes 1 Ecole Doctorale MATISSE A Model-driven Feature-based Approach to Runtime Adaptation of Distributed Software Architectures Thèse de Doctorat Mention : Informatique Présentée par An Phung-Khac Département : Informatique Equipe : CAMA Directeur de thèse : Antoine Beugnard Soutenue le 15 novembre 2010 Jury : M. Jean-Marc Jézéquel, Professeur, Université Rennes 1 (Président) M. Gordon Blair, Professeur, Lancaster University, UK (Rapporteur) Mme. Laurence Duchien, Professeur, Université Lille 1 (Rapporteur) M. Salah Sadou, Maître de conférences, Université Bretagne Sud (Examinateur) M. Antoine Beugnard, Professeur, Télécom Bretagne (Directeur) M. Jean-Marie Gilliot, Maître de conférences, Télécom Bretagne (Co-encadrant) Mme. Maria-Térésa Segarra, Maître de conférences, Télécom Bretagne (Co-encadrant)
Acknowledgements First and foremost, I would like to sincerely thank my advisors, Antoine Beugnard, Jean-Marie Gilliot, and Maria-Teresa Sagarra, for guiding me at every step throughout my Ph.D., for everything I have learned about research because of them, and for their sense of humour. More than four years ago, I knew nothing about research. Antoine Beugnard picked me up at the old Brest airport at midnight under the typical rain in Brittany, brought me to Telecom Bretagne, introduced me into the research world where I have learned many things. I would like to thank Prof. Laurence Duchien and Prof. Gordon Blair for spending time to review my thesis. Their comments and suggestions helped me to significantly improve my thesis. I would also like to thank my other thesis committee members, Prof. Jean-Marc Jézéquel and Prof. Salah Sadou for examining my thesis. Many thanks to my friends, and particularly to Dang Xuan Ha and Janet Ormerod, for checking English of the manuscript and articles. Thanks to Chantal-Eveline Kaboré and Jean-Baptiste Lézoray for the collaboration and being coauthors. Thanks to Pham Nguyen Cuong, Ali Hassan, Pham Quyet Thang, and Trinh Anh Tuan for interesting discussions. Thanks to all my friends for sharing every moment here in Finistère - the End of the Earth. Thanks to everyone in Département Informatique, particularly to Armelle Lannuzel who helped me with paperwork. Finally, my deepest gratitude goes towards my parents, my wife, and everyone in my big family. They are the ones who support me unconditionally and in every moment, good or bad.
Abstract Runtime software adaptation implies the ability of software systems to change at runtime in order to adapt to operating environments. By a runtime adaptation, an adaptive software system moves from a consistent variant to another one. Developing such a system is difficult due to complex tasks such as building consistent variants and defining adaptation actions that need to be performed to change the running system variant. In the context of distributed software systems, distributed adaptation actions may need to be coordinated, the development thus becomes much more challenging. This thesis proposes an approach to facilitating the development of adaptive distributed applications, called the adaptive medium approach. We particularly address the following challenges: (1) building consistent variants of the application; (2) transferring data between the variants; (3) modeling the modularity, the commonality, and the variability of the variants; (4) supporting automatic adaptation planning; (5) coordinating distributed adaptation actions; and (6) automating the development. In our approach, adaptations are realized by reconfiguring the running application at the level of software components. Adaptation actions such as component additions and removals are performed using reflection technologies supported by underlying component platforms. These actions are planned and executed by an adaptation controller that is externalized from the functional part of the application. On the other hand, the approach relies on a high-level abstraction of the distributed application, which is refined through a process combining (1) model-driven engineering to allow the generation of architectural variants and architectural models of these variants, and (2) system family engineering to enable the management the variants variability. The architectural models and the variability one are then used by the externalized adaptation controller to automatically plan and execute adaptations. Keywords: Software Architecture, Dynamic Adaptation, Model-Driven Engineering, System Family Engineering
Résumé L adaptation dynamique de logiciels définit la capacité des applications de se modifier elles-mêmes en cours d exécution afin de s adapter au contexte. Lors d une adaptation, une application passe alors d une variante à une autre. Le développement d une telle application est difficile du fait de tâches complexes comme la construction des variantes cohérentes et la définition des changements nécessaires pour changer la variante d exécution de l application. Dans le contexte des applications distribuées, les actions distribuées d adaptation doivent de plus être coordonnées, le développement n en est que plus difficile. Cette thèse propose une approche qui facilite le développement des applications distribuées adaptables dynamiquement, appelée l approche médium adaptable. L étude du développement de telles applications nous a amené à nous concentrer sur les verrous suivants : (1) support de la construction des variantes cohérence de l application ; (2) transfert des données entre les variantes de l application lors de l adaptation ; (3) modélisation de la modularité, de la similitude, et de la variabilité des variantes ; (4) planification automatique des adaptations ; (5) coordination des adaptations distribuées ; et (6) automatisation du développement. Dans cette approche, les adaptations sont réalisées en reconfigurant l application au niveau de composants. Les actions d adaptation telles que les ajouts et les enlèvements des composants sont effectuées en utilisant les technologies de réflexion fournies par des plateformes de composants. Ces actions sont planifiées et exécutées par un contrôleur de l adaptation qui est externalisée de la partie fonctionnelle de l application. Par ailleurs, l approche repose sur une abstraction de haut niveau de l application distribuée, qui est raffinée au travers d un processus combinant (1) l ingénierie dirigée par les modèles pour permettre la génération des variantes architecturales et des modèles architecturaux de ces variantes, et (2) l ingénierie des lignes de produits pour permettre la gestion de la variabilité des variantes. Les modèles architecturaux et celui de variabilité sont ensuite utilisés par le contrôleur d adaptation pour planifier et exécuter automatiquement les adaptations. Mots-clés : architecture logicielle, adaptation dynamique, l ingénierie dirigée par les modèles, l ingénierie des lignes de produits
Contents Résumé en français 1 1 Introduction.............................. 1 2 État de l art.............................. 3 2.1 Notions de base........................ 3 2.2 Travaux connexes....................... 4 3 Approche médium adaptable.................... 6 4 Processus de développement des médiums adaptables....... 10 5 Prototype............................... 13 6 Conclusion.............................. 14 1 Introduction 17 1.1 Problem Statement.......................... 17 1.2 Challenges and Key Issues...................... 19 1.2.1 Six Challenges........................ 19 1.2.2 Two Key Issues........................ 21 1.3 Overview of the Solution....................... 22 1.3.1 Adaptive Medium Approach................ 22 1.3.2 Adaptive Medium Development Process.......... 26 1.3.3 Claims............................. 27 1.4 Contributions of the Thesis..................... 28 1.4.1 Contributions of the Adaptive Medium Approach..... 28 1.4.2 Adopted Concepts and Solutions.............. 29 i
ii CONTENTS 1.5 Scope of the Thesis.......................... 29 1.6 Structure of the Thesis........................ 30 2 State of the Art 33 2.1 Chapter Overview.......................... 33 2.2 Software Adaptation......................... 34 2.2.1 Terminologies......................... 34 2.2.2 Software Adaptation and Evolution............ 37 2.2.3 Adaptation Control..................... 38 2.2.3.1 Adaptation Activities............... 38 2.2.3.2 Adaptation Control Architecture......... 40 2.2.4 Architecture-based Adaptation............... 41 2.2.4.1 Software Architecture............... 41 2.2.4.2 Definition of Architecture-based Adaptation.. 41 2.2.4.3 On the Role of Modularity............ 42 2.2.4.4 On the Role of Commonality and Variability.. 43 2.2.5 Distributed Adaptation................... 43 2.2.6 Discussion........................... 44 2.3 Automating Software Development................. 44 2.3.1 Model-Driven Engineering.................. 45 2.3.1.1 Modeling and Model-Driven Engineering.... 45 2.3.1.2 Model-Driven Architecture............ 45 2.3.1.3 Domain-Specific Modeling............ 46 2.3.2 System Family Engineering................. 47 2.3.2.1 Generative Software Development........ 47 2.3.2.2 Domain Engineering and Application Engineering 48 2.3.2.3 Modeling Commonality and Variability..... 49 2.3.2.4 Feature Modeling Method............. 49 2.3.3 Discussion........................... 50 2.4 Related Work in Adaptive Software Development......... 51
CONTENTS iii 2.4.1 A List of Related Approaches................ 52 2.4.2 Supporting Consistent Architectures............ 52 2.4.3 Transferring System State.................. 56 2.4.4 Modeling Commonality and Variability.......... 57 2.4.5 Supporting Automatic Adaptation Planning........ 60 2.4.6 Supporting Distributed Adaptations............ 62 2.4.7 Automating the Development of Adaptive Software.... 64 2.4.8 Limitations of the Related Approaches........... 65 2.5 The Medium Approach........................ 68 2.5.1 The Medium Concept.................... 69 2.5.1.1 Definition...................... 69 2.5.1.2 Examples...................... 70 2.5.2 Medium Refinement..................... 73 2.5.2.1 Medium Refinement Principles.......... 73 2.5.2.2 Modeling and Transformations.......... 75 2.5.2.3 Medium Refinement Process........... 78 2.5.3 Discussion........................... 80 2.6 State-of-the-Art Summary...................... 80 3 Adaptive Medium Approach 81 3.1 Chapter Overview.......................... 81 3.2 The Adaptive Medium Approach.................. 82 3.2.1 Approach Overview..................... 82 3.2.2 Adaptive Medium Development Process.......... 88 3.3 Developing the Adaptation Medium................ 88 3.3.1 Specifying the Adaptation Medium............. 89 3.3.2 Planning and Executing Adaptations............ 93 3.3.3 Discussion........................... 100 3.4 Generating Functional Medium Variants.............. 100 3.4.1 The Generation Overview.................. 101
iv CONTENTS 3.4.2 Architecture View...................... 104 3.4.3 Process View......................... 104 3.4.4 MCV View.......................... 105 3.4.5 Modeling Data Transfer................... 108 3.4.6 Modeling Reconfiguration Constraints........... 110 3.4.7 Discussion........................... 111 3.5 Composing the Adaptive Medium.................. 112 3.5.1 Adaptive Medium Architecture............... 112 3.5.2 Discussion........................... 113 3.6 Approach Summary and Discussion................. 113 3.6.1 Approach Summary..................... 114 3.6.2 Multiple Adaptive Mediums Applications......... 115 3.6.3 Challenges Revisited and Discussion............ 115 4 Adaptive Medium Development Process 119 4.1 Chapter Overview.......................... 119 4.2 Development Process Overview................... 120 4.2.1 Facilities for Developing Adaptive Mediums........ 120 4.2.2 Adaptive Medium Development Activities......... 121 4.3 File Sharing Adaptive Medium................... 123 4.4 Step 1: Specification......................... 124 4.4.1 Specifying the Functional Medium Abstraction...... 125 4.4.2 Specifying the Implementation Architecture........ 126 4.4.3 Identifying Concerns and Solutions............. 126 4.4.4 Summary........................... 134 4.5 Step 2: Transformation....................... 134 4.5.1 Defining Solution Introduction Transformations...... 134 4.5.2 Creating Solution Models.................. 136 4.5.3 Summary........................... 139 4.6 Step 3: Generation.......................... 140
CONTENTS v 4.6.1 Refining the Early MCV Model............... 141 4.6.2 Feature-based Modularization................ 151 4.6.3 Data Transfer Model..................... 156 4.6.4 Medium Reconfiguration Constraints Model........ 158 4.6.5 Defining the Generation Process Model.......... 161 4.6.6 Executing the Main Transformation............ 164 4.6.7 Summary........................... 164 4.7 Step 4: Composition......................... 165 4.8 Adaptation in the Adaptive Medium................ 166 4.8.1 Adaptation Plans....................... 166 4.8.2 Transferring Data...................... 167 4.8.3 Feature-based Adaptation Planning............ 169 4.8.4 Fine-grained Adaptations.................. 169 4.9 Development Process Summary and Discussion.......... 171 4.9.1 Development Process Summary............... 171 4.9.2 Model-Driven Architecture and Feature Modeling..... 172 4.9.3 Discussion........................... 174 5 Prototype 177 5.1 Chapter Overview.......................... 177 5.2 Adaptive Medium Development Framework............ 178 5.2.1 Framework Overview..................... 178 5.2.2 Basic Facility......................... 180 5.2.3 Concern Catalogue...................... 181 5.2.4 Using Basic Facility and Concern Catalogue........ 182 5.2.5 Adaptation Medium Implementations........... 182 5.2.6 Composition Program.................... 183 5.3 An Adaptation Medium Implementation.............. 184 5.3.1 Identifying Concerns and Solutions............. 184 5.3.2 Generating the Adaptation Medium Component Model. 188
vi CONTENTS 5.3.3 Implementing the Adaptation Medium........... 189 5.3.3.1 Fractal Component Model............ 189 5.3.3.2 Adaptation Medium Implementation Architecture190 5.3.3.3 Adaptation Plans................. 194 5.3.3.4 Discussion..................... 197 5.4 Case Study 1: File Sharing Adaptive Medium........... 197 5.4.1 Step 1: Specification..................... 197 5.4.2 Step 2: Transformation................... 198 5.4.3 Step 3: Generation...................... 198 5.4.4 Step 4: Composition..................... 202 5.4.5 Adaptation.......................... 202 5.4.6 Summary........................... 203 5.5 Case Study 2: Reservation Adaptive Medium........... 203 5.5.1 Step 1: Specification..................... 203 5.5.2 Step 2: Transformation................... 207 5.5.3 Step 3: Generation...................... 207 5.5.4 Step 4: Composition..................... 213 5.5.5 Summary........................... 213 5.6 Evaluation............................... 213 5.6.1 Execution Conditions.................... 213 5.6.2 Quantitative Analysis.................... 214 5.6.2.1 Supporting Consistent Architectures....... 214 5.6.2.2 Supporting Data Transfer............. 214 5.6.2.3 Modeling Commonality and Variability..... 214 5.6.2.4 Supporting Automatic Adaptation Planning.. 216 5.6.2.5 Supporting Distributed Adaptation....... 217 5.6.2.6 Automating the Development........... 217 5.6.3 Qualitative Analysis..................... 218 5.7 Prototype Summary and Discussion................ 221
CONTENTS vii 6 Conclusion 223 6.1 Contribution Summary........................ 223 6.2 Limitations.............................. 226 6.3 Perspectives.............................. 228 6.3.1 Improving the Approach................... 228 6.3.2 Generalizing the Approach................. 230 6.3.3 Remark............................ 230 A Publications 233 B Implementation Details 235 2.1 Feature Refinement Transformation................. 235 2.2 Feature-based Adaptation Planning Function........... 235 2.3 Basic Facility Package........................ 235 2.4 Concern Catalogue Package..................... 240 Bibliography 241
viii CONTENTS
List of Figures 1 Approche médium adaptable.................... 7 2 Processus de développement des médiums adaptables....... 11 2.1 Generic control loop model (from [Dobson 06]).......... 39 2.2 External adaptation control (from [Garlan 04]).......... 40 2.3 The MDA pattern (from [OMG 03])................ 46 2.4 Two engineering processes (from [Czarnecki 00])......... 48 2.5 A sample feature model (from [Czarnecki 07])........... 49 2.6 Description of the file sharing application using medium..... 70 2.7 Description of the reservation medium............... 71 2.8 A video conferencing application using several mediums..... 72 2.9 Architecture and process views of the medium refinement.... 74 2.10 Four abstraction levels of the medium............... 76 2.11 An example of transformation.................... 77 3.1 The overall adaptive medium approach............... 83 3.2 The adaptive medium composition target............. 89 3.3 Description of the adaptation medium............... 91 3.4 Adaptation medium model at the high abstraction level..... 92 3.5 Adaptation medium model after introducing managers...... 92 3.6 A view of the adaptation control loop (adapted from [Buisson 06]) 93 3.7 Distributed adaptation execution processes............ 95 3.8 Relations between V1 and V2 on a functional manager instance 96 ix
x LIST OF FIGURES 3.9 Require-constraints between adaptation actions.......... 97 3.10 A meta-model of local adaptation plans.............. 98 3.11 A meta-model of adaptation coordination plans.......... 99 3.12 Overview of the generation of functional medium variants.... 101 3.13 Views of the generation process of functional medium variants.. 103 3.14 Example of global adaptation.................... 105 3.15 Data transfer modeling principle.................. 109 3.16 Adaptive medium architecture................... 113 4.1 Activities in the development process of an adaptive medium.. 122 4.2 Class diagram of the FS medium at level 0............. 125 4.3 Class diagram of the FS medium at level 1............. 127 4.4 Data management concern usage pattern.............. 129 4.5 Early MCV model of the FS medium................ 131 4.6 Early MCV meta-model....................... 133 4.7 Simple data placement solution meta-model............ 135 4.8 Simple data placement models................... 137 4.9 Data annotation meta-model.................... 138 4.10 Solution reconfiguration constraints meta-model.......... 140 4.11 Example of derived solution features................ 143 4.12 Derived affect-constraints...................... 144 4.13 A primitive design concern is affected............... 145 4.14 Multiple affect-constraints...................... 146 4.15 Fine-grained MCV meta-model................... 147 4.16 FS medium fine-grained MCV model................ 150 4.17 Generic medium model at the component-implementation level. 151 4.18 Typical mappings from features to components.......... 154 4.19 A variant of the sharer manager................... 155 4.20 Data transfer meta-model...................... 157 4.21 Extract of the FS medium data transfer model.......... 159
LIST OF FIGURES xi 4.22 Medium reconfiguration constraints meta-model.......... 160 4.23 Design concerns and design solutions for the FS medium..... 162 4.24 Generation process meta-model................... 163 4.25 Component diagram of the adaptive manager........... 165 4.26 Generic structure of adaptation plans............... 167 4.27 An example of data transfer..................... 168 4.28 Relation between MCV model and generation process model... 174 5.1 Tailored transformations....................... 181 5.2 Decomposition of the adaptation medium abstraction...... 185 5.3 Early MCV model of the adaptation medium........... 186 5.4 The model of AMIV1 at the class-implementation level..... 188 5.5 The adaptive manager component structure in Fractal...... 191 5.6 A sequence diagram of the adaptation medium implementation. 193 5.7 Structure of local adaptation plans in AMIV1........... 195 5.8 Structure of adaptation coordination plans............. 196 5.9 Process model for generating file sharing medium variants.... 199 5.10 Two FS medium variants at the component-implementation level 201 5.11 Reservation medium model at the high abstraction level..... 204 5.12 Reservation medium model after introducing managers...... 205 5.13 The reservation medium early MCV model............ 206 5.14 The reservation medium fine-grained MCV model......... 208 5.15 Process model for generating reservation medium variants.... 209 5.16 Component models of three reservation medium variants..... 211 5.17 Comparison of fine-grained and coarse-grained adaptations... 216 B.1 Feature refinement transformation................. 236 B.2 Feature-based adaptation planning function............ 237 B.3 Basic meta-models and transformations in the framework.... 238 B.4 Meta-models and transformations in the concern catalogue... 240
xii LIST OF FIGURES
List of Tables 2.1 Related approaches to developing adaptive software....... 51 3.1 Adaptive medium approach summary............... 117 5.1 Elements in the adaptive medium development process...... 179 5.2 Adaptation time of fine-grained adaptations............ 215 5.3 Kept, removed, and added components............... 215 5.4 Generated adaptation plans and their elements.......... 217 5.5 User-defined and generated elements................ 218 5.6 Adaptive medium approach evaluation.............. 219 xiii
xiv LIST OF TABLES
Résumé en français Sommaire 1 Introduction....................... 1 2 État de l art........................ 3 3 Approche médium adaptable............. 6 4 Processus de développement des médiums adaptables 10 5 Prototype......................... 13 6 Conclusion........................ 14 1 Introduction Les applications informatiques sont omniprésentes dans notre environnement. Celles-ci doivent désormais pouvoir fonctionner sans s interrompre dans des contextes très variables, et cela, dans l idéal, même si une modification de structure interne est requise. Ce contexte variable comprend aussi bien des dispositifs et des réseaux que le comportement de l environnement et de l utilisateur. On parle ainsi d adaptation dynamique pour caractériser les applications pouvant changer leur comportement à l exécution en s adaptant au contexte d exécution courant. Plusieurs travaux récents proposent des approches dédiées au développement de telles applications. Cependant, ces approches n englobent pas encore la complexité du développement d une application adaptative, particulièrement lorsqu elles sont distribuées, et de nombreuses tâches délicates restent encore à la charge des développeurs. Nous avons identifié six verrous qui résument cette complexité dans le contexte du développement d applications distribuées : V1 - Supporter la cohérence des variantes : Dans une adaptation, une application remplace sa variante courante d exécution par une autre variante. Ces variantes doivent être cohérentes, c est-à-dire que l application doit continuer à fonctionner correctement après l adaptation. 1
2 Résumé en français V2 - Transférer l état : Une adaptation réussie doit permettre le transfert d état de la variante remplacée à la variante remplaçante. V3 - Modéliser la modularité, la similitude et la variabilité : Afin de remplacer de manière plus fine la variante courante par une autre variante, l application doit pouvoir conserver les parties communes aux deux variantes et remplacer uniquement les parties différentes de celles-ci. À cette fin, la modularité, la similitude et la variabilité des variantes doivent être explicitement modélisées. V4 - Automatiser la planification de l adaptation : L application doit pouvoir planifier automatiquement ses adaptations. L ensemble des actions d adaptation qui permettent de modifier l application et de transférer l état doit être défini automatiquement. V5 - Supporter des adaptations distribuées : Une adaptation distribuée se décompose en plusieurs processus distribués pour gérer l adaptation sur les différents sites. Ce type d adaptation est difficile car elle nécessite la coordination des processus distribués et le transfert de l état entre les sites. V6 - Automatiser le processus de développement : Un processus de développement d applications adaptatives permettant de gérer les verrous précédents est nécéssairement complexe. L automatisation d un tel processus est donc indispensable. Nous proposons dans le cadre de ce travail une approche appelée médium adaptable qui permet de relever ces différents verrous. L approche est élaborée en se basant sur deux principes : P1 - Une abstraction de haut niveau : L application adaptable est spécifiée à un haut niveau d abstraction, permettant d intégrer l aspect de distribution. Cette abstraction de l application peut ainsi être utilisée pour guider la construction des variantes, modéliser la modularité, la similitude et la variabilité, et également les informations utiles à la planification des adaptations comme les contraintes sur les actions d adaptation et les opérations de transfert de données. P2 - Un processus automatisé : Les tâches sont partiellement automatisées grâce à l ingénierie dirigée par les modèles. Ces deux principes d abstraction et d automatisation ont déjà fait l objet de travaux au sein de notre équipe. Nous étendons ainsi l abstraction d application distribuée appelée médium définie par Eric Cariou [Cariou 03] pour construire une abstraction d application distribuée adaptable appelée médium adaptable. Le processus de raffinement de médiums proposé par Evelyne Kabore
2. État de l art 3 [Kaboré 08a] est également repris en introduisant 1) la modélisation de la modularité, de la similitude et de la variabilité des différentes variantes de médium, 2) la modélisation du transfert de données entre les variantes, et 3) la modélisation des contraintes entre les actions d adaptation. L ajout de ces modèles permet de préciser le processus de raffinement de différentes variantes, l automatisation de la génération de ces variantes ainsi que les liens entre celles-ci, ce qui permet de générer des plans d adaptation nécessaires. Le reste de ce document est organisé comme suit. La section 2 résume les travaux connexes. La section 3 décrit l approche médium adaptable. La section 4 formule un processus de développement des médiums adaptables. La section 5 présente un prototype du framework dédié au processus. Enfin, la section 6 conclut le document. 2 État de l art Dans cette section, nous présentons quelques notions de base, puis nous effectuons une revue de travaux connexes. 2.1 Notions de base Nous réumons ici quelques notions clés autour de l adaptation dyanmique pour mieux préciser le cadre de ce travail. Adaptation dynamique L adaptation dynamique est la capacité des applications à se modifier ellesmêmes pendant leur exécution afin de s adapter aux changements de contexte [Oreizy 99]. Par rapport à l adaptation statique dans laquelle les applications sont arrêtées et recompilées afin d intégrer des modifications, l adaptation dynamique permet d augmenter la disponibilité des applications et de réduire le coût d exploitation des adaptations. Activités de contrôle d adaptation Dans une application adaptable, les activités de contrôle d adaptation comprennent typiquement l observation des changements du contexte et de l état de l application, la décision d adaptation en fonction de ces observations, la planification des actions d adaptation à réaliser, et finalement l exécution de ces actions [Buisson 06].
4 Résumé en français Adaptation distribuée Dans une application distribuée, une adaptation peut comprendre des actions distribuées. Une telle adaptation est appelée une adaptation distribuée. Elle est plus difficile qu une adaptation locale car les actions distribuées doivent être exécutées de manière coordonnée pour en assurer la cohérence. Adaptation architecturale Une adaptation qui réalise des modifications au niveau de l architecture de l application est appelée adaptation architecturale. Dans cette thèse, nous considérons que l architecture logicielle d une application est une structure de composants et d interactions entre ces composants. Une adaptation architecturale est alors réalisée par des modifications au niveau des composants de l application et de leurs liaisons. L adaptation architecturale permet ainsi d exploiter les modèles architecturaux décrivant l architecture de l application afin de surveiller et d adapter l application [Garlan 04]. 2.2 Travaux connexes Nous avons étudié nombre d approches de développement des applications adaptables, et nous avons fait le choix de les présenter selon les verrous identifiés dans la section 1. Supporter la cohérence des variantes La cohérence des variantes d une application adaptable peut être supportée soit par construction des variantes, par vérification de celles-ci, ou par vérification des actions d adaptation. Les approches existantes proposent ainsi des langages de description d architecture (ADL) [Magee 95, Oquendo 04], des langages dédiés (DSL) [Bencomo 08a], ou des styles architecturaux [Oreizy 99, Garlan 04, Oquendo 04]. Dans ce cadre, les développeurs d applications adaptables, i.e., les utilisateurs de ces approches, sont amenés à manipuler des abstractions de bas niveau liées aux éléments physiques tels que les composants, les connecteurs ou les objets, et à devoir en assurer la cohérence. La qualité de celle-ci dépend alors directement de leur niveau de compétence. Transférer l état Quelques approches permettent de prendre en compte le transfert d état
2. État de l art 5 entre variantes. Cependant, les fonctions de transfert des données nécessitent souvent un prise en charge manuelle par le développeur [Lee 06, Geihs 09]. Modéliser la modularité, la similitude et la variabilité Pour pouvoir affiner le changement entre variantes, il est nécessaire de pouvoir décomposer l applicaton en sous-modules. Le terme «modularité» renvoie donc à cet aspect de séparation. Dans ce cadre, il est alors nécessaire de pouvoir identifier explicitement les éléments à conserver et ceux à échanger, les termes «similitude» et «variabilité» renvoient à l identification des modules différents (resp. communs) des variantes de l application. La séparation des préoccupations et l ingénierie logicielle à base de composants sont des approches importantes pour supporter la modularité logicielle. Les préoccupations d une application sont séparées, puis réifiées au travers de modules appelés composants logiciels. Plusieurs modèles de composants ont ainsi été proposés, notamment CCM, COM et Fractal. Dans certains cas, il n est pas possible de décliner des préoccupations en composants, par exemple pour cause d inter-croisement de préoccupations. La technologie des aspects (AOP) propose alors une alternative pour assurer la séparation au travers d aspects qui seront tissés dans l application désirée [Kiczales 97, Pessemier 08]. Malgré tout, les chercheurs dans ce domaine n ont pas encore résolu des verrous tels que l interaction entre aspects. Le problème de la modularité n est donc pas encore complètement résolu. La variabilité est une notion importante dans le domaine des lignes de produits. En considérant les variantes d une application adaptable comme les membres d une ligne de produits, des approches de modélisation de la variabilité dans ce domaine peuvent être utilisées pour modéliser les applications adaptables. Les exemples comprennent la modélisation des features [Lee 06, Morin 09a, Cetina 09] ou le modèle orthogonal de variabilité [Bencomo 08a]. Cependant, ces approches supposent que les features peuvent être directement liés aux composants ou aux aspects. Le cas général où les aspects ou composants ne pourraient pas séparés n est donc pas pris en compte. Autrement dit, ces approches n abordent pas la modularité dans sa globalité. Automatiser la planification d adaptation Quelques approches supportent la planification d adaptation en utilisant les informations de développement. Les plans d adaptation peuvent ainsi être générés en comparant les configurations de features [Cetina 09] ou les modèles architecturaux [Garlan 04, Bencomo 08a]. Cependant, dans ces approches, les liens entre leurs éléments et les composants logiciels sont définis manuellement.
6 Résumé en français La correction des plans revient donc aux développeurs. Supporter des adaptations distribuées L adaptation distribuée est particulièrement difficile de par la nécessité d assurer la coordination des actions distribuées. Ce problème est abordé dans quelques approches telles qu ACEEL [Chefrour 05] et CACTUS [Chen 01]. Cependant, dans ces approches, la coordination des actions distribuées est basée sur une politique de coordination définie par les développeurs. Or, la définition d une telle politique reste une tâche difficile. Automatiser le processus de développement Le développement d une application adaptable peut être partiellement automatisé en faisant appel à l ingénierie dirigée par les modèles et/ou à des technologies de lignes de produits [Oquendo 04, Bencomo 08a]. Dans ce contexte, la génération de code et la réutilisation des artefacts logiciels tels que les composants sont adoptées. Cependant, le niveau d automatisation reste insuffisant. En effet les développeurs doivent spécifier l application adaptable au niveau d abstraction de composants physiques et donc gérer eux-mêmes l architecture distribuée. Conclusion La spécification à un haut niveau d abstraction des applications adaptables apparait comme une approche prometteuse pour dépasser les limitations des approches existantes. Le raffinement au niveau des composants physiques peut alors s intégrer au processus et ainsi être automatisée. Ce sont les points-clés de l approche de médium adaptable [Phung-Khac 08, Phung-Khac 10]. 3 Approche médium adaptable La figure 1 décrit le principe de l approche de médium adaptable, qui s articule autour d une abstraction de haut niveau, du raffinement, et de la composition au niveau de l implémentation. L abstraction de haut niveau L abstraction de haut niveau retenue dans le cadre de notre approche pour spécifier une application adaptable est le médium - une abstraction de communication dédiée aux applications distribuées [Cariou 03].
3. Approche médium adaptable 7 Médium adaptable (Haut niveau d abstraction) Composant client x Médium d adaptation? 1 adapter surveiller 1? Médium fonctionnel y Raffinement Raffinement x y x y Variante 1 Variante m distribuée * Variante 1 centralisée * 1 Variante n Modèles architecturaux Modèles facilitant l adaptation embaqués dans x Composition Médium adaptable avec le contrôle centralisé d adaptation (Niveau d implémentation) y Composants physiques Entité logique, agrégation des entités physiques Entité logique, une abstraction Lien abstrait Lien physique à distance Lien physique local Fig. 1 Approche médium adaptable
8 Résumé en français Un médium est une abstraction de la communication fonctionnelle distribuée dans une application. L application est donc spécifiée comme une interconnexion d un médium et des composants clients. Au niveau de l implémentation, l abstraction est réifiée par une agrégation des composants physiques appelés des gestionnaires. Cette agrégation est appelée le médium au niveau d implémentation. En utilisant le médium, l application adaptable est spécifiée comme une interconnexion d un médium adaptable et de quelques composants clients. Comme le montre la figure 1, le médium adaptable en tant qu abstraction se compose de deux parties : le médium fonctionnel et le médium d adaptation. Tandis que le premier encapsule la partie fonctionnelle distribuée de l application, le second encapsule les fonctionnalités permettant l adaptation ainsi que la coordination des actions distribuées utilisées pour reconfigurer le premier. Ainsi, le médium d adaptation utilise les modèles architecturaux des variantes du médium fonctionnel pour adapter le médium fonctionnel lors de son exécution. La génération des variantes du médium fonctionnel Le médium fonctionnel en tant qu abstraction est raffiné au niveau de l implémentation en utilisant le processus de raffinement de médium [Kaboré 08a]. Ce processus est construit en identifiant dans un premier temps une suite de préoccupations. Pour chaque préoccupation, une transformation est définie. Cette transformation permet d introduire une solution à la préoccupation dans le médium, et de le rendre ainsi plus concret à chaque étape. À cette fin, un métamodèle de solution et deux méta-modèles de médium sont définis (appelés métamodèles de médium source et cible). La transformation introduit donc un modèle de solution conforme au méta-modèle de solution dans un modèle de médium de source conforme au méta-modèle de médium de source, et puis, génère un modèle de médium de cible. En définissant pour chaque préoccupation plusieurs solutions différentes, il est ainsi possible, grâce au processus de raffinement, de générer des variantes différentes du médium au niveau de son implémentation. Chaque variante d implémentation est alors une agrégation des gestionnaires fonctionnels. En vue de gérer finement les différentes variantes et leurs transitions, nous étendons le processus de raffinement de médium en ajoutant trois modèles : Le modèle de modularité, de similitude et de variabilité : Ce modèle est une extension d un modèle de features [Kang 90, Czarnecki 00]. Dans ce modèle, les préoccupations et leurs solutions sont représentées comme des features. Les solutions pour une préoccupation sont représentées comme un groupe de features attaché au feature représentant cette préoccupation. Ce modèle permet donc de décrire les variantes, la similitude et la varia-
3. Approche médium adaptable 9 bilité entre variantes. En outre, nous introduisons la notion de «feature concret» et les «contraintes d affectation» afin de représenter la modularité de ces variantes. Grâce à ce modèle, les variantes de médium au niveau de l implémentation peuvent automatiquement être modularisées en composants. Le modèle de transfert de données : Ce modèle décrit comment les données sont transférées entre les variantes de médium lors d une adaptation. Pour cela, il décrit comment les données gérées par un ensemble de composants correspondant à une solution sont transférées à un autre ensemble de composants correspondant à une autre solution de la même préoccupation. Ce modèle est automatiquement généré en collectant les modèles d annotation de données correspondant aux préoccupations. Le modèle de contraintes de reconfiguration de médium : Ce modèle décrit l ordre des actions d adaptation. Il est également généré automatiquement à partir des modèles de contraintes de reconfiguration de solution. Les trois modèles ci-dessus permettent de décrire la modularité, la simiilitude et la variabilité des variantes, les opérations nécessaires pour transférer les données entre les variantes, et les contraintes entre les actions d adaptation. Ces modèles, ainsi que les modèles architecturaux des variantes sont utilisés pour planifier dynamiquement les adaptations du médium fonctionnel. Le développement du médium d adaptation Le médium d adaptation peut également être développé en utilisant le processus de raffinement de médium. Cependant, ce développement reste ouvert, dans le sens où nous n avons pas proposé de processus complet de développement d un tel médium dans le cadre de cette thèse. Nous proposons simplement le modèle abstrait d entrée et un modèle unique au niveau de l implémentation, ce qui permet incidemment de montrer qu un médium d adaptation peut être réutilisé pour plusieurs médiums fonctionnels différents. Au niveau de l implémentation, le médium d adaptation est une agrégation des composants physiques appelés des gestionnaires d adaptation. Lors de l exécution, un gestionnaire d adaptation reconfigure localement un gestionnaire fonctionnel en fonction d un plan local d adaptation décrivant les actions locales d adaptation. La coordination des actions distribuées est décrite dans un plan de coordination. À cette fin, nous proposons également un modèle d adaptation distribuée. Une telle adaptation appelée aussi processus global d adaptation se décompose en différents processus locaux d adaptation. Six étapes d adaptation sont identifiées : arrêter les services du médium fonctionnel, créer les composants rem-
10 Résumé en français plaçants, initialiser les composants remplaçants, transférer les données, enlever les composants remplacés, et redémarrer les services du médium fonctionnel. Nous proposons aussi un méta-modèle de plan d adaptation local et un métamodèle de plan de coordination. La composition du médium adaptable Le médium adaptable au niveau de l implémentation est composé d une variante du médium fonctionnel et d une variante du médium d adaptation. Tandis que le premier est la variante initiale et sera remplacée par une autre variante pendant l exécution afin d adapter le médium fonctionnel au contexte d exécution, le second est stable et sert de plateforme de contrôle d adaptation. À ce niveau d implémentation, le médium adaptable est une agrégation des gestionnaires adaptables, chacun se composant d un d un gestionnaire fonctionnel et d un gestionnaire d adaptation. Le médium d adaptation embarque les différents modèles nécessaires à la planification dynamique des adaptations, à savoir les modèles architecturaux des variantes du médium fonctionnel, le modèle de la modularité et la variabilité des variantes, ainsi que le modèle de transfert de données, et le modèle de contraintes de reconfiguration du médium. 4 Processus de développement des médiums adaptables Le processus de développement permet de raffiner l abstraction de haut niveau et d assurer la composition finale permettant le déploiement. La figure 2 décrit le processus de développement des médiums adaptables. Nous y avons identifié quatre rôles différents pour les développeurs, correspondant à des métiers différents et permettant de bien mettre en exergue les éléments du processus sur lesquels il est possible de capitaliser pour promouvoir la réutilisation. Quatre étapes du développement sont retenues permettant de mettre en évidence les collaborations entre ces différents rôles. Les rôles des développeurs Pour mettre en avant les différents aspects du processus de développement, nous avons retenu quatre rôles pour les développeurs participant au processus de développement d un médium adaptable : l expert de médium, le concepteur de solutions, le concepteur de processus, et le concepteur d application. Les tâches de l expert de médium et du concepteur de solutions concernent principalement les aspects d ingénierie de domaine du processus, c est-à-dire
4. Processus de développement des médiums adaptables 11 Expert de médium Ingénierie de domaine Concepteur de solutions Concepteur de processus Ingénierie d application Concepteur d application Générer le médium niveau 1 Identifier le médium niveau 0 Etape 1: Spécification Catalogue préserver réutiliser Identifier les préoc. et les solutions en définissant un modèle MSV-initial Identifier les variantes de médium Non Valider Oui Etape 2: Transformation Pour une préoc.: Définir 1 transformation Définir 1 métamodèle de solution Définir 2 métamodèles de médium Définir 1 métamodèle de décision Pour une solution: Définir un modèle de solution Définir un modèle de contr. de reconf. de solution Ajouter des infos au modèle d annotation de données Oui Oui Nouvelles préoc.? Non Nouvelles solutions? Non Etape 3: Génération Identifier les contraintes des features et les features concrètes Générer un modèle MSV-raffiné Définir un modèle de processus Générer les variantes niveau 4, 1 modèle de transfert de données, 1 modèle de contr. de reconf. de médium Etape 4: Composition Composer le médium adaptable Fig. 2 Processus de développement des médiums adaptables
12 Résumé en français les aspects de développement concernant la réutilisation et la capitalisation. Ils définissent des modèles génériques, tant au niveau du processus que des éléments de solutions correspondant aux différentes préoccupations. Le concepteur de processus et le concepteur d application se péoccupent quant à eux des aspects d ingénierie d application du processus. Ainsi le premier propose un processus sous forme de suites de préoccupations correspondant à un type d application donné, et sélectionne les variants pertinentes. Le second se concentre sur le développement d un médium adaptable pour une application donnée. Les étapes du processus Comme indiqué sur la figure 2, le processus se décompose en quatre étapes : spécification, transformation, génération, et composition. Spécification : Le concepteur d application commence par définir le modèle de médium fonctionnel souhaité au niveau d abstraction le plus haut. Le concepteur de processus dérive un modèle de médium fonctionnel plus concret dans lequel les gestionnaires abstraits sont introduits, en utilisant une transformation initiale. À partir de là, le concepteur de processus et le concepteur d application identifient les préoccupations et les solutions auxquelles ils s intéressent. Ces préoccupations et solutions sont décrites par un modèle de modularité, de similitude et de variabilité (appelé «MSV-initial»). Les préoccupations et solutions sont identifiées à partir d un catalogue des préoccupations réutilisables. Transformation : Cette étape permet de compléter éventuellement le catalogue des préoccupations et solutions disponibles. Si une préoccupation identifiée n existe pas dans le catalogue, l expert de médium doit alors définir un méta-modèle de solution, deux méta-modèles de médium et implémenter une nouvelle transformation. Il définit également un métamodèle de décision qui permet de paramétrer la transformation. L ajout de solution dans le catalogue, que ce soit suite à l ajout d une nouvelle préoccupation ou pour élargir les options d une préoccupation existante est réalisé par le concepteur de solution qui définit le nouveau modèle de solution, et ajoute les opérations de transfert de données de ce modèle de solution selon le modèle d annotation de données correspondant à la préoccupation. Il définit également le modèle de contraintes de reconfiguration de la solution. Génération : Les préoccupations et les solutions candidates étant identifiées et disponibles, le concepteur de processus identifie les features concrètes et les contraintes entre les features. Il utilise ensuite une transformation pour raffiner le modèle MSV-initial issu de la spécification. Le résultat est un modèle qui précise la modularité et la variabilité des
5. Prototype 13 variantes du médium fonctionnel, appelé le modèle «MSV-raffiné». Le concepteur de processus définit alors un modèle de processus qui décrit l ordre d exécution des transformations pour générer les variantes. Finalement, il utilise une transformation pour générer ces variantes au niveau de l implémentation où les composants sont décrits. Ces composants sont reliés aux caractéristiques du modèle MSV-raffiné. Un modèle de transfert de données et un modèle de contraintes de reconfiguration de médium sont aussi générés par cette transformation, pour permettre la réalisation de l adaptation dynamique. Composition : Le concepteur d application choisit une variante de medium d adaptation et une variante initiale pour le médium fonctionnel. Il utilise alors un programme de composition pour construire le médium adaptable au niveau de l implémentation. L organisation des rôles et des étapes présentées ci-dessus permet de clarifier le développement des médiums adaptables. Cette organisation permet, de plus, d augmenter le niveau de réutilisation et, ainsi, d augmenter progressivement le niveau d automatisation du processus de développement des médiums adaptables. 5 Prototype Nous avons construit un prototype du framework de développement des médiums adaptables, intégrant un ensemble de fonctionnalités de base permettant la mise en œuvre du processus de développement, une variante du médium d adaptation, et un programme de composition. L ensemble des fonctionnalités de base : Il comprend les méta-modèles et les transformations utilisés pour générer les variantes de tout médium. Il intègre notamment les méta-modèles de médium aux différents niveaux d abstraction, un méta-modèle de MSV-initial, un méta-modèle de MSVraffiné, un méta-modèle de processus, un méta-modèle d annotation de données et un méta-modèle de contraintes de reconfiguration. Ces métamodèles sont utilisés par les transformations suivantes : une transformation d introduction des gestionnaires, une transformation de raffinement de modèle MSV-initial, une transformation de modularisation et une transformation principale qui exécute le modèle de processus. Les méta-modèles et les transformations sont définis en utilisant le canevas de méta-modélisation Kermeta [Triskell]. Une variante du médium d adaptation : Le modèle d implémentation de cette variante a été généré en utilisant les fonctionnalités de base définies
14 Résumé en français précédemment. Les langages cibles sont Java et Fractal [Bruneton 06]. Le programme de composition : Ce programme est développé en Java. La composition est réalisée de manière directe, en utilisant l ADL de Fractal et l implémentation Julia [Bruneton 06]. Ce prototype a été utilisé pour développer deux médiums adaptables : un médium adaptable de réservation de sièges et un de partage de fichiers. Des scénarios d adaptation ont été déployés pour pouvoir valider l approche. 6 Conclusion Contributions Dans cette thèse, nous proposons une approche de développement des applications distribuées adaptables, appelée l approche médium adaptable. Une application distribuée adaptable y est d abord spécifiée à un haut niveau d abstraction en utilisant une abstraction appelée le médium adaptable. L aspect fonctionnel et l aspect d adaptation sont séparés à ce niveau abstrait sous forme de deux abstractions appelées respectivement médium fonctionnel et médium d adaptation. Nous utilisons ensuite un processus de raffinement pour générer des variantes d implémentation de chaque médium. Finalement, le médium adaptable au niveau d implémentation est composé à partir d une variante du médium fonctionnel et d une variante du médium d adaptation. Alors que la variante du médium fonctionnel peut être remplacée par une autre variante lors de son exécution afin de l adapter au contexte d exécution, la variante du médium d adaptation est stable et sert d infrastructure de contrôle d adaptation. Afin d adapter le médium fonctionnel, le médium d adaptation utilise des modèles originaux d architecture de variantes du médium fonctionnel, un modèle de modularité, de similitude et de variabilité de ces variantes, un modèle de transfert de données entre ces variantes, et un modèle de contraintes de reconfiguration. Ces modèles sont automatiquement générés par le processus de raffinement de médium. Grâce à l abstraction de haut niveau, au processus de raffinement basé sur les techniques de modèles et la modélisation des features, à la modélisation de transfert de données, et à la modélisation des contraintes de reconfiguration, l approche médium adaptable permet de résoudre les six verrous identifiés dans la section 1.