THÈSE. Présentée devant. L Institut National des Sciences Appliquées de Lyon. Pour obtenir LE GRADE DE DOCTEUR. Spécialité : INFORMATIQUE

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

L architecture présentée dans [CS03] est un exemple typique de gestion intrusive. La gestion de la QoS consiste à exécuter d abord les tâches les plus importantes, et ensuite les autres tâches en fonction du temps disponible. 2.6.3 Approche non-intrusive Dans ce type de gestion, l adaptation est mise en œuvre (ou pilotée) par l environnement de l application. Cette adaptation peut être réalisée de deux façons : (i) le système d exploitation gère la QoS, par exemple en répartissant le temps processeur. Il suffit seulement de lui ajouter des fonctions supplémentaires. L avantage essentiel de cette solution est que toutes les applications s'exécutant sur le même système d'exploitation bénéficient des mêmes services puisqu elles ne sont pas modifiées. Les besoins de QoS sont décrits de façon séparée, typiquement dans un fichier accompagnant toute application [HV99] ; (ii) une couche intermédiaire (middleware) entre l application et le système d exploitation gère la QoS [AGB02]. L avantage supplémentaire de cette technique par rapport à la précédente est qu elle pourrait être réutilisable pour plusieurs systèmes d exploitation avec un moindre effort. L approche proposée dans [AAG02] décrit un exemple intéressant de gestion non-intrusive pour un serveur. Elle propose de changer la taille des pages html et d ignorer les références et/ou les images en cas de dégradation. L adaptation se fait à l extérieur de l application (Serveur) par la redéfinition dynamique de chemins d accès (par exemple, des liens soft UNIX). 2.6.4 Approche mixte Nous proposons une approche tirant parti des avantages des deux approches précédentes. C est un compromis entre l approche intrusive et nonintrusive. Pour cette approche, les applications sont conçues de façon spécifique et exportent leurs besoins de ressources : elles fournissent leurs différentes configurations qui sont associées à des besoins en ressources, et la configuration la plus adaptée sera ensuite sélectionnée. Cependant, il faut une relation privilégiée (interface) entre l application d une part et le système de gestion de la QoS de l autre. Pour cela, une couche intermédiaire (middleware, cas de l approche non-intrusive) est utilisée entre l application et le système d exploitation gérant la QoS. Cette technique permet au gestionnaire de contrôler les ressources depuis l extérieur. Il choisit le meilleur mode opérationnel possible en fonction des ressources disponibles dans le contexte d exécution. Firas ALHALABI 24

Avec cette approche, comme dans le cas de l approche intrusive, les fonctionnalités spécifiques et la logique métier sont implémentées du côté des applications (c est-à-dire, l application participe à la gestion), alors que le système de contrôle de l adaptation est commun pour toutes ces applications comme dans le cas de l approche non-intrusive (pilotage externe). 2.6.5 Adaptation statique/dynamique Afin de compléter cette étude sur la gestion de la QoS du système, deux modèles d adaptation radicalement différents sont envisageables : l adaptation statique et l adaptation dynamique. L adaptation statique est effectuée avant ou pendant le déploiement de l application en fonction des connaissances détenues de l environnement [Tou05]. Pour cette technique, il faut connaître toutes les situations possibles ce qui n est pas le cas du contexte étudié. Dans l adaptation dynamique, le comportement de l application est ajusté en fonction d une politique ou de critères généralement liés à la disponibilité de ressources. Cela englobe la dégradation des applications de type temps-réel mou, mais aussi l adaptation du comportement d un système quand les ressources sont insuffisantes. L adaptation dynamique a lieu en cours d exécution. Cette technique d adaptation est utilisée dans certains travaux comme [SAW94], [DSN97], [GWB99]. Dans notre cas des systèmes ouverts, l adaptation est nécessairement dynamique puisque la loi d arrivée des événements est a priori inconnue. 2.7 Notions relatives à la gestion de la QoS 2.7.1 Catégories de QoS Afin de contrôler la QoS globale du système, il faut tenir compte du fait que les applications ont des besoins différents. Par exemple, les besoins en QoS pour les flux vidéo sont différents de ceux des transactions de mise à jour des bases de données [Xin00]. Ces différents besoins sont classés en catégories de QoS comme la sécurité ou la performance, et à partir de leur description on détermine le choix des paramètres de QoS à gérer [Int95], par exemple le temps de réponse ou la régularité de l affichage d images. Les catégories de QoS regroupent donc un ensemble de besoins de QoS spécifiques à un domaine d application. Firas ALHALABI 25

Concernant l adaptation du comportement de l application, nous considérons qu il n existe pas d intervention de l extérieur par des utilisateurs et que l application est suffisamment autonome pour faire des requêtes (par exemple, demander un service). De ce fait, la description de ces besoins en QoS est uniquement fournie par les applications ellesmêmes. 2.7.2 Gestionnaire de QoS La gestion de la QoS est réalisée par ce que nous appelons le gestionnaire de QoS (QoS Manager). L objectif du gestionnaire de QoS est d améliorer la QoS globale du système. Il faut bien faire la différence entre un gestionnaire de ressources et un gestionnaire de QoS. En général, un gestionnaire de ressources est une entité qui s occupe de la gestion de l état d une ressource et de son ordonnancement, c est-à-dire, la répartition des ressources du système entre les différentes applications. Par contre, un gestionnaire de QoS est une entité dédiée pour contrôler un ensemble de gestionnaires de ressources, par exemple en planifiant ces ressources. Ces derniers doivent aussi interagir avec le système d exploitation afin d utiliser des services standard, par exemple la réservation de ressources. 2.7.3 Contrat de QoS L application exprime, pour un niveau de qualité spécifiée, ses exigences en termes de QoS au travers de contraintes sur les paramètres utilisés pour contrôler la QoS (caractéristiques ou besoins de QoS). À l opposé, le système pourrait proposer une offre de QoS. Pour formaliser la relation établie lors de l utilisation d un élément par un autre, on parle de contrat de QoS. Le but de ce contrat et de caractériser une mise en relation de QoS requise et une QoS offerte. En principe, la QoS requise doit être un sous ensemble de la QoS offerte. Comme nous allons le voir, un contrat de QoS peut être le résultat d une négociation entre l application, demandeur du service, et le système, fournisseur du service. 2.7.4 Mode et Utilité Nous supposons que le système de gestion de la QoS pilote le fonctionnement des applications à travers une interface commune. Ce pilotage peut prendre plusieurs formes. D une façon générale, chaque application a des modes de fonctionnement (operating mode), et à chacun de ces modes est associée une valeur numérique nommée utilité (Utility) et Firas ALHALABI 26

une consommation de ressources. Un mode peut être défini par un niveau de QoS, par exemple mode normal ou dégradé. L utilité est une mesure abstraite de la QoS. C est la traduction numérique des niveaux de QoS. Il faut s arranger pour que chaque mode de fonctionnement soit associé à une valeur d utilité qui permette de juger de son intérêt par rapport aux ressources disponibles. Par exemple, la valeur 7 pour "résolution 800*600 et FPS de 25". Cette valeur de 7 est relative par rapport à d autres exigences/possibilités de la combinaison de "résolution" et "FPS". Un mode est donc associé à une utilité pour rendre compte de l intérêt d utiliser ce mode plutôt qu un autre pour un même service. Typiquement, le système de gestion peut agir sur le mode, l utilité ou les ressources. Comme nous allons voir dans le Chapitre 3, une succession d actions est liée à un choix de modes, d où un comportement différent dans l exécution de l application. 2.7.5 Les fonctions de gestion de la QoS 2.7.5.1 Traduction des paramètres de QoS Les besoins en QoS s expriment de différentes manières selon les services offerts par le support d exécution aux applications. Par exemple, prenons une application qui manipule le transfert des fichiers vidéo. Cette application peut exprimer un besoin de QoS pour le son et/ou l image en termes de qualité (par exemple, très bonne, bonne, moyenne ), alors que la description utilisée pour le contrôle et la gestion de la QoS, est exprimée sous forme de quantité, par exemple le délai, la consommation de ressources (par exemple, processeur=30% par seconde, mémoire=20mo). Pour passer de la QoS exprimée d un niveau à un autre (par exemple, du niveau application au niveau ressource), des fonctions de traduction seront nécessaires. Dans un premier temps, le gestionnaire de QoS doit traduire les caractéristiques et les contraintes spécifiées du niveau application au niveau de la gestion de la QoS (par exemple, ressource) pour être compréhensibles. Ces paramètres sont traduits vers un ensemble de ressources concernant tout le système. En fait, le gestionnaire de QoS n est pratiquement pas capable de déterminer tous les besoins de ressources nécessaires. Par exemple le nombre d images par seconde désiré dans une application vidéo à la demande (VoD) correspond au niveau du système à plusieurs paramètres : bande passante du réseau nécessaire pour transférer les données tout en respectant le délai de ce transfert, ainsi que le temps Firas ALHALABI 27

nécessaire pour éventuellement compresser/décompresser ces données, le temps de processeur, la quantité de mémoire, etc. Il faut attirer l attention sur le peu de travaux faits actuellement sur la traduction des paramètres de QoS. Il faut noter également que la traduction des paramètres de QoS devrait être bidirectionnelle pour permettre à l application de négocier avec le système [NS95], mais cette technique est difficile à mettre en œuvre puisque les travaux réalisés sur la traduction des paramètres de QoS sont pour le moment basés uniquement sur des estimations [SC00]. Étant donné la diversité des applications et des environnements d exécution, il n existe pas, à l heure actuelle, d algorithmes génériques pour la traduction des paramètres de QoS. Ainsi toutes les solutions proposées (par exemple, [HV98], [NCN98], [WFA99], [SC00]) dans la littérature sont des heuristiques. Ces solutions réalisent, en effet, la traduction d une manière statique. Il manque encore des approches rigoureuses et complètes visant à réaliser cette traduction. Pour cette raison, nous allons prévoir une technique de traduction (QoS Mapping), mais nous ne détaillons pas sa mise en œuvre. Un exemple de traduction (QoS Mapping) statique est représenté dans le Tableau 2-1. L idée est inspirée de [MM03] et les valeurs des paramètres dans ce tableau sont basées sur une estimation. Tableau 2-1 : La traduction des paramètres de QoS. Paramètre Processeur Mémoire Bande Passante Mode Utilité Excellent/Good 60% 50 Mo 10 KBps 1 7 Fair/Poor 30% 20 Mo 8 KBps 2 3 Bad 15% 10 Mo 6 KBps 3 1 2.7.5.2 Test d admission Lorsqu une nouvelle application souhaite entrer dans l infrastructure d exécution, elle doit tout d abord valider son inscription. Pour effectuer cette inscription, le gestionnaire de QoS doit vérifier que les ressources sont disponibles pour garantir l exécution de ce nouveau participant, mais aussi contrôler si les applications déjà admises ne seront pas perturbées par cette nouvelle arrivée. Par exemple, une nouvelle application qui demande une certaine quantité de mémoire ne peut être admise que si elle est capable Firas ALHALABI 28

d atteindre cette quantité sans perturber la consommation des autres applications du système. Si ce n était pas le cas, d autres décisions doivent être généralement prises (rejet de l application, négociation, etc.). 2.7.5.3 Négociation La négociation peut intervenir dès l admission d une application. L application envoie un message demandant son admission avec des paramètres de QoS au gestionnaire de QoS. Si les exigences de l application ne peuvent pas être satisfaites, la requête de cette application sera rejetée. Pour remédier à ce rejet, un processus de négociation peut/doit être lancé afin d obtenir un accord entre l application et le système [VH97]. Cet accord permet de définir un nouveau point de fonctionnement pour exécuter l application. Le résultat de cet agrément, si tout se passe bien, est le contrat de QoS (Section 2.7.3) entre l application et le système de gestion. Les contrats de QoS peuvent être négociés une fois qu ils sont spécifiés en utilisant un langage de description des besoins de QoS comme QML [SJ98]. Le processus de négociation peut être re-effectué (appelé renégociation dans [VH97], [CJC00]) si les besoins de l application dépassent un seuil déterminé. 2.7.5.4 Surveillance Les mécanismes d observation (ou de surveillance) sont des fonctions vitales pour la gestion dynamique de la QoS et elles sont aussi parfois relativement complexes à mettre en œuvre et à analyser. Ces fonctions doivent être capables de détecter les surcharges de ressources, la violation du contrat de QoS en comparant (de façon continue comme dans [CJC00] ou discrète comme dans [VSM05]) les valeurs contractuelles de la QoS avec les valeurs réelles. En effet, l acceptation d une application pendant la phase d admission ne signifie pas que tout est réglé et qu il n y a plus rien à contrôler. Des situations diverses (surcharges momentanées, par exemple) peuvent conduire à la détérioration de la QoS de certaines applications, par exemple si la consommation contractuelle de mémoire pour un service est de 50Mo alors que la consommation réelle est de 70Mo. Pour cela, la surveillance de la QoS doit être considérée. Cela demande de mettre en œuvre des mécanismes pour vérifier que l exécution de l application se déroule comme prévu. Lorsque des variations excessives (par exemple, le dépassement d un seuil est constaté) sont détectées, le composant de Firas ALHALABI 29

surveillance (Monitoring) avertit l application via le gestionnaire de QoS. Dans ce cas, le gestionnaire informe l application de l arrivée d un message d alerte ou d erreur. L application peut alors décider d arrêter l exécution de cette partie ou demander une renégociation. Ensuite, le processus d adaptation dynamique peut/doit être déclenché. 2.7.5.5 Adaptation L un des principaux objectifs de l adaptation est d ajuster la QoS fournie par rapport au contrat accepté. Si la QoS n est pas conforme, une adaptation de la QoS peut être mise en place en utilisant une ou des politiques d adaptation. À chaque changement d état du système, le processus d adaptation contrôle que les ressources fournies correspondent bien à celles du contrat. Pour que l application puisse s adapter à son contexte d exécution, le gestionnaire doit posséder la possibilité de contrôler les applications comme nous allons le décrire plus tard. 2.8 Notions relatives au développement à base de modèles et de langages D après les sections précédentes, nous constatons que la construction d un système de gestion de la QoS n est pas une tâche facile. Pour faciliter cette tâche, cette section présentera quelques techniques qui vont nous aider à atteindre notre but. 2.8.1 L'approche MDA 2.8.1.1 Caractéristiques générales Après la programmation orienté objet (Object Oriented Programming, OOP), la programmation orienté aspect, (Aspect Oriented Programming, AOP [KLM97]), les composants, le modèle de service (services web), etc., la tendance actuelle du génie logiciel est de se focaliser sur les modèles, les méta-modèles et les méta-méta-modèles [BJB08]. Pour rendre le développement des applications plus rationnel, l OMG a défini une nouvelle initiative appelée MDA (Model Driven Architecture). Le principe de base de MDA est la construction d un ou plusieurs modèles indépendants des plates-formes (Platform Independent Model, PIM) et ensuite la transformation de ces modèles en modèles dépendants des plates-formes (Platform Specific Model, PSM). Les Firas ALHALABI 30

techniques utilisées dans l approche MDA sont donc essentiellement des techniques de construction de modèles d une part et des techniques de transformation de modèles d autre part. 2.8.1.2 Le principe PIM vs. PSM En fait, MDA distingue trois types de modèles : CIM (Computation Independent Model) : ce modèle, appelé modèle de domaine, modélise les exigences du système. Il montre le système dans l environnement organisationnel dans lequel il va être exécuté. L objectif de ce modèle est d aider à comprendre le problème mais aussi de fixer un vocabulaire commun pour le domaine en question. Les exigences exprimées dans le CIM doivent être traçables dans le PIM et le PSM. PIM (Platform Independent Model) : c est le modèle qui est indépendant des plates-formes techniques. Il décrit le système sans montrer les détails des plateformes. Le PIM représente par exemple les différentes entités fonctionnelles du système ainsi que les connexions entre celles-ci. Un PIM est raffiné autant de fois qu il est nécessaire pour obtenir le niveau de description souhaité. PSM (Platform Specific Model) : Ce modèle dépend des plates-formes techniques. Les PSM servent de base à la génération de code exécutable vers les plates-formes techniques. Un PIM suffisamment détaillé est projeté, par l intermédiaire du modèle de plateforme (Platform Model, PM), vers un PSM. L approche MDA identifie plusieurs types de transformations entre les PIM et les PSM de la manière suivante : 1. PIM vers PIM : La transformation PIM vers PIM est généralement appliquée pour ajouter (ou enlever) des informations aux (des) modèles, par exemple quand on passe de la phase d analyse à la phase de conception. Cette transformation est un raffinement et elle n est généralement pas automatisable. 2. PIM vers PSM : L opération qui consiste à ajouter des informations liées à une plateforme technique pour pouvoir enfin générer le code est une transformation PIM vers PSM. 3. PSM vers PSM : Ces transformations s effectuent lors des phases de déploiement, d optimisation, de raffinement ou encore de reconfiguration. Firas ALHALABI 31

Enfin, il faut noter que notre proposition sera définie indépendamment de la démarche MDA, mais elle se place dans le même courant de pensée dans la mesure où elle se propose de faciliter le développement d une famille de systèmes dans un domaine en utilisant des modèles. 2.8.2 Profil UML 2.8.2.1 Définition de profil Pour étendre le langage UML, une première possibilité consisterait à changer son méta-modèle en ajoutant de nouvelles structures (méta-classes, méta-attributs, méta-associations, etc.). Ce mécanisme n est autorisé qu à partir de la version 2.0 d UML et cela poserait des problèmes puisque les outils de modélisation UML devraient permettre de faire une extension d UML basée sur l ajout de nouvelles méta-classes. Le profil UML (UML Profile) est la deuxième possibilité pour faire une extension d UML. D après le document de UML [OMG07], A profile package can specify a related model library and identify a subset of the UML meta model that is applicable for the profile. In principle, profiles merely refine the standard semantics of UML by adding further constraints and interpretations that capture domain-specific semantics and modelling patterns. They do not add any new fundamental concepts. Le but principal du Profile est de faire une extension des métaclasses existantes pour différents objectifs sans définir de nouvelle métaclasse. Ce type d extension peut être atteint par les stéréotypes, les propriétés (tagged values) et les contraintes. Les éléments font références à des méta-classes de base et/ou des stéréotypes du package Profile. Un stéréotype permet de définir une sorte de nouvelle méta-classe. Il ne définit pas de nouvelle méta-classe mais utilise des méta-classes existantes en ajoutant une nouvelle sémantique adaptée au domaine. Chaque stéréotype doit toujours être associé à une méta-classe ou à un autre stéréotype. Textuellement, la définition des stéréotypes peut être clarifiée par un tableau avec trois colonnes : (i) Stereotype : Présente le nom du stéréotype défini ; (ii) Base : Indique la classe de base d UML qui généralise ce stéréotype ; (iii) Description : Dans laquelle, on précise la sémantique de ce stéréotype. Le profil UML définit des notions mais aussi des conventions et directives pour utiliser ces notions. Nous pouvons également utiliser des notations graphiques pour modéliser la relation entre ce nouveau stéréotype et la classe de base d UML qu il généralise comme Firas ALHALABI 32

dans [PL01]. La Figure 2-1 illustre la définition d un nouveau stéréotype «Service» qui étend la méta-classe Class. Les tagged values sont équivalentes aux méta-attributs des métaclasses. Elles sont attachées aux stéréotypes et elles spécifient les propriétés de la nouvelle pseudo méta-classe. Les contraintes sont utilisées pour définir des restrictions d utilisation pour la nouvelle méta-classe [SK05]. Elles sont associées aux stéréotypes modélisant un élément UML. Les contraintes peuvent être spécifiées soit via un langage de contraintes dédié comme OCL (Object Contraintes Language) [OMG06], soit en langage naturel. Un élément marqué par un stéréotype doit respecter les contraintes définies pour ce stéréotype et définir les propriétés associées. Enfin, il faut noter que nous pouvons appliquer plusieurs profils différents sur le même modèle. «metaclass» Class «stereotype» Service Figure 2-1 : La définition d un nouveau stéréotype dans UML. 2.8.3 DSL/DSM Domain Specific [Modeling] Language L approche DSM (Domain Specific Modeling) met en avant une méthodologie de développement centrée sur la notion de domaine visant principalement à améliorer la productivité. L idée centrale de l approche DSM est de construire un langage de modélisation spécifique à un domaine (DSML ou DSL). Chaque utilisateur DSM doit définir son propre langage. Ce langage dédié fournit des notations et des constructions adaptées à la sémantique d un domaine. Contrairement au langage généraliste qui permet de répondre à une large classe de problèmes, un DSL se focalise sur des besoins particuliers et précis. Un point qui doit être considéré est l opportunité d'utiliser ou non UML pour la définition des langages spécifiques à un domaine. En effet, Un DSL peut être défini soit en utilisant UML (par extension), soit un autre langage de modélisation, soit à partir de zéro. L utilisation d UML pour définir des DSLs n est donc pas obligatoire. Cependant, sans utiliser UML, Firas ALHALABI 33

la définition de chaque DSL pour modéliser les concepts d un domaine demande de définir un nouveau méta-modèle. Ceci augmente la charge de développement d un DSL comparé aux résultats espérés, alors que le profil UML est basé sur le méta-modèle UML lui-même. Les principales limitations des DSLs non-basés sur UML et qui nous ont freinés pour choisir cette solution sont : 1. Il peut être nécessaire de fournir un DSL pour décrire chaque aspect du système (par exemple, la performance). Cette situation pose le problème d intégration de tous ces langages. Pour éviter un tel problème, nous allons utiliser uniquement le langage UML. 2. Il n est pas simple de faire évoluer un langage alors que, comme nous l avons vu, UML inclut un mécanisme de profil qui lui permet d être contraint et spécialisé pour des domaines et/ou des plates-formes spécifiques, mais aussi de faire des extensions pour ajouter des notions supplémentaires. 3. Nous pouvons ajouter les coûts de développement du DSL et de l outillage associé pour chaque domaine. 2.8.4 Software Product Line Une ligne de produit logiciel (Software Product Line, SPL) est un ensemble de systèmes partageant un ensemble de propriétés communes et satisfaisant des besoins spécifiques pour un domaine particulier [ZJ06]. Cependant, les préoccupations des lignes de produits logiciels sont relatives aux entreprises industrielles qui veulent mieux gérer le développement de leurs systèmes [BHJ03]. Bien qu elles soient proches de nos travaux, elles visent à représenter des produits qui répondent à la demande de segments de marché à faible couplage, alors que notre approche porte sur les concepts et la sémantique d'un domaine avec une grande cohésion. Puisqu un segment de marché est plus large qu un domaine, SPL introduit pas mal de points de variation, alors que, comme nous allons voir, notre cadre traite d'une grande partie commune avec peu de variabilités. De même que dans l approche SPL, dans notre approche, certaines transformations génériques communes seront réalisées automatiquement. 2.9 Conclusion Nous avons vu dans ce chapitre que la QoS des applications est spécifiée par un sous-ensemble de propriétés non-fonctionnelles. La gestion de la QoS consiste à trouver le meilleur niveau de satisfaction des contraintes Firas ALHALABI 34

spécifiées par ces applications. La problématique principalement considérée était celle de la disponibilité de ressources et de la garantie d un niveau de QoS. Étant principalement reliée au problème de changement dans le contexte d exécution, la réalisation de la gestion de la QoS trouve une solution dans la technique de l adaptation. Cette technique permet aux applications distribuées ou non distribuées de fournir, du moins partiellement, leurs services malgré les changements et les variations des environnements d exécution. La problématique autour de la QoS évolue sans cesse. Aujourd hui la communauté scientifique s intéresse également à la question de la facilité de programmation et de modification de la QoS d une application à un haut niveau d abstraction. L expérience acquise lors des études présentées et la motivation de vouloir éviter la reprogrammation complète de l application ont orienté les recherches vers la modélisation, la métamodélisation et la construction d une famille de systèmes voisins au lieu d un seul système. La fin de ce chapitre a été consacrée à la présentation de notions qui serviront à décrire notre proposition. Le chapitre suivant propose un modèle générique pour la conception des applications contrôlées par un système de gestion de la QoS. Nous décrivons également l architecture de gestion avec les différentes politiques de gestion de la QoS. Une comparaison de ces politiques est aussi présentée. Firas ALHALABI 35

Chapitre 3 Application et Environnement d Exécution 3.1 Introduction Pour gérer la QoS globale du système via une couche logicielle commune à toutes les applications, nous avons besoin d un modèle générique des applications. En s appuyant sur le modèle générique, les applications pourront échanger des messages avec le système de gestion de la QoS en utilisant un protocole commun. De plus, pour cet échange de messages, il faudra décrire l environnement dans lequel les applications s exécutent. Dans ce chapitre, nous présentons dans un premier temps notre modèle générique des applications. Puis, nous améliorons ce modèle pour qu il prenne en compte d autres aspects comme la synchronisation. Enfin, nous présentons l exemple d une application de transfert de données. Le deuxième point principal de ce chapitre concerne l architecture du système de gestion. Nous définissons trois politiques de gestion : centralisée, décentralisée complète et décentralisée partielle. Ensuite, nous comparons ces politiques en s appuyant sur le nombre de messages échangés pour chacune de ces politiques. Nous concluons ce chapitre par la présentation de résultats graphiques. 3.2 Modèle de l application La Figure 3-1 détaille le modèle de communication possible entre l application et la couche de gestion. L objectif est de gérer la QoS globale des applications en utilisant un protocole commun permettant la communication entre l application et la couche de gestion (middleware). Dans ce chapitre, nous détaillons les éléments relatifs à la partie Application de cette figure. Firas ALHALABI 36

