THÈSE Présentée devant L Pour obtenir LE GRADE DE DOCTEUR Spécialité : INFORMATIQUE ÉCOLE DOCTORALE : École Doctorale Informatique Information et Société Par MOHAMAD-FIRAS ALHALABI Ingénieur en informatique Jury Titre : Modélisation et Développement d Applications avec Comportement Adaptable Soutenance 13 Mai 2009 Gilles MOTET Professeur, Laboratoire LATTIS INSAT, Toulouse Lionel SEINTURIER Ahmed LBATH Mathieu MARANZANA Professeur, Laboratoire LIFL INRIA Université des Sciences et Technologies de Lille Professeur, Laboratoire LIG IMAG Université Joseph Fourier, Grenoble Maître de conférence Laboratoire LIESP INSA de Lyon Jean-Louis SOURROUILLE Professeur, Laboratoire LIESP INSA de Lyon Rapporteur Rapporteur Examinateur Examinateur Directeur de thèse Laboratoire d Informatique pour l Entreprise et les Systèmes de Production (LIESP) Lyon, France
RESUMÉ Dans le domaine du génie logiciel, les systèmes autonomes sont des systèmes capables de modifier leur comportement et d évoluer pour s adapter à leur environnement d exécution. Ces systèmes ont pour objectif de fonctionner, du moins partiellement ou de façon dégradée, dans des conditions qui n ont pas été définies a priori. Le domaine d application qui nous intéresse pour ces systèmes autonomes est la gestion de la qualité de service (Quality of Service, QoS). Le développement d un système autonome pour gérer la QoS et qui répond à tous les besoins est une tâche difficile. Afin de faciliter cette tâche et d aider les développeurs, nous proposons un cadre générique pour décrire une famille de systèmes de gestion de la QoS. Nous proposons également, sous forme de graphe, un modèle générique pour la conception des applications. Ce modèle permet d utiliser un protocole commun pour la communication entre les applications et le système de gestion de QoS. Nous définissons différentes politiques de gestion de la QoS centralisée et décentralisée, puis nous les comparons en fonction du nombre de messages échangés entre l application et le système de gestion. Dans le but de généraliser notre solution, nous proposons tout d abord une méthodologie de développement à base de composants et de profils UML. Cette méthodologie permet de développer un cadre générique pour une famille de systèmes voisins dans un domaine quelconque. Ensuite, nous détaillons l exploitation de cette méthodologie pour le domaine de la gestion de la QoS. En se basant sur cette méthodologie, nous allons nous concentrer sur la description des composants génériques nécessaires pour construire un middleware de gestion de la QoS par adaptation de comportement. Nous développons un cadre générique qui regroupe ces composants, leurs connexions ainsi que des contraintes. Ce cadre représente aussi bien les aspects fonctionnels et structurels que les aspects comportementaux. À partir de ce modèle de base (framework), un utilisateur pourra dériver des systèmes de gestion de la QoS spécifiques. Nous présentons un exemple de système spécifique, appelé PMQDA (Plan-based Middleware for QoS management of Distributed Applications), pour la gestion de la QoS d applications distribuées. Mots clés : Gestion de la QoS ; Composant UML ; Adaptation ; MDD (Model Driven Development) ; Planification ; Cadre Générique ; Applications Distribuées.
ABSTRACT In the domain of software engineering, autonomous systems are able to modify their behavior and to evolve to fit their execution context (selfadaptation). These systems aim to work in unpredictable contexts, at least partially or in a graceful degraded way, under some conditions that are not defined in advance. In this context of autonomous systems, we are interested in the Quality of Service (QoS) management. The development of an autonomous system dedicated to manage the QoS that meets all the requirements is a hard task. In order to facilitate this task and to help developers, we propose a generic framework aiming to describe a family of related QoS management systems. In addition, we propose a generic model for the design of applications as a graph model. This model allows an application to communicate with the QoS management system by using a common protocol. Concerning the management architecture, we define different centralized vs. decentralized management policies and then, we compare them by using the number of messages exchanged between the application and the QoS management system. In order to generalize our solution, we first propose a development methodology based on UML components and profiles. This methodology allows developing a generic framework for a family of related systems in any domain. Then, we detail the use of this methodology in the domain of QoS management system. Based on this development methodology, we focus on the description of the generic basic components that are necessary to build a QoS management system that adapt application s behavior. We develop a generic framework that gathers these components, their connectors as well as constraints. This framework characterizes the functional and structural as well as behavioral aspects. From this coarse-grained generic framework, a user will be able to derive his/her specific own QoS management system. We show an example of specific system called PMQDA (Plan-based Middleware for QoS management of Distributed Applications) for QoS management of distributed applications. Key-words: QoS Management; UML Component; Adaptation; MDD (Model Driven Development) ; Generic Framework; Distributed Applications.
REMERCIMENT Ce travail de thèse n aurait pas été aussi fructueux sans l aide de plusieurs personnes. Je remercie tous ceux qui ont contribué, de près ou de loin à réaliser ce travail. Je tiens à adresser mes remerciements aux membres du laboratoire que j ai pu côtoyer durant la période de ma thèse et qui ont su rendre mon travail agréable. Mes remerciements vont tout d abord à Monsieur Jean-Louis SOURROUILLE, Professeur enseignant au département Informatique de l INSA de Lyon, pour son encadrement continu, pour les remarques qu il m a fournies ainsi que pour ses conseils durant toute la période de cette thèse. Ma gratitude, mon profond respect et mes remerciements vont à tous les membres du jury et à tous les rapporteurs pour leur attention consacrée à l égard de mon travail : Monsieur Mathieu MARANZANA, Maître de Conférences à l INSA de Lyon, d avoir accepté de participer au jury et pour ses remarques et ses conseilles durant ce travail. Monsieur Gilles MOTET, Professeur au laboratoire LATTIS à l INSAT, d avoir accepté de rapporter mon mémoire de thèse et d avoir accepté de participer au jury. Monsieur Lionel SEINTURIER, Professeur au laboratoire LIFL à l université des Sciences et Technologies de Lille, d avoir accepté de rapporter mon mémoire de thèse et d avoir accepté de participer au jury. Je remercie également Monsieur Ahmed LBATH, Professeur au laboratoire LIG-IMAG à l université Joseph Fourier, d avoir accepté de participer au jury. Je pense, bien sûr à ma famille mais les mots ne suffiront pas à leur témoigner ce dont je leur suis redevable.
Sommaire Chapitre 1 Introduction Générale -------------------------------------------------------- 11 1.1 Introduction --------------------------------------------------------------------------------------- 11 1.2 Contexte et Motivation -------------------------------------------------------------------------- 12 1.3 Objectifs de la thèse ----------------------------------------------------------------------------- 13 1.4 Contributions ------------------------------------------------------------------------------------- 15 1.5 Structure du mémoire ---------------------------------------------------------------------------- 16 Chapitre 2 Notions et Concepts de base ------------------------------------------------- 18 2.1 Introduction --------------------------------------------------------------------------------------- 18 2.2 Systèmes autonomes et gestion de la QoS ---------------------------------------------------- 18 2.3 Notion de QoS ------------------------------------------------------------------------------------ 19 2.4 Niveau de QoS ----------------------------------------------------------------------------------- 20 2.5 Problématique de la QoS ------------------------------------------------------------------------ 21 2.5.1 Limitation des ressources -------------------------------------------------------------------- 22 2.5.2 Gestion de la dégradation -------------------------------------------------------------------- 22 2.6 Définition de l adaptation ----------------------------------------------------------------------- 23 2.6.1 Principe ---------------------------------------------------------------------------------------- 23 2.6.2 Approche intrusive --------------------------------------------------------------------------- 23 2.6.3 Approche non-intrusive ---------------------------------------------------------------------- 24 2.6.4 Approche mixte ------------------------------------------------------------------------------- 24 2.6.5 Adaptation statique/dynamique ------------------------------------------------------------- 25 2.7 Notions relatives à la gestion de la QoS ------------------------------------------------------ 25 2.7.1 Catégories de QoS ---------------------------------------------------------------------------- 25 2.7.2 Gestionnaire de QoS -------------------------------------------------------------------------- 26 2.7.3 Contrat de QoS -------------------------------------------------------------------------------- 26 2.7.4 Mode et Utilité -------------------------------------------------------------------------------- 26 2.7.5 Les fonctions de gestion de la QoS --------------------------------------------------------- 27 2.8 Notions relatives au développement à base de modèles et de langages ------------------- 30 2.8.1 L'approche MDA ------------------------------------------------------------------------------ 30 2.8.2 Profil UML ------------------------------------------------------------------------------------ 32 2.8.3 DSL/DSM Domain Specific [Modeling] Language -------------------------------------- 33 2.8.4 Software Product Line ----------------------------------------------------------------------- 34 2.9 Conclusion ---------------------------------------------------------------------------------------- 34 Chapitre 3 Application et Environnement d Exécution ------------------------------- 36 3.1 Introduction --------------------------------------------------------------------------------------- 36 3.2 Modèle de l application ------------------------------------------------------------------------- 36 3.2.1 Structure des applications ------------------------------------------------------------------- 37 3.2.2 Graphe d'exécution et Phases --------------------------------------------------------------- 38 Firas ALHALABI 5
3.2.3 Amélioration du modèle --------------------------------------------------------------------- 39 3.2.4 Langage de description des applications --------------------------------------------------- 40 3.2.5 Exemple ---------------------------------------------------------------------------------------- 41 3.3 Gestion centralisée vs. décentralisée ---------------------------------------------------------- 43 3.3.1 Gestion centralisée --------------------------------------------------------------------------- 43 3.3.2 Gestion décentralisée ------------------------------------------------------------------------- 43 3.3.3 Estimation des coûts -------------------------------------------------------------------------- 46 3.3.4 Comparaison : échanges de messages ------------------------------------------------------ 47 3.3.5 Résultats graphiques -------------------------------------------------------------------------- 55 3.4 Conclusion ---------------------------------------------------------------------------------------- 56 Chapitre 4 Approche à base de Composants et Méthodologie de Développement 58 4.1 Introduction --------------------------------------------------------------------------------------- 58 4.2 Définition du composant ------------------------------------------------------------------------ 58 4.3 Différentes catégories --------------------------------------------------------------------------- 59 4.4 Composant UML 2.0 ---------------------------------------------------------------------------- 59 4.4.1 Définition -------------------------------------------------------------------------------------- 59 4.4.2 Deux vues complémentaires du composant UML 2.0 ------------------------------------ 60 4.4.3 Imprécision dans UML ----------------------------------------------------------------------- 61 4.4.4 Présentation des éléments du modèle de composant en UML 2.0 ---------------------- 62 4.4.5 Solutions et Précisions ----------------------------------------------------------------------- 63 4.4.6 Héritage de composants ---------------------------------------------------------------------- 65 4.4.7 Substitution de composants ------------------------------------------------------------------ 70 4.5 Méthodologie de développement -------------------------------------------------------------- 74 4.5.1 Description du domaine : profil générique ------------------------------------------------ 75 4.5.2 Modélisation : Architecture ----------------------------------------------------------------- 76 4.5.3 Préparation de la dérivation : profil commun --------------------------------------------- 78 4.5.4 Dérivation : Profil de dérivation ------------------------------------------------------------ 80 4.5.5 Transformation de modèles ------------------------------------------------------------------ 82 4.5.6 Dérivation de modèles spécifiques --------------------------------------------------------- 83 4.5.7 Spécialisation : profil spécifique ----------------------------------------------------------- 85 4.5.8 Raffinement et Implémentation ------------------------------------------------------------- 85 4.5.9 Génération de code et retour d expérience ------------------------------------------------ 87 4.6 Comportement dynamique ---------------------------------------------------------------------- 87 4.6.1 Description ------------------------------------------------------------------------------------ 87 4.6.2 Problème de l incohérence lié à la suppression ------------------------------------------- 88 4.7 Conclusion ---------------------------------------------------------------------------------------- 89 Chapitre 5 Architectures Existantes et Cadre Générique pour la Gestion de la QoS 90 5.1 Introduction --------------------------------------------------------------------------------------- 90 5.2 Besoin d une architecture générique ---------------------------------------------------------- 91 5.3 Les architectures existantes --------------------------------------------------------------------- 92 5.3.1 Le standard ISO ------------------------------------------------------------------------------- 92 5.3.2 Architecture QoS-A -------------------------------------------------------------------------- 92 5.3.3 Architecture OMEGA ------------------------------------------------------------------------ 93 5.3.4 Architecture DART --------------------------------------------------------------------------- 95 5.3.5 Architecture RTARM ------------------------------------------------------------------------ 95 5.3.6 Architecture QuO ----------------------------------------------------------------------------- 98 5.3.7 Architectures développées par notre équipe ----------------------------------------------- 98 5.3.8 Architectures dédiées aux systèmes multimédia ---------------------------------------- 101 5.4 Commentaires sur les travaux existants ----------------------------------------------------- 102 5.5 Cadre générique pour une famille de systèmes de gestion de la QoS ------------------- 103 5.5.1 Description du domaine : Profil générique proposé ------------------------------------ 104 5.5.2 Modélisation : architecture ---------------------------------------------------------------- 106 Firas ALHALABI 6
5.5.3 Commentaires et Discussion -------------------------------------------------------------- 113 5.5.4 Préparation de la dérivation : contraintes de dérivation ------------------------------- 114 5.5.5 Scénario possible du fonctionnement ---------------------------------------------------- 115 5.6 Dérivation : le modèle PMQDA-------------------------------------------------------------- 116 5.6.1 Principe de dérivation ---------------------------------------------------------------------- 117 5.6.2 Contraintes spécifiques -------------------------------------------------------------------- 118 5.6.3 Le modèle de PMQDA dérivé ------------------------------------------------------------- 118 5.7 Conclusion -------------------------------------------------------------------------------------- 120 Chapitre 6 Conclusion et Perspectives -------------------------------------------------- 122 6.1 Implémentation --------------------------------------------------------------------------------- 122 6.2 Conclusion générale --------------------------------------------------------------------------- 123 6.3 Perspectives ------------------------------------------------------------------------------------- 124 Firas ALHALABI 7
Liste des Figures Figure 1-1 : Une communication simple entre l application et le middleware. ---------------- 12 Figure 1-2 : Schéma illustratif concernant la partie méthodologie de développement. ------- 14 Figure 1-3 : Schéma illustratif concernent la partie application. --------------------------------- 15 Figure 2-1 : La définition d un nouveau stéréotype dans UML. --------------------------------- 33 Figure 3-1 : La communication entre l application et le middleware. --------------------------- 37 Figure 3-2 : Modèle générique des applications sous forme de graphe. ------------------------ 37 Figure 3-3 : Modèle de l application avec la définition des phases. ----------------------------- 38 Figure 3-4 : Améliorations du modèle générique. -------------------------------------------------- 39 Figure 3-5 : Le modèle UML d'une application. ---------------------------------------------------- 40 Figure 3-6 : Un exemple d application sous forme de diagramme d activité en UML. ------ 42 Figure 3-7 : L architecture de déploiement de la politique centralisée. ------------------------- 44 Figure 3-8 : L architecture de déploiement de la politique décentralisée complète. ---------- 45 Figure 3-9 : L architecture de déploiement de la politique décentralisée partielle. ----------- 46 Figure 3-10 : Exemple de planification des ressources, illustrant le décalage d étapes. ----- 48 Figure 3-11 : La synchronisation des étapes pour notre exemple d application. -------------- 50 Figure 3-12 : Les échanges des messages nécessaires pour décaler l étape (a) qui utilise la ressource globale Net. ----------------------------------------------------------------------------------- 51 Figure 3-13 : L admission de l étape (c) utilisant la ressource globale Net. ------------------- 52 Figure 3-14 : La synchronisation des activités de notre exemple. ------------------------------- 53 Figure 3-15 : Le nombre de messages échangés Msg = f(sync), Node 6. -------------------- 55 Figure 3-16 : Le nombre de messages échangés Msg = f(shift) pour Node 10. ------------- 56 Figure 4-1 : Le modèle de composant dans UML 2.0. --------------------------------------------- 59 Figure 4-2 : Les vues externe (a) et interne (b) du composant dans UML 2.0. ---------------- 60 Figure 4-3 : Un composant primitif contenant quatre classes. ------------------------------------ 64 Figure 4-4 : Le composant composite dans UML 2.0. --------------------------------------------- 64 Figure 4-5 : L héritage de composants comme il est défini dans [Boc04]. --------------------- 66 Figure 4-6 : Héritage de composants selon le standard UML : X, Y, et p sont implicitement hérités. ----------------------------------------------------------------------------------------------------- 68 Figure 4-7 : La définition du stéréotype «BlackBox_Inheritance». ------------------------------ 68 Figure 4-8 : La définition du stéréotype «PortToPort_Inheritance» entre deux composants. -------------------------------------------------------------------------------------------------------------- 69 Figure 4-9 : La substitution absolue de composants. ----------------------------------------------- 71 Figure 4-10 : La substitution contextuelle pour des interfaces requises. ----------------------- 72 Figure 4-11: La substitution contextuelle pour des interfaces fournies. ------------------------ 72 Figure 4-12 : Machines à états associés aux interfaces des composants A et B. -------------- 73 Figure 4-13 : La description de notre méthodologie de développement. ----------------------- 75 Firas ALHALABI 8
Figure 4-14 : La définition des notions du domaine de SOA par des stéréotypes. ------------ 76 Figure 4-15 : Le modèle de l architecture de SOA. ------------------------------------------------ 77 Figure 4-16 : L application du stéréotype «remove» sur un modèle. ---------------------------- 79 Figure 4-17 : Le modèle de l architecture de SOA avec les stéréotypes de la variabilité ---- 81 Figure 4-18 : Un modèle spécifique possible dérivé du modèle générique. -------------------- 84 Figure 4-19 : la spécialisation d un stéréotype générique pour le modèle spécifique. -------- 85 Figure 4-20 : Un modèle spécifique dérivé du modèle générique avec raffinement. --------- 86 Figure 4-21: Le modèle de PSM en utilisant la plateforme EJB.--------------------------------- 86 Figure 4-22 : Un diagramme de composants et son diagramme de séquence. ----------------- 88 Figure 4-23 : Conserver la cohérence entre les diagrammes au moment de la dérivation. --- 88 Figure 5-1 : Le modèle de l architecture RTARM. ------------------------------------------------- 97 Figure 5-2 : Le modèle de l architecture DCBL -------------------------------------------------- 101 Figure 5-3 : Une architecture générique à base de composants pour une famille de systèmes de gestion de la QoS. ---------------------------------------------------------------------------------- 108 Figure 5-4 : Le diagramme de séquence générique relatif à un cycle de négociation. ------ 114 Figure 5-5 : Le déroulement de l application. ----------------------------------------------------- 116 Figure 5-6: Schéma illustrant la dérivation. ------------------------------------------------------- 119 Figure 5-7 : Le modèle spécifique PMQDA dérivé de notre architecture générique. ------- 120 Figure 6-1 : Exemple de transformation de modèle. --------------------------------------------- 123 Firas ALHALABI 9
Liste des tableaux Tableau 2-1 : La traduction des paramètres de QoS. ----------------------------------------------- 28 Tableau 3-1 : Un exemple d'une application de transfert de données. -------------------------- 41 Tableau 3-2 : La définition des variables utilisées. ------------------------------------------------ 48 Tableau 3-3 : Résumé des nombres de messages échangés pour les politiques de gestion centralisée et décentralisée de la QoS. --------------------------------------------------------------- 54 Tableau 5-1 : Comparaison entre différentes architectures de gestion de la QoS. ---------- 103 Tableau 5-2 : Les stéréotypes du profil générique. ----------------------------------------------- 105 Tableau 5-3 : Propriétés associées aux stéréotypes définis.------------------------------------- 106 Firas ALHALABI 10
Chapitre 1 Introduction Générale 1.1 Introduction Le principal problème du génie logiciel ne se pose plus en termes de «donnez-moi une spécification immuable et je produis une implantation de qualité» mais plutôt en «comment réaliser une implantation de qualité avec des spécifications continuellement mouvantes» [JGM06]. De nos jours, les machines sont de plus en plus puissantes, mais cela ne garantit aucunement qu une application s exécutera avec succès avant la date limite. En plus des aspects fonctionnels, dans de nombreux domaines, les services requièrent des propriétés additionnelles comme garantir une durée d exécution maximale, contrôler le déroulement de l application après son admission, surveiller les défaillances, réserver une certaine capacité de mémoire, adapter le comportement de l application face à son contexte. Ces propriétés sont regroupées sous le terme de gestion de la qualité de service (Quality of Service, QoS). Cette gestion est souvent rattachée à la notion d ordonnancement permettant de garantir ces critères dans de nombreux cas. Une solution pour assurer cette gestion est de connecter les applications à un système de gestion de la QoS, généralement un middleware, qui devrait contrôler la QoS pour l ensemble des applications. La littérature fournit de nombreux exemples de middlewares, et chaque application est écrite pour un middleware spécifique. Parallèlement, depuis l avènement d UML (Unified Modeling Language), la communauté des chercheurs en génie logiciel conduit de nombreuses recherches sur l ingénierie des modèles, c est-à-dire le déplacement du travail du niveau programmation vers le niveau plus abstrait de la modélisation. Au lieu de développer à partir de zéro, une grande attention a été portée sur la réutilisabilité et le développement conduit par les modèles (Model Driven Development, MDD) avec séparation en modèles indépendants de la plateforme (Platform Independent Model, PIM) et en modèles spécifiques PSM de la plateforme cible (Platform Specific Model, PSM). Cette tendance à manipuler Firas ALHALABI 11
directement les modèles représente une avancée majeure dans le domaine du génie logiciel. Le problème est qu UML offre peu de notions natives pour la description de la QoS, mais heureusement il peut être étendu à l aide de profils qui décrivent les nouvelles notions (stereotype), leurs propriétés (tagged value) et les contraintes relatives à leur utilisation. 1.2 Contexte et Motivation De nombreux travaux de recherche ont été proposés pour traiter la gestion de la QoS des applications (par exemple, [ZES97], [RL98], [KYO99], [HWC99], [CJC00], [CS01], [VSM05]). La plupart de ces travaux proposent de créer une couche intermédiaire (middleware), entre les applications et le système d exploitation. Son but est d augmenter les performances générales du système. L idée de ces approches est de prendre en compte les besoins non fonctionnels de l application dans le processus de développement. Elles sont basées sur un mécanisme d adaptation, c està-dire qu une partie du système modifie son comportement en fonction du contexte d exécution pour atteindre un nouveau point de fonctionnement plus satisfaisant. Dans ce contexte, nous supposons que l application s exécute généralement sur plusieurs nœuds dans des systèmes ouverts où la loi d arrivée des événements est inconnue. L application possède la connaissance nécessaire pour mettre en place ses comportements alternatifs, c est-à-dire fournir le même service avec différents niveaux de QoS. Par conséquent, elle offre une description de son comportement mais aussi de ses besoins en ressources afin de permettre une adaptation sous le contrôle du middleware. Cette approche implique des interactions entre l application et le middleware en utilisant un protocole commun. Ce dernier se compose de certains messages pour, par exemple, demander une admission, passer à l étape suivante, signaler l arrivée d un événement ou encore arrêter l exécution de l application. Cela se fait selon l état de l application (par exemple, Active, Inactive) et le contexte d exécution (Figure 1-1). La communication application/middleware doit être générée Application Inactive do/activity start() stop() Active Communication Protocol Middleware Figure 1-1 : Une communication simple entre l application et le middleware. Firas ALHALABI 12
selon le système choisi tout en essayant de respecter un modèle générique pour tous les systèmes de gestion qui existent dans la littérature. Pour résumer, la conception de ce type d application va orienter les développeurs vers une modélisation basée conjointement sur les aspects fonctionnels et non fonctionnels. Pour cela, nous choisissons de définir à la fois un modèle générique pour toutes les applications et un cadre générique pour une famille des systèmes de gestion. À partir de ce cadre, les systèmes de gestion dérivés contrôlent l exécution des applications afin que ces dernières puissent s adapter à leur contexte. La gestion de la QoS peut être effectuée par le biais d un protocole commun de communication définissant les échanges de messages entre l application et le système de gestion. Nous pouvons définir de nombreux messages qui composeraient ce protocole. Nous en citons quelques-uns : L application demande son admission avec des besoins de QoS et attend des directives ; L application demande un service avec une certaine qualité ; Le système de gestion alerte l application en cas de dépassement d un seuil prédéfini pour la consommation de ressources ; Le système demande à une application de se tuer. L enjeu est de définir un cadre générique pour la gestion de QoS d une part et de modéliser l application qui sera exécutée sous le contrôle d un système de gestion spécifique dérivé de ce cadre générique de l autre. 1.3 Objectifs de la thèse L objectif principal de cette thèse est de proposer un cadre générique à base de composants UML pour une famille de systèmes de gestion de la QoS par adaptation de comportement. Cela permet de simplifier le processus de développement d un système autonome qui permet à l application de s adapter à son contexte d exécution en respectant les exigences de la QoS. Dans un souci de généralité, nous proposons une méthodologie exploitable non seulement dans le domaine de gestion de la QoS, mais plus généralement pour obtenir une famille de systèmes dans n importe quel domaine d application. Nous détaillons par la suite la description de cette méthodologie pour le domaine de la gestion de la QoS. Nous proposons également un modèle générique pour la conception des applications afin qu elles puissent être gérées sous le contrôle du système de gestion de QoS. Concernant la partie méthodologie de développement, nous nous basons sur le développement conduit par les modèles (Model Driven Firas ALHALABI 13
Development, MDD), nous utilisons le principe des lignes de produits logiciels (Software Product Line, SPL) et/ou de la programmation générative pour définir un langage dédié au domaine (Domain Specific Language, DSL) basé sur un profil UML (UML Profile). De façon plus particulière, cette méthodologie nous permettra de développer un cadre générique pour une famille de systèmes de gestion de la QoS (QoS Management System, QMS) se basant sur les connecteurs (Connector) et les composants UML (Component). Ce dernier facilitera la dérivation d un système de gestion spécifique par transformation de modèles. La Figure 1-2 présente, sous forme d un réseau sémantique, un modèle illustrant les notions concernées pour le développement de notre méthodologie. Les différents éléments du modèle représentent les notions qui seront plus ou moins utilisées tout au long de ce mémoire. Ces notions sont représentées par des boîtes étiquetées par les mots correspondants. Les liens entre ces boîtes expriment les relations sémantiques entre les notions. MDD Use Model is a based on QMS Domain Development Methodology SPL Extension apply for define use the principle of based on Described in DSL UML based on based on UML Profile Specific System Family Generic Framework derived from Component PM PIM PSM for Connector apply on Component Inheritance Component Substitution Constraint Stereotype describe Concept Figure 1-2 : Schéma illustratif concernant la partie méthodologie de développement. Concernant la partie gestion de QoS, nous proposons un modèle générique pour la conception des applications sous forme d un graphe (Graph Model). Nous utilisons une combinaison des différentes politiques (intrusive et non-intrusive) et différents modes de gestion (centralisée et décentralisée) afin de contrôler le comportement de l application. Ceci étant dans le but d optimiser le niveau de la QoS (QoS Level). La Figure 1-3, schématise notre démarche sous forme d un réseau sémantique. Les Firas ALHALABI 14
Graph Model Application described by controled by controlled by constraints QoS Management System is a is a based on optimize QoS Level Adaptation is a soft hard Management Mode is a Management policy is a Static Dynamic Centralized Decentralized intrusive non-intrusive is a Fully Decentralized Partial Decentralized Figure 1-3 : Schéma illustratif concernent la partie application. boîtes de ce modèle représentent les notions qui seront étudiées dans la suite de ce mémoire. 1.4 Contributions Les principales contributions de cette thèse peuvent être synthétisées de la manière suivante : 1. Nous avons proposé un modèle générique pour la conception des applications ainsi que leur architecture de gestion. Chaque application est modélisée sous forme de graphe orienté. 2. Nous avons réalisé une comparaison des politiques centralisée et décentralisée de gestion de la QoS. Cette comparaison est basée principalement sur le test d admission et la gestion des étapes d exécution de l application en fonction du nombre de messages échangés entre les différents nœuds d applications distribuées. 3. Nous avons spécifié des contraintes pour préciser la sémantique d'uml, notamment l héritage de composants. Nous avons clarifié la notion de substitution de composants en distinguant la substitution absolue et la substitution contextuelle. 4. Nous avons proposé une méthodologie de développement à base de composants et de profils UML ainsi que des transformations guidées de Firas ALHALABI 15
modèles pour passer d un cadre (framework) générique à une description spécifique. Notre méthodologie est fondée sur le développement à base de modèles (MDD). 5. Nous avons identifié les composants nécessaires pour construire un cadre générique d une famille de systèmes de gestion de QoS par adaptation de comportement. Pour ce faire, nous avons effectué une étude bibliographique sur les différentes architectures de gestion de QoS existantes. Cela nous a permis de faire le premier pas vers la définition d un langage dédié (c est-à-dire, un DSL) pour le domaine de la gestion de la QoS. 6. Nous avons étudié le problème d instanciation de modèle et les possibilités d automatiser le processus de dérivation d un modèle spécifique à partir d un cadre générique. Dans cette étape, nous avons traité le problème lié à l incohérence produit particulièrement par la suppression d un composant ou un connecteur pendant la dérivation. 1.5 Structure du mémoire Le travail présenté dans cette thèse est lié à deux domaines de recherche : la modélisation à base de composants et le développement conduit par des modèles d une part et la gestion de la QoS globale du système par adaptation du comportement de l application de l autre. Nous présentons les principaux concepts, définitions et travaux étudiés de chacun de ces deux domaines. Ensuite, nous proposons quelques précisions pour l utilisation d UML concernant en particulier l héritage et la substitution de composants. Puis, nous proposons une méthodologie de développement à base de composants et de profils UML. Nous détaillons enfin la mise en œuvre de cette méthodologie pour le domaine de gestion de QoS. Ce mémoire de thèse est organisé en six chapitres de la manière suivante. Après avoir présenté le contexte, la motivation et l objectif ainsi que la contribution de ces travaux dans ce premier chapitre, le Chapitre 2 présentera les notions de base qui sont nécessaires pour comprendre la problématique et les travaux de recherche menés dans cette thèse. Le Chapitre 3 a pour but de modéliser les applications et de décrire l environnement dans lequel s exécutent ces applications. Dans ce chapitre, nous proposons un modèle générique pour la conception des applications sous forme de graphe et nous comparons ensuite les différentes politiques de gestion. Le Chapitre 4 expose les extensions apportées au langage UML concernant plus particulièrement l héritage et la substitution de Firas ALHALABI 16
composants. Ensuite, ce chapitre décrira notre méthodologie de développement à base de composants et de profils UML. Le Chapitre 5 est consacré à la présentation des architectures existantes de gestion de la QoS. Puis, nous détaillons la mise en œuvre de notre méthodologie de développement pour développer un cadre générique d une famille de systèmes de gestion de la QoS. Un système de gestion spécifique appelé PMQDA sera ensuite dérivé de notre cadre générique. Pour finir, le Chapitre 6 commence par présenter une partie de l implémentation que nous avons réalisée pour la mise en œuvre de nos propositions. Puis, nous conclurons ce mémoire en récapitulant les travaux réalisés et en proposant des directions pour les travaux futurs. Firas ALHALABI 17
Chapitre 2 Notions et Concepts de base 2.1 Introduction Dans ce chapitre, nous présentons les notions et les concepts utilisés dans notre démarche. Ce chapitre est organisé de la manière suivante : la section 2.2 présente la définition des systèmes autonomes. Le domaine sélectionné pour ces systèmes autonomes est la gestion de la QoS. Pour cela, les sections 2.3 et 2.4 présentent la notion de QoS et la section 2.5 décrit la problématique de la QoS. La QoS peut être gérée par adaptation du comportement de l application. C est la raison pour laquelle, la section 2.6 décrit le mécanisme d adaptation et présente des types de gestion. La section 2.7 décrit des notions relatives à la gestion de la QoS. Enfin, la section 2.8 conclut ce chapitre en présentant des notions et des langages qui seront discutés par la suite dans ce mémoire. 2.2 Systèmes autonomes et gestion de la QoS Les systèmes autonomes ont la capacité de continuer leur exécution et de s adapter à leur contexte selon les disponibilités de ressources. Ils peuvent s adapter à leur environnement d exécution et fonctionner dans des conditions qui n ont pas été définies a priori. Nous allons aborder le domaine de la gestion de la QoS comme un domaine d application proposé pour ces systèmes autonomes. Notre objectif est de définir un cadre générique pour construire un système autonome en maîtrisant la QoS globale d'applications distribuées ayant des capacités d'adaptation. À partir de ce cadre générique, les systèmes spécifiques peuvent être développés par dérivation. Les sections suivantes présenteront les notions et les concepts utilisés dans notre approche. Firas ALHALABI 18
2.3 Notion de QoS La première utilisation du terme QoS a été élaborée dans le cadre des performances réseaux et concerne la transmission de données. Dans ce domaine des réseaux, la QoS est définie par "Le moyen d allouer des ressources dans les commutateurs et les routeurs afin que les données arrivent à destination rapidement, de manière uniforme et fiable" [Int96]. Les caractéristiques définissant la QoS étaient alors le pourcentage de paquets perdus sur le réseau, la largeur de bande passante, le débit, etc. Dans cette perspective, la QoS permet de modéliser les performances de systèmes en définissant uniquement le prix qu un utilisateur est prêt à payer pour certaines garanties de qualité de service. À cause de nouvelles exigences de développement des applications, notamment des applications distribuées, la QoS devrait également être considérée à un niveau plus abstrait. La gestion de la QoS dépend de l environnement d exécution de l application (par exemple, le système d exploitation). Outre les télécommunications et la gestion des réseaux, le concept de QoS a été également introduit dans le domaine du génie logiciel avec deux buts : (i) évaluer la qualité des produits logiciels, (ii) appliquer le génie logiciel dans la gestion de la QoS. Ce deuxième objectif est en relation avec notre travail qui concerne l utilisation des activités du génie logiciel comme la modélisation, la conception, le raffinement et la transformation de modèles pour gérer la QoS globale du système. Il n existe pas une définition consensuelle applicable à tous les travaux qui concernent la gestion de la QoS. Cependant, quel que soit le contexte, la QoS caractérise l ensemble des propriétés non fonctionnelles d un système. La gestion de la QoS peut être vue comme un ensemble d activités permettant de fournir le service demandé dans les meilleures conditions possibles selon le contexte d exécution. Cette gestion permet aux développeurs du système de spécifier quelles garanties doit fournir une application pendant son exécution, par exemple le nombre d images affichées par seconde, le respect de contraintes temporelles ou la disponibilité de la mémoire. Le standard ISO définit un cadre appelé QoS Framework [Int95]. Ce cadre a pour but de fournir un compromis pour les exigences et les mécanismes de QoS dans un environnement. Selon la définition du standard ISO, la QoS est vue comme un ensemble des qualités relatives au comportement d ensemble d un ou plusieurs objets "au sens éléments du système". D autres tentatives viennent enrichir cette définition, notamment Firas ALHALABI 19
le travail présenté dans [VKV95], qui définit la QoS comme l ensemble des caractéristiques qualitatives et quantitatives de tout système qui a des contraintes sur le temps de réponse, l accès à ses ressources ou encore sur la qualité du flux de données sortant nécessaire à l accomplissement des fonctionnalités d une application. Dans ce travail, nous adoptons la définition de [VKV95] et nous nous focalisons sur la gestion de la QoS de haut niveau. De ce fait, la QoS a pour but de fournir des garanties quant aux conditions d exécution d une application. Dans cette direction, nous considérons que l application doit posséder des degrés de liberté. Par exemple, chaque application possède des modes de fonctionnement dans lesquels elle consomme plus ou moins de ressources : si l application ne peut plus transférer 25 images par seconde, une adaptation possible pour faire face à une surcharge momentanée serait de n en transférer que 12. 2.4 Niveau de QoS Le niveau de QoS est caractérisé par des valeurs particulières des propriétés extra fonctionnelles. D une manière générale, les applications s appuient sur les couches logicielles et matérielles (système d exploitation, réseau, etc.) de leur contexte d exécution pour fournir la meilleure QoS possible. En cas d incapacité de ce contexte à fournir les services demandés, il faut gérer les applications pour contrôler leur qualité. Cependant, conserver le niveau de QoS malgré les changements de contexte est un grand défi. À cette problématique se rajoute également l aspect complémentaire de modification de la QoS selon l évolution des besoins en répartissant les ressources de façon homogène et cohérente. Par exemple en diminuant la fréquence d échantillonnage du son ou en affichant des images de moins bonne résolution. En ce qui concerne le niveau de QoS il peut s agir de : 1. Best effort : la plupart du temps, les systèmes informatiques fournissent des services selon la politique du "best effort" (au mieux de leurs possibilités), politique qui s avère satisfaisante aussi longtemps que les ressources exigées sont disponibles sans aucune gestion complémentaire. Quand les ressources viennent à manquer, une politique plus efficace doit être mise en œuvre pour améliorer la QoS fournie ; 2. Garantie absolue (déterministe) : on garantit l accès aux ressources (possibilité de prédiction et de planification de l exécution). Dans ce cas, toutes les échéances doivent être respectées et la demande de ressources doit être satisfaite même dans le pire cas ; Firas ALHALABI 20
3. Probabiliste : le niveau de QoS peut être meilleur si une optimisation de l utilisation des ressources est faite en garantissant l accès aux ressources avec un certain degré de confiance. Par exemple, un service qui garantit que son échéance sera respectée dans 90% des cas. La difficulté de cette solution est d estimer le bon niveau de confiance. Nous proposons une solution qui tire avantage des deux premières approches best effort et déterministe. Cette solution consiste à fournir la meilleure QoS possible (best effort) tout en essayant de respecter les échéances (déterministe) par le biais de la planification de toutes les ressources du système. En plus des niveaux de QoS présentés ci-dessus, deux types de contraintes de temps peuvent être définis : les contraintes temps-réel dur et les contraintes temps-réel mou : Les contraintes temps-réel dur : regroupent les contraintes qui doivent être respectées quelque soit le contexte d exécution ; Les contraintes temps-réel mou : ces contraintes nécessitent des garanties temporelles, qualitatives et sécuritaires moins contraignantes que pour le temps-réel dur. Ces contraintes peuvent tolérer la perte de quelques informations dans la mesure où cela n est pas clairement perçu et peut être négligé. Puisqu il est impossible de respecter strictement les contraintes temps-réel dur dans les systèmes ouverts où la loi d arrivée des événements est inconnue, seules les applications à contraintes temps-réel mou seront considérées dans la suite de ce travail. 2.5 Problématique de la QoS Les recherches qui ont traité la QoS considèrent principalement les moyens d assurer un niveau donné de QoS : pour que l on puisse fournir les services demandés (aspect fonctionnels) de manière satisfaisante, une application a besoin d un certain niveau de QoS (aspects non fonctionnels) pour s exécuter. Il est important de pouvoir maintenir le niveau de QoS malgré les fluctuations et/ou changements du contexte d exécution. Ces fluctuations proviennent principalement de variations de la disponibilité des ressources (par exemple, le processeur) qui varie dans le temps. Pour arriver à maintenir le niveau de QoS il faut donc prendre en compte ces différentes variations et gérer la QoS en conséquence. Le fait de spécifier comment un système contrôlera sa QoS est un problème complexe à plusieurs dimensions. Nous distinguons Firas ALHALABI 21
essentiellement deux dimensions relativement liées entre elles qui sont la limitation des ressources et la gestion de la dégradation. 2.5.1 Limitation des ressources Généralement, l application demande des ressources et le système d exploitation essaie de les allouer. Ces ressources peuvent concerner une application ou des entités des applications distribuées (ressources locales sur un nœud). Parmi ces ressources, nous trouvons le temps d utilisation de processeur, la consommation de mémoire ou la charge de la batterie s il s agit d un ordinateur portable. Les ressources peuvent aussi concerner le réseau comme la largeur de la bande passante. Dans ce cas, elles affectent la manière dont les différentes parties de l application distribuée interagissent (ressources partagées entre plusieurs nœuds). En plus, afin de mieux gérer la QoS des applications distribués, un autre aspect doit être pris en compte qui est la synchronisation entre les nœuds. Cet aspect sera détaillé dans le Chapitre 3. La disponibilité des ressources affecte directement ou indirectement le fonctionnement des applications [Abd99]. Ainsi, pour garantir un niveau de QoS, le système de gestion doit prendre en compte l aspect variable de la disponibilité des ressources et réagir en cas de fluctuation de ces ressources. 2.5.2 Gestion de la dégradation Comme nous l avons mentionné, les systèmes autonomes ont pour but de fonctionner malgré des changements de leur contexte d exécution. Dans ce cas, il s agit non seulement de mettre en œuvre un service exigé, mais il s agit aussi de concevoir un service capable de s exécuter dans le pire cas (par exemple, en cas de surcharge du système) et même si cette exécution s effectue à un niveau très dégradé. Pour ce faire, nous supposons que les applications obéissent à une interface avec un gestionnaire de QoS (QoS Manager), ce qui permet au système de gestion de la QoS de dégrader harmonieusement (Adaptation au sens général du terme) les applications en cas de fluctuation du contexte et/ou de procéder à des négociations avec les applications. Comme nous verrons plus tard dans ce mémoire, cette approche nécessite la définition d un protocole commun entre les applications et le gestionnaire de QoS. La section suivante détaille le principe de l adaptation et présente différentes approches permettant sa mise en œuvre. Firas ALHALABI 22
2.6 Définition de l adaptation 2.6.1 Principe Le mot adaptation signifie qu une partie du système modifie son comportement en fonction du contexte pour atteindre un nouveau point de fonctionnement plus satisfaisant. Autrement dit, une application dispose de capacités d adaptation lorsqu elle peut rendre le même service de plusieurs façons [VH97]. Tout système est à priori supposé faire au mieux pour satisfaire les besoins attendus. L adaptation débute au-delà, lorsque tous les besoins ne peuvent être satisfaits. Le gestionnaire de QoS doit posséder la capacité de réagir face aux variations des contraintes de l environnement ou des besoins. La stratégie d adaptation définit donc les paramètres importants qui influencent le fonctionnement d une application et spécifie les actions à entreprendre lorsque ces paramètres ne vérifient pas certaines propriétés (niveau de QoS fourni non satisfaisant). En plus, l adaptation du comportement de l application signifie qu il faut prendre des décisions pour exécuter des actions visant à augmenter la QoS globale du système et/ou maintenir la satisfaction globale au plus haut niveau possible. De très nombreuses visions de l adaptation existent dans la littérature : un changement dans le niveau de consommation des ressources, un refus d admission et plus généralement un changement de mode de fonctionnement de l application de façon à modifier cette consommation [Abd99]. En général, nous pouvons distinguer deux approches permettant la mise en œuvre du mécanisme d adaptation : approche intrusive et approche non-intrusive. 2.6.2 Approche intrusive Dans cette approche, l application participe elle-même de façon active à l adaptation de la QoS. Le principal avantage de l approche intrusive est de permettre des adaptations très appropriées car seule l application dispose de la connaissance nécessaire pour gérer au mieux ses ressources et s adapter à son contexte de façon optimale. Par exemple, une application peut passer de 25 à 12 images par seconde pour diminuer sa consommation de ressources tout en conservant un service acceptable. L inconvénient évident est que cela ne concerne que les applications développées spécifiquement à cet effet [HWC99]. Firas ALHALABI 23