THÈSE

Présentée devant

L’Institut National des Sciences Appliquées de Lyon

Pour obtenir

LE GRADE DE DOCTEUR

Spécialité : INFORMATIQUE

ÉCOLE DOCTORALE : École Doctorale Informatique Information et Société

Par

M O H A M AD - FI RA S ALH AL AB I

Ingénieur en informatique

Titre :

Modélisation et Développement d’Applications avec

Comportement Adaptable
Soutenance 13 Mai 2009

Jury
Gilles MOTET Professeur, Laboratoire LATTIS – Rapporteur
INSAT, Toulouse
Lionel SEINTURIER Professeur, Laboratoire LIFL –INRIA Rapporteur
– Université des Sciences et
Technologies de Lille
Ahmed LBATH Professeur, Laboratoire LIG –IMAG Examinateur
Université Joseph Fourier, Grenoble
Mathieu MARANZANA Maître de conférence – Laboratoire Examinateur
LIESP – INSA de Lyon
Jean-Louis SOURROUILLE Professeur, Laboratoire LIESP – Directeur de thèse
INSA de Lyon

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 (self -
adaptation). 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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

start()
Inactive Middleware
do/activity Active Communication
stop() Protocol

Figure 1-1 : Une communication simple entre l‟application et le middleware.

Firas ALHALABI 12
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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.

QMS
Domain Specific
System Family
apply for
derived from
based on Development define based on
Methodology Generic
MDD DSL
Framework
use the principle of
Use
based on based on
SPL
Model
Described in UML Profile Component
is a Extension UML

for
PM PIM PSM
Connector

Component Component Constraint Stereotype

Inheritance Substitution
describe
apply on
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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 Graph QoS
Model Level

described by optimize
controled by based on
Application QoS Management
System Adaptation
is a
controlled by constraints is a is a

Static Dynamic
soft hard Management Management
Mode policy
is a
is a

intrusive non-intrusive
Centralized Decentralized
is a

Fully Partial
Decentralized 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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 non-
intrusive. 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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, deu x

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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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 elles -
mê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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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

[Link] 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 ressource s
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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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 uniqueme nt
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.

Bande
Paramètre Processeur Mémoire Mode Utilité
Passante
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

[Link] 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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.).

[Link] 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é.

[Link] 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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é.

[Link] 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

[Link] 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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.

[Link] 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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 d es
modèles.

2.8.2 Profil UML

[Link] 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éta-
classes existantes pour différents objectifs sans définir de nouvelle méta -
classe. 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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éta-
classes. 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 n on
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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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éta-
modé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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
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 global e
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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 Not Application Communication
Loaded Protocol
Middleware
Load/ Send(m,EndOfStep)

Loaded m:
a:
/Send(m,EndOfStep) Application Middleware
Running Waiting
NextStep(operatingMode)
do/activity
EndOfStep()
NextStep(operatingMode)

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 N1

Action Node N2

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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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 : Applicatio n mo no-thread

changement de plan (endroit quelco nque)

Normal

b : Applicatio n 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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 P2 , il
attend que l‟application A1 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 steps
P1
A1

A2
P2

a : Spécification d’une échéance. b : Synchronisation entre deux étapes.

Figure 3-4 : Améliorations du modèle générique.

Firas ALHALABI 39
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
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
#refRdV
0..1 #next
SchedulingUnit
RdV
delay : Time
pathId parallel : Boolean

0..1 #rdv
{ordered}
1..n #activities
1 1..n
Activity modeId Mode Step
PhaseId #mode utility Aect
: Integer #steps
* {ordered}
Hardware
#phase

0..n #requirements

Resource
global : boolean

Figure 3-5 : Le modèle UML d'une application.

Firas ALHALABI 40
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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 N2 et l‟acquisition de données (Acquisition) sur le nœud
N1 , 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
Activité Utilité Node
planification Mode étape (Step)
(Activity) (Utility) (Nœud)
(SU)
Load N1
1
Start Initialisation 100
Load N2

Acquisition 1 Acquisition 100 N1