Not Loaded Application Load/ Send(m,EndOfStep) Communication Protocol Middleware Loaded /Send(m,EndOfStep) Running Waiting do/activity NextStep(operatingMode) a : Application m : Middleware NextStep(operatingMode) EndOfStep() Figure 3-1 : La communication entre l application et le middleware. 3.2.1 Structure des applications Afin de gérer la QoS des applications via un protocole commun, nous proposons au préalable de définir un modèle général des applications sous forme d un graphe [AVM06]. Chaque nœud de ce graphe est un point de décision. Les points de décision explicitent des choix d arcs qui induisent chacun un comportement différent. C est via ce mécanisme que les applications s adaptent dynamiquement à leur contexte d exécution. En pratique, un arc est associé à l exécution d une action qui est une portion quelconque de code métier de l application. L exécution d une application est donc un parcours de ce graphe et la quantité de ressources consommée est ajustée (c est-à-dire, modifiée en adaptant le comportement) uniquement en des points de décision prédéfinis. Les choix effectués à un point de décision sont valables jusqu au point de décision suivant. La Figure 3-2 illustre le modèle générique que nous avons proposé pour une application. Il faut noter qu un point de décision correspond à un niveau d avancement de l application, mais ce n est pas un état. Quand il y a un Execution Path Decision point Node N 1 Action Node N 2 a : Exécution sur un nœud. b : Exécution sur deux nœuds. Figure 3-2 : Modèle générique des applications sous forme de graphe. Firas ALHALABI 37

cycle dans le graphe, l état réel de l application est a priori différent à chaque fois que l on repasse dans un point de décision. Le graphe n est donc pas un diagramme d états UML, mais un parcours. Pour adapter le comportement de façon continue, il suffirait d avoir des points de décision infiniment proches afin de pouvoir changer le comportement à tout moment. En pratique, cela signifierait pouvoir arrêter le traitement en cours à tout moment pour commencer un nouveau traitement, ce qui est difficilement réalisable par essence (l exécution des instructions est discrète). Dans le modèle discret proposé, il suffira de rapprocher suffisamment les points de décision pour obtenir une adaptation quasi continue. Les sous-sections suivantes complètent notre modèle d application et clarifient les possibilités de choix. 3.2.2 Graphe d'exécution et Phases Dans le cas où plusieurs applications sont actives simultanément, chacune d elles suit un chemin particulier dans son graphe. C est le cas d une application monothread comme dans la Figure 3-3a ou multithreads (distribuées ou non) comme dans la Figure 3-3b. Dans le cas des applications multithreads, plusieurs chemins sont Emergency a : Application mono-thread changement de plan (endroit quelconque) Normal b : Application multi -thread c : Application avec plusieurs plans de choix Figure 3-3 : Modèle de l application avec la définition des phases. Firas ALHALABI 38

parcourus en parallèle. Avec un système de préemption, une application peut être arrêtée au cours de son chemin mais cela n a pas d influence sur les principes. Sauf en cas (anormal) de destruction de l application, elle reprend son cours sur son chemin lorsque les ressources nécessaires lui sont attribuées. Pour augmenter et clarifier les possibilités de choix, une application peut définir des "phases" et leurs associe un ensemble de choix d arcs différents. Les phases sont par exemple : initialisation, normal, etc. Au moment du changement de phase de l application, tout se passe comme s'il y avait un changement de plan avec de nouvelles possibilités : l action en cours se termine et l action suivante sera choisie dans le nouveau plan (Figure 3-3c). À cet effet, les applications pourraient encore s adapter à leur contexte en demandant la modification de leurs phases d exécution. Dans ce cas l exécution se déroulera comme si elle était dans le nouveau plan. Cette solution a été retenue pour le système de gestion présenté dans [CS03]. Les phases y sont par exemple : initialisation, normal, panique, urgent. L application change la phase en sélectionnant le nouveau plane. 3.2.3 Amélioration du modèle Le modèle d application proposé est suffisant pour exprimer la capacité d adaptation, mais pour augmenter la puissance d expression, il peut être enrichi. Par exemple pour indiquer qu une échéance est relative à une suite d actions, il faudrait définir une zone par rapport au point de départ (Figure 3-4a). La deuxième amélioration possible est de découper une action du graphe en des étapes (steps) de manière à explicitement introduire des rendez-vous (Figure 3-4b) : quand l application A 2 arrive en point P 2, il attend que l application A 1 soit arrivée en point P 1 s il n est pas déjà passé. Nous détaillons ce point dans les sous-sections suivantes. deadline P 1 steps A 1 A 2 P 2 a : Spécification d une échéance. Figure 3-4 : Améliorations du modèle générique. b : Synchronisation entre deux étapes. Firas ALHALABI 39

3.2.4 Langage de description des applications Nous avons proposé un formalisme de description des applications [VSM05]. Le modèle de ce formalisme est illustré dans la Figure 3-5. Une application est composée d une ou plusieurs unités de planification (Scheduling Unit, SU). Chaque unité peut contenir une ou plusieurs activités (Activity). Le modèle montre aussi clairement qu à chaque activité d une application est associé un mode d exécution (mode) et une utilité (Utility qui présente l intérêt d utiliser le mode, Section 2.7.4) valable pour toutes les étapes (Steps) qui composent l activité. À la différence d une activité qui peut s exécuter sur plusieurs nœuds, une étape est toujours associée à un seul nœud. Les étapes sont également utilisées pour séparer les traitements associés à des besoins en ressources variés dans la même activité. La consommation de ressources est définie au niveau de chaque étape et dépend du nœud d exécution. La planification (Planning) porte sur une succession d activités, mais une activité commencée dans un mode se termine toujours dans le même mode d exécution. Un changement de phase pourrait être effectué au moment d exécution d un mode anormal par exemple. Dans le modèle présenté Figure 3-3, le changement de phase s effectue uniquement aux points de décision. Application LocalApplication 1 #schedulingunits 0..1 SchedulingUnit #next delay : Time pathid #refrdv RdV parallel : Boolean {ordered} 0..1 #rdv 1..n #activities PhaseId Activity modeid 1 #mode Mode utility Aect : Integer 1..n #steps Step * {ordered} #phase Hardware 0..n #requirements Resource global : boolean Figure 3-5 : Le modèle UML d'une application. Firas ALHALABI 40

Les applications distribuées sur plusieurs nœuds sont associées à plusieurs applications locales (LocalApplication, LA), chacune s exécutant sur un nœud. Une application locale sera associée à un nœud physique au moment de l exécution. Pour toutes les applications qui s exécutent sur un même matériel (Hardware), il ne sera créé qu une seule occurrence de la class Hardware. Etant donné qu une application doit pouvoir s exécuter sur n importe quel matériel, à la création d une "LocalApplication", le matériel sur lequel celle-ci s exécutera lui est inconnu. Ce lien sera créé dynamiquement. De plus, un mécanisme de rendez-vous (RdV dans la Figure 3-5) permet de synchroniser l exécution de deux étapes n appartenant pas à la même application locale. 3.2.5 Exemple La Figure 3-6 schématise l exemple d une application distribuée de transfert de données sur deux nœuds, décrit Tableau 3-1. Cet exemple est présenté en utilisant le formalisme du diagramme d activité UML [ANA08]. Après le chargement de l application (Load dans le Tableau 3-1) sur les nœuds N 1 et N 2 et l acquisition de données (Acquisition) sur le nœud N 1, ces données sont soit envoyées directement (Transmission 1 ) ou compressées (Compression) avant d'être envoyées (Transmission 2 ). Le nœud N 2 reçoit les données directement (Reception 1 ) ou reçoit et Tableau 3-1 : Un exemple d'une application de transfert de données. Unité de planification (SU) Activité (Activity) Mode étape (Step) Utilité (Utility) Node (Nœud) Load N 1 Start Initialisation 1 100 Load N 2 Sample Acquisition 1 Acquisition 100 N 1 Transmission Display 1 Transmission1 N 1 100 Reception1 N 2 Compression N 1 2 Transmission2 N 1 100 Reception2 N 2 Decompression N 2 1 Display1 100 N 2 2 Display2 80 N 2 Firas ALHALABI 41

Noeud 1 Noeud 2 Rendez-vous Activity Mode Acquisition Decision Point [2] [1] Compression Transmission 1 Reception 1 Transmission 2 Reception 2 Decompression [1] [2] Display 1 Display 2 Final State Figure 3-6 : Un exemple d application sous forme de diagramme d activité en UML. décompresse ces données (Reception 2, Decompression). Au final, les données sont affichées soit en mode 1 (Display 1 ) ou en mode 2 (Display 2 ). Comme le montre le Tableau 3-1, le transfert direct ou la compression avant la transmission définissent deux modes avec la même utilité, tandis que les deux affichages possèdent deux utilités différentes. En ce qui concerne la transmission de ces données, l adaptation est effectuée sans perte de qualité car les deux modes ont la même utilité (100), mais il serait possible de définir un autre mode incluant une compression avec perte et avec une utilité inférieure pour accomplir l adaptation avec une dégradation "gracieuse". De plus, le modèle de cet exemple permet de prendre en compte ce que nous appelons un point de rendez-vous. Ce point de rendez-vous indique que deux étapes doivent commencer leur exécution simultanément. Par exemple, la transmission (Transmission 1 ) et la réception (Reception 1 ) des données sur notre modèle doivent être parallélisées. Firas ALHALABI 42

3.3 Gestion centralisée vs. décentralisée En plus du modèle générique des applications que nous avons proposé dans la section 3.2, la description de l architecture de gestion joue un rôle très important pour le développement d un système de gestion de la QoS. Nous rappelons qu une application est distribuée sur plusieurs nœuds (LocalApplication). Par exemple, une application app 1 peut être distribuée entre le nœud N 1 (app 1.1 ) et le nœud N 2 (app 1.2 ). Afin de gérer au mieux la QoS globale des systèmes distribués, nous discutons dans ce qui suit les différentes possibilités qui permettent de mettre en œuvre cette gestion. Nous distinguons deux politiques de gestion [ANA08] : politique centralisée (Centralized Policy) et politique décentralisé (Decentralized Policy). Cette dernière est, à son tour, divisée en deux sous-types : décentralisée complète (Fully Decentralized) et décentralisée partielle (Partial Decentralized). Nous présentons une étude comparative entre ces trois politiques de gestion. 3.3.1 Gestion centralisée Dans l approche centralisée (Figure 3-7), un seul gestionnaire global (Global Manager, GM) détient la description complète de toutes les applications, mais aussi la description de l environnement dans lequel les applications s exécutent. Ce gestionnaire unique ajuste et planifie l utilisation de toutes les ressources (locales et globales) pour toutes les applications en vue de maximiser la QoS globale du système. Chaque nœud possède un gestionnaire local (Local Manager, LM). Ce gestionnaire local joue le rôle d intermédiaire entre les applications et le gestionnaire global. L inconvénient de cette approche est l existence d un point unique de gestion : si ce point central tombe en panne, le système est bloqué (ou inopérant). 3.3.2 Gestion décentralisée Dans l approche décentralisée, la gestion des ressources est répartie entre un ensemble de gestionnaires (gestionnaires locaux et/ou globaux). Pour définir l architecture d une approche décentralisée, plusieurs choix sont possibles. Nous avons proposé la gestion décentralisée complète (Fully Decentralized) et la gestion décentralisée partielle (Partial Decentralized). Firas ALHALABI 43

N 1 N2 LM1 LM2 app1.1 app3 Net Net app1.2 app2.3 N0 GM Application and environment descriptions with local and global plannings N4 LM4 Net Net N3 LM3 app2.1 app2.2 app4 Figure 3-7 : L architecture de déploiement de la politique centralisée. 3.3.2.1 Décentralisée complète Dans l approche décentralisée complète (Figure 3-8), la description des applications ainsi que celle de l environnement sont stockées sur chaque nœud. Cette technique de stockage permet de diminuer le volume d informations transférées sur le réseau lors des communications. Pour cette approche, il n existe pas de gestionnaire global. Cependant, sur chaque nœud un gestionnaire local prend en charge non seulement la gestion de ses ressources locales, mais aussi les ressources globales nécessaires pour la gestion ainsi que la synchronisation des plannings pour les traitements distribués. Chaque nœud peut communiquer avec n importe quel autre nœud du système. Il possède le planning des ressources locales ainsi que le planning partagé des ressources globales. L inconvénient de cette approche est le coût à cause du nombre de communications très élevé. 3.3.2.2 Décentralisée partielle L approche décentralisée partielle (Figure 3-9) est un compromis entre l approche centralisée d une part et décentralisée complète d autre part. Firas ALHALABI 44

Dans cette approche, chaque nœud détient la description des applications (qui exécutent sur lequel) ainsi que le planning des ressources locales. Un nœud central possède la description de l environnement, la description des applications et le planning des ressources globales. De cette manière, la gestion des ressources est effectuée en deux étapes : (i) Sur N1 LM1 app1.1 Local1 and global planning with application and environment description Local2 and global planning with application and environment description Net N2 LM2 app1.2 app3 app2.3 Net Net Net Net N4 LM4 app2.1 Local4 and global planning with application and environment description Net Local3 and global planning with application and environment description N3 LM3 app2.2 app4 Figure 3-8 : L architecture de déploiement de la politique décentralisée complète. chaque nœud, un gestionnaire local (LM) a la responsabilité de la gestion des ressources locales. C est la seule entité qui connaît le planning de ses ressources ; (ii) Un des nœuds héberge le gestionnaire global (GM). C est ce gestionnaire global qui a la responsabilité de la gestion des ressources partagées entre plusieurs nœuds. De plus, le gestionnaire global se charge de synchroniser les plannings des différents nœuds lorsqu une ressource partagée est utilisée. Le problème du point unique de commande reste le même que dans le cas de l approche centralisée. Cependant, pour cette approche si le point central tombe en panne, certaines applications peuvent continuer leur exécution. Nous pouvons ajouter le problème de la synchronisation des plannings locaux et globaux qui est un problème délicat dans cette approche. Firas ALHALABI 45

N1 LM1 Loca1 planning with application description Local2 planning with application description N2 LM2 app1.1 app3 Net Net app1.2 app2.3 N0 GM Global Planning, Full application & environnement description N4 N3 LM4 Net Net LM3 app2.1 Loca4 planning with application description Loca3 planning with application description app2.2 app4 Figure 3-9 : L architecture de déploiement de la politique décentralisée partielle. 3.3.3 Estimation des coûts Afin de donner une idée de l évolution du nombre d échanges liés à la planification distribuée en vue de comparer les approches présentées cidessus, considérons les hypothèses énumérées ci-après : 1. Le planning est vu comme l occupation des ressources locales sur chacun des nœuds et/ou l occupation des ressources partagées. Ce planning doit être modifié quand on tombe sur un nouveau traitement à planifier (c est-à-dire, pour chaque nouvelle étape). 2. Nous considérons la synchronisation d au plus deux traitements répartis sur au plus deux nœuds. Autrement dit, si une ressource globale est concernée alors deux nœuds sont impliqués, par exemple pour transférer un fichier d un nœud vers un autre avec deux traitements Transmission et Reception. La synchronisation entre plus de deux nœuds n est pas considérée dans ce mémoire. 3. Seule une ressource par nœud est prise en compte. Par exemple, la ressource processeur sur un nœud pour pouvoir effectuer un traitement. Firas ALHALABI 46

4. Chaque décalage d une étape synchronisée dans le planning entraîne le décalage de son étape associée et le cas échéant des étapes précédentes (Figure 3-10). 5. Chaque introduction d étapes synchronisées peut entraîner des décalages successifs sur les nœuds dont les étapes sont déjà synchronisées. Les décalages s effectuent en remontant dans le temps donc, les modifications déjà effectuées sur un nœud ne sont pas remises en cause par les nouvelles modifications. 6. Le coût des communications locales (c est-à-dire les communications entre les gestionnaires locaux et les applications et vice-versa) est négligé (ce sont les mêmes pour toutes les approches). 7. Le coût de planification est évalué en nombre d échanges (c est-à-dire messages échangés) entre les nœuds. 3.3.4 Comparaison : échanges de messages Dans cette section, notre discussion est limitée au coût des échanges étant donné que le coût de planification varie très peu d une approche à l autre et qu il est de plus négligeable devant le temps nécessaires pour l échange de messages entre les nœuds du système (nous avons utilisé une différence d un facteur 1000 mesuré sur le système présenté dans [VSM05]). Afin de calculer le coût total des échanges, nous utilisons notre exemple du Tableau 3-1. En s appuyant sur cet exemple, nous considérons deux phases : (i) La phase de l admission ; (ii) La phase de gestion des étapes qui concerne l exécution de ces étapes et leur synchronisation. Les diagrammes de séquences seront utilisés pour montrer les messages échangés et compter leur nombre. Comme nous l avons vu, les applications pourraient être exécutées dans plusieurs modes de fonctionnement. Par souci de simplification, nous supposons qu il existe un seul mode par point de décision. Le Tableau 3-2 définit les variables que nous allons utiliser pour calculer le nombre de messages échangés entre les nœuds pour les trois politiques de gestion proposées. Firas ALHALABI 47

Tableau 3-2 : La définition des variables utilisées. Variable Node Step Sync Shift Description Le nombre de nœuds dans le système Le nombre d étapes exécutées Le nombre d étapes qui utilisent des ressources globales Le nombre d étapes qui utilisent des ressources globales déplacées durant le test d admission. Avant de faire la comparaison entre les trois politiques, la Figure 3-10 illustre les traitements qu il est nécessaire de déplacer pour permettre à un nouveau traitement d être inséré dans le planning. Les lettres (a), (b), (c), (d), (e) désignent les étapes qui utilisent des ressources globales et qui nécessitent une synchronisation. Dans ce planning, les nœuds qui supportent les étapes synchronisées (b) et (e) ne sont pas tous explicitement présentés pour ne pas charger le dessin. La synchronisation de deux nœuds Now loc d d c d1 d2 CPU 1 (N 1 ) loc c CPU 2 (N 2 ) d e b a c Net (N 0 ) loc a loc CPU i (N i ) e loc a CPU n (N n ) Figure 3-10 : Exemple de planification des ressources, illustrant le décalage d étapes. Firas ALHALABI 48

