Le logiciel est devenu, de nos jours, un élément central et omniprésent dans des domaines aussi variés que l’économie, l’industrie, le domaine médical, l’automobile ou encore l’administration. Il ne représente plus seulement la part technique et marginale des systèmes, mais est devenu le cœur de fonctionnement et l’intelligence qui contrôle les systèmes modernes. Ainsi, les systèmes logiciels actuels réalisent des services très divers et ont acquis une importance telle que les fonctionnalités qu’ils offrent constituent leur valeur ajoutée et représentent leurs caractéristiques majeurs et discriminantes. Compte tenu de cette utilisation répandue et intensive, les contraintes sur les systèmes logiciels sont de plus en plus fortes. Ils doivent offrir de plus en plus vite des fonctionnalités de plus en plus riches ; celles-ci doivent satisfaire à des exigences en terme de qualité ; les systèmes ont aussi une durée de vie plus longue et ils doivent donc régulièrement évoluer pour répondre à de nouveaux besoins et convenir à des contextes d’utilisation de plus en plus variés (distribution, hétérogénéité, etc.). Toutes ces contraintes ont pour conséquence directe d’augmenter radicalement la taille et la complexité des systèmes logiciels, et d’introduire une pression supplémentaire sur les délais ainsi que sur les coûts de développement et de maintenance.

Pour maîtriser la construction et l’évolution des systèmes logiciels, le génie logiciel propose continuellement divers principes, méthodes et techniques ayant pour objectif final de produire, dans une approche systématique, du logiciel de qualité élaboré en respectant les contraintes de délais et de coûts et qui satisfasse aux besoins des utilisateurs finaux. Pour répondre à cet objectif, le développement logiciel doit, en particulier, faire face à deux défis majeurs que sont l’augmentation croissante de la complexité des systèmes et le besoin croissant de les adapter à leur environnement ainsi qu’à de nouveaux besoins. Les techniques de génie logiciel sont donc contraintes à évoluer sans cesse pour permettre de maîtriser cette complexité et d’offrir une certaine capacité d’adaptation. Cette évolution se fait notamment en introduisant de nouvelles abstractions à divers niveaux (langages, plates-formes, architectures, etc.), tout en continuant à s’appuyer sur des notions fortes déjà existantes telles que la réutilisation [McIlroy 1968] et la modularisation [Parnas 1972].

Dans cette perspective, le génie logiciel à composants [Heineman et Councill 2001; Szyperski 2002] a récemment été mis en avant comme étant une approche pertinente qui applique ces principes et promet a priori une gestion plus efficace de la complexité, une réduction significative des temps/coûts de développement ainsi qu’une productivité accrue [Brown 2000]. Dans cette approche, les composants encapsulent des fonctionnalités bien définies, et exposent clairement des interfaces fournies et requises qui décrivent les fonctionnalités qu’ils fournissent et requièrent. Ils représentent alors des briques fonctionnellement unitaires aux dépendances explicites et fortement réutilisables. Ces composants préalablement développés peuvent alors être assemblés pour construire, de façon incrémentale, des systèmes logiciels plus larges. De plus, de nouvelles fonctionnalités sont apportées ou retirées des systèmes en les reconfigurant, par exemple, par des ajouts ou retraits de composants, et des modifications de leurs connexions.

Comme l’approche par composants contribue à rendre plus explicite la structure des systèmes logiciels au travers des composants, elle entretient des liens très étroits et complémentaires avec l’architecture des systèmes [Bass et al. 1998]. Cette dernière discipline se concentre, à un niveau général, sur la description de l’organisation et de la structure des systèmes (unités, propriétés visibles, relations, etc.) et intervient surtout dans les premières phases de développement pour évaluer la satisfaction aux exigences. L’approche par composants s’efforce de prolonger et de maintenir l’architecture des systèmes aussi lors des phases de déploiement et d’exécution. Ainsi, dans les systèmes à composants avancés, les composants et la structure des systèmes restent explicites aussi à l’exécution, et l’approche par composants maintient donc un continuum d’architecture entre les différentes phases du cycle de vie des systèmes (développement, déploiement, configuration, exécution, reconfiguration). De plus, ils autorisent aussi maintenant les compositions hiérarchiques de composants (des composants peuvent être assemblés récursivement pour former un autre composant) [Bruneton et al. 2006], et offrent aussi des capacités réflexives (introspection et intercession) de plus en plus étendues [Kon et al. 2000; Coulson et al. 2002; Bruneton et al. 2006].

L’approche à composants est appliquée de façon répandue et avec succès à la fois dans les milieux académique et industriel, et de nombreuses technologies à composants, se situant à différents niveaux d’abstraction et couvrant un large spectre de classes d’applications (systèmes d’exploitation, systèmes embarqués, intergiciels, etc.) ont été proposées pour soutenir le développement par composants. Toutefois, le génie logiciel à composants n’a pas encore complètement réussi. Les attentes restent fortes et de nombreux défis doivent encore être résolus. En particulier, alors que les aspects fonctionnels des composants et des systèmes sont par nature plutôt clairement spécifiés au travers des interfaces fournies et requises, tous les aspects autour des caractéristiques extrafonctionnelles des composants ne sont pas encore complètement résolus, et un verrou majeur réside notamment dans le manque de support pour gérer les aspects extrafonctionnels des composants. Ces aspects extrafonctionnels ne concernent pas directement les services fournis et requis des composants mais décrivent plutôt d’une façon très générale les qualités des systèmes et les conditions dans lesquelles les fonctionnalités sont rendues. En outre, comme ils sont définis simplement par opposition aux aspects fonctionnels, les aspects extrafonctionnels sont réellement divers, et un premier problème apparaît donc dans l’existence de définitions à la fois nombreuses et souvent imprécises. Dans la pratique, ces aspects sont considérés de façon très variée ; ils peuvent être abordés selon différents points de vue, et différents degrés d’importance peuvent aussi leur être accordés. Par exemple, du point de vue d’utilisateurs finaux, des exemples de propriétés extrafonctionnelles importantes sont représentées par des qualités générales des systèmes telles que la simplicité d’installation, la facilité d’utilisation ou encore un bon comportement attendu. D’autres propriétés extrafonctionnelles cette fois-ci pertinentes du point de vue du fonctionnement des systèmes, décrivent par exemple la robustesse, la consommation en ressources ou encore la qualité des services rendus [Barbacci et al. 1995]. En conséquence, en plus de la réalisation stricte des services, les propriétés extrafonctionnelles des systèmes logiciels actuels sont devenues de première importance et constituent un critère de différenciation à fonctionnalités équivalentes.