Transmission1 N1
1 100
Reception1 N2
Transmission Compression N1
Transmission2 N1
2 100
Reception2 N2
Sample Decompression N2
1 Display1 100 N2
Display
2 Display2 80 N2

Firas ALHALABI 41
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 Noeud 1 Noeud 2

Rendez-vous

Activity Acquisition
Decision Point

Mode

[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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
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 app1 peut être
distribuée entre le nœud N 1 (app1.1) et le nœud N2 (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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 N1 N2

LM1 LM2

app1.1 app1.2
Net Net
app3 app2.3

N0 Application and
environment
GM descriptions with
local and global
plannings

N4 N3
Net Net
LM4 LM3

app2.2
app2.1
app4

Figure 3-7 : L‟architecture de déploiement de la politique centralisée.

[Link] 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é.

[Link] 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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

Local1 and global Local2 and global

planning with planning with
N1 N2
application and application and
environment environment LM2
LM1
description description
Net
app1.1 app1.2

app3 app2.3

Net Net
Net Net

N4 N3
Net LM3
LM4
Local4 and Local3 and
global planning global planning app2.2
app2.1 with application with application
and environment and environment app4
description description

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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 Loca1 planning Local2 planning N2
N1
with application with application
description description LM2
LM1

app1.1 app1.2
Net
Net
app3 app2.3

N0
Global Planning,
Full application
GM & environnement
description

N4 N3
Net Net LM3
LM4

app2.2
app2.1 Loca4 planning Loca3 planning
with application with application
app4
description description

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 ci -
dessus, 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 Tableau 3-2 : La définition des variables utilisées.

Variable Description

Node Le nombre de nœuds dans le système

Step Le nombre d‟étapes exécutées

Sync Le nombre d‟étapes qui utilisent des ressources globales

Le nombre d‟étapes qui utilisent des ressources globales

Shift
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

d1
Now
d
d2
c
loc
CPU1 (N1)
d

loc c
CPU2 (N2)

d
c
e b a
Net (N0)

loc a loc
CPUi (Ni)

e loc a
CPUn (Nn)

Figure 3-10 : Exemple de planification des ressources, illustrant le

décalage d‟étapes.

Firas ALHALABI 48
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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é N0 .
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.

[Link] 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 N1:LM1 N0:GM N2:LM2

1: NextStep(mode) // Load

unique mode

Admission
2: NextStep(mode) // Load
in fact

3: EndOfStep()

4: EndOfStep()

5: mode=modeScheduling()

6: NextStep(mode) // Transmission

Gestion d’étapes
7: NextStep(mode) // Reception

8: EndOfStep()

9: EndOfStep()

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.

[Link] 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 exemple, Transmission1 du nœud N 1 et Reception par N2. 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.

[Link] 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 Transmission 1 avec Reception 1 sur les nœuds N 1 et N2 , les deux nœuds
doivent être prêts. À cet effet, N 1 envoie 1 message (I_am_ready()) à N0
(qui accueille le GM) pour savoir si la transmission est possible. À son tour
N0 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 N1 et N2 sont notifiés par le GM hébergé sur le nœud
N0 , 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
4
(cas simple)
3*Sync
Décentralisé partielle
2*Shift + Node -1 +4
(cas complexe)

Décentralisée complète 2*Shift + 2*Node + 1 2*Sync

Firas ALHALABI 54
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
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
50
Exchanged messages

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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 Centralized Partial decentralized Fully decentralized

Exchanged messages 60

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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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 permettan t
d‟intégrer notre méthodologie de développement d‟une famille de systèmes
voisins.

Firas ALHALABI 57
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
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 :B1 :B2

Figure 4-1 : Le modèle de composant dans UML 2.0.

Firas ALHALABI 59
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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 : La vue externe de composant.

Port
A Delegation

b:B c1:C connector

Interface

c2: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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
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.

[Link] 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.

[Link] 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.

[Link] 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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.

[Link] 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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.

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 c1:C connector

connector
Provided
c2:C Required

interface
interface

d:D e:E

Figure 4-4 : Le composant composite dans UML 2.0.

Firas ALHALABI 64
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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.

[Link] 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.

[Link] 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 promouvoi r
la réutilisation par héritage [ACC03].

Firas ALHALABI 65
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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 (interfac es 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

b:B c:C

d:D
IBD

AA AAA

b:BB c:CC b:BBB c:CCC

C

d:DD d:DDD
IBD IBD

Figure 4-5 : L‟héritage de composants comme il est défini dans [Boc04].

Firas ALHALABI 66
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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.

[Link] 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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éta-
classe 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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

p
Port q is inherited I_Base_Provided
C_Base
implicitly q

I_Base_Required
«PortToPort_Inheritance»
{redefines p}
p_Spec
C_Specialized I_Specialized_Provided

I_Specialized_Required

Figure 4-8 : La définition du stéréotype «PortToPort_Inheritance» entre

deux composants.

Firas ALHALABI 69
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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 C1 ayant les
ports p 1, p 2 par le composant C2 ayant les ports q1 , q 2 nécessite de mettre
chaque qi 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.

[Link] 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
IRA). 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.

IFA
«Interface» «Interface»

IRB IFA A

IRA

«Interface» «Interface» IFB

B
IRA IFB

IRB

Figure 4-9 : La substitution absolue de composants.

[Link] 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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 IC ayant des services S 1, S2 , S 3, S4 (IC 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  IB  IC). Dans ce contexte-là, le
composant B est substituable à A, mais dans d‟autres context es cette
substituabilité n‟est probablement pas possible. Ce type de substitution est
envisageable sans prouver la possibilité de substitution car nous ne

IA I C
A C

IA={S1, S2}
IC={S1, S2, S3, S4}
IB
B
IB={S3, S4}
(IA  IB  IC)

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.

JA JC
A C

JA={S1, S2, S3, S4}

JC={S1, S2} JB
B
JB={S1, S2, S3, S5 S6}
(JC  JA  JB)

Figure 4-11: La substitution contextuelle pour des interfaces fournies.

Firas ALHALABI 72
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 [Link] 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 :

S [Pre
-  S'
Condition] methode/[Post-Condition]

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

On
Protocole P1 State A1 State A2
Off

On On
Protocole P2 State B1 State B2 State B3

Off

Figure 4-12 : Machines à états associés aux interfaces des composants A et B.

Firas ALHALABI 73
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 même comportement [Sou99]). Nous acceptons que B soit substituable à A
si P 1=P2 (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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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.

(d)
Expert
UML

Common
Profile

describe (a)
Family of systems Generic
Architect

In a given domain (1) Profile

(b)
(2) design
(6) Derivation
Generic Model
Profile
(c)
automatic
Specific

Scope of profile
TModel Profile
feedback
Developer

manuala (3)
utomatic
Specific
Model
(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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 Generic Profile

«metaclass» «metaclass» «metaclass»

Component Component Component

«stereotype» «stereotype» «stereotype»

ServiceRequester ServiceProvider 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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» «ServiceProvider»
req
:G_ ServiceRequester :G_ ServiceProvider

«WebService»
G_WebService

«PortToPort_Inheritance»

«WebServiceA» «WebServiceB»
G_WebServiceA 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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

assocBC
assocAC
«remove»

«ComponentA»
assocAB «ComponentB»
:G_ A :G_ B

«PortToPort_Inheritance»

«ComponentD» «remove»
«ComponentE»
G_D
G_E

Le même partie après transformation et application de stéréotype «remove»

«ComponentC»

G_C TModel

assocAC

«ComponentA»
assocAB «ComponentB»
:G_ A :G_ B

«ComponentD»

G_D

Figure 4-16 : L‟application du stéréotype «remove» sur un modèle.

Firas ALHALABI 79
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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

«Variation»
«ServiceRegister»
G_ServiceRegister
«Variant» «Variant»
«WebService» «LocationService»
:G_WebService :G_LocationService

find
«optional» publish

«ServiceRequester» «ServiceProvider»
req
:G_ ServiceRequester :G_ ServiceProvider

«Variation»
«WebService»
G_WebService
«PortToPort_Inheritance»

«Variant» «Variant»
«WebServiceA» «WebServiceB»
G_WebServiceA 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
4.5.5 Transformation de modèles

[Link] 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
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 en tre deux
composants en utilisant les deux stéréotypes que nous avons introduits dans
la section [Link].

Firas ALHALABI 83
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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» «ServiceProvider»
req
:S_ ServiceRequester :S_ ServiceProvider

Figure 4-18 : Un modèle spécifique possible dérivé du modèle générique.

Firas ALHALABI 84
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 «ServiceRequester» «ServiceProvider»
req
:S_ ServiceRequester :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» req «ServiceProvider»

SRequester:S_ ServiceRequester SProvider:S_ ServiceProvider

«EJBSessionBean» «EJBSessionBean»
«SRequester» «SProvider»
«EJBRealizeRemote»

«EJBRealizeRemote»

* *
«EJBImplementation» «EJBImplementation»

SRequesterImplementation SProviderImplementation
«EJBRealizeHome»

«EJBRealizeHome»

«EJBSessionRemoteInterface» «EJBSessionRemoteInterface»
Request Provide
e
«EJBCreateMethod» request() «EJBCreateMethod» Send()

instantiate instantiate
«EJBSessionHomeInterface» «EJBSessionHomeInterface»
HomeRequest HomeProvid
«EJBCreateMethod» Create() e
«EJBCreateMethod» Create()

Figure 4-21: Le modèle de PSM en utilisant la plateforme EJB.

Firas ALHALABI 86
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
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 m2 () 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 m2().
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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 m1() belongs to the
interface IA SD Generic Scenario

A
a :A b :B c :C d :D

b :B
IA IA m1()

IBC m2()

«Interface»
IBC
c :C m3()
m2()
m8()

m4()

m5()
d :D

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

SD Specific Scenario
A

b :B a :A b :B d :D
IA IA

m1() C is
removed

C is removed

m4()

d :D

Figure 4-23 : Conserver la cohérence entre les diagrammes au

moment de la dérivation.

Firas ALHALABI 88
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
m2(), m3() et m5() 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 m1() 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 cad re
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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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 sous-
composants 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 eux-
mê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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 * supervise
:Application :LSM :HSM
*
* 0..1
1

1
:OS

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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
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

[Link] 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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).

[Link] 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
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 [Link] 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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 * 1
:Application :Manager

* *
1

1
:OS

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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 Tableau 5-1 : Comparaison entre différentes architectures de
gestion de la QoS.

Caractéristiques Composants

Architecture Distribuée Spécification Admission Négociation Traduction Surveillance Adaptation

de QoS (test) (Mapping) (Monitoring)

QoS-A Oui Oui Oui/sans Non Oui/ Non Oui

préciser
Couches

OMEGA Oui Oui Oui/sans Oui/sans Non/2KQ Non Non/Oui

préciser préciser 2KQ ,
Oui Agilos

DART Non Oui Non Non Non Non Oui

RTARM Oui Oui Oui/sans Oui/sans Oui/Sans Oui Oui/après

préciser préciser préciser l‟exécution

QuO Oui Oui/via QDL Non Oui/sans Non Non Oui

préciser

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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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é

[Link] 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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 Tableau 5-2 : Les stéréotypes du profil générique.

Stéréotype Class de Base Description

UML
«Manager» Component Gestionnaire de QoS en général.
Gestionnaire global de QoS, le
«GlobalManager» Component gestionnaire global est un type de
«Manager».
Gestionnaire local pour chaque nœud,
«LocalManager» Component chaque gestionnaire local est de type
«Manager».
Déclencheur de la partie locale de
«Loader» Component
l‟application qui se trouve sur un nœud.
Partie locale de l‟application pour
«LocalApplication» Component
chaque nœud.
Entité qui réalise la traduction des
«Mapping» Component paramètres de QoS en consommation de
ressources et vice-versa.

Composant qui surveille les ressources

«Monitoring» Component
et détecte la violation du contrat de QoS.
Négociateur qui cherche un agrément
«Negotiation» Component
avec l‟application pour l‟admettre.
Élément qui cherche le meilleur point
«Adaptation» Component opérationnel possible pour exécuter
l‟application et pilote la politique
«Policy».
Entité qui prend des décisions et les
«DecisionMaking» Component
applique par négociation ou adaptation.
Entité qui teste si les ressources
«Admission» Component nécessaires pour lancer les applications
sont disponibles.
Politiques à suivre pour gérer les
«Policy» Component
ressources du système.
Indique que le système de gestion utilise
«MixedPolicy» Component plusieurs politiques d‟ordonnancement à
la fois.
Indique que la politique que l‟on utilise
«SimplePolicy» Component est une politique simple (une seule
politique).
«OS» Component Système d‟exploitation virtuel utilisé.

Firas ALHALABI 105

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 [Link] 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.

Nœud qui abrite le gestionnaire global

«GlobalManager» Location : string
dans le système.

Attaché à chaque gestionnaire local pour

«LocalManager» NodeNum : int indiquer le numéro du nœud qui
l‟héberge.

NodeNum : int Numéro du nœud.

«LocalApplication»
Numéro de la partie locale de
PartNum : int
l‟application (instance).

Intérêt d‟utiliser tel ou tel mode de

«Adaptation» Utility : int
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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 [Link] 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.

[Link] 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.

[Link] 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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 Specification Source code
0..1
supervise «Manager»
* 1 «Manager»
«LocalApplication» G_Manager
:G_LocalApplication :G_Manager *
«PortToPort_Inheritance»
* * 1 p
1
*
1 «Optional»
«OS» «LocalManager» «GlobalManager»
«Loader»
:G_OS :G_Loader G_LocalManager G_GlobalManager
1 *
«Manager»
G_Manager
«Optional» «Optional»
«Mapping» «DecisionMaking» «Admission» «Monitoring
:G_Mapping :G_DecisionMaking :G_Admission :G_Monitoring

«DecisionMaking» «DecisionMaking»
G_DecisionMaking
G_DecisionMaking
«Optional» «Policy»
«Negotiation» «Adaptation» «PortToPort_Inheritance»

:G_Negotiation :G_Adaptation :G_Policy

«Admission»
G_Admission

«Policy»

G_Policy
«PortToPort_Inheritance»
«MixedPolicy»
G_MixedPolicy «Optional» «Optional»
«Optional» «Optional» «SimplePolicy» «MixedPolicy»
«Learning» «ExpertSystem» G_SimplePolicy G_MixedPolicy
:G_Learning :G_ExpertSystem
«PortToPort_Inheritance»

«Optional» «Optional» «Optional»

«Learning» .......... «Planning» ...... «ExpertSystem»
:G_Learning G_Planning :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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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.

[Link] 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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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 multi -
agents (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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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 plu s
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].

[Link] 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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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

a1: G_Local lm1: G_Local gm1: n1:

Application Manager G_GlobalManager G_Negotiation

negotiate(operatingModes)
negotiate(operatingModes)
negotiate(operatingModes)

decision(reply, mode)

alt [reply=ok] accept(mode)

accept(mode)
Selected mode
[else]
reject(mode)

reject(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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
  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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 SU0 SU1 SU2 SUi SUn-1 SUn

(2)
Exit()

(6) Monitoring Monitoring Monitoring Monitoring

(7) Adaptation Adaptation Adaptation Adaptation

Admission of Admission (3) Admission Admission Admission

SU0, without Mapping (4) Mapping ........ Mapping Mapping
Negotiation
Negotiation (5) Negotiation Negotiation Negotiation

(1) Loading Execution Unload

End
Outside the Application Execution Application
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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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 contrai ntes
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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 Generic copy Generic
Model Model (copy with tags)

automatic
transformations

PMQDA Temporary
Model manual Model Tags to guide the
transformations 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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 «LocalApplication» * «SpecificLM» supervise «GlobalManager»
:PM_LocalApplication :PM_LocalManager :PM_GlobalManager
*
* p 0..1
* Port p to PM_Loader
«OS» «Loader» is removed because
* the multiplicity is 0
:PM_OS :PM_Loader

Explicit inheritance is «GlobalManager» «LocalManager»

required to propagate
ancestor ports G_GlobalManager G_LocalManager

«PortToPort_Inheritance» «PortToPort_Inheritance»
«BlackBox_Inheritance» «BlackBox_Inheritance»
«GlobalManager» «SpecificLM»
PM_ GlobalManager PM_ LocalManager

«GlobalManager»
«SpecificLM» PM_ GlobalManager
PM_ LocalManager «Admission» «DecisionMaking»
:PM_ Admission :PM_ DecisionMaking

«DecisionMaking»
«DecisionMaking»
PM_ DecisionMaking
PM_ DecisionMaking
«Planning» «PortToPort_Inheritance»
«Adaptation»
«Admission»
:PM_ Adaptation :PM_ Planning
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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 À 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.

Règles de
modèle source modèle cible
transformation
source1 cible1

source2 cible2
transforme
source3 cible3
copie
source4 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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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 perspective s
intéressantes et plusieurs travaux futurs peuvent être envisagés :

Firas ALHALABI 124

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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 non-
fonctionnels de la QoS, puis de tisser ces aspects pour former l‟application
finale.

Firas ALHALABI 125

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 Bibliographie
[AAG02] 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.

[Abd99] Tarek Abdelzaher, "QoS Adaptation in Real-Time Systems" PhD thesis,

in The University of Michigan, Ann Arbor, MI, USA, 1999,
[Link]

[ACC03] Le projet RNTL ACCORD, "Assemblage de Composants par Contrats en

environnement Ouvert et Réparti", ENST Bretagne, France, 2003,
[Link]

[AGB02] 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.

[AMS07] 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.

[AMS08] 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.

+
[ANA 08] 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.

+
[AVM 06] 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.

+
[BCO 02] Franck Barbier, Corine Cauvet, Mourad Oussalah, Dominique Rieu,
Sondes Bennasri, and Carine Souveyet, "Composants dans l'ingénierie

Firas ALHALABI 126

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 des systèmes d'information: concepts clés et techniques de
réutilisation". Assises du GDR I3, Nancy, France, 2002.

[BCS09] Gordon Blair, Thierry Coupaye, and Jean-Bernard Stefani, "Component-

based Architecture: the Fractal Initiative". Annals of
Telecommunications, Vol 64 (1-2), p. 1-4, 2009.

+
[BHJ 03] 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.

[BJB08] 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.

+
[BNB 98] Scott Brandt, Gary Nutt, Toby Berk, and Marty Humphrey, "Soft real-
time 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.

[Boc04] Conrad Bock, "UML Composition Model". JOT: Journal OF OBJECT

TECHNOLOGY, Vol 3, N° 10, 2004.

[Bor09] Borland Software Corporation "Together", 2006,

[Link] consulté dernièrement le
21/03/2009.

[BV05] Ken Birman, and Alexey Vaysburd, "Adaptive Quality of Service for
Availability (AQuA)", Intelligent Distributed Computing Department
Distributed Systems Technology Group Projects, 2005,
[Link]

[Cam96] Andrew Campbell, "A Quality of Service Architecture" PhD thesis,

Lancaster University, England, 1996,
[Link]
[Link]

[Cas96] 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] Andrew Campbell, Geoff Coulson, and David Hutchison, "A Quality of
Service Architecture". ACM SIGCOMM Computer Communications
Review, p. 6-27, 1994.

+
[CCR 95] 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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 Communications, Special Issue on ATM LANs., Vol 13, N° 4, p. 686-
699, U. K., 1995.

[CH03] 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.

[CJC+00] 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] José Lino Contreras, and Jean Louis Sourrouille, "A Framework for QoS
management". TOOLS'39, p. 183-193, Santa Barbara, CA, USA, 2001.

[CS03] 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)