indique que deux étapes utilisent la même ressource globale (par exemple, la ressource globale Net est utilisée par l étape (a) sur la Figure 3-10). La ressource globale est gérée par un gestionnaire global sur le nœud dédié N 0. Les étapes loc sont locales dans le sens où elles utilisent uniquement des ressources locales. De ce fait, pour l approche décentralisée, le coût des échange (c est-à-dire, le nombre de messages échangés) entre deux nœuds est très grand en comparaison au coût de traitement local (c est-à-dire, pour les étapes loc). Les applications strictement locales sont planifiées et contrôlées localement ce qui limite les échanges de messages pour le contrôle de ce type d applications. Enfin, chaque flèche verticale sur la figure représente une échéance d étape. Afin de compter le nombre de messages échangés, pour simplifier nous considérons uniquement une admission et un nombre donné d étapes. En s appuyant sur le planning de la Figure 3-10, pour chacune des politiques de gestion, la position du planning (ou une partie de celui-ci) ainsi que les messages échangés seront décrits dans les sous sections suivantes. 3.3.4.1 Centralisée Comme nous l avons vu dans la section 3.3.1, dans le cas de la gestion centralisée, les applications attendent des ordres envoyés par le gestionnaire global (Global Manager, GM) par le biais de son gestionnaire local (Local Manager, LM). Admission : pour admettre une application distribuée sur deux nœuds, chaque LM envoie une requête au GM. Les deux nœuds qui accueillent les parties de l application attendent des décisions pour exécuter. Ainsi, 2 messages sont échangés (NextStep(mode) // Load). À la fin de chaque étape de chargement, un message EndOfStep() est envoyé au GM. Nous avons donc 2 messages. Au total, 2+2=4 messages échangés pour l admission. Gestion d étapes : pour la gestion des étapes, le GM lance les étapes sélectionnées sur chaque nœud. Pour la synchronisation des étapes, le GM informe les deux nœuds concernés de débuter le traitement simultanément (Figure 3-11). Le message NextStep(mode) permet de contrôler l exécution des applications en précisant le mode de fonctionnement. De son côté, chaque LM notifie le GM de la fin d exécution de l étape, EndOfStep(). Nous avons donc 2 messages pour chaque étape synchronisée (Étapes : Transmission, Reception). Ainsi, pour Step étapes exécutées, il existe (2*Step) messages échangés pour la gestion des étapes. Firas ALHALABI 49

N1:LM1 N0:GM N2:LM2 1: NextStep(mode) // Load unique mode in fact 3: EndOfStep() 2: NextStep(mode) // Load Admission 4: EndOfStep() 5: mode=modescheduling() 6: NextStep(mode) // Transmission 8: EndOfStep() 7: NextStep(mode) // Reception 9: EndOfStep() Gestion d étapes Figure 3-11 : La synchronisation des étapes pour notre exemple d application. Résultat : En tenant compte des 4 messages pour le test d admission, nous avons au total (2*Step+4) messages échangés en utilisant l approche centralisée. 3.3.4.2 Décentralisée complète En général, l approche décentralisée nécessite de garantir la cohérence des données. Pour l approche décentralisée complète, nous avons introduit la notion de jeton : c est le nœud qui possède ce jeton qui peut modifier le planning global et qui possède donc la dernière version à jour du planning global. Admission : pendant la phase d admission, le nœud qui hôte la première partie de la nouvelle application envoie (Node-1) messages pour informer tous les autres nœuds. Quand la deuxième partie de cette application arrive, le nœud qui accueille cette deuxième partie répond en envoyant 1 message. Puis, il demande le jeton du nœud qui possède la version à jour du planning globale (1 message) et il le reçoit (1 message) Firas ALHALABI 50

pour accomplir l admission. Ainsi, nous avons (Node-1+ 1+1+1=Node+2) messages concernant l admission d une application. Afin d éviter une collision des ressources globales (ressource communes), l insertion de certaines étapes dans le planning nécessite un décalage d étapes. Par exemple, afin d admettre l étape (d) dans le planning (Figure 3-10), il est nécessaire d avancer l étape (a). La Figure 3-12 illustre les échanges des messages nécessaires pour le décalage qui concerne l étape (a). Le décalage de l étape (a) entraîne la modification (ou décalage) en cascade de la planification des couples d étapes (b) et (e) sur le nœud du gestionnaire global N 0. Durant l admission, les deux nœuds qui sont concernés par un décalage d étapes échangent des messages : (2*Shift) messages sont échangés dans le cas où le test d admission requiert le déplacement de Shift étapes. Chaque nœud envoie un message de validation aux autres nœuds, nous avons donc au plus (Node-1) messages pour valider. Ainsi, durant la phase du test d admission, il existe au plus (Node+2+ 2*Shift+ Node-1= 2*Shift+2*Node+1) messages. N0:GM Ni:LMi Nn:LMn 1: shift(a) 2: shift_ok() 3: shift(a) 4: shift_ok() 5: validate() 6: validate() Figure 3-12 : Les échanges des messages nécessaires pour décaler l étape (a) qui utilise la ressource globale Net. Gestion d étapes : au début de chaque étape utilisant des ressources globales, le premier nœud concerné demande le jeton et reçoit une réponse (2 messages). Puis il envoie 1 message au second nœud synchronisé (qui répond par 1 message) pour débuter l exécution. Par Firas ALHALABI 51

exemple, Transmission1 du nœud N 1 et Reception par N 2. Puisque Sync est le nombre d étapes qui utilisent des ressources globales, Pour Sync étapes, il existe (2*Sync) messages. Résultat : au final, nous avons donc (2*Sync+2*Shift+2*Node+1) messages pour cette approche. 3.3.4.3 Décentralisée partielle Comme dans l approche centralisée, l admission débute quand les deux parties de l application sont soumises au gestionnaire global (GM). Le planning des ressources globales est mis à jour et les deux nœuds concernés sont informés pour réserver les ressources nécessaires. Admission : Pour calculer le nombre de messages échangés pour le test d admission, nous considérons deux cas de figures : sans décalage et avec décalage. Sans décalage : comme la Figure 3-10 le montre, l admission de l étape (c) qui utilise une ressource globale est assez facile puisqu elle n exige aucun décalage. Après que les deux nœuds concernés ont envoyé deux messages pour le test d admission (admit (app,c) sur la Figure 3-13), tous les deux reçoivent un message de confirmation (reply() sur cette figure). Dans ce cas, nous avons donc 4 messages. Avec décalage : le cas de l étape (d) qui utilise une ressource globale est un peu plus complexe : comme nous l avons vu, l insertion de l étape (d) dans le planning requiert le décalage des étapes (a), (b) et (e). Cependant pour déplacer une étape utilisant une ressource globale (par N1:LM1 N0:GM N2:LM2 1: admit(app,c) 2: admit(app,c) 3: reply(ok) 4: reply(ok) Figure 3-13 : L admission de l étape (c) utilisant la ressource globale Net. Firas ALHALABI 52

exemple, l étape (a)) deux nœuds sont concernés (N i et N n ). Dans ce cas, 1 message est envoyé à chaque nœud pour décaler l étape concernée (message shift(a) sur la Figure 3-12). Ensuite, chaque nœud répond en envoyant 1 message (message shift_ok() sur la Figure 3-12). Pour (Shift) étapes globales (c est-à-dire les étapes qui utilisent des ressources globales) déplacées, il existe (2*Shift) messages échangés au moment de l admission. En plus, nous avons (Node-1) messages maximum pour valider (Validate()). Au final, nous avons 4 messages pour le test d admission de l étape (c) qui utilise une ressource globale (cas facile sans décalage) et (2*Shift+Node-1+4) pour le test d amission de l étape (d) (cas plus difficile avec décalage). Gestion d étapes : concernant la phase de gestion d étapes, puisque pour cette politique, seuls les gestionnaires locaux (LM) qui gèrent les ressources locales, il n existe aucun message échangé pour gérer les étapes locales. De cette manière, il n existe ni un message pour indiquer la fin de l étape (EndOfStep()), ni un message pour exécuter l étape suivante (NextStep()). Cependant, il est important de savoir qu avant d utiliser une ressource globale, 1 message est envoyé du gestionnaire local au gestionnaire global pour savoir si le second nœud est prêt pour la synchronisation (Figure 3-14). Par exemple, pour synchroniser N1:LM1 N0:GM N2:LM2 1: I_am_ready() 2: are_you_ready() 3: yes () 4: mode= modeselelection() 5: NextStep(mode) // Transmission 6: NextStep(mode) // Reception 7: EndofStep() 8: EndofStep() Figure 3-14 : La synchronisation des activités de notre exemple. Firas ALHALABI 53

Transmission 1 avec Reception 1 sur les nœuds N 1 et N 2, les deux nœuds doivent être prêts. À cet effet, N 1 envoie 1 message (I_am_ready()) à N 0 (qui accueille le GM) pour savoir si la transmission est possible. À son tour N 0 envoie 1 message (Are_you_ready()) à N 2 pour savoir s il est prêt. Après la réponse du nœud N 2 par 1 message (message yes() dans la Figure 3-14), les deux nœuds N 1 et N 2 sont notifiés par le GM hébergé sur le nœud N 0, et les étapes Transmission/Reception sont lancées (NextStep(mode) dans la Figure 3-14). Nous avons donc 1+1+1=3 messages échangés pour chaque étape globale utilisée. Rappelons que Sync est le nombre d étapes qui utilisent des ressources globales. Par conséquence, le nombre de messages échangés pour gérer Sync étapes synchronisées est donc (3*Sync). Résultat : au final, nous avons (4+3*Sync) messages pour l étape (c) (cas facile sans décalage). Cependant, le nombre total de messages échangés est (2*Shift+3*Sync+Node-1+4) pour le cas complexe de l admission (c est-à-dire, admission de l étape (d) qui utilise la ressource globale Net). Le Tableau 3-3 résume les nombres de messages échangés que nous avons obtenus pour chacune de nos politiques de gestion. 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. Approche Admission Gestion d étapes Centralisée 4 2*Step Décentralisée partielle (cas simple) Décentralisé partielle (cas complexe) 4 2*Shift + Node -1 +4 3*Sync Décentralisée complète 2*Shift + 2*Node + 1 2*Sync Firas ALHALABI 54

3.3.5 Résultats graphiques Le nombre de messages échangés entre les nœuds (noté Msg) dépend de la politique de gestion et est exprimé en fonction de variables. Ces variables sont le nombre de nœuds Node, le nombre d étapes synchronisées Sync et la charge du système (représentée par la variable Shift). Dans cette section, nous présentons sous forme graphique y=f(x), les résultats que nous avons obtenus pour illustrer et valider notre démarche. La Figure 3-15 donne le nombre de messages échangés en fonction de la variable Sync, c est-à-dire, Msg=f(Sync). Dans cette figure, nous utilisons le pourcentage des applications distribuées en fixant les paramètres Shift et Node : Shift=1, Node 6. Les trois courbes montrent le nombre de messages échangés qui sont relatifs à la gestion des étapes tout en augmentant le nombre d étapes synchronisées. À partir d un certain point de Sync, l approche décentralisée complète est meilleure que l approche décentralisée partielle. L approche centralisée est le meilleur choix car le nombre de messages échangés est indépendant des étapes synchronisées. Centralized Partial Decentralized Fully Decentralized 60 Exchanged messages 50 40 30 20 10 0 1 2 3 4 5 6 7 8 9 Sync Figure 3-15 : Le nombre de messages échangés Msg = f(sync), Node 6. La Figure 3-16 donne le nombre de messages échangés durant l admission en fonction de la variable Shift, c est-à-dire, Msg=f(Shift). Quand le système est surchargé, la valeur de Shift augmente. Nous présentons le nombre de messages échangés pour chacune de nos politiques en fixant la valeur de Sync à 8, Node 10. Dans ce cas, l approche Firas ALHALABI 55

Centralized Partial decentralized Fully decentralized 60 Exchanged messages 50 40 30 20 10 0 1 2 3 4 5 6 7 8 9 Shift Figure 3-16 : Le nombre de messages échangés Msg = f(shift) pour Node 10. décentralisée complète requiert moins de messages que l approche décentralisée partielle. En augmentant la valeur de Node, cette différence également s augmente. Pour résumer, l approche décentralisée conduit à un nombre important d échanges pour la planification d applications distribuées, mais les coûts engendrés par le contrôle des applications strictement locales (peu de synchronisation) sont économisés avec une approche décentralisée. Au final, la politique adoptée pour l approche décentralisée n est pas efficace pour diminuer le nombre de messages échangés, il faut donc trouver une autre politique pour la gestion de ressources et rendre l approche décentralisée beaucoup plus performante. 3.4 Conclusion Dans ce chapitre, nous avons proposé un modèle générique pour la conception des applications qui seront gérées par un système de gestion de la QoS. Nous avons également proposé trois politiques de gestion de la QoS. Ces trois politiques ont été comparées en fonction du nombre de messages échangés entre les nœuds du système. C est le premier pas pour construire un système autonome permettant de contrôler les applications afin qu elles puissent s adapter à leur contexte d exécution. Dans la suite, nous allons passer à la conception Firas ALHALABI 56

de modèle du système de gestion. Le rôle de ce système est de communiquer avec les applications en utilisant un protocole commun afin d assurer leur adaptation au contexte d exécution. Dans un souci de garantir la réutilisabilité du système de gestion résultant, nous nous basons sur les principes de développement à base de composants permettant d intégrer notre méthodologie de développement d une famille de systèmes voisins. Firas ALHALABI 57

Chapitre 4 Approche à base de Composants et Méthodologie de Développement 4.1 Introduction Ce chapitre se focalise sur le développement à base de composants. Il présente les différentes catégories du composant et les principales imprécisions dans UML pour l utilisation de composants. Nous proposons des solutions pour améliorer le développement à base de composants avec UML. Nous proposons enfin une méthodologie de développement à base de composants et de profils UML pour construire une famille de systèmes spécifiques dérivés d un cadre générique fourni par l architecte dans un domaine quelconque. 4.2 Définition du composant L approche à base de composants est depuis une dizaine d années considérée comme un nouveau paradigme de développement des systèmes [BCO02]. Cependant, les modèles de composants restent pour de nombreux points à préciser car la recherche dans ce domaine est relativement récente. Selon [Tou05], il n existe pas à l heure actuelle de consensus pour la définition du composant. La définition la plus répandue du composant a été proposée dans [OMG07] : le composant est une entité informatique modulaire complètement développée et conditionnée en vue d'être déployée pour fonctionner dans un environnement précis (réalise des interactions avec d autres composants via des connecteurs). Firas ALHALABI 58

4.3 Différentes catégories Généralement, deux catégories de composants peuvent être évoquées : le composant physique et le composant logique. Un composant physique peut être un composant matériel qui présente n importe quel élément matériel ou un composant du marché comme EJB [GLK06], CCM [OMG06], etc. Ce type de composant est souvent utilisé dans la phase d implémentation et/ou de déploiement d un composant comme dans [Roo03]. Pour ce qui est des composants logiques, trois catégories peuvent être envisageables : les composants métiers, les composants conceptuels et les composants logiciels. Un composant métier est défini par une représentation de la nature et du comportement d entités du monde réel dans des termes issus du vocabulaire d une entreprise [Cas96]. Un composant logiciel est, quant à lui, un paquetage cohérent d implantation logicielle qui peut être développé et délivré indépendamment [DW98], [BCS09]. Enfin, un composant conceptuel est une partie cohérente d un modèle qui peut être réutilisée avec d autres composants pour bâtir un modèle complet, comme un diagramme de composants UML [Wei00] ou une architecture dans ADL [MN00]. C est le composant conceptuel qui sera adopté tout au long de ce mémoire. Nous avons choisi les composants UML car ils sont représentatifs et standards. Nous allons détailler ce type de composant. 4.4 Composant UML 2.0 4.4.1 Définition Les différentes versions d UML ont subi de nombreuses modifications dans la définition du composant [OMG05]. Le document de la spécification UML 2.0 définit le composant comme une unité réutilisable à l intérieur d un système qui fournit ou requiert un ensemble d interfaces externes et également possède une structure interne (Figure 4-1). Ce composant peut interagir avec son environnement éventuellement par l intermédiaire de A B :B :C :B 1 :B 2 Figure 4-1 : Le modèle de composant dans UML 2.0. Firas ALHALABI 59

points d interactions appelés ports (Figure 4-2). [HM06] clarifie la définition du composant UML 2.0 : il le définit comme un paquetage logique composé d éléments. Chacun de ces éléments (i) peut être développé et livré indépendamment, (ii) possède explicitement une ou plusieurs interfaces bien définies pour les services qu il fournit à son environnement, (ii) possède explicitement une ou plusieurs interfaces bien définies pour des services qu'il attend d'autres composants ou de son environnement, (iv) peut se composer d'autres sous éléments (v) peut posséder des propriétés internes (des attributs et/ou des méthodes). Cette définition semble la plus complète, elle admet la possibilité de modéliser un composant en utilisant des niveaux d abstraction autres que le niveau d implémentation. Dans notre étude, nous allons adopter la définition de [HM06] en ajoutant le fait que les interfaces de composants peuvent être potentiellement exposées par l intermédiaire de ports. 4.4.2 Deux vues complémentaires du composant UML 2.0 À partir de la deuxième version UML 2.0, deux vues pour les composants ont été définies : une vue de type boîte noire (vue externe) et une vue de type boîte blanche (vue interne). La vue de type boîte noire : cette vue considère qu'un composant est une entité d encapsulation caractérisée uniquement par ses interfaces requises et/ou fournies. Cette vue montre donc les propriétés publiques d un composant. D autres diagrammes UML (par exemple, diagramme de séquence, d activités) peuvent être utilisés pour détailler le comportement du composant. En plus, une machine à états peut décrire le mode A a : La vue externe de composant. Port A Delegation Interface b:b c 1:C connector c 2:C b : La vue interne de composant. Figure 4-2 : Les vues externe (a) et interne (b) du composant dans UML 2.0. Firas ALHALABI 60

d utilisation du port et/ou de l interface ou le comportement du composant lui-même. La vue de type boîte blanche : cette vue définit la structure interne du composant. Le composant est constitué de sous composants appelés parties (parts) et peut contenir des connecteurs internes pour connecter ces sous composants. Cette vue montre donc les propriétés privées d un composant car la partie interne d un composant est cachée et n est accessible qu au travers de ses interfaces (Figure 4-2). Cette vue interne montre les relations entre les différents éléments et les connecteurs qui les relient. Le lien entre les deux vues est réalisé par délégation des traitements à des connecteurs sur les ports qui sont connectés à des parties internes. La Figure 4-2 donne une représentation schématique d un composant avec ses deux vues interne et externe. 4.4.3 Imprécision dans UML Dans un souci de consensus global, UML ne définit pas précisément la sémantique de certaines constructions dans le diagramme de composant. Sans lister l ensemble de ces imprécisions, prenons l exemple de la réalisation d un composant, c est-à-dire la description de la façon dont un composant est conçu pour pouvoir mettre en œuvre les services qu il expose. Il peut être composé de composants, de classes comme dans [ICG04] ou bien d objets comme dans [DW98]. La différence, au sens UML des termes, entre type de composant et instance de composant dans les diagrammes représentant le contenu d un composant n est pas très claire. En effet, il est possible de décrire un composant par une abstraction représentant des types de composant comme dans la Figure 4-1 ou par une collaboration d instances de composant interconnectées comme dans la Figure 4-2. L héritage de composants, décrit ultérieurement dans ce mémoire, est un autre exemple de l imprécision dans UML. Le modèle d architecture à base de composants, décrit en UML, peut être interprété de différentes manières. Il est donc nécessaire de préciser les significations et de profiter des mécanismes d extension d UML pour préciser la sémantique du langage utilisé. Dans la suite, nous allons répondre à ces questions en proposant quelques précisions pour améliorer le développement à base de composants UML. Firas ALHALABI 61

4.4.4 Présentation des éléments du modèle de composant en UML 2.0 Dans cette section, nous allons présenter les éléments qui nous servent pour combler les faiblesses d UML pour le développement à base de composants. 4.4.4.1 Interface L interface de composant en UML regroupe un ensemble non vide d opérations qui spécifient des services requis/offerts par celui-ci. En UML, une interface définit un type et peut être attachée à un port (voir la définition de port). UML définit l interface fournie et l interface requise. Une interface fournie par un composant regroupe tous les services que le composant offre à son environnement. Une interface requise par un composant est une interface qui décrit les services que ce composant attend de son environnement. 4.4.4.2 Port Selon [PP05], A port is a way to offer functionality from a composite structure without exposing the internal details of how that functionality is realized. À partir de cette définition, le port de composant peut être vu comme un point d'accès à l ensemble ou à une partie de ses sous composants (ou classes). Un port véhicule les invocations d opérations des interfaces externes du composant. Pour respecter l encapsulation, quand des éléments de deux composants différents sont connectés entre eux, cette connexion doit passer par les ports des composants englobant. 4.4.4.3 Connecteur Les interactions entre les composants sont décrites par des connecteurs. Un connecteur est une entité qui relie deux ports et/ou deux interfaces de composant. UML 2.0 définit deux types de connecteurs (voir Figure 4-4) : Les connecteurs de délégation (delegation connector) et les connecteurs d assemblage (assembly connector). La distinction entre ces deux types relève de la nature des interfaces mises en connexion : Firas ALHALABI 62

Delegation connector : le connecteur de délégation joint l interface externe publique d un port à une partie interne (part) réalisant cette interface. C est le cas d un composant qui offre un service réalisé par un de ses sous composants et dont l interface est compatible avec l interface du composant englobant. Assembly connector : lorsque les interfaces interconnectées sont de natures différentes (requises/fournies), on parle cette fois-ci du connecteur d assemblage. 4.4.5 Solutions et Précisions Après la présentation des éléments qui sont nécessaires pour le développement à base de composant, il est utile de profiter des mécanismes d extension dans UML pour préciser et clarifier certains points dans la spécification UML. 4.4.5.1 Réalisation de composant Selon la spécification UML, la réalisation de composant est décrite en utilisant des flèches avec des lignes pointées. Certains comme [Sto05] considèrent qu un composant peut contenir un assemblage d autres composants. D autres modélisent le composant par un ensemble d instances sans préciser clairement la notion d instance de composant comme dans [HM06]. Le standard UML lui-même spécifie la réalisation de composant en utilisant uniquement un ensemble de classes connectées [OMG07]. Les auteurs de [ICG04] utilisent des instances pour réaliser un composant. Le composant dans [DW98] est construit à partir d autres composants ainsi que des objets (dans le sens d instances de composants). Il est donc pour le moment possible de trouver au sein d un même diagramme de composant, des composants, des classes et des instances de composant interconnectées en même temps, ce qui est inacceptable. Afin de remédier à ce problème et pour être plus clair, nous avons proposé de distinguer la modélisation de composant de sa réalisation en adoptant deux niveaux d abstraction. Composant primitif Un composant dit primitif (ou simple) n inclut aucun autre composant en son sein. Ce composant étend la notion de classe structurelle. C est une entité instanciable qui interagit avec son environnement, par l intermédiaire Firas ALHALABI 63

de ports ou d interfaces (requises et fournies) vers d autres composants du système. Nous considérons qu un composant primitif est implémenté par une (ou plusieurs) classes et des relations entre ces classes (Figure 4-3). La description du comportement de tels composants est fondée sur des machines à états ou des diagrammes de séquences. A b:b c:c d:d e:e Figure 4-3 : Un composant primitif contenant quatre classes. Composant composite Un composant composite est une notion propre au paradigme composant. Il permet de concevoir des composants en assemblant d'autres composants liés de façon cohérente. Chaque composant composite est modélisé en montrant ses sous composants et leurs rôles (Figure 4-4). L avantage d une telle représentation est que dans ce cas, nous sommes capables de représenter deux parties (vues comme des instances) du même composant (vu comme un type) dans la même structure interne du composant englobant, dans le cas où ces deux parties joueraient des rôles différents. Une partie représente un ou plusieurs rôles spécifiés par la multiplicité qui A Delegation Assembly b:b c 1:C connector connector Provided c 2:C Required interface interface B d:d e:e Figure 4-4 : Le composant composite dans UML 2.0. Firas ALHALABI 64

indique le nombre de rôles dans la partie. Si un des sous composants d'un composant A est, à son tour, composé d'autre sous composants (par exemple, le composant B dans la Figure 4-4), nous représentons le composant A en considérant deux étapes : Dans la première étape, nous retrouvons le composant A avec ses sous composants (B et C) qui jouent des rôles différents (b: B et c 1, c 2 : C). Dans la deuxième étape, nous modélisons chacun de ces sous composants (si composite) avec ses propres sous composants (D et E) et ainsi de suite. 4.4.5.2 Instance de composant Dans un composant composite, les sous composants sont des propriétés (de type property dans le méta-modèle UML). En principe, la création d un composant composite implique la création des instances des propriétés, mais la création d une instance de composant n a pas de sémantique précise. En effet, la définition de ce que nous appelons une instance de composant a été beaucoup changée dans la littérature. Par exemple les auteurs de [ACC03], dans son livrable 1.4, ont proposé de représenter une instance de composant de la même façon qu une instance de classe. Cette solution s applique plus difficilement sur les composants que sur les classes car il existe des différences entre les deux concepts. Par exemple, la création d un composant n a pas le même sens que la création d une classe. Pour remédier à ce problème, nous supposons que les instances ne sont crées que pour des propriétés de type Class. 4.4.5.3 Connexion Nous permettons aux composants de s interconnecter entre eux uniquement par l intermédiaire de ports ayant des interfaces fournies et/ou requises. Cette contrainte empêche la connexion directe via des connecteurs sans types. 4.4.6 Héritage de composants En tant que sous-type particulier de classe Class, un composant Component peut posséder des attributs et des opérations. Il peut aussi prendre part à des relations d association ainsi que d héritage dans le méta-modèle UML 2.0. Cependant, il faudrait préciser les éléments des composants qui peuvent être hérités car l approche composant est encore soucieuse de promouvoir la réutilisation par héritage [ACC03]. Firas ALHALABI 65

Chaque concepteur définit le lien d héritage entre les composants qui répond à ses propres besoins. Par exemple [Sto05] définit deux types d héritage de composant : (i) l héritage de l implémentation est défini de la manière suivante : un composant hérite le code logiciel de son composant de base. Le composant héritant doit avoir au moins les mêmes fonctionnalités que son ancêtre ; (ii) l héritage de la spécification est défini par le fait qu un composant hérite seulement les signatures (déclarations) des interfaces et développe (implémente) ses propres fonctionnalités. Ce type d'héritage est lié à la vue boîte noire du composant. Les interfaces seront héritées avec une possibilité de raffinement de la multiplicité des ports. Autrement dit, lors de la spécialisation d un composant, ses ports peuvent subir des redéfinitions en changeant leur cardinalité ou en remplaçant une interface par l une de ses spécialisations (interfaces héritant de celle-ci) [ICG04]. La définition de [Sto05] ne peut pas être adoptée dans notre travail car il considère que le composant est uniquement déployable au niveau implémentation comme dans UML1.x et pas au niveau conceptuel. Dans [Boc04], Conrad Bock a proposé de traduire l héritage de composant par l héritage de chacune de ses parties internes (Figure 4-5). Cependant, dans sa définition il propose qu un composant puisse posséder uniquement un ensemble fini de classes et pas de sous composants. Dans ce cas, un des inconvénients majeurs est la perte des niveaux d abstraction de la forme composant composite/sous-composants. En plus, il est évident que A b:b c:c d:d I BD AA AAA b:bb c:cc C b:bbb c:ccc d:dd d:ddd I BD I BD Figure 4-5 : L héritage de composants comme il est défini dans [Boc04]. Firas ALHALABI 66

la définition de [Boc04] restreint la définition de l héritage car selon la Figure 4-5, cet héritage est uniquement au niveau des instances et pas au niveau des classifiers (par exemple, classe ou composant) [Doc05]. Une solution a été proposée par [MP06]. Cette solution consiste à définir l héritage de composant par la conservation des interfaces fournies et requises et aussi la structure interne entre les deux composants en même temps : le composant hérité acquiert non seulement les interfaces fournies et requises de son ancêtre mais aussi sa structure interne. Cette définition est uniquement acceptable si toutes les interfaces ainsi que la structure interne du composant sont connues, mais le problème se pose dans le cas où le composant fourni sans exposer sa structure interne (vue boîte noire). Pour clarifier la définition de l héritage de composants et en essayant de prendre en compte les limites des définitions précédentes, nous allons définir deux nouveaux types d héritage de composants. 4.4.6.1 Notre définition de l héritage À partir de toutes les idées et définitions précédemment énoncées, nous avons proposé une nouvelle définition visant à spécifier clairement ce que nous entendons par héritage de composants. D après la relation de Generalization dans le méta-modèle UML, les composants doivent hériter des ports de leurs ancêtres. D un point de vue connexion, l héritage de ports implique que chaque composant est substituable à son parent. D un point de vue services, quand les descendants redéfinissent les ports, la conformité entre un port et son descendant doit être forcée pour affirmer la substitution. La structure interne des sous composants visibles (qui ne sont pas privés) est héritée. En considérant ces idées, en plus de la définition standard d UML [OMG07] (Figure 4-6), nous avons défini deux types d héritage de composants : l héritage en boîte noire (BlackBox) et l héritage de ports (PortToPort). Firas ALHALABI 67

C_Base X Y p C_Specialized /X /Y Z /p Figure 4-6 : Héritage de composants selon le standard UML : X, Y, et p sont implicitement hérités. Pour préciser UML et rendre notre proposition exploitable pour tous les développements à base de composants, nous avons défini deux stéréotypes avec des contraintes relatives à ces deux définitions : «BlackBox_Inheritance» et «PortToPort_Inheritance». Ces stéréotypes sont facilement intégrables dans n importe quel outil UML. Nous allons décrire ces deux stéréotypes dans ce qui suit : Supposons deux composants C_Base et C_Specialized dans la Figure 4-7. En utilisant le stéréotype «BlackBox_Inheritance», le composant C_Specialized n hérite pas des sous composants de son ancêtre C_Base. Autrement dit, le stéréotype «BlackBox_Inheritance» étend la métaclasse Generalization en interdisant au composant C_Specialized d hériter de la structure de C_Base. C est un stéréotype qui considère que l intérieur du composant est privé, et donc n est pas hérité. Indépendamment, le composant C_Specialized peut ajouter ses propres C_Base X Y p «BlackBox_Inheritance» C_Specialized Z /p Figure 4-7 : La définition du stéréotype «BlackBox_Inheritance». Firas ALHALABI 68

parties. Par exemple, le composant Z est ajouté au composant C_Specialized dans la Figure 4-7. La contrainte associée au stéréotype «BlackBox_Inheritance» est exprimée en OCL et restreint les membres hérités de l élément Composant (Component) de la façon suivante : Le deuxième type d héritage que nous avons défini est l héritage des ports. Nous avons défini un stéréotype «PortToPort_Inheritance». Ce stéréotype étend la méta-classe Generalization en précisant les contraintes entre les interfaces des ports. La Figure 4-8 illustre le stéréotype «PortToPort_Inheritance» en utilisant nos deux composants C_Base et C_Specialized. La redéfinition du port p par p_spec implique des règles similaires à celles de pré/post-conditions. En considérant une interface comme un contrat, nous spécifions deux contraintes pour ce type d héritage : Le port p_spec ne peut pas requérir plus de services que p. L interface requise du port p_spec est donc incluse dans l interface requise du port p, par exemple, I_Base_Required hérite de I_Specialized_ Required; Le port p_spec doit fournir au moins les services du port p. L interface fournie du port p est donc incluse dans l interface fournie du port p_spec, par exemple, I_Specialized_Provided hérite de I_Base_Provided. La contrainte OCL associée à ces deux conditions s exprime sous Port q is inherited implicitly q C_Base p I_Base_Provided «PortToPort_Inheritance» C_Specialized I_Base_Required {redefines p} p_spec I_Specialized_Provided I_Specialized_Required Figure 4-8 : La définition du stéréotype «PortToPort_Inheritance» entre deux composants. Firas ALHALABI 69

la forme suivante (à l aide de l outil Borland Together [Bor09]) : Une autre possibilité pour forcer ces contraintes aurait pu être d utiliser la relation de dépendance (dependency) avec le stéréotype «substitute», mais cela aurait nécessité une relation de mise en correspondance entre les ports : la substitution du composant C 1 ayant les ports p 1, p 2 par le composant C 2 ayant les ports q 1, q 2 nécessite de mettre chaque q i en correspondance avec un p j. Dans notre cas cette relation de mise en correspondance est atteinte par la redéfinition. La section suivante met ce point en évidence en présentant différentes possibilités pour la substitution de composants. 4.4.7 Substitution de composants Le composant peut être vu comme un type qui est défini par l ensemble de ses interfaces. Pourtant, la substitution d un composant A par un composant B sur la base de la conformité des interfaces n est pas toujours bien spécifiée. Comme nous le verrons plus loin, ceci suppose généralement d étudier des informations complétant la déclaration des interfaces, comme les machines à état associées. La substitution de composants est importante car nous en avons besoin notamment pour remplacer un composant par un de ses descendants. Pour cette raison, nous allons étudier et clarifier les modes de substitution de composants en distinguant la substitution absolue, la substitution contextuelle et la substitution dynamique. 4.4.7.1 Substitution absolue Un des avantages de la modélisation par composants est qu un composant peut être facilement remplacé par un autre plus adapté en cas d évolution du système. Autrement dit, la spécification des interfaces permet d utiliser les composants sans avoir besoin d aucun détail concernant leur structure interne. Par exemple, les composants du marché CCM [OMG06] permettent de réutiliser des composants écrits dans un langage de programmation (par exemple, C++) dans un autre langage que celui dans lequel ils ont été écrits (par exemple, JAVA) [Tou05]. Firas ALHALABI 70

De son point de vue, l OMG a défini la substitution en UML de la manière suivante "A substitution is a relationship between two classifiers which signifies that the substituting Classifier complies with the contract specified by the contract classifier. This implies that instances of the substituting Classifier are runtime substitutable where instances of the contract classifier are expected" [OMG07]. En conséquence, afin de remplacer un composant par un autre, il faut que ses interfaces externes soient compatibles. Cependant, peu d informations concernant cette compatibilité se trouve dans la spécification, ce qui représente encore un manque important. Pour cette raison, nous avons proposé une idée pour la substitution de composants. Cette idée est synthétisée de la manière suivante : Supposons deux composants A et B (Figure 4-9). Le composant A possède une interface fournie (notée IF A ) et une interface requise (notée IR A ). Le composant B, quant à lui, possède une interface fournie (notée IF B ) et une interface requise (notée IR B ). On dit que le composant A peut se substituer au composant B si l interface IF B hérite de (ou est égale à) IF A et si IR A hérite de (ou est égale à) IR B. Nous avons appelé ce type de substitution "Substitution Absolue" car il existe une relation explicite (ici l héritage) entre les deux interfaces de ces composants. «Interface» «Interface» IF A IR B IF A A IR A «Interface» IR A «Interface» IF B B IF B IR B Figure 4-9 : La substitution absolue de composants. 4.4.7.2 Substitution contextuelle Dans le cadre de cette thèse, nous avons introduit une autre définition pour la substitution de composants. Nous avons constaté que la substitution peut être possible uniquement dans un contexte donné et pas pour des critères indépendants du contexte comme dans le cas de la substitution absolue. Nous avons appelé ce type de substitution "Substitution Contextuelle". Firas ALHALABI 71

Dans la substitution contextuelle, une interface fournie (requise) d un composant est mise en relation avec une interface requise (fournie) seulement dans un contexte donné, par exemple dans la Figure 4-10, un composant A avec une interface requise I A ayant deux services S 1 et S 2. Le composant A est assemblé au composant C qui possède une interface fournie I C ayant des services S 1, S 2, S 3, S 4 (I C hérite de l interface I A ). Supposons maintenant un composant B ayant une interface requise I B vérifiant la condition suivante (I A I B I C ). Dans ce contexte-là, le composant B est substituable à A, mais dans d autres contextes cette substituabilité n est probablement pas possible. Ce type de substitution est envisageable sans prouver la possibilité de substitution car nous ne A I A I C C I A ={S 1, S 2 } I C ={S 1, S 2, S 3, S 4 } I B ={S 3, S 4 } (I A I B I C ) B I B Figure 4-10 : La substitution contextuelle pour des interfaces requises. connaissons pas à priori l interface I B du composant B, c est-à-dire il n existe pas de relation (ou contrat) entre les composants A et B en dehors du contexte du composant C. En suivant le même principe, dans la Figure 4-11, supposons que le composant A possède une interface fournie J A avec des services S 1, S 2, S 3, S 4 et qu il est connecté au composant C qui a une interface requise J C ayant des services S 1, S 2. Pour que le composant B qui possède une interface fournie J B soit substituable à A, il doit vérifier la condition suivante J C J A J B. A J A J C C J A ={S 1, S 2, S 3, S 4 } J C ={S 1, S 2 } J B ={S 1, S 2, S 3, S 5 S 6 } (J C J A J B ) B J B Figure 4-11: La substitution contextuelle pour des interfaces fournies. Firas ALHALABI 72

4.4.7.3 Substitution dynamique Dans certains cas, même si la substitution statique (absolue ou contextuelle) est possible, cette substitution n est pas suffisante. Prenons à titre d exemple, l ordre dans lequel on appelle les méthodes des interfaces de composant. À la limite nous devons définir un protocole qui dit si je remplace un composant A par un composant B, il faut que les deux composants possèdent le même protocole. Dans ce cas, la substitution doit être réalisée en tenant compte de ce protocole. Un protocole en UML décrit les séquences d appels autorisées pour un objet, un port ou une interface. L événement déclencheur est un appel d opération et toutes les méthodes qui font changer d état figurent dans ce protocole [OMG06]. La syntaxe des transitions est la suivante : [Pre-Condition] S methode/ [Post-Condition] S' S, S' sont des états, Pre-Condition, Post-Condition sont des contraintes qui peuvent être exprimées à l aide d expressions OCL, methode est la méthode à exécuter. Revenons aux composants A et B de notre exemple précédent (Figure 4-11), nous définissons un protocole d interface P 1 pour l interface fournie du composant A et également un protocole d interface P 2 pour l interface fournie de B (Figure 4-12). Dans ce cas-là, nous supposons que le composant B est substituable à A en utilisant le principe de la substitution absolue ou contextuelle (substitution statique). En appliquant la définition de notre protocole, nous constatons que la substitution dynamique n est pas possible car les interfaces de ces deux composants ne possèdent pas le même protocole (les deux composants n auraient pas le Protocole P 1 State A1 On Off State A2 Protocole P 2 State B1 On State B2 On State B3 Off Figure 4-12 : Machines à états associés aux interfaces des composants A et B. Firas ALHALABI 73

même comportement [Sou99]). Nous acceptons que B soit substituable à A si P 1 =P 2 (Figure 4-12). Une étude détaillée sur ce point est nécessaire, mais elle sort du cadre de ce travail. 4.5 Méthodologie de développement Notre but principal est de définir un cadre générique pour un ensemble de systèmes de gestion de la QoS. Afin de décrire notre proposition, nous utilisons les principes abordés dans ce chapitre. Dans un souci de généralité, nous définissons d abord une méthodologie de développement d un cadre générique pour aider à construire une famille de systèmes dans un domaine quelconque. Ce cadre générique sera défini à base de composants UML 2.1.1 [OMG07]. Dans le chapitre suivant, nous appliquerons notre méthodologie au domaine de gestion de la QoS. Dans cette thèse, nous entendons par le mot domaine la définition suivante [HM07] : "In software engineering a domain is often understood to be a system family, that is, a set of software systems that exhibit similar functionality". À partir de cette définition, nous considérons que le mot domaine signifie un ensemble des systèmes qui partagent des fonctionnalités similaires. Le principe de notre méthodologie est similaire au développement dirigé par les modèles (Model Driven Development, MDD) et précisément MDA [OMG03]. Dans cette optique, le modèle indépendant de la plateforme (Platform Independent Model, PIM) est progressivement transformé en modèle spécifique de la plateforme (Platform Specific Model, PSM) qui est fusionné avec le modèle de la plateforme pour finalement obtenir le code de l application. À ce point, nous rappelons que MDD/MDA vise à séparer les aspects conceptuels qui sont décrits par le PIM de toutes les implémentations spécifiques qui sont décrites par les PSM. Dans un premier temps, notre approche nécessite la définition d un modèle générique pour une famille de systèmes dans un domaine donné. Dans un deuxième temps, des systèmes spécifiques seront dérivés de ce modèle générique. Il faut bien noter que le modèle générique et les modèles spécifiques sont tous des modèles indépendants de la plateforme (c est-à-dire, des PIM). Au final, le squelette du code sera automatiquement généré à partir du dernier modèle spécifique de la plateforme (c est-à-dire, le dernier PSM) [AMS08]. La Figure 4-13 illustre notre méthodologie de développement en distinguant deux rôles principaux : (i) l architecte, qui est un expert d un domaine donné, identifie les concepts qui sont au cœur du domaine. C est Firas ALHALABI 74

le développement pour une réutilisation (development for reuse) ; (ii) Les développeurs qui dérivent le modèle générique pour obtenir chacun son propre modèle spécifique. C est le développement avec une réutilisation (development with reuse). Nous pouvons aussi ajouter le rôle de l expert en UML qui peut aider l architecte du domaine ainsi que les développeurs des systèmes spécifiques à définir les profils. Notre processus de développement est détaillé au sein des sous-sections suivantes. UML Expert (d) Common Profile Developer Architect feedback (6) Family of systems In a given domain (2) design Generic Model TModel automatic manuala utomatic Specific Model (3) (1) describe (b) Derivation Profile (c) Specific Profile (a) Generic Profile Scope of profile (4) refinement PSM (5) Code Figure 4-13 : La description de notre méthodologie de développement. 4.5.1 Description du domaine : profil générique L architecte du domaine crée, éventuellement à l aide d un expert UML, un profil UML, appelé profil générique (Generic Profile (a)). Ce profil définit les concepts communs à la plupart des systèmes du domaine. Ces concepts sont représentés à l aide de stéréotypes qui sont des sortes de méta-classes définies par l utilisateur. Par exemple, dans le domaine de l architecture orientée service (Service Oriented Architecture, SOA [Erl05]), l architecte identifie toutes les notions relatives à ce domaine qui sont le demandeur de service, le fournisseur de service et le registre de service. Ensuite, il définit Firas ALHALABI 75

Generic Profile «metaclass» Component «metaclass» Component «metaclass» Component «stereotype» ServiceRequester «stereotype» ServiceProvider «stereotype» ServiceRegister Figure 4-14 : La définition des notions du domaine de SOA par des stéréotypes. des stéréotypes à l aide des noms qui correspondent à l utilisation de ces notions. Pour notre exemple du domaine de SOA, les stéréotypes «SeviceRequester», «ServiceProvider», «ServiceRegister» sont définis et groupés dans le profil générique comme il est montré dans la Figure 4-14. D autre part, dans UML, des contraintes peuvent/doivent être définies pour une méta-classe particulière (Component dans notre cas) ou au niveau d'un stéréotype. Ces contraintes sont écrites sous la forme d'une expression en OCL (Object Constraint Language [OMG06]), comme dans [CMS04]. L utilisation de ce langage pour exprimer les contraintes reste difficile. Dans une grande majorité de cas nous utiliserons le langage naturel afin de spécifier les contraintes comme UML le fait dans la spécification [OMG07] (page 154). Les contraintes définies sur les stéréotypes du profil générique sont appelées contraintes génériques (Generic Constraint). Elles sont définies par l architecte du domaine et appliquées à tous les modèles (portée du profil dans la Figure 4-13) pour guider l utilisation des notions du domaine concernant les composants, les ports et les connecteurs. Un exemple de contrainte générique dans le domaine de l architecture Client/Server, serait de réduire les connexions licites, "Chaque Client doit être associé avec au moins un Server". 4.5.2 Modélisation : Architecture Après la définition du profil générique, l architecte construit une architecture à base de composants. Cette architecture fournit tous les éléments qui sont communs (commonality) et implicitement quelques points de variation (variability) pour tous les systèmes de ce domaine. L architecte introduit les composants nécessaires et leurs rôles, Firas ALHALABI 76

connecteurs, ports, interfaces et contraintes. La Figure 4-15 schématise le modèle générique d une architecture dans le domaine de SOA. D après cette figure, nous constatons que le modèle générique de SOA possède trois composants principaux : le composant G_ServiceProvider qui rend des services au composant G_ServiceRequester via le connecteur req. Le composant G_ServiceRegister est un composant composite qui contient la description des services, c est-à-dire les sous composants G_WebService et G_LocationService. Le composant G_ServiceRequester possède également une référence publish au G_ServiceProvider et une autre au G_ServiceRequester, appelée find. «ServiceRegister» G_ServiceRegister «WebService» «LocationService» :G_WebService :G_LocationService find publish «ServiceRequester» :G_ ServiceRequester req «ServiceProvider» :G_ ServiceProvider «WebService» G_WebService «PortToPort_Inheritance» «WebServiceA» G_WebServiceA «WebServiceB» G_WebServiceB Figure 4-15 : Le modèle de l architecture de SOA. Durant cette étape, l architecte fournit aussi les diagrammes de séquence génériques pour décrire les aspects dynamiques du système, c està-dire les interactions et les communications entre les instances de composants. Firas ALHALABI 77

4.5.3 Préparation de la dérivation : profil commun Concernant les actions de transformation du modèle générique pour obtenir des modèles spécifiques, certaines transformations sont communes à tous les domaines tandis que d autres sont spécifiques au domaine. Les transformations spécifiques ou non automatisables sont effectuées manuellement. Les exigences spécifiques ne sont pas à priori connues et ne sont pas réutilisables d un modèle à un autre. Pour mener à bien la dérivation, notre but est d automatiser au maximum les transformations communes. Pour ce faire, nous définissons des marqueurs à l aide de stéréotypes. Ces stéréotypes sont regroupés dans un profil UML appelé profil commun (Common Profile (d) dans la Figure 4-13). Par exemple, le stéréotype «remove» est défini pour indiquer que tous les éléments marqués par ce stéréotype doivent être supprimés pendant la dérivation. Firas ALHALABI 78

Dans cette étape, les développeurs partent du modèle générique, marquent les éléments avec les stéréotypes du profil commun, définissent et exécutent ensuite le Model Mapping en interprétant ces marqueurs à l aide d un langage de transformation de modèle comme QVT [OMG05] pour obtenir à la fin un modèle temporaire nommé TModel. La Figure 4-16 Une partie d un modèle générique avant transformation «ComponentC» G_C assocac «ComponentA» :G_ A assocab assocbc «remove» «ComponentB» :G_ B «PortToPort_Inheritance» «ComponentD» G_D «remove» «ComponentE» G_E Le même partie après transformation et application de stéréotype «remove» «ComponentC» G_C TModel assocac «ComponentA» :G_ A assocab «ComponentB» :G_ B «ComponentD» G_D Figure 4-16 : L application du stéréotype «remove» sur un modèle. Firas ALHALABI 79

illustre un exemple simple d application du stéréotype «remove» sur des éléments d un modèle pour obtenir le TModel. Dans cette figure, le stéréotype «remove» est appliqué sur le connecteur AssocBC, mais dans ce cas les ports des composants reliés par ce connecteur doivent aussi être supprimés avec une règle générale : "lorsqu on supprime un élément du modèle, il faut également supprimer tout ce qui y fait référence, par exemple les connecteurs, les ports, les interfaces". Puisque le profil commun contient des éléments qui sont indépendants de la description du domaine, les deux stéréotypes que nous avons introduits en vue d améliorer le développement à base de composants sont inclus dans ce profil (c est-à-dire, «BlackBox_Inheritance» et «PortToPort_Inheritance»). 4.5.4 Dérivation : Profil de dérivation L architecte spécifie les contraintes de dérivation et les regroupe dans le profil de dérivation (Derivation Profile (b)). La variabilité entre les modèles est limitée par les contraintes de ce profil. Ces contraintes de dérivation sont appliquées à tous les modèles spécifiques qui seront dérivés du modèle générique (Figure 4-13). Ce sont des contraintes qui assurent la cohérence des modèles après la dérivation. Par exemple, pour compléter la contrainte générique précédente de notre exemple dans le domaine du Client/Server, l architecte pourrait ajouter la contrainte suivante «n'importe quel Server doit avoir au moins un Client». Cette contrainte de dérivation interdit le fait que l on trouve un Server non connecté. Dans cette étape, afin de modéliser la variabilité d une manière explicite, nous pourrions utiliser le principe de la ligne de produits logiciels et de la programmation générative de la manière suivante : le stéréotype «optional» est utilisé pour désigner les éléments optionnels du modèle (par exemple, composant, connecteur, interface). Les stéréotypes «variant» et «variation» visent à spécifier l alternative dans le choix de composants durant la dérivation d un système spécifique. Par exemple, chaque élément marqué par «variation» doit associer à un et un seul élément marqué par «variant» pendant la dérivation. Ces deux derniers stéréotypes peuvent concerner l héritage de composants ainsi que leur composition. Firas ALHALABI 80

En s appuyant sur le domaine de SOA, la Figure 4-17 illustre un exemple sur l héritage de composants qui indique que durant la dérivation les développeurs des systèmes spécifiques peuvent garder/supprimer le composant G_WebServiceA ou G_WebServiceB mais pas les deux à la fois. Un exemple d application de ces stéréotypes sur la composition est donné par le composant G_ServiceRegister qui contient deux variantes relatives aux composants G_WebService et G_LocationService. Sur le modèle, les «Variant» «WebService» :G_WebService «Variation» «ServiceRegister» G_ServiceRegister «Variant» «LocationService» :G_LocationService find «optional» «ServiceRequester» :G_ ServiceRequester req publish «ServiceProvider» :G_ ServiceProvider «Variation» «WebService» G_WebService «PortToPort_Inheritance» «Variant» «WebServiceA» G_WebServiceA «Variant» «WebServiceB» G_WebServiceB Figure 4-17 : Le modèle de l architecture de SOA avec les stéréotypes de la variabilité éléments stéréotypés par «optional», comme le connecteur find, peuvent être éliminés dans la dérivation par les développeurs des systèmes spécifiques. Firas ALHALABI 81

4.5.5 Transformation de modèles 4.5.5.1 Principe Les transformations de modèles sont au cœur des processus de développement à base de modèles. La transformation de modèles est une opération qui consiste à transformer un modèle issu d un méta-modèle en un modèle issu d un autre méta-modèle (ou le même). Plusieurs cas de figures peuvent se présenter. Pratiquement, ce sont des programmes dont les entrées et les sorties sont des modèles. Dans [CH03], nous trouvons une comparaison des langages de transformation de modèles. D après [Kur05], il existe deux types de transformations de modèles : 1. Modèle à Modèle : ce type de transformation de modèles consiste à prendre un modèle source et à le transformer pour obtenir un modèle cible. Typiquement, cela transforme le modèle source d un niveau donné d abstraction en un modèle cible (i) de même niveau d abstraction, par exemple la transformation PIM à un autre PIM. Cette transformation est généralement un raffinement de modèles ; (ii) ou de niveau moins élevé, par exemple le passage d un modèle PIM au modèle PSM. Nous distinguons les transformations endogènes des transformations exogènes. La transformation endogène concerne la transformation d un modèle source dans un modèle cible avec le même méta-modèle. Par exemple, la transformation d un diagramme UML dans un autre. En revanche, la transformation exogène consiste à transformer un modèle source décrit par un méta-modèle dans un modèle cible décrit par un méta-modèle différent. Un exemple pour ce dernier type de transformation est la transformation d un modèle UML en un modèle de base de données. 2. Modèle à Code : c est la traduction d un modèle en texte. Cette technique est implémentée dans la plupart des outils de développement, et la génération de code est un cas particulier. En général, les transformations de modèles sont exprimées en utilisant un langage de transformation de modèles comme QVT [OMG05] ou ATL [JAB08]. Pour dériver un modèle spécifique de notre modèle générique, nous allons utiliser les transformations endogènes. Ensuite, pour la génération du code source à partir du modèle spécifique obtenu, nous pourrions/devrions utiliser la transformation modèle à code. Firas ALHALABI 82

4.5.6 Dérivation de modèles spécifiques Rappelons que le modèle générique doit décrire non seulement la commonalité (Commonality), mais aussi la variabilité (variability) entre les modèles. La commonalité se réfère à tous les éléments qui sont communs à tous les modèles du domaine. La variabilité est limitée par les contraintes de dérivation, par exemple, garder ou supprimer un composant et/ou une interface du modèle générique durant la dérivation. À partir du modèle générique enrichi par les profils, pour son modèle spécifique, le développeur sélectionne les éléments (par exemple, composant, connecteur, port) du modèle générique qui l intéressent et qui devront être inclus dans son modèle spécifique pour répondre à ses besoins particuliers. Ensuite le développeur construit son modèle spécifique par dérivation. Le modèle dérivé (premier modèle spécifique, c est-à-dire Specific Model dans la Figure 4-13) doit être conforme aux contraintes (a) et (b). Pendant la dérivation, nous pouvons imaginer de nombreuses transformations applicables sur le modèle générique : Ajouter un composant ou un sous-composant : pour ajouter un nouveau sous composant, chaque interface fournie (requise) de ce nouveau composant doit être soit connectée à une interface requise (fournie) d un autre sous composant, soit déléguée à une interface fournie (requise) externe. Supprimer un composant ou un sous-composant. Remplacer un composant ou un sous-composant par substitution, par exemple, des composants ayant les mêmes interfaces mais des structures différentes. Dans ce cas la substitution de composant est effectuée en suivant le principe que nous avons décrit dans la section 4.4.7. Ajouter/Supprimer un connecteur entre deux composants. Ajouter/Supprimer un port de composant. Transformer une partie de modèle en utilisant les Design Patterns [GHJ95]. À cette liste, nous pouvons ajouter une autre forme de transformation possible qui est la traduction d un lien d héritage entre deux composants en utilisant les deux stéréotypes que nous avons introduits dans la section 4.4.6.1. Firas ALHALABI 83

Cela peut introduire des incohérences qui proviennent en particulier de la suppression de composants pendant la dérivation. Les développeurs doivent donc vérifier la cohérence entre les modèles. Un des moyens pour conserver la cohérence de modèles pendant la dérivation pourrait être d utiliser un langage de transformation de modèles. Mais, formaliser les actions de dérivations qui sont très spécifiques au domaine serait une charge trop lourde par rapport aux bénéfices obtenus. En résumé, pour dériver des modèles spécifiques, dans un premier temps, l architecte fournit les contraintes de dérivation à l aide d un expert UML. Ensuite, les développeurs dérivent leurs propres modèles à partir du modèle du cadre générique. Ils appliquent les actions de transformation, testent automatiquement les contraintes OCL, et vérifient manuellement les contraintes sémantiques exprimées en langage naturel. Dans tous les cas, nous supposons que les développeurs utilisent un environnement de développement intégré de traitement des profils et des contraintes, et fournissant un moyen facile pour décrire et tester les contraintes. La Figure 4-18 schématise un modèle spécifique dérivé du modèle générique présenté dans la Figure 4-17. Le développeur part du modèle générique et obtient le modèle spécifique en trois étapes : (i) Il garde les composants marqués par «ServiceRequester» et «ServiceProvider» ; (ii) Il garde le composant «ServiceRegister» avec son sous composant «WebService» ; (iii) Il prend la décision de substituer (comme décrit dans la Section 4.4.7) le composant «WebService» par un de ses descendants «WebService» de type B, c est-à-dire, S_WebServiceB. «ServiceRegister» S_ServiceRegister «WebServiceB» :S_WebServiceB find publish «ServiceRequester» :S_ ServiceRequester req «ServiceProvider» :S_ ServiceProvider Figure 4-18 : Un modèle spécifique possible dérivé du modèle générique. Firas ALHALABI 84

4.5.7 Spécialisation : profil spécifique Les développeurs peuvent définir un profil spécifique (Specific Profile (c)), et tester ses contraintes, appelées contraintes spécifiques (Specific Constraint), pour rendre leur description beaucoup plus formelle. Puisque les contraintes spécifiques sont définies par les développeurs, elles sont appliquées uniquement sur les modèles dérivés. Par exemple, pour compléter notre exemple de l architecture Client/Server, une contrainte spécifique pourrait être ajoutée "Chaque Client est associé à exactement un Server". Cette dernière contrainte définit une connexion point à point pour le modèle raffiné. Le développeur peut aussi spécialiser un ou plusieurs stéréotypes du modèle générique pour une utilisation supplémentaire ou particulière. Par exemple, comme nous montre la Figure 4-19, le stéréotype «SpecificServiceRequester» spécialise le stéréotype «ServiceRequester» du modèle générique en utilisant notre stéréotype «PortToPort_Inheritance». «ServiceRequester» G_ServiceRequester «PortToPort_Inheritance» «SpecificServiceRequester» S_ServiceRequester Figure 4-19 : la spécialisation d un stéréotype générique pour le modèle spécifique. 4.5.8 Raffinement et Implémentation Comme dans la plupart des processus de développement, les modèles sont progressivement raffinés. Ce raffinement peut être effectué par le remplacement d un composant abstrait par un de ses descendants, la réalisation d un composant par un ensemble de classes ou encore la suppression d un composant ou d un lien du modèle spécifique (après la dérivation). Par exemple, le développeur du système spécifique peut raffiner son modèle spécifique de la Figure 4-18 pour obtenir le modèle de la Figure 4-20. Firas ALHALABI 85

«ServiceRequester» :S_ ServiceRequester req «ServiceProvider» :S_ ServiceProvider Figure 4-20 : Un modèle spécifique dérivé du modèle générique avec raffinement. À ce stade, il faut attirer l attention sur le fait que les composants des modèles spécifiques sont encore des types (pas des instances). Au niveau de l implémentation, ils seront instanciés en fonction du contexte particulier (PSM). La Figure 4-21 illustre une implémentation de notre modèle spécifique de la Figure 4-20 en utilisant la plateforme EJB (Entreprise Java Bean [GLK06]). «ServiceRequester» SRequester:S_ ServiceRequester req «ServiceProvider» SProvider:S_ ServiceProvider «EJBSessionBean» «SRequester» «EJBSessionBean» «SProvider» «EJBImplementation» SRequesterImplementation «EJBSessionRemoteInterface» Request e «EJBCreateMethod» request() instantiate «EJBSessionHomeInterface» HomeRequest «EJBCreateMethod» Create() * «EJBRealizeRemote» «EJBRealizeHome» «EJBRealizeHome» «EJBRealizeRemote» * «EJBImplementation» SProviderImplementation «EJBSessionRemoteInterface» Provide «EJBCreateMethod» Send() instantiate «EJBSessionHomeInterface» HomeProvid e «EJBCreateMethod» Create() Figure 4-21: Le modèle de PSM en utilisant la plateforme EJB. Firas ALHALABI 86

4.5.9 Génération de code et retour d expérience Le processus se termine par la génération du squelette du code qui correspond au modèle de la dernier PSM. Ce but est atteint en traduisant le modèle de la plateforme spécifique, par exemple le modèle de la Figure 4-21, en utilisant un outil de développement du marché. Enfin, selon l expérience acquise pendant la conception des modèles spécifiques, les développeurs pourront demander à l architecte d améliorer le modèle générique (feedback, Figure 4-13). 4.6 Comportement dynamique 4.6.1 Description Comme il est décrit dans [GCK00], A component diagram is often used to depict the topology of a system at a high level of granularity and plays a similar function, although at the implementation level, as an architectural description of a system. Le diagramme de composants représente l architecture du système et pas le comportement dynamique. Cette architecture comporte un ensemble de conventions et contraintes à respecter dans la construction, mais ne précise pas le comportement des composants. À ce stade, pour compléter les diagrammes de composants UML, les diagrammes de séquence sont utilisés pour spécifier les aspects dynamiques et comportementaux du système. Ces diagrammes de séquence sont des scénarios génériques qui décrivent les échanges de messages entre les composants ou sous composants. Évidemment, la cohérence entre la structure et la dynamique ne doit pas être négligée. Ainsi, chaque message appartenant au diagramme de séquence doit correspondre aux interfaces, ports, connecteurs du diagramme de composants [AMS07]. La Figure 4-22 schématise un diagramme de composants et son possible diagramme de séquence associé. L envoie du message m 2 () du composant b:b au composant c:c requiert la connexion entre b et c à l aide de ports et un ou plusieurs connecteurs d assemblage. L interface I BC qui est associée à ces ports devrait fournir/requérir le message m 2 (). Comme nous l avons indiqué, pour une description supplémentaire du comportement, les machines à états pourraient être utilisées. Ces machines à états peuvent être associées à un composant, un port ou à une interface, mais cette idée dépasse le cadre de cette thèse. Firas ALHALABI 87

m 1() belongs to the interface I A SD Generic Scenario A a :A b :B c :C d :D I A I A b :B m 1() I BC m 2() «Interface» I BC m 2() m 8() c :C m 3() m 4() d :D m 5() Figure 4-22 : Un diagramme de composants et son diagramme de séquence. 4.6.2 Problème de l incohérence lié à la suppression La dérivation des modèles de systèmes spécifiques peut introduire des incohérences entre les diagrammes, par exemple dans le cas où le A SD Specific Scenario b :B a :A b :B d :D I A I A m 1() C is removed C is removed m 4() d :D Figure 4-23 : Conserver la cohérence entre les diagrammes au moment de la dérivation. Firas ALHALABI 88

développeur n a plus besoin d un composant. Afin de conserver la cohérence des diagrammes de séquence, deux cas peuvent être considérés : 1. Si le modèle spécifique (comme dans la Figure 4-22) n a pas besoin du composant C qui est englobé dans le composant A, alors les messages m 2 (), m 3 () et m 5 () qui passent par C doivent être supprimés du diagramme de séquence (Figure 4-23). 2. Si le composant qui déclenche le message initial (le message m 1 () dans la Figure 4-23) n est plus requis dans le modèle spécifique, le diagramme en entier doit être effacé. 4.7 Conclusion Dans ce chapitre, nous avons traité le développement à base de composants UML en vue de l utiliser dans notre approche. Nous avons tout d abord défini la notion de composant. Ensuite, nous avons présenté différentes catégories du composant. Nous avons aussi discuté les principales imprécisions d UML pour l utilisation de composants dans notre travail. À cet effet, nous avons proposé des solutions pour adapter le développement à base de composants et notamment pour l héritage de composants. Le deuxième point principal de ce chapitre est la définition de notre méthodologie de développement. Cette méthodologie permet de construire un cadre générique pour une famille de systèmes voisins dans un domaine quelconque. Nous avons aussi traité le problème de l incohérence des modèles qui provient principalement de la suppression des éléments du modèle générique pendant le processus de dérivation des modèles pour les système spécifiques. Après la description de notre méthodologie générique, nous rappelons que l objectif principal de notre travail est de bâtir un cadre générique permettant la conception des systèmes de gestion de la QoS. Pour cela, dans le chapitre suivant, nous allons effectuer un tour d horizon des architectures de gestion de la QoS qui existent dans la littérature. L objectif est d identifier les éléments nécessaires pour bâtir le système de gestion de la QoS visé. Cela nous permettra ensuite de construire un cadre générique pour une famille de systèmes voisins pour la gestion de la QoS. Firas ALHALABI 89

Chapitre 5 Architectures Existantes et Cadre Générique pour la Gestion de la QoS 5.1 Introduction Dans le Chapitre 3, nous avons proposé un modèle générique pour la conception des applications afin qu elles puissent s adapter à leur contexte d exécution. Nous avons modélisé chaque application par un graphe. Nous avons proposé différentes politiques de gestion, et nous les avons comparées notamment en fonction des messages échangés entre les nœuds de systèmes distribués. En plus de la modélisation des applications, une autre activité importante dans toute approche supportant la gestion de la QoS est de développer le middleware qui contrôlera l exécution de ces applications. Dans le Chapitre 4, nous avons présenté notre méthodologie de développement qui permet de définir un cadre générique pour une famille de systèmes quel que soit le domaine en question. En s appuyant sur cette méthodologie, dans ce chapitre l attention est essentiellement portée sur le domaine de la gestion de la QoS. Nous présentons d abords un état de l art des middlewares existants dans la littérature. Chaque middleware sera présenté sous forme d une architecture de système de gestion de la QoS dans l optique des systèmes autonomes adaptables. Nous présentons dans la section 5.2 les principales raisons qui nous ont amené à définir un cadre générique pour un système de gestion de la QoS. Ensuite, nous décrivons quelques architectures de gestion de la QoS qui existent dans la littérature, et qui nous ont aidés à trouver les composants de base nécessaires pour construire un système de gestion de la QoS. Nous détaillons la mise en œuvre de notre méthodologie de développement pour le domaine de gestion de la QoS. De cette façon, nous définissons un cadre générique pour une famille de systèmes de gestion de Firas ALHALABI 90

la QoS. Nous dérivons ensuite un système de gestion de la QoS spécifique développé par notre équipe. 5.2 Besoin d une architecture générique Différentes architectures ont été proposées pour fournir un support pour la QoS dans les applications et il existe actuellement de nombreuses solutions permettant la gestion de la QoS à différents niveaux (par exemple, [FK98], [KYO99], [Li00], [LN00], [TJJ00], [WBG02]). Chacun de ces travaux définit un modèle d un système de gestion de la QoS à travers différentes vues complémentaires. L assemblage de ces vues pourrait nous permettre de construire un modèle générique complet. Chaque type de solution est généralement adapté à un contexte particulier et répond à des besoins spécifiques. Les choix sont trop nombreux pour avoir une solution adaptée à tous les cas de figures. Selon [XXH00], It is useful to design a general QoS management framework, which can easily change the QoS strategies and arithmetic without wholly reprogramming and redesigning for different types of applications. Il est donc souhaitable de définir un cadre générique pour assister les développeurs dans l utilisation des fonctions des systèmes de gestion de la QoS pour construire leurs propres systèmes. Ce cadre générique désigne un ensemble de composants interconnectés. De façon générale, la conception d un cadre générique pour une famille de systèmes de gestion de la QoS est une tâche complexe. Une solution pour faciliter la conception de ce cadre est de se baser sur des standards et sur certaines architectures des systèmes existants et déjà validés. En plus des travaux de l équipe (par exemple, [CS03]) nous avons étudié de nombreuses architectures, par exemple, [CCH94], [NQ96], [CJC00], [Def02]. Chacune de ces architectures est différente et répond à des besoins spécifiques. Les approches proposées utilisent des architectures en couches [LN00], orientées objet [FK98] [KR00], à base d agents [DPT98] [HWC99] [KYO99], des hiérarchies de services [CJC00], etc. Les différentes architectures qui seront présentées dans la section suivante soit font partie des travaux de l équipe, soit ont été proposées dans la littérature, mais chacune complète les autres. Ces architectures nous ont servi à identifier les composants de base pour construire un système de gestion de la QoS. Pendant la description de ces architectures (Section 5.3), nous marquons les composants et les fonctions de gestion en italiques afin de faciliter leur Firas ALHALABI 91

identification. Ceci nous permet de faire une comparaison entre les travaux existant pour trouver les éléments communs de notre modèle générique. Il faut remarquer qu il existe de nombreuses autres architectures de gestion (comme celles présentées dans [Cam96], [ZES97], [SLC99], [KR00], [SC00], [XXH00], etc.). Nous avons étudié ces architectures, mais dans l ensemble elles sont couvertes par les architectures qui seront décrites par la suite. 5.3 Les architectures existantes 5.3.1 Le standard ISO Dans le cadre du projet ISO [Int95] [Int96], des recherches ont été menées sur les différentes manières d aborder la QoS. Une résultante de leurs travaux est la nécessité d introduire une architecture de QoS. Cette déduction provient de l étude des besoins des différentes applications, par exemple les applications multimédia. Celles-ci doivent permettre aux utilisateurs d exprimer certains besoins de QoS (Specification). Le système doit être en mesure de les analyser et de les traduire afin de respecter les contraintes exprimées par les applications (Mapping). Les applications faisant intervenir des flux continus induisent des besoins importants de QoS. Ces applications ont des contraintes de temps de bout en bout relativement fortes. Ces travaux ont défini certaines fonctions nécessaires pour la gestion de la QoS et ils ont concerné plutôt le niveau réseau. En s appuyant sur le cadre ISO et sur des travaux existants, nous avons déduit les composants indispensables à inclure dans un cadre générique pour une famille de systèmes de gestion de la QoS. Nous allons détailler les principales architectures que nous avons étudiées. 5.3.2 Architecture QoS-A Les chercheurs de l université de Lancaster ont développé une architecture de QoS appelée QoS-A [CCH94]. L objectif premier de cette architecture est de supporter les flux audio et vidéo. Cette architecture repose sur trois notions : flux, contrats et gestion. Les flux identifient les données circulant dans le système et caractérisent la production, la transmission et la consommation de ces données associées à un niveau de QoS (mode opératoire ou mode dans notre cas). Les contrats spécifient les accords sur les niveaux de QoS entre les utilisateurs et les fournisseurs de services. La gestion des flux réalise la supervision, le contrôle et la maintenance (par adaptation) des niveaux de QoS tels qu ils sont décrits dans les contrats. Firas ALHALABI 92

L architecture QoS-A est composée d un ensemble de plans verticaux et de couches horizontales. La couche supérieure est constituée des plates-formes des applications distribuées augmentées de services pour permettre les communications multimédias et la spécification de la QoS dans les environnements orientés objet. Une couche d orchestration sous-jacente (joue le rôle du gestionnaire) permet de traiter la synchronisation [CCG92]. La couche inférieure (la couche transport) fournit un ensemble de mécanismes et de services configurables de QoS. Les dernières couches forment la base pour le support de la QoS au niveau du réseau. Trois plans sont définis : Le plan protocolaire distinguant des protocoles différents au niveau de chaque couche ; Le plan de maintenance (adaptation) de la QoS contenant un ensemble de gestionnaires de QoS spécifiques à chaque couche et responsables de la surveillance et de la maintenance (par adaptation) de leurs entités protocolaires correspondantes ; Le plan de gestion des flux qui a pour rôle l établissement du flux (contrôle d admission, réservation de ressources, routage en fonction de la QoS), la traduction des paramètres de QoS et l adaptation. Les couches reflètent la division hiérarchisée des services comme dans le modèle de référence ISO [Int95]. Les plans verticaux montrent la partition des fonctions de gestion dans les couches. Cette architecture est mise en œuvre sur un environnement distribué à base de micronoyau et utilise un réseau local ATM [CCR95]. e micronoyau a été étendu par des abstractions spécifiques pour les flux de médias continus. 5.3.3 Architecture OMEGA L architecture OMEGA [NQ96] a été développée pour fournir des garanties de QoS aux applications distribuées. Cette architecture assure la QoS de bout en bout [NS96]. En se basant initialement sur ce travail, un groupe de chercheurs a successivement réalisé des études concernant les architectures de QoS pour les systèmes de communications multimédia [VKV95]. Dans ce contexte, OMEGA exécute des fonctions de gestion principales comme la gestion de ressources [NWX00], le routage de QoS [XXH00], la communication multimédia [HV99]. L'architecture OMEGA traite le problème de gestion de QoS au niveau de l application en supposant que les réseaux de communication et Firas ALHALABI 93

les systèmes d exploitation sont capables de fournir les niveaux de QoS exigés. Dans cet objectif, elle se concentre essentiellement sur la gestion et la réservation de ressources de bout en bout en intégrant des techniques spécifiques aux protocoles d établissement des sessions multimédia. Ces travaux sont similaires à ceux de [HV99] dont le noyau du système est un broker (gestionnaire) qui se charge de traduire la QoS depuis l interface de l utilisateur et de partager les ressources disponibles aux différentes applications distribuées. OMEGA joue le rôle d un pont interconnectant l application et les protocoles de transport. Le fonctionnement d OMEGA est spécifié par deux modèles : le modèle de communications et le modèle de ressources. Ces modèles correspondent respectivement à deux tâches principales : la gestion des communications et la gestion des ressources. Chaque modèle comprend des informations des couches application et transport. Dans le modèle de communications, le gestionnaire de QoS appelé QoS broker a la responsabilité d effectuer un contrôle d admission et de négocier les exigences de l application avec l offre du système pour établir une connexion de bout en bout. D une façon similaire, le modèle de ressources contient toutes les informations de QoS des équipements matériels et logiciels de bout en bout (QoS Specification) pour réaliser la gestion de la QoS afin de garantir les ressources de bout en bout. Ces ressources se divisent en trois groupes : application (par exemple, flot du média, équipements d acquisition), système (par exemple, système d exploitation nommé OS) et réseau (par exemple équipements du réseau, trafic). La communication est établie après une phase d initialisation où l application spécifie ses besoins à l aide des paramètres de QoS. Le niveau de la QoS est ensuite négocié et les garanties sont fournies à plusieurs niveaux entre l application, le système de communication et le système d exploitation. Dans [LKN01], une amélioration a vu l ajout d un service de renégociation qui permet aux applications de modifier leur niveau de QoS. L idée d OMEGA a été développée avec certaines architectures comme 2K Q [NWX00] et Agilos [Li00] en respectant la vision initiale des couches et des modèles. Ces deux travaux, qui sont en fait des recherches approfondies et étendues d OMEGA, se focalisent sur l amélioration des mécanismes de spécification et d adaptation en appliquant l approche middleware et orientée objet. Néanmoins, la compatibilité entre ces modèles au niveau implémentation reste encore indéterminée. L architecture Agilos se concentre sur l adaptation et la prédiction de la sélection des ressources en utilisant des mécanismes intelligents, tandis que Firas ALHALABI 94

2K Q porte sur la traduction des paramètres de QoS en appliquant l approche orientée objet [NWX00]. 5.3.4 Architecture DART DART [RL98] (Distributed Adaptive Run-Time) est une architecture qui fait partie des projets utilisant la réflexion pour réaliser l adaptation. Dans cette architecture, l adaptation est considérée comme un changement de l implémentation d un objet pendant l exécution en fournissant des moyens de réification des invocations de méthodes qui peuvent être soit réflectives (ou réfléchies), soit adaptables. Les méthodes réflectives permettent la personnalisation de l environnement d exécution de l objet. Un niveau méta contient des objets gérant des services indépendamment de l application. Ce sont ces méta-objets qui jouent les rôles des gestionnaires de QoS. Dans le cas de l appel d un objet ayant une méthode réflective, l appel est redirigé vers ces méta-objets. DART définit plusieurs mécanismes pour l adaptation, par exemple, la gestion de stratégies d adaptation en réaction à des événements, les méthodes adaptables ainsi que les méthodes réfléchies et enfin, la possibilité de gérer des événements. Cette architecture ne permet ni la traduction des paramètres de QoS, ni la négociation entre l application et le système de gestion. 5.3.5 Architecture RTARM L architecture RTARM [CJC00] (Real-Time Adaptive Resource Management) fournit un système de gestion de la QoS pour adapter le comportement des applications distribuées dans les systèmes temps-réel. Dans RTARM, une distinction a été faite entre les clients et les applications. Les clients demandent des services et négocient un contrat de QoS qui définit les services alloués. Ce contrat est représenté par un ensemble de plages de valeurs, chacune associée à une dimension de QoS appartenant à une catégorie de QoS. Une application utilise les services alloués par un client et coopère sans cesse avec le système de gestion des ressources pour fournir la meilleure QoS possible tout en respectant le contrat de QoS. Le composant capital dans RTARM est appelé le gestionnaire de service (Service Manager, SM). Ce composant joue le rôle d un gestionnaire de QoS. Il a donc la responsabilité de planifier les différentes ressources dans le système (en utilisant la politique RippleScheduling) et de contrôler l exécution de l application. Firas ALHALABI 95

Schématiquement, l architecture RTARM est une hiérarchie de gestionnaires en distinguant deux groupes de SM : le gestionnaire de services au bas niveau (Low-Level Service Manager, LSM) et le gestionnaire de services de haut niveau (High-Level Service Manager, HSM). Un LSM se charge de planifier les ressources locales. Les HSM communiquent afin de contrôler l exécution de toutes les applications du système. Tandis que chaque HSM est un nœud de la hiérarchie, les LSM sont les feuilles (c est-à-dire chaque HSM supervise un ou plusieurs LSMs). En général, chaque SM, à son tour, peut contenir un ensemble de souscomposants qui sont responsables de tâches différentes, mais chaque composant n a pas besoin de tous les autres sous-composants pour pouvoir fournir des services. Par exemple, pour réaliser la négociation un LSM n a pas besoin d un composant de traduction (Mapping) car les paramètres de QoS à ce niveau sont des valeurs quantitatives. Cependant, le composant de la traduction de la QoS dans HSM est indispensable pour traduire les besoins en QoS du niveau application au niveau ressource. Le modèle de RTARM est présenté sur la Figure 5-1. Dans cette figure, les sous composants ainsi que les composants connectés sont présentés comme des sortes d instances sans nom de rôle (par exemple, ":Application"). Cependant, pour l héritage, ce sont les composants euxmêmes qui sont utilisés. L architecture RTARM prend en compte deux types d adaptation de la manière suivante (prend de décision) : Une renégociation des contrats de QoS pour définir les services alloués à chacune des applications. La renégociation des contrats n a lieu qu à des points précis que sont l admission d une nouvelle application et le départ d une application. Cette renégociation s appuie sur une hiérarchie de gestionnaires de service et un protocole de validation de transaction à deux phases, appliqué récursivement à chacun des services de la hiérarchie. Tandis que la première phase teste la disponibilité des services et se charge de la réservation de ressources, la seconde valide ou annule les réservations de la transaction. Une boucle de contrôle fermée (QoS Monitoriong) pour maintenir la QoS fournie au niveau de la QoS désirée. La boucle de contrôle fermée permet de corriger périodiquement le comportement de l application (adaptation du comportement). À chaque point de décision (à chaque période dans ce cas), l application précise son point de fonctionnement courant (les valeurs associées à chacune des dimensions de QoS) et le gestionnaire de service contacté renvoie les changements pour maintenir la QoS de l application dans la région désirée (par exemple, en modifiant la fréquence d échantillonnage). Firas ALHALABI 96

:Application * :LSM supervise :HSM * * 1 0..1 :OS 1 HSM :Admission :Monitoring :Mapping :Decision LSM :Admission :Monitoring Decision Admission :Adaptation :RippleScheduling :Negotiation Figure 5-1 : Le modèle de l architecture RTARM. Pour résumer, l application continue son exécution jusqu à une violation possible du contrat. À ce moment-là, la politique de feedback est commencée en informant l application de faire une adaptation (approche intrusive). Si le gestionnaire de QoS a détecté une grande différence entre le comportement actuel de l application (c est-à-dire la consommation de ressources) et le contrat spécifié, il appelle le feedback-adapter qui fait une adaptation en choisissant une action convenable pour répondre à un tel changement d état du système (QoS Monitoring). Firas ALHALABI 97

5.3.6 Architecture QuO L objectif de l architecture QuO [Def02] est de définir une infrastructure qui permette la spécification et la gestion de la QoS dans des applications composées d objets distribués. Dans la logique de QuO, une application peut avoir plusieurs points de fonctionnement acceptables avec des QoS différentes. L identification de ces régions permet de choisir les actions d adaptation de façon dynamique. Ces actions peuvent être des actions prédéfinies se trouvant au niveau des mécanismes système. Par exemple, la négociation de ressources avec RSVP [KK03] ou des actions définies par l application. L architecture QuO définit un langage de description de la QoS et de la stratégie d adaptation pour l application et intègre ces descriptions sous forme d entités exécutables dans un modèle de CORBA [OMG06]. L architecture QuO est utilisée dans plusieurs projets de recherche notamment. Par exemple, le AQuA (Adaptive Quality of Service for Availability) [BV05] se concentre sur le problème de disponibilité (prédiction, spécification de QoS, garantie). En revanche, le DIRM (Dynamic Integrated Resource Management) [ZYS99] vise à donner aux applications le contrôle sur leurs communications au-dessus de RSVP. Enfin, Quorum (Adaptive QoS in Dynamic Distributed Computing Environments) a pour objectif l intégration de tous les travaux autour de la QoS. Ceci permet de formuler et comprendre les notions (via le mécanisme de la traduction), gérer de la QoS dans des situations différentes et à différents niveaux dans le système, garantir l exécution avec un certain niveau de QoS, etc. L architecture QuO utilise un langage de description de la QoS appelé QDL (QoS Description Language) [Def02]. Le langage QDL est utilisé pour exprimer le contrat de QoS entre les clients (application) et le système (OS). Il utilise la technique de programmation par aspect (AOP [KLM97]) pour tisser les propriétés non-fonctionnelles de la QoS avec les logiques métiers des applications. 5.3.7 Architectures développées par notre équipe 5.3.7.1 Architecture ARTO L architecture ARTO [CS03] est très similaire à l architecture DART, précédemment décrite. Cependant, dans ARTO, les objets demandent des services en précisant la QoS (échéance, précision, etc.) désirée (QoS Firas ALHALABI 98

Specification), et collectivement, ils s'accordent pour rendre le meilleur service possible en fonction du contexte d exécution (adaptation). Le contrôle s'effectue à partir d une description en UML des éléments de QoS, des objets et de leurs adaptations. La description s'effectue via un outil (Rational Rose) à partir duquel le code relatif à la QoS est engendré automatiquement en s'appuyant sur un noyau à base de méta-objets. Dans ARTO, un contrat entre le client (l application qui demande le service) et le serveur (qui est le fournisseur de service) peut être établi et négocié (QoS Negotiation). Ce projet est orienté vers le temps-réel mou et fournit une "dégradation gracieuse" des applications (Adaptation). 5.3.7.2 Architecture PMQDA À partir de la description des besoins (QoS Specification) en ressources d'applications distribuées, un contrôleur joue le rôle d un gestionnaire global dans l architecture PMQDA [VSM05]. Ce gestionnaire planifie l exécution de toutes les applications sur les différents nœuds du système afin de maximiser le service global rendu. Le contrôleur impose à chaque application le mode de fonctionnement correspondant à la consommation de ressources autorisée. La description de la QoS s'effectue en UML et elle est ensuite exploitée par le contrôleur pour planifier l utilisation des ressources. L architecture PMQDA est organisée autour de trois éléments : le chargeur (Loader), le gestionnaire global (Global Manager, GM), et un ensemble fini de gestionnaires locaux (Local Manager, LM). Le Loader lance les applications. Lorsque ce chargeur est appelé pour lancer une partie d une application distribuée, il commence par demander son admission au gestionnaire local qui se trouve sur son nœud. Dans le cas où la demande d admission est acceptée, cette partie locale de l application est lancée. Après son admission, l application interagit directement avec le gestionnaire local correspondant à son nœud. Le gestionnaire global planifie et contrôle l exécution de l ensemble des applications du système à partir de leur description (Specification) et en utilisant la politique planning. Il sélectionne le mode de fonctionnement de façon à optimiser la QoS exprimé sous forme d utilité. Dans le cas du début d une nouvelle application, le mode de fonctionnement est indiqué à l application. De son côté, l application fait remonter au gestionnaire global les arrivées d événements et les chemins d exécution sont sélectionnés dynamiquement. Firas ALHALABI 99

5.3.7.3 Architecture DCBL Contrairement aux deux précédents projets ARTO et PMQDA, cette approche ne demande pas de mesure de consommation des ressources. À partir d'indicateurs sur le contexte (disponibilité de ressources) et les applications (degré de satisfaction), le mode de fonctionnement des applications est adapté pour maximiser la QoS globale du système. Le comportement des applications est ajusté en continu pour s'adapter au contexte via un système de décision par apprentissage (politique de gestion). C est un système de boucle classique où les sorties sont comparées aux objectifs, et les entrées sont élaborées en conséquence. Dans DCBL [VS03], une entité appelée Interface combine les informations fournies par les applications à une description (QoS Specification) très générale du système pour tenir à jour une représentation interne du système. La représentation interne du système utilisée par cette interface est organisée autour de deux types d entrées : les perceptions (Perception) et les moniteurs (Monitor). Les perceptions sont des informations qui permettent de déterminer l état du système (par exemple, la disponibilité d une ressource) tandis que les moniteurs permettent de juger de la capacité du système à fournir les services demandés, son utilité (par exemple, la proportion de requêtes refusées par un serveur). Dans la représentation interne du système, chaque type d application est associé à une liste d entrées. Au moment de l enregistrement d une application, la liste des entrées associées est retrouvée à partir du type de l application ce qui permet de conserver une trace de la valeur des perceptions et moniteurs fournis par l application. Les perceptions et moniteurs sont combinés pour obtenir respectivement l état et l utilité de l ensemble du système (QoS Monitoring). Le gestionnaire de QoS utilise l état et l utilité pour sélectionner le niveau de dégradation (Adaptation) en s appuyant sur un algorithme d apprentissage par renforcement (ReinforcementLearning Policy). DCBL utilise aussi la politique ExpertSystem (Figure 5-2). Firas ALHALABI 100

:Application * 1 :Manager 1 * * :OS 1 Manager :Perception :Monitor Manager Monitor :Adaptation :Policy Policy :ExpertSystem :ReinforcementLearning Figure 5-2 : Le modèle de l architecture DCBL. 5.3.8 Architectures dédiées aux systèmes multimédia De nombreuses architectures de gestion de QoS pour les applications multimédia distribuées sont proposées. Par exemple le travail présenté dans [HV99], porte particulièrement sur les activités de négociation et de renégociation. Elle prend en considération les informations statiques qui identifient le service et les informations dynamiques qui caractérisent la session de communication. Le modèle de cette architecture regroupe à la fois les profils de l utilisateur et la description de l application ainsi que des ressources (c est-à-dire la spécification). La traduction (Mapping) met en correspondance les profils pour réaliser la négociation. Firas ALHALABI 101

Le modèle XRM [Laz94] est un modèle d une architecture de communication pour les réseaux multimédia. Ce modèle se compose de cinq plans fonctionnels. Les ressources considérées pour la garantie de la QoS sont le réseau mais aussi le système terminal. Le réseau décide si une nouvelle connexion peut être établie (QoS Decision) sans violer les garanties de QoS déjà acceptées. Cette décision s opère en se basant sur la classe de trafic désirée, la capacité du lien, les statistiques concernant le trafic, la taille des tampons ainsi que l algorithme d ordonnancement utilisé (politique). 5.4 Commentaires sur les travaux existants Nous pouvons constater que les architectures de gestion de la QoS recensées dans la littérature ont globalement des fonctionnalités similaires. Cependant, la plupart des architectures existantes sont adaptées pour des environnements spécifiques et principalement pour les couches de bas niveau du système. Ces architectures de gestion répondent chacune parfaitement aux besoins du système de gestion de la QoS pour lequel elles ont été conçues. Nous présentons, dans le Tableau 5-1, un récapitulatif sous forme de comparaison entre les architectures. Les différents travaux sont présentés selon deux axes, les fonctions et les composants qui sont utilisés. Cette comparaison nous a permis d identifier les composants fondamentaux et nécessaires pour construire notre cadre générique pour des systèmes de gestion de la QoS. Nous remarquons que seulement RTARM, ARTO et DCBL permettent la surveillance, et parmi eux seul RTARM a une architecture distribuée. L architecture OMEGA prévoit la traduction des paramètres de QoS (Mapping) via son extension 2K Q, mais cette traduction n est pas formellement décrite. Certains travaux font référence au test d admission (par exemple, QoS-A, PMQDA et OMEGA). Cependant, QoS-A et OMEGA ne décrivent pas clairement comment ils mettent en œuvre ce test. D après le tableau, il est clair que peu de travaux permettent la traduction des paramètres de QoS (QoS Mapping). Certains travaux permettent la négociation (par exemple, OMEGA, RTARM, ARTO). Cependant, seul ARTO qui décrit clairement comment cette négociation peut être réalisée. Firas ALHALABI 102

Tableau 5-1 : Comparaison entre différentes architectures de gestion de la QoS. Caractéristiques Composants Architecture Distribuée Spécification de QoS Admission (test) Négociation Traduction (Mapping) Surveillance (Monitoring) Adaptation QoS-A Oui Oui Oui/sans préciser Non Oui/ Couches Non Oui OMEGA Oui Oui Oui/sans préciser Oui/sans préciser Non/2K Q Oui Non Non/Oui 2K Q, Agilos DART Non Oui Non Non Non Non Oui RTARM Oui Oui Oui/sans préciser Oui/sans préciser Oui/Sans préciser Oui Oui/après l exécution QuO Oui Oui/via QDL Non Oui/sans préciser Non Non Oui ARTO Non Oui Non Oui Non Oui Oui PMQDA Oui Oui Oui Non Non Non Oui DCBL Non Non Non Non Non Oui Oui Enfin, la majorité de ces architectures permet uniquement la gestion locale de la QoS pour un seul nœud, ce qui limite leur application dans un environnement distribué. Ces différentes constatations nous amènent à penser qu il est très utile de définir une démarche pour construire des systèmes de gestion de la QoS dédiés à partir d un cadre générique prédéfini et fourni par un architecte. 5.5 Cadre générique pour une famille de systèmes de gestion de la QoS Comme nous l avons constaté, les systèmes autonomes adaptables (dans le sens des systèmes de gestion de la QoS) ont en commun des fonctions génériques qui couvrent la majorité des besoins. La section précédente a identifié des éléments communs qui sont nécessaires pour construire un système de gestion de la QoS (par exemple adaptation). Il faut en plus Firas ALHALABI 103

s intéresser aux différences ou variations entre les différents modèles car certains composants appartiennent à un système et pas à un autre, par exemple négociation. Notre but est d identifier au mieux les éléments qui sont nécessaires dans tous les modèles. De façon générale, un élément commun définit une caractéristique indispensable pour tous les membres (ou la majorité) d une famille de systèmes alors qu une variation précise les différences entre les membres. Dans cette section, nous utilisons le diagramme de composant ainsi que les profils UML pour construire notre cadre générique. Certains points resteront imprécis intentionnellement car nous ne décrivons pas une architecture spécifique pour un système de gestion de la QoS mais plutôt un cadre générique sous forme d un langage de description permettant de faciliter le processus de développement d un tel système de gestion. C est à la charge des développeurs des systèmes spécifiques de détailler le comportement de leurs propres systèmes de gestion qui dérivent de notre cadre générique. À cet effet, nous présentons un scénario générique possible. Notre méthodologie est en quelque sorte une ébauche de langage spécifique à un domaine (c est-à-dire, DSL) et des points à prendre en compte pour développer un système de gestion de la QoS. 5.5.1 Description du domaine : Profil générique proposé 5.5.1.1 Stéréotypes Chaque domaine possède ses propres concepts et requiert des mots appropriés pour représenter ces concepts. Puisque UML ne permet pas de modéliser directement un domaine spécifique, nous avons défini un profil qui répond à nos besoins. Ce profil appelé profil générique (Generic Profile), définit des notions représentées sous forme de stéréotypes qui étendent la méta-classe Component. Notre profil générique peut être considéré comme un pseudo méta-modèle que l on peut/doit utiliser pour vérifier la cohérence des modèles des systèmes de gestion de la QoS spécifiques. En faisant le tour des architectures de gestion de la QoS dans la littérature ainsi que du standard ISO [Int95], nous avons identifié des notions telles que Manager, Admission, Mapping, etc., présentées Tableau 5-2. Les stéréotypes marquent les composants (Figure 5-3) pour spécifier leur sémantique (c est-à-dire, quel concept ils représentent dans le domaine), mais aussi pour assurer la traçabilité (c est-à-dire, les liens entre le modèle source et les modèles cibles) après la dérivation. Firas ALHALABI 104

Stéréotype Tableau 5-2 : Les stéréotypes du profil générique. Class de Base UML Description «Manager» Component Gestionnaire de QoS en général. «GlobalManager» «LocalManager» «Loader» «LocalApplication» «Mapping» «Monitoring» «Negotiation» «Adaptation» «DecisionMaking» «Admission» «Policy» «MixedPolicy» «SimplePolicy» Component Component Component Component Component Component Component Component Component Component Component Component Component Gestionnaire global de QoS, le gestionnaire global est un type de «Manager». Gestionnaire local pour chaque nœud, chaque gestionnaire local est de type «Manager». Déclencheur de la partie locale de l application qui se trouve sur un nœud. Partie locale de l application pour chaque nœud. Entité qui réalise la traduction des paramètres de QoS en consommation de ressources et vice-versa. Composant qui surveille les ressources et détecte la violation du contrat de QoS. Négociateur qui cherche un agrément avec l application pour l admettre. Élément qui cherche le meilleur point opérationnel possible pour exécuter l application et pilote la politique «Policy». Entité qui prend des décisions et les applique par négociation ou adaptation. Entité qui teste si les ressources nécessaires pour lancer les applications sont disponibles. Politiques à suivre pour gérer les ressources du système. Indique que le système de gestion utilise plusieurs politiques d ordonnancement à la fois. Indique que la politique que l on utilise est une politique simple (une seule politique). «OS» Component Système d exploitation virtuel utilisé. Firas ALHALABI 105

5.5.1.2 Tags associés aux stéréotypes Le Tableau 5-3 représente un exemple de pseudos attributs (c est-à-dire, tagged values) qui sont de nouvelles propriétés attachées à nos stéréotypes. Tableau 5-3 : Propriétés associées aux stéréotypes définis. Stéréotype Propriété Description «Manager» Distributed : bool Système distribué ou non. «GlobalManager» Location : string Nœud qui abrite le gestionnaire global dans le système. «LocalManager» «LocalApplication» NodeNum : int NodeNum : int PartNum : int Attaché à chaque gestionnaire local pour indiquer le numéro du nœud qui l héberge. Numéro du nœud. Numéro de la partie locale de l application (instance). «Adaptation» Utility : int Intérêt d utiliser tel ou tel mode de fonctionnement. «OS» OSName : string Nom du système d exploitation virtuel. 5.5.2 Modélisation : architecture L identification des concepts du domaine n est pas suffisante pour construire un langage. L architecte du domaine doit aussi compléter la description et décrire comment ces concepts pourraient être reliés entre eux en utilisant des contraintes. Par exemple, comme il est présenté sur la Figure 5-3 qui schématise notre architecture générique à base de composants pour une famille de systèmes de gestion de la QoS, «Manager» doit être connecté à «OS». Nous détaillerons la description des éléments de cette architecture, c est-à-dire, les composants, les ports, les connecteurs, etc. Nous avons divisé cette description en cinq parties de la manière suivante : Firas ALHALABI 106

5.5.2.1 La partie description La partie description est divisée en deux parties Specification et Source code. Specification : la spécification des besoins de QoS caractérise la description des exigences des applications en termes de consommation de ressources comme la taille d une image, le nombre d images par seconde, etc. Nous supposons l existence d un outil permettant d exprimer les besoins de QoS. Source code : décrit la logique métier de l application. C est le code de l application sans la gestion de la QoS. 5.5.2.2 La partie interface Application : d une façon générique, Application représente la partie locale de l application sur chaque nœud. Pour chaque application, le composant G_LocalApplication implémente la logique métier de l application tissée avec les mécanismes de gestion de la QoS indispensables pour assurer une adaptation du comportement. 5.5.2.3 La partie gestion de ressources Cette partie est divisée en deux parties : Loader et Manager. Loader : le composant G_Loader prend la description statique de l application et la passe au gestionnaire local associé. C est ce composant qui lance la partie locale de l application après une admission. Manager : au cœur d un système de gestion de la QoS se trouve le gestionnaire (Manager) de QoS. Ce gestionnaire est chargé de répartir les ressources du système entre les différentes applications qui les consomment. Au sein de notre architecture, le composant G_Manager modélise ce gestionnaire en distinguant deux types de gestionnaire : Le gestionnaire local (G_LocalManager) : chaque nœud possède un gestionnaire local pour la gestion des ressources locales (par exemple, le mémoire) ; Le gestionnaire global (G_GlobalManager) : ce gestionnaire a la responsabilité de la gestion des ressources partagées entre plusieurs Firas ALHALABI 107

Specification «LocalApplication» :G_LocalApplication «OS» :G_OS * 1 «Optional» «Mapping» :G_Mapping Source code 1 * 1 1 * «Manager» * 0..1 :G_Manager 1 * «Optional» «Loader» :G_Loader p «DecisionMaking» :G_DecisionMaking * «Manager» G_Manager supervise «PortToPort_Inheritance» «LocalManager» G_LocalManager «Admission» :G_Admission «Manager» G_Manager «GlobalManager» G_GlobalManager «Optional» «Monitoring :G_Monitoring «Optional» «Negotiation» :G_Negotiation «DecisionMaking» G_DecisionMaking «Adaptation» :G_Adaptation «Policy» :G_Policy «DecisionMaking» G_DecisionMaking «PortToPort_Inheritance» «Admission» G_Admission «Policy» G_Policy «Optional» «Learning» :G_Learning «MixedPolicy» G_MixedPolicy «Optional» «ExpertSystem» :G_ExpertSystem «PortToPort_Inheritance» «Optional» «Optional» «SimplePolicy» «MixedPolicy» G_SimplePolicy G_MixedPolicy «PortToPort_Inheritance» «Optional» «Learning» :G_Learning «Optional»... «Planning»... G_Planning «Optional» «ExpertSystem» :G_ExpertSystem Figure 5-3 : Une architecture générique à base de composants pour une famille de systèmes de gestion de la QoS. nœuds du système distribué (par exemple, la bande passante du réseau). De façon générale, un composant G_Manager est constitué d un ensemble de sous-composants destinés à modéliser certaines Firas ALHALABI 108

fonctions de gestion de QoS. Pour modéliser le gestionnaire de QoS, nous avons introduit le stéréotype «Manager», un composant abstrait qui peut être spécialisé pour avoir le gestionnaire local «LocalManager» et/ou le gestionnaire global «GlobalManager». Autrement dit, les composants G_LocalManager et G_GlobalManager héritent la structure interne du G_Manager. Un G_GlobalManager contrôle un ou plusieurs G_LocalManager via le connecteur Supervise. Dans le Chapitre 3, nous avons présenté et détaillé les différentes connexions possibles entre «LocalManager» et «GlobalManager» pour les architectures de gestion centralisée et centralisée. Enfin, chaque composant G_Manager est fabriqué à l aide de quatre sous-composants : G_Mapping, G_Monitoring, G_Admission et G_DecisionMaking. Ces quatre composants seront décrits dans la sous-section suivante. 5.5.2.4 La partie prise de décisions La prise de décision est composée de sept parties : DecisionMaking, Admission, Negotiation, Adaptation, Policy, Mapping, et Monitoring. DecisionMaking : le choix de la meilleure décision au bon moment est un aspect très important et une tâche difficile pour la gestion de la QoS. Dans [SZ95] les auteurs ont défini un agent qui prend en charge le contrôle de la gestion. Cet agent prend les décisions pour adapter le comportement de l application afin d améliorer la QoS globale du système. Nous avons introduit le composant G_DecisionMaking qui prend en charge la prise de décision pour contrôler les autres composants. Ce composant est aussi au cœur de notre architecture. Il est composé de trois sous-composants : G_Negotiation, G_Policy et G_Adaptation. Le composant G_DecisionMaking a la responsabilité de contrôler certains de ces composants (par exemple, G_Negotiation, G_Adaptation). Cela dépend des décisions prises par les développeurs des systèmes spécifiques qui sont dérivés. Admission : le composant G_Admission vérifie s il existe la quantité de ressources nécessaire à l exécution en faisant en sorte de ne pas perturber l exécution des applications déjà admises. Le gestionnaire admet une nouvelle application distribuée si et seulement si cette dernière peut atteindre et garantir la QoS demandée par l application. Si ce n est pas le cas, d autres décisions doivent être prises (par exemple, négociation, rejet l application). Après que l application a reçu son Firas ALHALABI 109

autorisation de chargement et a signé le contrat de QoS, elle envoie une demande d exécution avec ses besoins (paramètres de QoS) à son gestionnaire local. Le composant G_Admission hérite du composant G_DecisionMaking en appliquant notre stéréotype «PortToPort_Inheritance». Negotiation : afin d établir le contrat de QoS, l application peut faire une négociation avec le système pour déterminer un point opérationnel (operating point) pour chaque application, c est-à-dire un compromis entre la consommation de ressources et le niveau de la QoS. Il s agit d une boucle d interaction entre l application qui demande le service et le système qui est le fournisseur de service (c est-à-dire, le gestionnaire de QoS). À chaque itération, l application envoie ses besoins de QoS au système. Après que le système a traduit ces besoins en une consommation de ressources nécessaires pour fournir le service demandé, le composant G_Negotiation examine la possibilité de répondre à ces besoins. En cas d échec, l application peut ajuster sa demande et relancer la négociation. Plusieurs façons sont envisageables pour la mise en œuvre de la négociation. Par exemple, les auteurs de [KYO99] ont distingué deux types de négociation en utilisant la technique des systèmes multiagents (MAS) : une négociation locale et une négociation globale. La négociation locale est réalisée entre l application qui cherche son admission d une part et le gestionnaire local de QoS de l'autre. La négociation globale, quant à elle, est vue comme une négociation entre les différents nœuds du système distribué. Le but de cette négociation est de chercher, d une manière efficace, l hôte qui possède la capacité d exécuter l application. Une des difficultés de mise en place de la négociation est le choix des instants où cette négociation peut/doit être déclenchée. En général, ces instants peuvent correspondre aux moments où l application demande un service avec une certaine qualité, aux moments où le contrôle et la supervision de l état du système indiquent des changements importants du niveau de la charge et aux moments d interruption d exécution. Cette idée est discutée en détail dans [Xin00], The QoS manager performs the negotiation to choose the best system configuration that can support the user requirements. Nous définissons le contrat de QoS comme une entité (ou structure de données) contenant les besoins de QoS que l application a la garantie d obtenir après des éventuelles négociations avec le système. Nous considérons que le contrat de QoS est un agrément Firas ALHALABI 110

mutuel entre le système et l application. Il s exprime sous la forme de contraintes à respecter. Par exemple, un contrat peut spécifier que l application doit consommer au plus 20Mo de mémoire pendant son exécution. Enfin, Pour mener à bien la négociation, l architecte peut/doit définir le protocole de négociation utilisé dans le modèle générique ainsi que dans les modèles spécifiques. Le but de ce protocole est de définir les messages que les composants pourront/devront s envoyer entre eux. Le protocole de négociation que nous proposons est caractérisé par une suite de messages échangés entre l application (initiateur) et le système de gestion de la QoS (participant). La description de ce protocole de négociation est illustrée sur la Figure 5-4. Adaptation : au sein de notre architecture générique, l adaptation peut avoir lieu à deux moments : Lors de la demande d admission et du choix du meilleur mode comme dans certains systèmes de gestion spécifiques dérivés de notre modèle générique, par exemple, [VS03]. Au moment où le système fait face à un changement de contexte d exécution comme dans [CJC00]. Dans ce dernier cas, l adaptation survient lorsque le mécanisme de gestion n arrive plus à effectuer l ajustement nécessaire. L adaptation est la conséquence d une observation de carence ou tout simplement d un changement d état du système. À ce moment-là, le système est obligé d effectuer une adaptation du comportement actuel d exécution et/ou de changer le mode d exécution de l application. La transformation d un mode d exécution vers un autre nécessite certaines actions. Le développeur doit préciser les actions à prendre quand le système n arrive plus à réaliser le niveau de QoS demandé. Par exemple, le système retarde l exécution des tâches les moins importantes. Dans [CJC00], Adaptation relies on monitoring of delivered QoS and uses the difference between delivered and desired QoS to adapt the application behavior". Dans tous les cas l adaptation correspond à une prise de décision (DecisionMaking). Le composant G_Adaptation spécifie cette fonction dans notre architecture générique. Policy : l ordonnancement de ressources consiste à planifier ces ressources pour exécuter les applications. Cela peut être effectué en appliquant la politique d ordonnancement. Cette planification permet aux différentes applications d obtenir la QoS qui leur a été promise au Firas ALHALABI 111

moment de leur admission. Quelle que soit la politique d ordonnancement, nous avons identifié deux approches de réservation de ressources : la réservation statique et la réservation dynamique. La réservation statique consiste à n accepter une application que si toutes les ressources dont elle a besoin sont disponibles. Dans ce cas, une fois l application acceptée, les ressources restent réservées (et non disponibles pour les autres applications dans le système) jusqu à la fin de l exécution de cette application. Cette approche a le mérite de la simplicité, mais aussi de la clarté (soit on les accepte soit on les rejette et si elles sont acceptées, les applications verront les besoins de QoS respectés). La réservation dynamique, en revanche, consiste à allouer les ressources au fur et à mesure qu elles sont réellement demandées par les applications. Pour la technique de réservation dynamique, le gestionnaire de QoS demande aux applications de s adapter pour tenir compte de l état actuel du système, par exemple une consommation plus ou moins importante de ressources en fonction de la charge du système. Chaque développeur de système applique sa propre politique pour planifier les ressources. Le composant G_Policy modélise la politique d ordonnancement : nous distinguons la politique simple (dénommée G_SimplePolicy) et la politique mixte (dénommée G_MixedPolicy). G_MixedPolicy peut inclure des politiques simples et/ou mixtes, par exemple, dans [VS03], G_MixedPolicy contient les politiques G_Learning et G_ExpertSystem. Pendant la dérivation, si la politique souhaitée est simple, le composant G_Policy sera remplacé par n importe quel composant qui hérite de G_SimplePolicy (par exemple, G_Learning, G_Planning dans la Figure 5-3). Les composants G_SimplePolicy et G_MixedPolicy héritent des ports et des interfaces du G_Policy grâce au stéréotype «PortToPort_Inheritance» que nous avons introduit. Mapping : nous supposons que le gestionnaire de QoS s occupe de transformer les paramètres de QoS spécifiés au niveau application en valeurs numériques compréhensibles par le système. Le composant G_Mapping réalise la traduction des besoins de QoS de haut niveau en ressources, par exemple traduit la résolution d une image en consommation de mémoire, processeur, etc. Le composant G_Mapping permet de fabriquer les données nécessaires pour la gestion. La traduction des paramètres de QoS (Mapping) étant très délicate et Firas ALHALABI 112

difficile à réaliser, la description s effectue directement en termes de ressources. Monitoring : le composant G_Monitoring compare la consommation réelle de ressources avec la consommation prévue pour détecter les cas de défaillance et les violations du contrat de QoS. Dès qu un dépassement de seuil est constaté, le composant G_Monitoring envoie un rapport informatif (feedback) de violation au composant G_Manager qui a la responsabilité de faire les actions appropriées. L application peut effectuer un traitement spécifique en cas d erreur ou de dysfonctionnement. Par exemple, chercher un autre point de fonctionnement. La surveillance doit être réalisée périodiquement chaque unité de temps. Il peut s avérer utile de définir des mécanismes d alarme permettant de notifier qu un paramètre de QoS a dépassé un seuil important. Dans [BNB98], en fonction des ressources disponibles, l application est avertie que les ressources requises ne sont plus disponibles et qu elle doit s adapter. En cas de violation du contrat, le gestionnaire informe l application qui a alors le choix entre trois possibilités : arrêter l exécution comme dans [VSM05], continuer à exécuter en mode dégradé comme dans [Abd99], ou faire une renégociation comme dans [NQ96]. 5.5.2.5 La partie des services supplémentaires Operating System (OS) : le composant G_OS modélise le système d exploitation que l on utilise pour chacun des nœuds du système distribué. Ce composant réside en dessous de la couche middleware. Pendant l exécution, les applications interagissent avec les gestionnaires de QoS ou utilisent directement les services offerts par le système d exploitation. 5.5.3 Commentaires et Discussion Au sein de notre cadre générique, les stéréotypes sont utiles pour identifier les composants pendant et après la dérivation. Dans la suite de ce mémoire, le symbole «X» fait référence soit à un composant marqué par le stéréotype «X», soit à un composant qui hérite d un autre composant qui est lui-même marqué par ce stéréotype. Les rôles des composants seront utilisés pour discriminer les instances multiples du même composant. Il faut attirer l attention sur le fait que notre cadre générique est destiné à être applicable à n importe quel système de gestion de la QoS. Pour cela, ce cadre devait être le plus générique possible et ses composants Firas ALHALABI 113

sont plutôt "abstraits" et limités aux composants essentiels pour différents systèmes de gestion. Les développeurs des systèmes spécifiques devront adapter le cadre générique pour construire les modèles qui répondent à leurs propres besoins. Par exemple, le modèle du cadre générique suppose que dans le cas où une nouvelle application est rejetée au moment du test d admission (effectué par le composant «Admission»), le processus de négociation pourrait être déclenché afin de retrouver un nouveau point opérationnel. Cela conduit à échanger certains messages entre l application et le système de gestion (Figure 5-4). sd Negotiation a 1: G_Local Application lm 1: G_Local Manager gm 1: G_GlobalManager n 1: G_Negotiation negotiate(operatingmodes) negotiate(operatingmodes) negotiate(operatingmodes) decision(reply, mode) alt [reply=ok] accept(mode) [else] accept(mode) reject(mode) reject(mode) Selected mode Possible mode Figure 5-4 : Le diagramme de séquence générique relatif à un cycle de négociation. Dans le cas où le système de gestion ne permettrait pas la négociation, le composant «Negotiation» doit être supprimé du modèle dérivé et dans ce cas-là, la cohérence entre les diagrammes doit être examinée et assurée (voir Section 4.6.2). Par ailleurs, puisque le test d admission est un service primordial pour tous les systèmes de gestion de la QoS, le composant «Admission» apparaît dans tout système de gestion spécifique. 5.5.4 Préparation de la dérivation : contraintes de dérivation Les contraintes de dérivation doivent être satisfaites pour le premier modèle spécifique qui dérive du modèle générique. Voici quelques exemples : Firas ALHALABI 114

Au moins un gestionnaire (c est-à-dire «Manager») doit rester au sein de n importe quel modèle dérivé. Ce manager pourra être soit local («LocalManager»), soit global («GlobalManager») dans le cas d un seul nœud ; Au moins un «Manager» («LocalManager» ou «GlobalManager») doit inclure un composant «Policy» ; Au moins un composant «Admission» doit rester au sein de n importe quel modèle du système de gestion de la QoS. En revanche, le composant «Mapping» pourrait être supprimé. 5.5.5 Scénario possible du fonctionnement Pour le modèle du cadre générique, il est impossible d évoquer tous les scénarios relatifs aux communications entre les composants. C est justifié par le fait que les communications entre les composants dépendent des besoins de chaque système spécifique. Dans cette section, nous présentons à titre d exemple un scénario réutilisable et générique pour tous les systèmes de gestion de la QoS spécifiques dérivés du modèle du cadre générique. Les numéros se référent à la Figure 5-5. 1. Dans un premier temps, le «Loader» d une application demande l admission de sa partie locale («LocalApplication») à son gestionnaire local («LocalManager»). Dans cette phase, il n y a pas de négociation et l application soit obtient l autorisation de se lancer, soit est rejetée. 2. Dans le cas d une approche centralisée (voir la section 3.3), «LocalManager» transmet la demande de lancement au gestionnaire global (c est-à-dire, «GlobalManager»). Au moment de lancer une application, le «GlobalManager» demande l exécution de la première étape au «Loader». 3. Lorsque toutes les parties locales de cette application sont prêtes, tous les «LocalManager» sont avertis du succès de l admission. Une application demande une admission pour chaque unité de planification et fournit éventuellement ses besoins en QoS. 4. À partir de ces besoins, le composant «Mapping» identifie les ressources nécessaires pour prendre en compte ces besoins. Ensuite, «Mapping» traduit ces caractéristiques du niveau application vers un niveau plus bas, par exemple besoins en ressources : processeur, mémoire, etc. Firas ALHALABI 115

SU 0 SU 1 SU 2 SU i SU n-1 SU n (2) Exit() (6) Monitoring Monitoring Monitoring Monitoring (7) Adaptation Adaptation Adaptation Adaptation Admission of SU 0, without Negotiation Admission Mapping Negotiation (3) (4) (5) Admission Mapping Negotiation... Admission Mapping Negotiation Admission Mapping Negotiation (1) Loading Execution Unload Outside the Application Application Execution End Application Figure 5-5 : Le déroulement de l application. 5. «LocalApplication» négocie avec le gestionnaire de la manière suivante : «LocalApplication» demande (via son «LocalManager») un service avec certaine qualité et elle envoie sa demande à «Negotiation». Le composant «Negotiation», à son tour, peut accepter la demande si elle est réalisable, sinon «LocalApplication» peut/doit refaire une requête avec une autre consommation de ressources ou abandonner sa requête. Une attente est possible s il n y a pas suffisamment de ressources. 6. Durant l exécution de l application, les ressources sont surveillées périodiquement par le composant «Monitoring». 7. Si le composant «Monitoring» détecte une violation du contrat en faisant une comparaison entre les valeurs contractuelles et les valeurs réelles, il envoie un rapport au «Adaptation» via le «DecisionMaking». 5.6 Dérivation : le modèle PMQDA Dans cette section, nous rappelons le principe de dérivation d un système spécifique de notre cadre générique. Nous proposons ensuite des contraintes pour un système spécifique de gestion de la QoS d applications Firas ALHALABI 116

distribuées. Enfin, nous présentons une dérivation du modèle de ce système. Ce système, appelé PMQDA, a été développé par notre équipe en utilisant IBM Rational Rose Real-Time et sa couche de communication Connexis. 5.6.1 Principe de dérivation Rappelons brièvement certains points pour la dérivation : 1. Le modèle générique contient la plupart des composants et connecteurs nécessaires pour construire un système de gestion de la QoS). 2. Le modèle de chaque système spécifique sera dérivé du cadre générique en supprimant certains composants et/ou liens. Les développeurs peuvent ajouter de nouveaux stéréotypes ou utiliser des stéréotypes déjà définis. Les développeurs peuvent également ajouter des contraintes spécifiques. 3. Les modèles des systèmes spécifiques doivent respecter les contraintes définies pour le modèle du cadre générique, mais aussi leurs contraintes. 4. Le modèle du cadre générique (fourni par l architecte) ainsi que les modèles des systèmes spécifiques (dérivés par les développeurs) sont tous des modèles indépendants de la plateforme (PIM). La transformation du modèle générique vers des modèles spécifiques que l on veut élaborer s inscrit dans la philosophie des transformations PIM vers PIM de MDA. Autrement dit, les composants des modèles spécifiques sont encore des composants abstraits et peuvent être ensuite implémentés par transformation vers n importe quelle plateforme spécifique (c est-à-dire PSM). Dans notre cas, l automatisation de toutes les transformations est quasiment impossible car la construction des modèles des systèmes spécifiques dépend des éléments (par exemple, composant, port, connecteur) choisis par les développeurs des systèmes spécifiques en fonction de leurs besoins particuliers qui sont a priori inconnus. Par contre, toutes les transformations génériques sont automatisables (par exemple, tous les éléments marqués par notre stéréotype «remove» seront supprimés pendant la dérivation, Section 4.5.3). Firas ALHALABI 117