Comme discuté précédemment, tout système logiciel à partir d’une certaine taille fait nécessairement intervenir diverses propriétés extrafonctionnelles. En même temps que les fonctionnalités des systèmes s’enrichissent, les aspects extrafonctionnels des systèmes doivent être mieux couverts et pris en compte afin de toujours satisfaire les besoins des utilisateurs et les qualités de fonctionnement des systèmes. Par ailleurs, comme les propriétés extrafonctionnelles sont très diverses, couvrent tout le cycle de vie des systèmes et que ce dernier tend justement à s’allonger, les propriétés extrafonctionnelles doivent aussi être mises en relation selon ce même cycle de vie. En particulier, elles doivent être prises en compte le plus tôt possible ; elles doivent évoluer avec les besoins, les utilisations et les contextes d’exploitation des systèmes, et elles doivent être gérées de différentes manières en fonction des phases du cycle de vie (déploiement, configuration, exécution, etc.). Dans ce contexte, deux problématiques liées à la gestion des propriétés extrafonctionnelles se posent. Il est important de pouvoir définir et identifier les propriétés extrafonctionnelles mises en jeu. Lorsque ces dernières sont mal ou très faiblement connues, il devient très difficile d’avoir une idée précise des comportements généraux des systèmes et des niveaux de qualités résultants, et cela a pour conséquence de limiter le niveau de confiance que l’on peut leur accorder (mauvaises utilisations, erreurs, comportements inattendus,…). De plus, comme de nombreuses propriétés extrafonctionnelles sont relatives au comportement des systèmes à l’exécution et qu’elles varient lors de celle-ci, il est primordial de pouvoir maintenir des niveaux de qualités acceptables malgré les fluctuations dans le fonctionnement ou l’environnement des systèmes. De telles fluctuations sont par exemple des variations de ressources (mémoire, processeur, etc.), des variations d’environnement (environnements de déploiement, plates-formes hétérogènes, etc.), des changements de mode de fonctionnement, etc. La gestion des propriétés extrafonctionnelles à l’exécution est importante de fait puisque ces propriétés ont un impact particulier sur la qualité des services rendus par le système et visibles à l’exécution par les utilisateurs finaux. De plus, comme la tendance actuelle est aussi d’offrir des systèmes qui fonctionnent en continu et doivent maintenir des services hautement disponibles, cette phase d’exécution des systèmes acquiert une place encore plus importante dans son cycle de vie. Pour maintenir des niveaux de qualités attendus, des approches classiques, surtout issus des travaux dans le domaine de la construction fiable de systèmes ou des télécommunications et réseaux, proposent de garantir un certain niveau de qualité par construction des systèmes ou par dimensionnement des ressources de l’environnement d’exécution. Parallèlement à ces approches, et devant le constat que toutes les propriétés ne peuvent pas être complètement modélisées et garanties avant l’exécution des systèmes, de nombreux axes de recherche se sont aussi développés autour de l’adaptation des systèmes lors de leur exécution. L’adaptation dynamique représente la capacité de modifier le comportement de sousparties d’un système lors de son exécution. Par exemple, cela peut-être motivé par le besoin de modifier une partie d’un système pour introduire de nouvelles fonctionnalités, ou pour ce qui concerne plus notre cadre d’étude, par la nécessité de faire évoluer et reconfigurer des systèmes qui fonctionnent en continu en réponse à de nouveaux besoins (utilisateurs, applications, etc.) ou des changements d’environnement (ressources, niveaux de services, etc.). Les systèmes adaptatifs se déclinent entre autres en deux sous-classes selon qu’ils soient adaptables ou auto-adaptatifs. Les systèmes adaptables fournissent des moyens qui permettent uniquement à des acteurs externes de les adapter explicitement [Blair et al. 2001], mais ces adaptations peuvent être opérées potentiellement à n’importe quel moment y compris à l’exécution. A l’inverse, les systèmes auto-adaptatifs ne requièrent pas d’intervention extérieure [Oreizy et al. 1999]. Ils fonctionnent en boucle fermée et intègrent des logiques d’adaptation, souvent définies et intégrées dès la construction des systèmes, qui leur permettent de surveiller activement des conditions de leur fonctionnement et de réagir eux-mêmes à des changements de leur état ou de l’environnement. Ainsi, ces systèmes auto-adaptatifs possèdent des logiques qui décrivent quand et comment réagir aux événements bien précis, et en fournissant des moyens pour modifier les systèmes de façon autonome lors de leur exécution, ces technologies d’auto-adaptation à l’exécution constituent aussi une base fondatrice pour l’élaboration de qualités d’auto-régulation plus générales (surveillance, configuration, réparation, optimisation, protection) dans le contexte émergent des systèmes autonomiques [Kephart 2005; Parashar et Hariri 2005].