[Def02] Defense Advanced Research Projects Agency, "Quality Objects (QuO)",

2002, [Link]

[Doc05] 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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 Modeling Notations". Science of Computer Programming, Vol 44, N° 1,
p. 23-49, 2000.

[GHJ+95] 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.

[GLK+06] 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.

+
[GWB 99] 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] Jan Heering, and Marjan Mernik, "Domain-Specific Languages in

Perspective". Report Software Engineering, No SEN-E0702, 2007. ISSN
1386-369X

[HV98] Abdelhakim Hafid, and Gregor V. Bochmann, "Quality of Service

Adaptation in Distributed Multimedia Applications". Multimedia
Systems, Vol 6, N° 5, p. 299-315, 1998.

[HV99] 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.

[HWC99] 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, [Link]

[Link]/software/awdtools/swarchitect/standard/features, consulté
dernièrement le 23/03/2009,

+
[ICG 04] 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.

[Int95] International Organization for Standardization (ISO Standard), "Quality

of Service-Basic Framework (ISO/IEC JTC1/SC21 N9309)", 1995.

[Int96] 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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 +
[JAB 08] 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.

[JGM+06] 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.

[KK03] Geng-Sheng Kuo, and Po-Chang Ko, "Dynamic RSVP protocol". IEEE
Communications Magazine, Vol 41, N° 5, p. 130-135, 2003.