5.6.2 Contraintes spécifiques Chaque développeur du système spécifique peut définir et ajouter ses contraintes spécifiques. Dans notre cas, le développeur du système de gestion spécifique PMQDA spécifie des contraintes spécifiques comme : Les développeurs peuvent raffiner les stéréotypes du modèle générique dans le but d ajouter des notions particulières, mais aussi des contraintes relatives à leurs besoins spécifiques. Par exemple, le stéréotype «SpecificLM» raffine «LocalManager» en ajoutant une contrainte qui indique que les «LocalManager» du modèle du système spécifique sont des feuilles pour la relation Supervise ; Les composants «SpecificLM» et «GlobalManager» n incluent pas de composant «Negotiation» car PMQDA n offre pas le mécanisme de négociation. Cela peut aussi être obtenu en utilisant le stéréotype «remove» ; Le modèle de système distribué PMQDA inclut un «GlobalManager» unique hébergé sur un nœud particulier et un seul «SpecificLM» dérivé de «LocalManager» sur chaque nœud ; Le «SpecificLM» n inclut aucun composant «Policy» car la gestion des ressources dans PMQDA est centralisée sur le nœud qui héberge le «GlobalManager». 5.6.3 Le modèle de PMQDA dérivé La Figure 5-6 illustre le processus de dérivation dont le résultat est le modèle de PMQDA donné Figure 5-7. Le modèle de PMQDA est dérivé du modèle du cadre générique présenté dans la Figure 5-3. Ensuite, toutes les contraintes doivent être testées, c est-à-dire, les contraintes génériques, spécifiques et les contraintes de dérivation. Quand la multiplicité d un connecteur devient 0, le port connecté doit être supprimé puisqu il devient inutile, par exemple, le port attaché au connecteur qui relie PM_GlobalManager et PM_Loader est supprimé, tandis que le port P attaché au connecteur qui relie PM_LocalManager et PM_Loader est conservé. Comme la Figure 5-7 représente, après la dérivation, le modèle de PMQDA englobe des éléments suivants : Firas ALHALABI 118

Generic Model copy Generic Model (copy with tags) automatic transformations PMQDA Model manual transformations Temporary Model Tags to guide the automatic transformations manual transformations Figure 5-6: Schéma illustrant la dérivation. PM_GlobalManager : ce superviseur contrôle (via le connecteur Supervise) l exécution de tous les PM_LocalManagers et applique la politique PM_Planning pour planifier les ressources de toutes les applications. Grâce au PM_Adaptation, le PM_GlobalManager ajuste le comportement des applications selon le choix fait pendant la phase de planification. À cause de la nécessité d hériter des ports précis, le PM_GlobalManager hérite les ports du G_GlobalManager en utilisant notre stéréotype «PortToPort_Inheritance». PM_LocalManager : existe sur chaque nœud de ce système distribué. Chaque PM_LocalManager joue un rôle d intermédiaire entre le GM_GlobalManager et les PM_LocalApplications qui sont exécutées sur son nœud (le nœud hôte de ce PM_LocalManager). PM_Loader : pendant le test d admission d une application locale, le PM_Loader établit un dialogue avec son PM_LocalManager afin d obtenir un ordre pour lancer PM_LocalApplication. PM_LocalApplication : tisse le code métier de l application avec les services d adaptation du comportement. PM_Admission : puisque PMQDA exécute les mêmes opérations pour le test d admission que pour l adaptation, le PM_Admission possède la même structure interne que PM_DecisionMaking. Cela peut être atteint en appliquant notre stéréotype «PortToPort_Inheritance». PM_Adaptation possède les mêmes fonctionnalités de PM_Admission car PMQDA fait l adaptation au moment de l admission d une nouvelle application. En plus, la surveillance s effectue directement par Firas ALHALABI 119