[KLM+97] 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)

[KR00] Fabio Kon, and Manuel Román, "The dynamic TAO Reflective ORB",
2000, [Link]

[Kur05] Ivan Kurtev, "Adaptability of Model Transformations" PhD thesis,

University of Twente, The Netherlands, 2005,
[Link]

+
[KYO 99] 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.

[Laz94] Aurel Lazar, "Challenges in Multimedia Networking". in Proc of

International Hi-Tech Forum, Osaka, Japan, 1994.

[Li00] 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,
[Link]

[LKN01] 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.

[LN00] 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)

[MM03] 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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
[MN00] 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.

[MP06] 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.

[NCN98] 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.

[NQ96] 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.

[NS95] 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,
[Link]

[OMG05] OMG: Object Management Group, "UML 2.0 Superstructure", document

formal/05-07-04, August 2005, [Link]
[Link].

[OMG05] OMG: Object Management Group, "MOF QVT Final Adopted

Specification", November 2005, [Link]
[Link].

[OMG06] OMG: Object Management Group, "Object Constraint Language

Available Specification Version 2.0", May 2006,
[Link]

[OMG06] OMG: Object Management Group, "Specification of CORBA Component

Model (CCM) V4", document formal/06-04-01, April 2006,
[Link]

[OMG07] OMG: Object Management Group, "UML 2.1.1 Superstructure",