«LocalApplication» :PM_LocalApplication * «OS» :PM_OS * «SpecificLM» :PM_LocalManager p * «Loader» * :PM_Loader supervise * «GlobalManager» Port p to PM_Loader is removed because the multiplicity is 0 :PM_GlobalManager 0..1 Explicit inheritance is required to propagate ancestor ports «GlobalManager» G_GlobalManager «LocalManager» G_LocalManager «PortToPort_Inheritance» «BlackBox_Inheritance» «GlobalManager» PM_ GlobalManager «PortToPort_Inheritance» «BlackBox_Inheritance» «SpecificLM» PM_ LocalManager «SpecificLM» «GlobalManager» PM_ GlobalManager PM_ LocalManager «Admission» :PM_ Admission «DecisionMaking» :PM_ DecisionMaking «DecisionMaking» PM_ DecisionMaking «Adaptation» «Planning» :PM_ Adaptation :PM_ Planning «DecisionMaking» PM_ DecisionMaking «PortToPort_Inheritance» «Admission» PM_ Admission Figure 5-7 : Le modèle spécifique PMQDA dérivé de notre architecture générique. PM_LocalManager. Ainsi, il n existe pas de composant de surveillance (par exemple, PM_Monitoring) dans le modèle de PMQDA. 5.7 Conclusion Ce chapitre met l accent sur le domaine de gestion de la QoS. Tout d abord, nous avons étudié les différentes architectures de gestion de la QoS qui existent dans la littérature. Cette étude nous a permise d identifier les composants nécessaires pour construire un système de gestion de la QoS. En utilisant les composants extraits de ces architectures étudiées et en s appuyant sur notre méthodologie de développement décrite dans le Firas ALHALABI 120