document forma/07-02-03., 2007,
[Link]

Firas ALHALABI 131

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
[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] 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.

[Roo03] Azam Roomi, "One step further towards a generic framework using
XML" PhD thesis, Royal Institute of Technology, Stockholm, 2003,

[SAW94] 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.

[SC00] 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.

[SJ98] 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.

[SK05] 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.

[SLC99] 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] Zoran Stojanoviæ, "A Method for Component-Based and Service-

Oriented Software Systems Engineering" PhD thesis, Doctoral
Dissertation, Delft University of Technology, The Netherlands, 2005,

[SZ95] 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.

[TJJ00] 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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
[Tou05] 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, Institut National des Sciences Appliquées de Lyon,
Villeurbanne, France, 2005, [Link]
00009704/en.

[VH97] 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.

+
[VKV 95] 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.

[VS03] 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] Park Wei-Jin, "Architecture Description Using UML (Unified Modeling

Language) in the Development for DCOM Application", Korea, 2000. à
compléter

[WFA99] 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.

[Xin00] Yajin Xin, "Design and Implementation of an Agent-based Architecture

for QoS Management" PhD thesis, Ottawa-Carleton Institute for
Computer Science, Ontario, Canada, 2000,
[Link]
[Link].

[XXH00] 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.

[ZES97] John A. Zinky, David E. Bakken, and Richard E. Schantz, "Architectu ral
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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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,
[Link] (ajouter la date de
consultation)

Firas ALHALABI 134

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
Firas ALHALABI 135
Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 INSA DE LYON, DÉPARTEMENT DES ÉTUDES DOCTORALE, Écoles Doctorales 2007 -2010

SIGLE ECOLE DOCTORALE NOM ET COORDONNEES DU RESPONSABLE

CHIMIE DE LYON M. Jean Marc LANCELIN
Université Claude Bernard Lyon 1
CHIMIE [Link] Bât CPE, 43 bd du 11 novembre 1918
69622 VILLEURBANNE Cedex
M. Jean Marc LANCELIN Tél : 04.72.43 13 95 Fax :
Insa : R. GOURDON lancelin@[Link]
MICROBIOLOGIE, MODELISATION M. Jean-Pierre FLANDROIS
E2M2 CNRS UMR 5558
[Link] Université Claude Bernard Lyon 1
Bât G. Mendel, 43 bd du 11 novembre 1918
69622 VILLEURBANNE Cédex
M. Jean-Pierre FLANDROIS Tél : 04.26 23 59 50 Fax 04 26 23 59 49
06 07 53 89 13
Insa : H. CHARLES e2m2@[Link]
ELECTRONIQUE, M. Alain NICOLAS
E.E.A. ELECTROTECHNIQUE, AUTOMATIQUE Ecole Centrale de Lyon
[Link] Bâtiment H9
M. Alain NICOLAS 36 avenue Guy de Collongue
Insa : D. BARBIER 69134 ECULLY
ede2a@[Link] Tél : 04.72.18 60 97 Fax : 04 78 43 37 17
Secrétariat : M. LABOUNE eea@[Link]
AM. 64.43 – Fax : 64.54 Secrétariat : M.C. HAVGOUDOUKIAN
INFORMATIQUE ET INFORMATION M. Alain MILLE
EDIIS POUR LA SOCIETE Université Claude Bernard Lyon 1
LIRIS - EDIIS
[Link] Bâtiment Nautibus
43 bd du 11 novembre 1918
M. Alain MILLE 69622 VILLEURBANNE Cedex
Secrétariat : I. BUISSON Tél : 04.72. 44 82 94 Fax 04 72 44 80 53
ediis@[Link] - [Link]@[Link]
INTERDISCIPLINAIRE SCIENCESSANTE M. Didier REVEL
EDISS Hôpital Cardiologique de Lyon
Sec : Safia Boudjema Bâtiment Central, 28 Avenue Doyen Lépine
69500 BRON
M. Didier REVEL Tél : 04.72.68 49 09 Fax :04 72 35 49 16
Insa : M. LAGARDE [Link]@[Link]
MATERIAUX DE LYON M. Jean Marc PELLETIER
INSA de Lyon
Matériau M. Jean Marc PELLETIER MATEIS
x Bâtiment Blaise Pascal, 7 avenue Jean Capelle
Secrétariat : C. BERNAVON 69621 VILLEURBANNE Cédex
83.85 Tél : 04.72.43 83 18 Fax 04 72 43 85 28
[Link]@[Link]
MATHEMATIQUES ET INFORMATIQUE [Link] KOIRAN
Math IF FONDAMENTALE Ecole Normale Supérieure de Lyon
46 allée d‟Italie, 69364 LYON Cédex 07
M. Pascal KOIRAN Tél : 04.72.72 84 81 Fax : 04 72 72 89 69
[Link]@[Link]
Insa : G. BAYADA Secrétariat : Fatine Latif - latif@[Link]
MECANIQUE, ENERGETIQUE, GENIE M. Jean Louis GUYADER
MEGA CIVIL, ACOUSTIQUE INSA de Lyon
Laboratoire de Vibrations et Acoustique
M. Jean Louis GUYADER Bâtiment Antoine de Saint Exupéry
25 bis avenue Jean Capelle
Secrétariat : M. LABOUNE 69621 VILLEURBANNE Cedex
PM : 71.70 –Fax : 87.12 Tél :[Link].70 Fax : 04 72 18 87 12
mega@[Link]
ScSo ScSo M. BRAVARD Jean Paul
Université Lyon 2, 86 rue Pasteur
M. BRAVARD Jean Paul 69365 LYON Cedex 07
Tél : [Link].76 Fax : [Link].48
Insa : J.Y. TOUSSAINT [Link]@[Link]

Firas ALHALABI 136

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon
 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 f aç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 Qo S 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

Thèse en Informatique / 2009
Institut National des Sciences Appliquées de Lyon