chapitre précédent, nous avons défini un cadre générique d une famille de systèmes voisins pour la gestion de la QoS. À ce point, nous arrivons à un espèce de langage décrivant les concepts dans le domaine de la gestion de la QoS, c est-à-dire un DSL. Nous avons ensuite défini un scénario générique possible pour construire à partir de ce cadre générique, un système de gestion de la QoS par dérivation. Enfin, et en se basant sur notre cadre générique, nous avons obtenu le modèle du système spécifique de gestion de la QoS pour des applications distribuées. Ce système de gestion spécifique appelé PMQDA. Firas ALHALABI 121

Chapitre 6 Conclusion et Perspectives 6.1 Implémentation Dans cette section, nous présentons brièvement une partie de l implémentation que nous avons réalisée pendant ce travail de thèse en vue de montrer la faisabilité de nos propositions. C est la première étape de mise en œuvre d une maquette complète pour la dérivation des modèles spécifiques à partir d un modèle générique. Le fait d utiliser le langage UML est un point positif puisque nous n avons utilisé que des notions standards, donc un certain nombre d outils peuvent nous aider à valider nos propositions. Nous avons choisi de développer une maquette via un outil de modélisation du marché IBM RSASE (IBM Rational Software Architecture Standard Edition) [IBM09]. Parmi les nombreuses possibilités de cet outil, il permet la définition des profils UML, la spécification et la validation des contraintes, mais aussi la transformation de modèles avec un haut niveau d abstraction, qui sont des aspects qui nous intéressent. En utilisant cet outil, des tests ont été réalisés sur certains points : La définition et la validation des profils. Nous avons défini les profils UML proposés comme prévu ; La vérification des contraintes écrites en OCL. Nous avons testé les contraintes du profil de dérivation et celles du profil commun. Nous avons vérifié quelques contraintes des profils générique et spécifique. Pour certaines contraintes, il est impossible d utiliser OCL, nous avons écrit du code en JAVA pour les spécifier ; La spécification des transformations de modèles. La manière d implémenter sort du cadre de cette thèse. Le but final est de dériver un modèle spécifique à partir du modèle générique. Pour cela, nous avons utilisé la transformation modèle à modèle (Model Mapping) de l outil RSASE. Nous travaillons sur une copie du modèle générique marquée par les stéréotypes pour ne pas le modifier en fonction des modèles spécifiques à dériver (comme nous l avons illustré dans la Figure 5-6). Ces stéréotypes fournissent le moyen pour spécifier les transformations par marquage d éléments du modèle. Cela guide l automatisation de la transformation. Firas ALHALABI 122

À ce point, nous définissons des règles de transformation entre les éléments du modèle source et ceux du modèle cible. C est ici que l on spécifie les règles telles que : effectuer l action A pour un élément marqué par le stéréotype «X». Par exemple, remplacer le composant qui est marqué par le stéréotype «replace», supprimer le connecteur qui est marqué par le stéréotype «remove», etc. Une transformation est généralement composée d un ensemble de transformations élémentaires. Par exemple, modèle à modèle qui nécessite package à package qui nécessite composant à composant. Pour exécuter la transformation de modèle, il faut d abord définir ces transformations élémentaires, et puis les exécuter automatiquement. La Figure 6-1 représente un exemple simple de transformation du modèle source à un modèle cible. Dans cet exemple, un élément du modèle source est (i) soit copié tel quel dans le modèle cible comme l élément source4 ; (ii) soit transformé en un élément différent comme dans le cas de l élément source3 du modèle source qui devient cible3 dans le modèle cible ; (iii) soit copié ou transformé en plusieurs éléments dans le modèle cible. C est le cas de l élément source1 qui est transformé en deux éléments cible1 et cible2 dans le modèle cible. L élément source2 du modèle source n est pas utilisé dans le modèle cible. Dans ces deux derniers cas, il faut écrire une règle de transformation qui filtre l élément source afin d obtenir l élément (ou les éléments) cible qui lui correspond. Dans RSASE, la copie est fournie et les règles de transformation sont écrites en JAVA. modèle source source1 source2 source3 source4 Règles de transformation transforme copie modèle cible cible1 cible2 cible3 source4...... Figure 6-1 : Exemple de transformation de modèle. 6.2 Conclusion générale L objectif principal de ce travail était de définir un cadre générique permettant la conception de systèmes de gestion de la QoS. Dans un premier temps, nous nous sommes attachés à l étude des systèmes existants de gestion de la QoS. Cette étude nous a montré que les systèmes de gestion de la QoS offrent souvent des fonctionnalités très similaires et ont des propriétés communes. En Firas ALHALABI 123

s appuyant sur cette étude, nous avons identifié la plupart des composants de base nécessaires pour construire un système de gestion de la QoS (middleware). En parallèle, pour gérer la QoS du système, il faut proposer un protocole qui permet l interconnexion entre les applications et le système de gestion de QoS proposé. Chaque application est écrite spécifiquement pour un middleware. Pour cela, nous avons proposé un modèle générique d application sous forme de graphe dans lequel les arcs sont des actions et les nœuds sont des points de décision. L exécution d une application est un chemin dans ce graphe. La gestion consiste alors à trouver le meilleur chemin possible dans ce graphe. Dans ce contexte, nous avons étudié différentes architectures distribuées et nous avons analysé trois politiques de gestion : centralisée, décentralisée complète et décentralisée partielle. Nous les avons comparées en fonction du nombre de messages échangés. Afin de généraliser notre solution, nous avons proposé une méthodologie de développement destinée à construire un cadre générique pour une famille de systèmes non seulement dans le domaine de la gestion de la QoS mais aussi dans un domaine quelconque. Cette méthodologie s inscrit dans le développement conduit par les modèles. À cet effet, nous avons utilisé les composants et le profil UML ainsi que des transformations assistées. Pendant le développement de notre méthodologie, nous avons constaté que l approche à base de composants nécessite certains éclaircissements : nous avons proposé de préciser l utilisation des notions telles que l instance de composant. Pour l héritage de composant, nous avons proposé : l héritage en boîte noire (BlackBox_Inheritance) et l héritage de ports (PortToPort_Inheritance). Un des principes de l héritage est de pouvoir substituer un élément par son descendant. Dans ce contexte, nous avons distingué la substitution absolue et contextuelle de composants. Enfin, nous avons appliqué notre méthodologie de développement pour construire un cadre générique pour une famille de systèmes de gestion de la QoS. Pour ce cadre, nous avons décrit aussi bien les aspects structurels que les aspects comportementaux, mais l aspect générique du comportement est plus difficile à décrire que l aspect générique de la structure. Ainsi, le comportement est basé sur des scénarios en fonction des besoins spécifiques de chaque développeur. À partir de notre cadre générique, les développeurs des systèmes de gestion de la QoS spécifiques peuvent dériver leurs propres modèles par transformation. Nous avons présenté la dérivation du système de gestion de la QoS spécifique PMQDA, développé par notre équipe. 6.3 Perspectives Les travaux réalisés dans le cadre de cette thèse ouvrent diverses perspectives intéressantes et plusieurs travaux futurs peuvent être envisagés : Firas ALHALABI 124

1. Des expérimentations supplémentaires sont nécessaires pour valider l approche décentralisée complète et partielle. Par exemple, via des agents. 2. Appliquer notre méthodologie de développement à un autre domaine que la gestion de la QoS. Par exemple, appliquer cette méthodologie au domaine des entreprises virtuelles. Dans ce cas, il faut définir une architecture orientée service qui serve comme un cadre générique pour une famille de systèmes spécifiques, chacun pour une entreprise et qui répond à ses besoins spécifiques. 3. Aider les développeurs des systèmes spécifiques de gestion de la QoS en leur offrant un environnement d exécution virtuelle leur permettant d essayer différents modes d exécution des applications et d obtenir des informations qualitatives et quantitatives pour évaluer leurs décisions. L avantage décisif est qu au lieu de développer tous les comportements alternatifs possibles, il suffira de développer les comportements qui présentent un réel intérêt pour améliorer la QoS globale du système. 4. Génération automatique du code de l application en utilisant la programmation par aspect (Aspect Oriented Programming, AOP). L idée serait de faire une description séparée des aspects fonctionnels et nonfonctionnels de la QoS, puis de tisser ces aspects pour former l application finale. Firas ALHALABI 125

Bibliographie [AAG02] [Abd99] [ACC03] [AGB02] [AMS07] [AMS08] [ANA + 08] [AVM + 06] [BCO + 02] Tarek Abdelzaher, Ella M. Atkins, and Kang G. Shin, "QoS Negotiation in Real-Time Systems and its application to Automated Flight Control". IEEE Transaction on Computers, Vol 49, N 11, p. 1170-1183, 2000. Tarek Abdelzaher, "QoS Adaptation in Real-Time Systems" PhD thesis, in The University of Michigan, Ann Arbor, MI, USA, 1999, http://citeseer.ist.psu.edu/abdelzaher99qos.html Le projet RNTL ACCORD, "Assemblage de Composants par Contrats en environnement Ouvert et Réparti", ENST Bretagne, France, 2003, http://www.infres.enst.fr/projets/accord/. Tarek Abdelzaher, Kang G. Shin, and Nina Bhatti, "Performance Guarantees for Web Server End-Systems: A Control-Theoretical Approach". IEEE Trans. Parallel and Distributed Systems, Vol 13, N 1, p. 80-96, 2002. Firas Alhalabi, Mathieu Maranzana, and Jean-Louis Sourrouille, "UML Component-based Framework: a Case Study for QoS Management Systems". In Poster in International Symposium on Distributed Objects and Applications (DOA'07). OTM LNCS Springer Conferences, Vilamoura, Algarve, Portugal, 2007. Firas Alhalabi, Mathieu Maranzana, and Jean-Louis Sourrouille, "A UML based methodology to ease the modeling of a set of related systems". The 3rd International Conference on Software Engineering Advances (ICSEA'08), p. 51-57, Sliema, Malta, 2008. Firas Alhalabi, Batouma Narkoy, Régis Aubry, Mathieu Maranzana, Lionel Morel, and Jean-Louis Sourrouille, "Centralized vs. Decentralized QoS Management Policy". 3rd International IEEE Conference on Information and Communication Technologies From Theory to Applications (ICTTA 08), p. 1-6, Damascus, Syria, 2008. Firas Alhalabi, Patrice Vienne, Mathieu Maranzana, and Jean-Louis Sourrouille, "Code Generation from the Description of QoS-Aware Applications". 2nd International IEEE Conference on Information and Communication Technologies From Theory to Applications (ICTTA 06), Vol 2, p. 3216-3221, Damascus, Syria, 2006. Franck Barbier, Corine Cauvet, Mourad Oussalah, Dominique Rieu, Sondes Bennasri, and Carine Souveyet, "Composants dans l'ingénierie Firas ALHALABI 126

des systèmes d'information: concepts clés et techniques de réutilisation". Assises du GDR I3, Nancy, France, 2002. [BCS09] [BHJ + 03] [BJB08] [BNB + 98] [Boc04] Gordon Blair, Thierry Coupaye, and Jean-Bernard Stefani, "Componentbased Architecture: the Fractal Initiative". Annals of Telecommunications, Vol 64 (1-2), p. 1-4, 2009. Andreas Birk, Gerald Heller, Isabel John, Klaus Schmid, Thomas von der Masen, and Klaus Muller, "Product Line Engineering: The State of the Practice". IEEE Software, vol 20, no. 6, p. 52-60, 2003. Mikaël Barbero, Frédéric Jouault, and Jean Bézivin, "Model Driven Management of Complex Systems: Implementing the Macroscope s Vision". 15th Annual IEEE International Conference and Workshop on Engineering of Computer Based Systems (ECBS'08), p. 277-286, Belfast, Northern Ireland, 2008. Scott Brandt, Gary Nutt, Toby Berk, and Marty Humphrey, "Soft realtime application execution with dynamic quality of service assurance". Quality of Service 1998, (IWQoS'98) Sixth International Workshop on, p. 154-163, Napa, CA, USA, 1998. Conrad Bock, "UML Composition Model". JOT: Journal OF OBJECT TECHNOLOGY, Vol 3, N 10, 2004. [Bor09] Borland Software Corporation "Together", 2006, http://www.borland.com/together, consulté dernièrement le 21/03/2009. [BV05] [Cam96] [Cas96] Ken Birman, and Alexey Vaysburd, "Adaptive Quality of Service for Availability (AQuA)", Intelligent Distributed Computing Department Distributed Systems Technology Group Projects, 2005, http://www.dist-systems.bbn.com/projects/aqua/. Andrew Campbell, "A Quality of Service Architecture" PhD thesis, Lancaster University, England, 1996, http://www.ctr.columbia.edu/~campbell/andrew/publications/papers/t hesis.ps.gz Cory Casanave, "Business Object Architectures and Standards". Business Object Design and Implementation Workshop in the International Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA'96), p. 7 28, Miami, USA, 1996. [CCG + 92] Andrew Campbell, Geoff Coulson, Francisco Garcia, and David Hutchkon, "A Continuous Media Transport and Orchestration Service". In Proc. ACM SIGCOMM 92, Maryland, USA, 1992. [CCH94] [CCR + 95] Andrew Campbell, Geoff Coulson, and David Hutchison, "A Quality of Service Architecture". ACM SIGCOMM Computer Communications Review, p. 6-27, 1994. Geoff Coulson, Andrew Campbell, Phillipe Robin, S. Blair Gordon, Michael Papathomas, and David Hutchison, "Support for Continuous Media in Distributed Systems". IEEE Journal on Selected Areas in Firas ALHALABI 127

Communications, Special Issue on ATM LANs., Vol 13, N 4, p. 686-699, U. K., 1995. [CH03] [CJC+00] Krzysztof Czarnecki, and Simon Helsen, "Classification of Model Transformation Approaches". In Proceedings of the 2nd OOPSLA Workshop on Generative Techniques in the Context of Model-Driven Architecture, California, USA, 2003. Ionut Cardei, Rakesh Jha, Mihaela Cardei, and Allalaghatta Pavan, "Hierarchical Architecture for Real-Time Adaptive Resource Management". Middleware 2000, Heidelberg, Springer Verlag, p. 415-434, New York, USA, 2000. (LNCS 1795) [CMS + 04] Eric Cariou, Raphaël Marvie, Lionel Seinturier, and Laurence Duchien, "Model Transformation Contracts and Their Definition in UML and OCL", Technical Report, N 2004-08, Laboratoire d Informatique Fondamentale de Lille (LIFL), Université des Sciences et Technologies de Lille, 2004. [CS01] [CS03] [Def02] [Doc05] José Lino Contreras, and Jean Louis Sourrouille, "A Framework for QoS management". TOOLS'39, p. 183-193, Santa Barbara, CA, USA, 2001. José Lino Contreras, and Jean-Louis Sourrouille, "Adaptable Objects for Dependability". Dependable Computing, LADC 2003, Heidelberg, Springer Verlag, p. 181-196, Grenoble, 2003. (LNCS 284) Defense Advanced Research Projects Agency, "Quality Objects (QuO)", 2002, http://www.dist-systems.bbn.com/tech/quo. Mike Docherty, "Object-Oriented Analysis and Design: Understanding System Development with UML 2.0". Chichester : J. Wiley & sons, April 2005. ISBN 978-0-470-09240-8 [DPT98] Hermann De. Meer, Antonio Puliafito, and Orazio Tomarchio, "Management of QoS with Software Agents". Cybernetics and Systems: An International Journal, Vol 27, N 5, 1998. [DSN + 97] Brian D. Noble, M. Satyanarayanan, Dushyanth Narayanan, James Eric Tilton, Jason Flinn, and Kevin R. Walker, "Agile Application-Aware Adaptation for Mobility". in 16th ACM Syposium in Operating System Principles (SOSP'97), Vol 31, N 5, p. 276-287, Saint Malo, France, 1997. [DW98] Desmond D'Souza, and Alan Wills, "Objects, Components, and Frameworks with UML". Menlo Park (Calif.) : Addison-Wesley Professional, 1998. ISBN 0201310120 [Erl05] Thomas Erl, "Service-Oriented Architecture (SOA): Concepts, Technology, and Design". London : Prentice Hall., 2005. ISBN 9780131858589 [FK98] Svend Frølund, and Svend Koistinen, "Quality of Service Specification in distributed object systems". Distributed Systems Engineering Journal, Vol 5, N 4, p. 179-202, 1998. [GCK00] David Garlan, Shang-Wen Cheng, and Andrew J. Kompanek, "Reconciling the Needs of Architectural Description with Object- Firas ALHALABI 128

Modeling Notations". Science of Computer Programming, Vol 44, N 1, p. 23-49, 2000. [GHJ+95] [GLK+06] [GWB + 99] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, "Design Patterns, Elements of Reusable Object-Oriented Software". Reading (Mass.) : Addison-Wesley, 1995. ISBN 0-201-63361-2. Hyun Gi Min, Jin Yeal Lee, Sung Ahn Kim, and Soo Dong Kim, "An Effective Method to Design CBD Components in Enterprise JavaBeans (EJB)". International Conference on Software Engineering Research, Management and Applications (SERA'06) (SERA'06), p. 49-56, Seattle, Washington, 2006. Steven Gribble, Matt Welsh, Eric Brewer, and David Culler. "The MultiSpace: an Evolutionary Platform for Infrastructural Services". In Proceeding of the 1999 Usenix Annual Technical Conference, Monterey, California, USA, 1999. [HM06] Kim Hamilton, and Russell Miles, "Learning UML 2.0". Sebastopol, CA : O'Reilly, 2006. ISBN 0-596-00982-8 [HM07] [HV98] [HV99] [HWC99] Jan Heering, and Marjan Mernik, "Domain-Specific Languages in Perspective". Report Software Engineering, No SEN-E0702, 2007. ISSN 1386-369X Abdelhakim Hafid, and Gregor V. Bochmann, "Quality of Service Adaptation in Distributed Multimedia Applications". Multimedia Systems, Vol 6, N 5, p. 299-315, 1998. Abdelhakim Hafid, and Gregor V. Bochmann, "An Approach to Quality of Service Management in Distributed Multimedia Application: Design and an Implementation". Multimedia Tools Appl., Vol 9, p. 167-191, 1999. Jiandong Huang, Yih Wang, and Feng Cao, "On Developing Distributed Middleware Services for QoS and Criticality-Based Resource Negotiation and Adaptation". Journal of Time-Critical Computing Systems, Vol 16, p. 187-221, 1999. [IBM09] IBM Rational Software Architect Standard Edition, http://www- 01.ibm.com/software/awdtools/swarchitect/standard/features, consulté dernièrement le 23/03/2009, [ICG + 04] [Int95] [Int96] James Ivers, Paul Clements, David Garlan, Robert Nord, Bradley Schmerl, Jaime Rodrigo, and Oviedo Silva, "Documenting Component and Connector Views with UML 2.0", Technical Report, N CMU/SEI- 2004-TR-008, ESC-TR-2004-008, Carnegie Mellon University U.S., 2004. International Organization for Standardization (ISO Standard), "Quality of Service-Basic Framework (ISO/IEC JTC1/SC21 N9309)", 1995. International Organization for Standardization (ISO Standard), "ITU-T Rec. X 901 ISO/IEC Foundations, Rapport technique N10746 Information technology: Reference Model - Open Distributed Procession (RM-ODP)", 1996. Firas ALHALABI 129

[JAB + 08] [JGM+06] [KK03] [KLM+97] [KR00] [Kur05] [KYO + 99] [Laz94] [Li00] [LKN01] [LN00] [MM03] Frédéric Jouault, Freddy Allilaire, Jean Bézivin, and Ivan Kurtev, "ATL: A model transformation tool". Science of Computer Programming Journal, Special Issue on Second issue of experimental software and toolkits (EST), Vol 72 (1-2), p. 31-39, 2008. Jean-Marc Jézéquel, Sébastien Gérard, Chokri Mraidha, and Benoit Baudry, " Le génie logiciel et l'idm : Approche Unificatrice par les modèles" chap. 3. In Jean-Marie Favre, Jacky Estublier, Mireille Blay- Fornarino, "L'ingénierie dirigée par les modèles", Paris : Hermès science publ., 2006. Geng-Sheng Kuo, and Po-Chang Ko, "Dynamic RSVP protocol". IEEE Communications Magazine, Vol 41, N 5, p. 130-135, 2003. Gregor Kiczales, John Lamping, Anurg Mendhekar, Chris Maeda, Christina Lopes, Jean-Marc Loingitier, and John Irwin. "Aspect Oriented Programming". European Conference on Object-Oriented Programming (ECOOP'97), Heidelberg : Springer-Verlag, Jyväskylä, Finnland, 1997. (LNCS 1241) Fabio Kon, and Manuel Román, "The dynamic TAO Reflective ORB", 2000, http://srg.cs.uiuc.edu/2k/dynamictao/. Ivan Kurtev, "Adaptability of Model Transformations" PhD thesis, University of Twente, The Netherlands, 2005, http://www.vf.utwente.nl/~kurtev/files/thesis.pdf. Masakatsu Kosuga, Tatsuya Yamazaki, Nagao Ogino, and Jun Matsuda, "Adaptive QoS Management Using Layered Multi-Agent System for Distributed Multimedia Applications". International Conference on Parallel Processing (ICPP'99), Vol 1, p. 388-394, Aizu-Wakamatsu, Fukushima, Japan, 1999. Aurel Lazar, "Challenges in Multimedia Networking". in Proc of International Hi-Tech Forum, Osaka, Japan, 1994. Baochun Li, "Agilos: A Middleware Control Architecture for Application- Aware Quality of Service Adaptations" PhD thesis, Department of Computer Science, University of Illinois, Urbana-Champaign, 2000, http://citeseer.ist.psu.edu/li00agilos.html. Baochun Li, William Kalter, and Klara Nahrstedt, "A Hierarchical Quality of Service Control Architecture for Configurable Multimedia Applications". Journal of High Speed Networks, Special Issue on Management of Multimedia Networking, Vol 9, N 3-4, p. 153-174, 2001. Baochun Li, and Klara Nahrstedt, "QualProbes: Middleware QoS Profiling Services for Configuring Adaptive Applications". Middleware 2000, Heidelberg : Springer Verlag, p. 256-272, 2000. (LNCS 1795) Mohammad Riaz Moghal, and Mohammad Saleem Mian, "QoS-Aware Adaptive Resource Management in Distributed Multimedia System Using Server Clusters". IEEE International Conference on Cluster Computing (CLUSTER'03), p. 508-511, 2003. Firas ALHALABI 130

[MN00] [MP06] [NCN98] [NQ96] [NS95] Nenad Medvidovic, and Richard N. Taylor, "A Classification and Comparison Framework for Software Architecture Description Languages". IEEE Computer Society, Transactions on Software Engineering, Vol 26, N 1, p. 70-93, USA, 2000. Vladimir Mencl, and Matej Polak, "UML 2.0 Components and Fractal: An Analysis". 5th Fractal Workshop Leveraging an European open source community around the Fractal component model, (part of ECOOP'06), p. 1-4, Nantes, France, 2006. Klara Nahrstedt, Hao-hua Chu, and Srinivas Narayan, "QoS-aware resource management for distributed multimedia applications". Journal of High Speed Networks, Special issue on multimedia networking, Vol 7, N 3-4, p. 229-257, 1998. Klara Nahrstedt, and Lintian Qiao, "Tuning System for Distributed Multimedia Applications", Technical Report, N UIUCDCS-R-96-1958, UILU-ENG-96-1721, University of Illinois, Urbana, IL, 1996. Klara Nahrstedt, and Ralf Steinmetz, "Resource Management in Networked Multimedia Systems". IEEE Computer Society, Vol 28, N 5, p. 52-63, 1995. [NS96] Klara Nahrstedt, and Jonatham M. Smith, "End-to-End QoS Guarantees: Lessons Learned from OMEGA, Distributed Systems Laboratory", Technical Report, N UIUCDCS-R-96-1957, UILU-ENG-69-1720, University of lllinois, 1996. [NWX00] Klara Nahrstedt, Duangdao Wichadakul, and Dongyan Xu, "Distributed QoS Compilation and Runtime Instantiation". IEEE/IFIP International Workshop on Quality of Service, Vol 1, p. 198-207, 2000. [OMG03] OMG: Object Management Group, "MDA Guide Version 1.0.1", Document Number: omg/2003-06-01, June 2003, http://www.omg.org/docs/omg/03-06-01.pdf. [OMG05] OMG: Object Management Group, "UML 2.0 Superstructure", document formal/05-07-04, August 2005, http://www.omg.org/docs/formal/05-07-04.pdf. [OMG05] OMG: Object Management Group, "MOF QVT Final Adopted Specification", November 2005, http://www.omg.org/docs/ptc/05-11- 01.pdf. [OMG06] OMG: Object Management Group, "Object Constraint Language Available Specification Version 2.0", May 2006, http://www.omg.org/docs/formal/06-05-01.pdf. [OMG06] OMG: Object Management Group, "Specification of CORBA Component Model (CCM) V4", document formal/06-04-01, April 2006, http://www.omg.org/technology/documents/formal/components.htm. [OMG07] OMG: Object Management Group, "UML 2.1.1 Superstructure", document forma/07-02-03., 2007, http://www.omg.org/docs/formal/07-02-03.pdf. Firas ALHALABI 131

[PL01] François Pinet, and Ahmed Lbath, "An Algorithm for Stereotype Deduction in UML-Based Formalism and its Application in Geographic Information Systems". In: Proc. of the Int. Symposium on Human- Centric Computing Languages and Environments (Visual/Multimedia Approaches to Programming and Software Engineering). IEEE Press, p. 296-314, Italy, 2001. [PP05] Dan Pilone, and Neil Pitman, "UML 2.0 in a Nutshell". Paris : O'Reilly, Jun 2005. ISBN 0-596-00795-7 [RL98] [Roo03] [SAW94] [SC00] [SJ98] [SK05] [SLC99] Pierre-Guillaume Raverdy, and Rodger Lea, "DART: A Distributed Adaptive Run-Time". in the IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing, The Lake District, U.K., 1998. Azam Roomi, "One step further towards a generic framework using XML" PhD thesis, Royal Institute of Technology, Stockholm, 2003, Bill N. Schilit, Norman Adams, and Roy Want, "Context-Aware Computing Applications". Workshop on Mobile Computing Systems and Applications, IEEE Computer Society, pp. 85-90, Santa Cruz, CA,1994. Frank Siqueira, and Vinny Cahill, "Quartz: A QoS Architecture for Open Systems". IEEE International Conference on Distributed Computing Systems (ICDCS'00), p. 197-204, Los Alamitos, CA, USA, 2000. Frolund Svend, and Koisten Jari, "QML: A Language for Quality of Service Specification", Technical Report, N HPL-98-10. USA : Hewlett Packard Laboratories, 1998, pp. 63. Miroslaw Staron, and Ludwik Kuzniarz, "Guidelines for creating "good" stereotypes". Proceedings of the NWUML 2005: The 3rd Nordic Workshop on UML and Software Modeling, Tampere, Finland, 2005. Douglas Schmidt, David Levine, and Chris Cleeland, "Architectures and Patterns for developing High-performance, Real-time CORBA Object Request Brokers". In Advances in Computers, Ed., Academic Press, Marvin Zelkowitz, 1999. [Sou99] Jean-Louis Sourrouille, "UML Behavior: Inheritance and Implementation in Current Object-Oriented Languages". in «UML» 99 The Unified Modeling Language, Vol 1, p. 457-472, 1999. [Sto05] [SZ95] [TJJ00] Zoran Stojanoviæ, "A Method for Component-Based and Service- Oriented Software Systems Engineering" PhD thesis, Doctoral Dissertation, Delft University of Technology, The Netherlands, 2005, Claudia Schmidt, and Martina Zitterbart, "Towards Integrated QoS Management". in Proceedings of the 5th IEEE Computer Society, Workshop on Future Trend of Distributed Computing Systems, Cheju Island, Korea, 1995. Eddy Truyen, Bo N. Joergensen, and Wouter Joosen, "Customization of Object Request Brokers through Dynamic Reconfiguration". in Proceedings of Tools Europe 2000, IEEE press, Mont-St-Michel, France, 2000. Firas ALHALABI 132

[Tou05] [VH97] [VKV + 95] [VS03] Jean-Charles Tournier, "Qinna, une architecture à base de composants pour la gestion de la qualité de service dans les systèmes embarqués mobiles" PhD thesis,, Villeurbanne, France, 2005, http://tel.archives-ouvertes.fr/tel- 00009704/en. Gregor v. Bochmann, and Abdelhakim Hafid, "Some Principles for Quality of Service Management". Distributed Systems Engineering Journal, Vol 4, N 1, p. 16-27(12), 1997. Andreas Vogel, Brigitte Kerhervk, Gregor V. Bochmann, and Jan Gecsei, "Distributed Multimedia and QoS: A survey". IEEE Multimedia Jornal, Vol 2, N 2, p. 10-19, 1995. Patrice Vienne, and Jean Louis Sourrouille, "DCBL: A framework for Dynamic Control of Behavior based on Learning". Proc. of ACM ESEC/FSE Int. Workshop on Intelligent Technologies in Software Engineering (WITSE'03), Vol 1, p. 44-47, Helsinki, Finland, 2003. [VSM05] Patrice Vienne, Jean-Louis Sourrouille, and Mathieu Maranzana, "Modeling Distributed Applications for QoS Management". Software Engineering and Middleware (SEM 2004), LNCS 3437, Springer Verlag, p. 170-184, Linz, Autriche, 2005. [WBG02] Nanbor Wang, Krishnakumar Balasubramanian, and Chris Gill, "Towards a Real-Time CORBA Component Model". in OMG Workshop On Embedded and Real-Time Distributed Object Systems, Washington D.C., 2002. [Wei00] [WFA99] [Xin00] [XXH00] [ZES97] Park Wei-Jin, "Architecture Description Using UML (Unified Modeling Language) in the Development for DCOM Application", Korea, 2000. à compléter Varuni Witana, Michael Fry, and Mark Antoniades, "A Software Framework for Application Level QoS Management". in Proceedings of Seventh International Workshop on Quality of Service (IEEE/IFIP IWQoS'99), p. 52-61, London, UK, 1999. Yajin Xin, "Design and Implementation of an Agent-based Architecture for QoS Management" PhD thesis, Ottawa-Carleton Institute for Computer Science, Ontario, Canada, 2000, http://www.collectionscanada.ca/obj/s4/f2/dsk1/tape3/pqdd_0019/m Q57762.pdf. Chen Xiaomei, Lu Xichen, and Wang Huaimin, "The Design of QoS Management Framework Based on CORBA A/V Stream Architecture". IEEE Computer Society, The Fourth International Conference/Exhibition Proceedings on High-Performance Computing in the Asia-Pacific Region, Vol 1, p. 542-547, Beijing, China, 2000. John A. Zinky, David E. Bakken, and Richard E. Schantz, "Architectural Support for Quality of Service for CORBA Objects". TAPOS - Theory and Practice of Object Systems, CORBA Object Syst, Vol 3, N 1, p. 55-73, 1997. [ZJ06] Tewfik Ziadi, and Jean-Marc Jézéquel, "Software Product Line Engineering with the UML: Deriving Products". The 10th International Firas ALHALABI 133

Software Product Line Conference (SPLC 2006), LNCS Springer Verlag, p. 557-588, Baltimore, Maryland, USA, 2006. [ZYS+99] John A. Zinky, Yecham Yemini, Richard E. Schantz, and Rodrigo Vanegas, "Dynamic Integrated Resource Management (DIRM)", BBN Intelligent Distributed Computing Systems Project, Department Distributed Systems Technology Group Projects, 1999, http://www.dist-systems.bbn.com/projects/dirm/. (ajouter la date de consultation) Firas ALHALABI 134

Firas ALHALABI 135

INSA DE LYON, DÉPARTEMENT DES ÉTUDES DOCTORALE, Écoles Doctorales 2007-2010 SIGLE ECOLE DOCTORALE NOM ET COORDONNEES DU RESPONSABLE CHIMIE E2M2 E.E.A. EDIIS EDISS Matériau x Math IF MEGA ScSo CHIMIE DE LYON http://sakura.cpe.fr/ed206 M. Jean Marc LANCELIN Insa : R. GOURDON MICROBIOLOGIE, MODELISATION http://biomserv.univ-lyon1.fr/e2m2 M. Jean-Pierre FLANDROIS Insa : H. CHARLES ELECTRONIQUE, ELECTROTECHNIQUE, AUTOMATIQUE http://www.insa-lyon.fr/eea M. Alain NICOLAS Insa : D. BARBIER ede2a@insa-lyon.fr Secrétariat : M. LABOUNE AM. 64.43 Fax : 64.54 INFORMATIQUE ET INFORMATION POUR LA SOCIETE http://ediis.univ-lyon1.fr M. Alain MILLE Secrétariat : I. BUISSON INTERDISCIPLINAIRE SCIENCESSANTE Sec : Safia Boudjema M. Didier REVEL Insa : M. LAGARDE MATERIAUX DE LYON M. Jean Marc PELLETIER Secrétariat : C. BERNAVON 83.85 MATHEMATIQUES ET INFORMATIQUE FONDAMENTALE M. Pascal KOIRAN Insa : G. BAYADA MECANIQUE, ENERGETIQUE, GENIE CIVIL, ACOUSTIQUE M. Jean Louis GUYADER Secrétariat : M. LABOUNE PM : 71.70 Fax : 87.12 ScSo M. BRAVARD Jean Paul Insa : J.Y. TOUSSAINT M. Jean Marc LANCELIN Université Claude Bernard Lyon 1 Bât CPE, 43 bd du 11 novembre 1918 69622 VILLEURBANNE Cedex Tél : 04.72.43 13 95 Fax : lancelin@hikari.cpe.fr M. Jean-Pierre FLANDROIS CNRS UMR 5558 Université Claude Bernard Lyon 1 Bât G. Mendel, 43 bd du 11 novembre 1918 69622 VILLEURBANNE Cédex Tél : 04.26 23 59 50 Fax 04 26 23 59 49 06 07 53 89 13 e2m2@biomserv.univ-lyon1.fr M. Alain NICOLAS Ecole Centrale de Lyon Bâtiment H9 36 avenue Guy de Collongue 69134 ECULLY Tél : 04.72.18 60 97 Fax : 04 78 43 37 17 eea@ec-lyon.fr Secrétariat : M.C. HAVGOUDOUKIAN M. Alain MILLE Université Claude Bernard Lyon 1 LIRIS - EDIIS Bâtiment Nautibus 43 bd du 11 novembre 1918 69622 VILLEURBANNE Cedex Tél : 04.72. 44 82 94 Fax 04 72 44 80 53 ediis@liris.cnrs.fr - alain.mille@liris.cnrs.fr M. Didier REVEL Hôpital Cardiologique de Lyon Bâtiment Central, 28 Avenue Doyen Lépine 69500 BRON Tél : 04.72.68 49 09 Fax :04 72 35 49 16 Didier.revel@creatis.uni-lyon1.fr M. Jean Marc PELLETIER INSA de Lyon MATEIS Bâtiment Blaise Pascal, 7 avenue Jean Capelle 69621 VILLEURBANNE Cédex Tél : 04.72.43 83 18 Fax 04 72 43 85 28 Jean-marc.Pelletier@insa-lyon.fr M.Pascal KOIRAN Ecole Normale Supérieure de Lyon 46 allée d Italie, 69364 LYON Cédex 07 Tél : 04.72.72 84 81 Fax : 04 72 72 89 69 Pascal.koiran@ens-lyon.fr Secrétariat : Fatine Latif - latif@math.univ-lyon1.fr M. Jean Louis GUYADER INSA de Lyon Laboratoire de Vibrations et Acoustique Bâtiment Antoine de Saint Exupéry 25 bis avenue Jean Capelle 69621 VILLEURBANNE Cedex Tél :04.72.18.71.70 Fax : 04 72 18 87 12 mega@lva.insa-lyon.fr M. BRAVARD Jean Paul Université Lyon 2, 86 rue Pasteur 69365 LYON Cedex 07 Tél : 04.78.69.72.76 Fax : 04.37.28.04.48 Jean-paul.bravard@univ-lyon2.fr Firas ALHALABI 136

FOLIO ADMINISTRATIF THESE SOUTENUE DEVANT L INSTITUT NATIONAL DES SCIENCES APLQUEES DE LYON NOM : ALHALABI Date de soutenance Prénoms : Mohamad-Firas 13 Mai 2009 TITRE : Modélisation et Développement d Applications avec Comportement Adaptable NATURE : Doctorat Ecole doctorale : EDIIS Numéro d ordre : 2009- ISAL-0038 Spécialité : Informatique Cote B.I.U. Lyon : CLASSE : RESUME : 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 CLES : Gestion de la QoS ; Composant UML ; Adaptation ; MDD/MDE/MDA ; Planification ; Cadre Générique ; Applications Distribuées. Laboratoire(s) de recherches : LIESP Directeur de thèse : Pr. Jean-Louis SOURROUILLE Composition du jury : Gilles MOTET, Lionel SEINTURIER, Ahmed LBATH, Mathieu MARANZANA, Jean-Louis SOURROUILLE. Firas ALHALABI 137