BETTOU Farida

République Algérienne Démocratique et Populaire
Ministère de l’enseignement supérieur

Et de la recherche scientifique
Université Constantine 2 - Abdelhamid Mehri
Faculté des Nouvelles Technologies de
l’Information et de la Communication
N° d’ordre : ……………………….
Série : …………………….…
THESE
Présentée pour obtenir le Diplôme de Doctorat en Sciences en
Informatique
Thème:
Gestion de la Qualité de Service dans les Applications
Multimédia basée sur les préférences de l’utilisateur
et orientée vers la Programmation Orientée Aspect
Présentée par : BETTOU Farida Dirigée par : Pr. BOUFAIDA Mahmoud
Soutenue à Constantine le : 15/ 05/2017
Devant le jury :
Président : Pr. Ramdane Maamri, Université Abdelhamid Mehri, Constantine 2.
Rapporteur : Pr. Mahmoud Boufaida, Université Abdelhamid Mehri, Constantine 2.
Examinateurs : Pr. Nadir Farah, Université Badji Mokhtar, Annaba.
: Pr. Mohamed Tarek Khadir, Université Badji Mokhtar, Annaba
: Dr. Mourad Bouzenada, Université Abdelhamid Mehri, Constantine 2
1
Remerciements
D'abord, louange à DIEU, le tout puissant, que je remercie beaucoup de m'avoir donné la
force et le courage de terminer cette thèse. Sans lui, rien n’aurait pu être réalisé.
Tout d’abord, je tiens à remercier et exprimer toute ma reconnaissance auprès de mon

encadreur monsieur, BOUFAIDA Mahmoud, Professeur à l'université Constantine 2. Il m’a
initié à la recherche dans un domaine qui m’a toujours motivé. Méticuleux et perfectionniste,
toujours disponible, il m’a prodigué des conseils inestimables, dans tous les domaines, tout au
long de ma thèse. Je suis très fière de la formation de chercheuse acquise sous son
encadrement. Je le remercie très fort et je m’excuse auprès de sa noble personne de lui avoir
pris beaucoup de son temps.
Je tiens aussi à remercier Monsieur Mr. MAAMRI Ramdane, Professeur à l'université

Constantine 2 de m’avoir fait l’honneur d’accepter de présider le jury de ma soutenance de
thèse, ainsi que :
• Monsieur Mr. FARAH Nadir Professeur à l’université de Annaba,

• Monsieur Mr. KHADIR Mohamed Tarek Professeur à l’université de Annaba.
• Monsieur Mr. BOUZENADA Mourad Maitre de conférences A à université Constantine 2,
Pour l’honneur d'avoir accepté de faire partie de ce jury en tant qu'examinateurs.
Enfin, je tiens à présenter mes remerciements les plus sincères à ma famille. A mes parents,
pour leurs soutiens et encouragements de tous les instants et sans qui cette aventure n’aurait
jamais vu le jour. Mes pensées vont également vers mes sœurs et mes frères, à ma petite
famille mes deux filles sans oublier mon mari. Enfin, je n'omettrais pas de remercier vivement
les membres de l'équipe du Laboratoire d'Informatique LIRE de Constantine, et en particulier
les membres de l'équipe SIBC, doctorants, magisters et LMD avec lesquels j'ai pu échanger
des idées, discuter, et enfin partager et vivre des moments agréables parmi eux.
2
Titre : Gestion de la Qualité de Service dans les Applications Multimédia basée sur les
préférences de l’utilisateur et orientée vers la Programmation Orientée Aspect
Résumé
Actuellement, les documents multimédia doivent pouvoir être exécutés sur de nombreuses
plates-formes (téléphones portables, PDA, ordinateurs de bureau, etc.). Cette diversification
des préférences des utilisations et des supports nécessite l’adaptation des documents à leur
contexte d’exécution, parfois imprévisible au moment de la conception du document.
L’adaptation des documents multimédia est nécessaire, car ils peuvent être consultés à tout
moment et n'importe où avec une grande variété de dispositifs. L'adaptation d’un contenu
multimédia en fonction des préférences des utilisateurs est un aspect important de la qualité
de service (QoS). Nous proposons une architecture d’adaptation des documents multimédia
basés sur les préférences de l'utilisateur pour la gestion de qualité de service. Nous présentons
également des définitions formelles des concepts liés à la technique d’adaptation définissant
une politique d’adaptation pertinente pour réaliser un document adapté dans la situation où
des conflits sont détectés entre l'hétérogénéité des propriétés du document multimédia et les
besoins des utilisateurs. Aussi, nous considérons l’adaptation comme étant une propriété non-
fonctionnelle assurée par des aspects. Pour cela, nous présentons une transformation des
conflits de la propriété des médias dans les aspects. Nous développons un algorithme
d'adaptation permettant non seulement détecter et résoudre le problème de l’incompatibilité
entre les propriétés du document multimédia, mais aussi de gérer cette adaptation en fonction
des préférences de l'utilisateur. Nous illustrons l'approche proposée par une étude de cas.
Mots-clés: Qualité de Service (QoS), Adaptation de documents multimédia, contexte

utilisateur, Préférences de l’utilisateur, Programmation Orientée Aspect.
3
Title: Quality of Service Management in Multimedia Applications based on user’s
preferences and oriented towards Aspect-Oriented Programming
Abstract
Currently, multimedia documents must be able to run on many platforms (mobile phones,
PDAs, desktops, etc.). This diversification of the uses preferences and the devices necessitates
the adaptation of the documents to their context of execution, sometimes unpredictable at the
time of the conception of the document. The multimedia documents adaptation is necessary
because they can be viewed at anytime and anywhere with a wide variety of devices.
Adapting multimedia content according to user preferences is an important aspect of quality
of service (QoS). We propose an architecture for adapting multimedia documents based on
the user preferences for quality of service management. We also present formal definitions of
concepts related to the adaptation technique defining a relevant adaptation policy to produce a
suitable document in the situation where conflicts are detected between the heterogeneity of
the properties of the multimedia document and the needs of the users. Also, we consider
adaptation as a non-functional property assured by aspects. To this end, we present a
transformation of the conflicts of media proprieties in aspects. We develop an adaptation
algorithm allowing not only detect and resolve the problem of the incompatibility between the
properties of the multimedia document, but also to manage this adaptation according to the
user preferences. We illustrate the approach proposed by a case study.
Keywords: Quality of Service (QoS), Multimedia Documents Adaptation, User Context, User
Preferences, Aspect Oriented Programming.
4
‫العنوان ‪꞉‬إدارة جودة الخدمة في تطبيقات الوسائط المتعددة القائمة على تفضيل المستخدم و الموجهة نحو البرمجة جانبية‬
‫المنحى‬
‫ملخص‬
‫حاليا‪ ،‬الوثائق وسائط متعددة يجب أن تكون قادرة على تشغيل على العديد من المنصات (الهواتف النقالة‪ ،‬أجهزة المساعد‬
‫الرقمي الشخصي والحاسوب‪ ،‬وما إلى ذلك)‪ .‬هذا التنوع في تفضيالت المستخدم وأجهزة اإلعالم يتطلب تكييف الوثائق‬
‫لسياقها التنفيذي‪ ،‬وأحيانا ال يمكن التنبؤ بها في ذلك الوقت من تصميم الوثيقة‪ .‬تكييف وثائق الوسائط المتعددة ضروري ألنها‬
‫يمكن أن ينظر إليها في أي وقت وفي أي مكان مع مجموعة متنوعة من األجهزة‪ ،‬تكييف محتوى الوسائط المتعددة بناء على‬
‫تفضيالت المستخدم هو جانب هام من جوانب جودة الخدمة‪ .‬نقترح بنية للتكيف مع وثائق الوسائط المتعددة بناء على‬
‫تفضيالت المستخدم إلدارة جودة الخدمة‪ .‬نقدم تعريفات رسمية للمفاهيم المتعلقة بتقنية التكيفية التي تختار سياسات التكيف‬
‫ذات الصلة لتحقيق وثيقة مناسبة في الحالة التي يكون فيها تم الكشف عن الصراعات بين عدم تجانس خصائص المستند‬
‫نضمنها بواسطة الجوانب‪ ،‬لذلك الوسائط المتعددة واحتياجات المستخدمين‪ .‬نقترح أن نرى التكيف كخاصية غير وظيفية‬
‫نقدم التحول من النزاعات بين خصائص وسائل اإلعالم الى جوانب‪ .‬نحن وضعنا خوارزمية التكيف يمكنها اكتشاف وإيجاد‬
‫حل لمشكلة عدم التوافق بين خصائص المستند وسائط متعددة‪ ،‬ولكن أيضا إلدارة هذا التكيف بناء على تفضيالت المستخدم‪.‬‬
‫نقوم بتوضيح النهج الذي اقترحناه بدراسة حالة‬
‫كلمات البحث‪:‬‬
‫التكيف الوثائق الوسائط المتعددة‪ ،‬سياق المستخدم‪ ،‬البرمجة جانبية المنحى ‪ ،‬جودة الخدمة‪.‬‬
‫‪5‬‬
Table des matières
Gestion de la qualité de service dans les applications multimédia basée sur

les préférences de l’utilisateur et orientée vers la programmation orientée
aspect
Introduction générale
1 Contexte …………………..……………………………………….………………… 01
2 Problématique………………………………………………………………………… 02
3 Motivations et objectifs……………………………………………………………….. 03
4 Plan de la thèse………………………………………………………………………... 05
Chapitre 1 : Caractéristiques des architectures de fourniture et d’adaptation de contenus

Multimédia
1 Introduction……………………………………………………………………………... 07
2 Applications multimédia distribuées……………………………………………………. 08
2.1 Classification des applications multimédia…………………………………………. 08
2.1.1 Télésurveillance .................................................................................................... 09
2.1.2 Vidéoconférence ..................................................................................………..… 09
2.1.3 Vidéo à la demande ............................................................................................... 09
2.2 Types des medias dans les applications distribuées .................................................... 10
2.2.1 Médias continus…………………...……………………………………...….….. 10
2.2.2 Médias discrets....................................................................................................... 10
2.3 Quelques outils de description de contenus multimédia ............................................. 11
2.3.1 MPEG-7………………………………………………………………………… 11
2.3.2 SMIL .........……………………………………………………………………… 13
2.4 Discussion ………………………………………………………………………… 13
3 Qualité de Service et Contexte ………………………..………………………………... 14
3.1 Notion de contexte ……………………………………..………………………..….. 14
3.1.1 Contexte d'utilisateur …………………………………………………………… 15
3.1.2 Contexte d'utilisation ……………………………………………………………. 15
3.1.3 Contexte d'exécution ……………………………………………………………. 16
3.2 Quelques outils de description de contexte.................................................................. 16
3.2.1 CC/PP..................................................................................................................... 16
3.2.2 MPEG-21……………………………………………………………………….. 18
3.3 Définition de la qualité de service ............................................................................... 18
3.3.1 Point de vue de l’utilisateur.................................................................................... 19
3.3.2 Point de vue de l’environnement d’exécution ...................................................... 20
3.4 Gestion des contraintes de qualité de service ............................................................ 20
3.4.1 Réservation de ressources...................................................................................... 21
3.4.2 Adaptation de document multimédia................................................................... 21
6
Table des matières
3.5 Discussion …………………………………………………………………………. 22

4. Techniques d’adaptation de document multimédia …………………………………… 22
4.1 Contraintes d'adaptation …………………………………………………………… 22
4.2. Types d’adaptation ……………………………………..…..……………………... 23
4.2.1 Adaptation locale………………………………………………………………. 23
a) Transcodage……………………………………….………………........................ 23
b) Transmodage………………………………………………………..……………. 24
c) Transformation……………………………………………………….…...….…… 24
4.2.2 Adaptation globale ……………………………………………………………… 24
5. Familles d’approches d’adaptation ……………………………………………………. 25
5.1 Approches basés sur la spécification d'alternatives…………....………………….. 25
5.1.1 Approches basées sur des profils cibles……...…………………….…………… 25
5.1.2 Approches basées sur le contenu ………………………………………….…... 25
5.1.3 Approches mixtes ……………………………………………………….…….. 26
5.2 Approches basés sur la spécification de règles d'adaptation ……………………….. 26
5.3 Approches basés sur la spécification de modelés de document flexibles………….. 27
5.4 Approche sémantique et dynamique ……………………………………………….. 27
6. Adaptation des contenus multimédia et les modèles architecturaux…………………... 28
6.1 Modèle architectural client / serveur et adaptation………………………………… 28
6.1.1 Système d’adaptation au niveau du client……………………………………... 28
6.1.2 Système d’adaptation au niveau du serveur………………………………… 29
6.2 Modèle architectural client / intermédiaire (s) / serveur et adaptation ……………… 29
6.3 Modèle architectural pair-à-pair et adaptation …………………………………….. 30
7. Techniques de consommation et d’adaptation de contenus multimédia ........................ 30
8. Synthèse………………………………………………………………………………... 31
9. Conclusion……………………………………………………………………………… 32
Chapitre 2 Etude de quelques architectures d’adaptation de contenu multimédia pour gérer la QoS et
apport de la POA
1. Introduction…………………………………………………………………………… 33
2. Architecture NAC ........................................................................................................... 34
2.1 Principes………………………………………………………………….…………. 34
2.2 Adaptation de DM pour la gestion de QoS………………………………….……… 35
2.3 Gestion du contexte…………………………………………………………………. 35
3. Architecture PAAM ........................................................................................................ 36
3.1 Principes……………………………………………………………………………. 37
3.2 Adaptation de DM pour la gestion de QoS ……………………………….…..…… 37
3.3 Gestion du contexte……………………………………………………..…………. 38
4. Architecture DCAF ......................................................................................................... 38
4.1 Principes…………………………………………………………………...……….. 38
4.2 Adaptation de DM pour la gestion de QoS……………………………………….. 39
4.3 Gestion du contexte………………………………………………………………. 39
5. Architecture APPAT ....................................................................................................... 39
7
Table des matières
5.1 Principes……………………………………………………………………………. 40
5.2 Adaptation de DM pour la gestion de QoS………………………….……...……… 41
5.3 Gestion du contexte………………………………………………………………… 41
6. Autre travaux liés à l’adaptation de DM……………………...…………………….…. 42
7. Synthèse…………………………………………………………………………...…… 47
8. Programmation orienté aspect………………………….……………………….…........ 48
8.1 Problèmes résolus par la POA……………………….……………………....……. 49
8.1.1 Fonctionnalités transversales…………………………………………..…….... 49
8.1.2 Dispersion du code……………………………………………………………. 50
8.2 Concepts de base de la programmation orientée aspect…………………………. 50
8.2.1 Aspect……………………………………………………………...………… 50
8.2.2 Point de jonction…………………………………...…………………………. 51
8.2.3 Coupes……………………………………………………………..………… 51
8.2.4 Codes advice………………..………………………………..…..………… 51
8.2.5 Tissage d’aspects ………………………………………………………..….. 52
8.2.6 Mécanisme d’introduction ……………………………...…………..….…… 52
8.3 Aperçus sur le langage AspectJ…………………………………………….………. 52
8.4 Apport de la POA à la gestion de document multimédia…………………………... 53
9. Conclusion……………………………………………………………………………… 53
Chapitre 3 Un modèle formel d’adaptation de document multimédia pour gérer la qualité de service
1. Introduction ……………………………………………………………………………. 55
2. Motivation……………………………………………………………………….....…... 56
3. Fondements de notre approche………………………………………………….……… 57
4. Concepts formels d’adaptation de documents multimédia............................................. 57
4. 1 Document multimédia (MD)………………………………….………………..….. 58
4. 2 Préférences de l'utilisateur (UP)……………………………….……………….….. 58
4. 3 Propriétés des médias (MP)…………………………………………………….…. 59
4. 4 Contexte de l'utilisateur (UC)…………………………………………………..….. 60
4. 5 Conflit de la propriété des médias (MPC)…………………………………..…….. 60
4. 6 Service d’adaptation (AS)…………………………………………………....……. 61
4. 7 Conflit de service d’Adaptation (ASC)……………………………………..…… 62
4. 8 Services de dépendance (SD)……………………………………………..……… 62
4. 9 Chemin d'adaptation (AP)……………………………………………….………… 64
5. Propriétés de graphe d’adaptation................................................................................... 64
5.1 Rôles .......................................................................................................................... 65
5.2 Nœuds ..................................................................................................................... 65
5.3 Arcs .......................................................................................................................... 66
6. Construction du graphe d’adaptation………………………………………………..… 66
7. Recherche des Conflits………………………………………………….…………..… 66
8. Processus d’adaptation de document multimédia……………………………………… 67
9. Algorithmes d’adaptation de document multimédia…………………………………… 68
8
Table des matières
10. Exemple d’application de notre approche………………………………...…………... 69

11. Conclusion……………..……………………………………………………………… 72
Chapitre 4 Une Architecture d’adaptation des documents multimédias pour la gestion de qualité de
service basée sur les préférences de l’utilisateur
1. Introduction ………………………………………………………………………..…... 73
2. Motivation…………………………………………………………………………..….. 74
3. Aperçu de l’approche proposée …………………………………………………...…… 75
4. Architecture global du système………………..……………………………………….. 78
5. Description des différents composants de notre architecture………………..…………. 79
5.1 Interface utilisateur (UI)…………………………………………….……………… 80
5.2 Gestionnaire de Document Multimédia (MDM)……………………………….…... 80
5.3 Gestionnaire de Qualité de Service (QoSM)……………………………..…….…... 81
5.4 Gestionnaire d'Adaptation (AM)……………………………………………….…... 81
5.5 Superviseur de Contexte de l'utilisateur (UCS)………………………….…….…... 81
6. Technique d’adaptation de DM………………… ……………………………….…….. 83
7. Adaptation des documents multimédia basée sur la Programmation Orientée Aspect
(POA)……………………………………………………………………………………… 85
8. Conclusion ……………………………………………………………………………... 88
Chapitre 5 Etude de cas et quelques aspects d’implémentations
1. Introduction ................................................................................................................. 89
2. Outils technologiques utilisés ……………………………………………………...... 90
2.1 Langage de programmation……………………………………………………… 90
2.2 Environnement de développement…………………………………………..…… 91
2.3 Affichage graphique…………………………………………………………....... 91
3. Présentation de l’étude de cas………………………………………………….…… 91
3.1 Enoncé ………………………………………………………………………… 92
3.2 Présentation d’un Prototype …………………………………………………… 92
4. Implémentation …………………………………………………............................... 94
5. Application de l’architecture proposée.......................................................................... 99
6. Discussion…………………………………………………………………………… 102
7. Conclusion…………………………………………………………………………… 102
Conclusion et Perspectives...........................................................................…………. 104

Bibliographie.......................................................................……………………………. 106
9
Liste des Figures
Liste des Figures

Figure.1.1 Fragment de description de vidéo en MPEG-7 [54] …………………………………..12
Figure.1.2 Exemple de profil CC/PP[1] ,[69]…………………………………………….………..17
Figure. 1.3 Adaptation en catégories……………………………………………………………….23
Figure. 1.4 Un DM adapté à l'aide d'une base de règles de transformation [1].…………...............27
Figure.2.1 Organisation générale de l’architecture NAC………………………………..………...34
Figure. 2.2 Architecture fonctionnelle de PAAM [10]………………………………….…………37
Figure. 2.3 Architecture DCAF [3]……………………………………………………...………...38
Figure. 2.4 Architecture de la plateforme APPAT [32]………………………………....………...40
Figure. 2.5 Dispersion du code d’une fonctionnalité……………………………………………...49
Figure 3 .1 Graphe d’adaptation des scenarios…………………………………………..………...63
Figure 3 .2 Algorithme général d'adaptation du MMD aux préférences de l'utilisateur.………….68
Figure 3.3 Graphe d’adaptation des scenarios de l’exemple……………………………..………..71
Figure. 4.1: Modèle de description d’un contexte………………………………………..……….76
Figure. 4.2: Exemple de description du contexte avec CC/PP…………………………...……….77
Figure 4.3 Une architecture d’adaptation de documents multimédia basés sur les préférences de
l'utilisateur ( AAMDUP)…………………………………………………………………………...79
Figure 4 .5 Description de contexte de l‘utilisateur…………………………………..…………...82
Figure 4 .6 Processus d’adaptation de document multimédia……………………………………...84
Figure 4.7 Diagramme de séquence pour un scenario typique……………………...….………......85
Figure 4.8 Aspect d’élimination de media non prioritaire……………………………..…………..86
Figure 4.9 Aspect de détection de conflit………………………………………………..………….87
Figure 4.10 Aspect de résolution de conflit………………………………...……………………….87
Figure. 5.1 : Document source présentant la ville de Constantine………………….….…………..92
Figure. 5.2 Place du système AAMDUP.………………………….……………...……………….93
Figure.5.3 Interface d’accueil de l’utilisateur……………………………………….………….......94
Figure 5.4 Extrait de code de la méthode run() de construction de UP…………………………….95
Figure 5.5 Extrait de code d’aspect de construction de MPC ……………………..……………….96
Figure 5.6 Extrait de code de méthode de capture de la taille mémoire………………..…………..97
Figure 5.7 Extrait de code de méthode de capture et d’affichage de contexte
d’utilisateur……………………………………………………………………………....………….97
Figure 5.8 Extrait de code méthode recherche DM par GDM………………….…..……………..98
Figure.5.9 Choix de document multimédia………………………………………..……................99
Figure. 5.10 Choix de préférences de l’utilisateur…………………………….……..…..............100
Figure. 5.11 Document adapté au contexte de l’utilisateur………………………………………101
10
Liste des tableaux
Liste des Tableaux
Tableau 1.1 : Exemple du transcodage…………………………………………..……………………..24
Tableau 2.1 Étude comparative entre les architectures d’adaptations existantes…………………….....44
Tableau 3.1 Exemple de service d'adaptation (ADP), Paramètres d'entrée et Paramètres de sortie……62
Tableau 3.2 Comparaison de l'adaptation en utilisant notre technique et la technique de
(Shahidi M. et al, 2010) [81]……………………………………………………………………….…...64
Tableau 3.3 Exemple de service d'adaptation (ADP)……………………….……………………….…70
Tableau 3.4 Comparaison d'adaptation de document multimédia………………………….…………..71
11
1. Contexte
L'hétérogénéité des moyens et des appareils d'accès s'est accompagnée d’une évolution
importante du côté du contenu de l'information disponible sur le réseau. Aujourd'hui, nous
trouvons une multitude de formats complexes avec de nouvelles fonctionnalités, telles que la
vidéo interactive, les animations 3D et le dessin vectoriel. Ces formats s'appuient sur de
nouveaux modèles qui intègrent le monde multimédia (la structure logique, l'espace, le temps
et la navigation). La notion de présentation multimédia est devenue de plus en plus répandue
et utilisée dans différents domaines tels que l’enseignement à distance (e-learning), l’imagerie
médicale, les jeux vidéo ou encore l’art numérique. Cependant, quel que soit le format d’un
Document Multimédia (DM), il est nécessaire de gérer une grande quantité de ressources pour
assurer la transmission des données liées les réseaux et respecter ses contraintes temporelles,
qui se répartissent en trois catégories : les contraintes de bout en bout, les contraintes de
synchronisation et la gigue. Cela a conduit à des modèles dans lesquels sont empilées
différentes couches de gestion de la Qualité de Service1 (QoS). Chaque couche s’appuie sur
celles des niveaux inférieurs pour restituer son service.
L’évolution des contenus ainsi que celle des appareils et des moyens d'accès ont fait
apparaitre des environnements hétérogènes ou des utilisateurs ayant des facultés différentes et
souhaitant d'accéder au même contenu à travers différents réseaux de communication. D'autre
part, le contenu peut être trop complexe pour qu'un terminal ayant des capacités limitées
puisse le traiter et le présenter correctement. Face à cette réalité, il est nécessaire de trouver
des outils qui permettent l'accès et l'utilisation de l'information sous une forme correspondant
aux contraintes imposées par l'environnement ou aussi par l’utilisateur.
L'adaptation de contenus multimédias constitue certainement l'un des outils principaux dans la
mise en œuvre effective des systèmes d'information pervasifs. La très grande hétérogénéité
des moyens de connexion et des conditions de communication (bande passante notamment),
la très grande variabilité des préférences des utilisateurs et la diversité des médias (texte,
image, son, vidéo) imposent en effet de fournir des outils adéquats d'adaptation des contenus
aux contextes utilisateurs. On entend par contexte utilisateur les caractéristiques personnelles
1
Plus connues sous le nom en anglais QoS pour Quality of Service.
1
de l’utilisateur (telles que sa langue, son handicap et ses centres d’intérêt), ses préférences de
présentation des contenus multimédia (son lecteur multimédia préféré ou la taille d’image
souhaitée), les capacités de son terminal (la taille de l’écran du terminal ou les lecteurs
multimédia présents) et les propriétés de son réseau d’accès (la bande passante). Compte tenu
de la combinaison des éléments de contexte, il n’est pas envisageable de fournir autant de
versions de DMs que de contextes possibles : l’adaptation des contenus devient nécessaire
[10].
Le travail présenté dans cette thèse a pour objectif de contribuer à l’adaptation de DMs en
considérant les préférences de l’utilisateur et en faisant appel aux technologies ‘Aspect’.
2. Problématique
Aujourd'hui, une grande diversité de plates-formes (ou terminaux) permettent l’accès à
l'information n'importe où et n'importe quand : les ordinateurs portables, les assistants
personnels (PDA), les téléphones mobiles, les lecteurs de salon, les adjoints de poste de
télévision (set-top boxes) et autres. Chacune de ces plates-formes dispose de capacités très
variées, en particulier, les tailles d'écran, les possibilités d'interaction et les capacités de
présentation de l'information (par exemple, résolution et couleur de l'écran) différente de
manière importante d'un terminal à l'autre. Compte tenu de cette hétérogénéité, les DMs ne
peuvent pas être exploités de la même manière pour tous les terminaux. Ces documents
doivent satisfaire un ensemble de contraintes de présentation spécifiées notamment dans des
profils. Ces profils caractérisent les capacités matérielles et logicielles du terminal utilisé ainsi
que les préférences de l'utilisateur. Pour satisfaire ces profils, une solution possible [1],
consiste à concevoir et diffuser les variantes adaptées d'un document pour chaque terminal.
Par exemple, à partir d'un document initial on pourrait concevoir des versions dédiées aux
téléphones portables, et aux assistants personnels. Ce traitement devrait être effectué
également pour chaque type de plate-forme considérée et chaque type de profil. Au vu du
nombre d'alternatives à engendrer, leur accroissement constant, la diversité et de l'évolution
des profils, cette solution est coûteuse et très fastidieuse.
Dans le cas où un DM ne satisfait pas un profil particulier, une autre solution [1], consiste à
adapter automatiquement ce document, c'est-à-dire lui faire subir un ensemble de
transformations lui permettant de s'exécuter correctement le compte tenu d'un profil donné.
Pour garantir une qualité d'adaptation, un ensemble de propriétés sur l'application des
transformations doivent être définies, comme par exemple sélectionner des transformations
2
efficaces en termes de temps d'exécution, ou être le plus proche possible de l'intention de

l'auteur du document initial ou bien, de la structuration du document initial.
L'adaptation de DMs doit enfin être en mesure d'adapter des langages standards de description
de documents, notamment ceux définis par le W3C (World Wide Web Consortium) comme
les DMs SMIL [3], car ce sont des formats très utilisés et directement exécutables sur de
multiples plates-formes.
Le problème est comment répondre aux préférences des utilisateurs et aux changements de
l'environnement par des adaptations des DMs pour principal critère de QoS de l'application.
Nous nous attachons particulièrement à la gestion de la QoS des DMs face aux contraintes
matérielles de leur support, aux exigences de l'utilisateur et aux circonstances courantes
d'utilisation. En effet, bien que les caractéristiques proposées par ces périphériques tendent à
améliorer la qualité du service rendue à l'utilisateur, chaque utilisateur possède ses propres
préférences, se connecte grâce à un terminal ayant certaines capacités et utilise son propre
réseau d’accès. Ces usagers souhaitent s’échanger des DMs qui peuvent contenir de la vidéo,
de l’audio, de l’image et du texte ou un mélange de ces médias élémentaires.
Dans de très nombreux cas, ces utilisateurs ne disposent donc pas d’une plateforme identique
à celle ayant servi à la réalisation du DM initial. De plus, à de nombreuses plates-formes
disposent de capacités limitées ou élargies comme la taille d’écran ou les moyens
d’interaction possibles, voire de préférences utilisateurs comme la langue naturelle.
Nous proposons de voir l’adaptation comme une propriété non-fonctionnelle basée sur les
préférences de l’utilisateur et assurée par des aspects. Donc, nous présentons une
transformation des conflits de la propriété des médias dans les aspects qui seront injectés à
chaque besoin d’adaptation.
3. Motivations et objectifs
L’échange de DMs composés de plusieurs médias élémentaires tels que des vidéos, des
images ou du texte, est l’une des applications les plus populaires d’Internet. Idéalement, tout
usager d’Internet devrait pouvoir accéder à ces contenus et les recevoir dans un format adapté
au contexte dans lequel il travaille.
Les solutions proposées actuellement n’attaquent pas le problème de l’adaptation de la
composition des DMs de manière complète, mais essaient de fournir des solutions, souvent
manuelles ou explicites, liées à des ensembles de contraintes d’adaptation très spécifiques.
3
Ces solutions sont aussi très souvent basées sur des langages de description de DMs rendant
l’adaptation plus ou moins flexible.
Par conséquent, il apparaît important de rendre l’adaptation plus indépendante face à tous ces
langages de description de DMs et plus flexible pour ainsi couvrir de nombreuses contraintes
d’adaptation.
Des résultats pratiques portent sur la prise en compte des contraintes de composition via un
langage standard de description de profils nommé CC/PP (Composite Capability / Preference
Profiles) [68].
Dans cette thèse, nous avons choisi d'aborder l'adaptation des DMs dans les applications
multimédia comme un outil de gestion de la QoS. Nous proposons une architecture
d’adaptation des DMs basés sur les préférences de l'utilisateur. Nous commençons par une
présentation des définitions formelles des concepts liés à la technique d’adaptation. Nous
proposons de voir l’adaptation comme une propriété non-fonctionnelle assurée par des
aspects, donc nous basons sur les technologies ‘Aspect’ pour transformer des conflits de la
propriété des médias dans les aspects. Nous développons un algorithme d'adaptation pouvant
non seulement de détecter et résoudre le problème de l’incompatibilité entre les propriétés du
DM, mais aussi de gérer cette adaptation en fonction des préférences de l'utilisateur. Nous
proposons des méthodes portant exclusivement sur l’adaptation des DMs. Ces méthodes
permettent au développeur de réduire le temps, l’effort, ainsi que le coût dans la gestion de la
QoS des applications multimédias.
Il existe plusieurs solutions architecturales qui adaptent des contenus multimédia au contexte
d’un utilisateur. Citons, par exemple, les plates-formes ADMITS [93], APPAT [32], ISIS
[95],UMA [96] et NAC [97], DCAF [79], M21 [99] et SATO [100]. L’analyse de ces
architectures (que nous présentons dans le chapitre 2) montre qu’elles ne répondent pas à tous
les besoins des utilisateurs.
L'objectif principal de ce travail de recherche est donc d'améliorer l'adaptation de DMs en
tenant compte des préférences de l'utilisateur, car l'adaptation du contenu multimédia via les
préférences des utilisateurs est un aspect important de la QoS. En d'autres termes, notre
architecture proposée vise à adapter le DM à l'aide d'une interface de préférence de
l'utilisateur.
Généralement, les architectures d’adaptations existantes gèrent des DMs qui sont envoyés à
partir d'une machine serveur à un dispositif client. Cependant, notre architecture proposée
permet d'accélérer le processus de négociation du contenu et d'éviter l'échange de messages
inutiles entre le client et le serveur et réduire le temps d'attente du client. Dans ce contexte,
4
notre objectif est double. En premier lieu, une partie formelle qui montre comment à partir
d’un DM ainsi que d’un profil cible, il est possible d’extraire automatiquement des besoins en
termes d’adaptation nommés des conflits. Il convient alors de définir un mécanisme de
comparaison des préférences de l’utilisateur/document et de spécifier un modèle de
description de besoins d’adaptation par une présentation formelle. En deuxième lieu, une
partie consiste à montrer qu’à partir des besoins d’adaptation il est possible de trouver
efficacement des politiques d’adaptation mais également de les déployer pour transformer le
document. La réalisation de ces adaptations nécessite une architecture logicielle également
adaptable. L’approche proposée a été validée par une étude de cas relative à la gestion des
DMs à la demande.
4. Plan de la thèse
Ce document est organisé en cinq chapitres. Le premier chapitre constitue l’état de l’art sur
les caractéristiques des architectures de fourniture et d’adaptation de contenus multimédia.
L’une des premières tâches qui nous incombe, dans ce chapitre, est de fixer le cadre de notre
travail de recherche en définissant de manière précise les applications multimédias
distribuées, l’adaptation et la QoS. Nous présentons aussi quelques concepts de la notion de
modèle architectural et les outils de description de contenus multimédia et de contexte pour
les expliquer dans l’adaptation des applications.
Le deuxième chapitre porte sur une étude de quelques architectures d’adaptation de contenu
multimédia pour gérer la QoS et la programmation orienté aspect2 (POA) [62]. Il présente un
état de l’art sur les différentes architectures de fourniture de contenus multimédia adaptables
au contexte d’un utilisateur, ainsi que les avantages et les inconvénients de chaque
architecture. Cette analyse de quelques travaux sera suivie d’une étude comparative entre ces
architectures.
Dans le troisième chapitre nous proposons un modèle formel d’adaptation de DM pour gérer
la QoS. L’objectif est de présenter formellement les concepts d’adaptation
de D M qui est une étape très important dans le processus d’adaptation. A
travers cette présentation, nous essayons d'améliorer l'adaptation de DMs en tenant
compte des préférences de l'utilisateur. Nous développons aussi un algorithme d'adaptation
pouvant non seulement de détecter et résoudre le problème de l’incompatibilité entre les
2
Plus connues sous le nom en anglais AOP pour Aspect-Oriented-Programming
5
propriétés du DM, mais aussi de gérer cette adaptation en fonction des préférences de
l'utilisateur en se basant sur les concepts formels définis.
Le quatrième chapitre est consacré à notre deuxième contribution qui consiste en la
proposition d’une architecture d’adaptation des DMs pour la gestion de la QoS. Il fournit les
deux parties de notre contribution. La première partie est consacrée à la présentation des
principales fonctionnalités de différents composants de cette architecture. La deuxième partie
concerne la transformation des concepts d’adaptation dans des aspects basée sur la POA.
Le cinquième chapitre présente une étude de cas sur lequel nous appliquons les différentes
étapes du processus d'adaptation de notre Architecture d’Adaptation des Documents
Multimédias basée sur les Préférences de l’Utilisateur baptisée AAMDUP.
Enfin, nous terminerons notre thèse par un bilan du travail de recherche effectué durant la
préparation de cette thèse en donnant quelques perspectives envisagées pour la poursuite de ce
travail de recherche.
6
Caractéristiques des architectures de
Chapitre fourniture et d’adaptation de contenus
01 multimédia
1. Introduction
Ces dernières années, les progrès technologiques récents ont permis l'apparition d'une grande
variété de nouveaux moyens permettant à un utilisateur d'accéder et d'utiliser l'information
multimédia qui l'intéresse en tout lieu et à tout moment. L'accès au contenu ne l’effectue de la
même manière qu'il y a quelques années.
En effet, les appareils d'accès à l'information ont subi une véritable révolution. Les utilisateurs
peuvent accéder au contenu à travers des appareils très divers : ordinateurs portables,
assistants personnels, téléviseurs, téléphones cellulaires, etc. Le nombre d’utilisateurs de ces
nouveaux appareils continue sa croissance exponentielle. Les moyens d'accès au contenu ont
également évolué, avec de nouveaux réseaux tels que les réseaux sans fil WiFi, GPRS, etc.
Ces réseaux se sont développés et se sont intégrés Internet. L'utilisation du World Wide Web
ne ressemble donc plus à ce qu'elle était à l'origine, où l'utilisateur accédait à l'information
depuis son ordinateur personnel et à travers le réseau filaire [22].
L'hétérogénéité des moyens et des appareils d'accès s'est accompagné d’une évolution
importante du côté du contenu de l'information disponible sur le réseau. Aujourd'hui, nous
trouvons une multitude de formats complexes avec de nouvelles fonctionnalités, telles que la
vidéo interactive, les animations 3D et le dessin vectoriel. Cependant, ces formats s'appuient
sur de nouveaux modèles qui intègrent le monde multimédia (la structure logique, l'espace, le
temps et la navigation). Nous nous intéressons plus particulièrement aux DMs, c'est-à-dire des
documents structurés qui contiennent plusieurs médias [22].
En effet, ces DMs occupent actuellement une part considérable sur le web. Cependant, ils sont
le plus souvent réalisés sous des plate-formes différentes de celles destinées à leur
7
Chapitre 1 Caractéristiques des architectures de fourniture et d’adaptation de contenus
multimédia
présentation (téléphones portables, PDA, ordinateurs de bureau, ordinateurs portables, etc…).

De plus, les préférences et le contexte de l’utilisateur (la langue, le type de synchronisation
des médias souhaité, la capacité de la bande passante, la taille de l’écran, etc…) sont
généralement différents de ceux ayant servi pour leur réalisation. Compte tenu de cette réalité,
l'adaptation des DMs est devenue une nécessité. Elle consiste à essayer de satisfaire ces
contraintes par des transformations sur le document initial. L'enjeu est de proposer des
solutions afin de pouvoir exécuter et diffuser un document de qualité dans une présentation
cohérente et qui restitue le plus fidèlement possible le message contenu dans le document
initial. L’adaptation de contenu multimédia a besoin de mécanismes efficaces pour atténuer le
problème d’hétérogénéité des composants logiciels, des dispositifs matériels, des réseaux et
des contraintes des environnements informatiques. En outre, l’adaptation permet de fournir
des données conformes aux préférences de l'utilisateur et au contexte de son environnement.
L’une des premières tâches, dans ce premier chapitre, est de fixer le cadre de notre travail de
recherche en définissant de manière précise les applications multimédias distribuées,
l’adaptation et la QoS. Aussi, nous présentons aussi quelques notions de modèle architectural
et les outils de description de contenus multimédia et de contexte pour les utiliser dans
l’adaptation des données multimédia.
2. Applications multimédias distribuées

Généralement une application multimédia manipule de manière simultanée et interactive
plusieurs modes de représentation de l’information appelés médias. Néanmoins, cette
tentative de définition reste trop générale, qu’il est donc nécessaire de la préciser [5]. Une
application est dite multimédia si elle possède la propriété de traiter différents types de média
où le média est le type de donnée qui définit la nature de l’information comme décrite dans
son format de codage [37].
Ces applications peuvent être classées selon leur fonctionnalisées ce qui permet d’en
distinguer trois types présentés dans la suivante.
2.1 Classification des applications multimédia

Les applications multimédia présentent cependant des caractéristiques différentes en ce qui
concerne le type de QoS qu’elles se doivent d’offrir.
8
multimédia
2.1.1 Télésurveillance
Les applications de télésurveillance permettent la mise en place de surveillance à distance par
l’intermédiaire d’un réseau de communication. L’objectif est de détecter des événements ou
phénomènes physiques à l’aide de capteurs. Ainsi, une telle application doit pouvoir réagir en
informant les différents utilisateurs (stations de surveillance) par transmission d’alarmes ou
d’informations audiovisuelles et ce dans des délais acceptables. Ces applications multimédia
distribuées sont souvent équipées de caméras. On parle alors de vidéo surveillance. Elles sont
très utilisées dans les domaines de la domotique et de la télémédecine [5].
Ces applications multimédia distribuées se caractérisent par le fait qu’elles doivent offrir des
informations fiables en temps réel sans toutefois nécessiter des images d’excellente qualité.
En revanche, elles sont soumises à l’utilisation de supports de transmission de faible débit et à
des conditions environnementales non maîtrisables (éclairage, etc…) [5].
2.1.2 Vidéoconférence
Les applications de vidéoconférence appartiennent au groupe qui concerne les applications
conversationnelles permettant la communication en temps réel [37]. Elles permettent aussi la
réunion de plusieurs personnes physiquement situées en des lieux différents par transmission
en temps réel de la parole et de l’image de chaque site. Ces médias peuvent être accompagnés
d’autres supports comme par exemple des transparents dans le cadre d’une conférence à
distance [5].
De plus, l’emploi de médias comme l’audio et la vidéo nécessite la mise en œuvre de
mécanismes particuliers afin d’assurer leur restitution de façon synchrone. Ces systèmes
couvrent un nombre important de champs d’application : réunions de travail, cours à distance,
conférences à distance, etc. Ces applications multimédia distribuées sont caractérisées par des
débits multilatéraux importants. Elles doivent garantir la synchronisation des médias afin
d’offrir un service agréable à utiliser [5].
2.1.3 Vidéo à la demande
Les applications de vidéo à la demande appartiennent au groupe d’applications qui permettent
la consultation d’informations multimédia préalablement stockées dans une base de données
[37]. Elles permettent aussi la diffusion à différents utilisateurs de médias stockés sur une ou
plusieurs machines distantes et dédiées (appelées parfois serveurs de médias). Chaque
utilisateur choisit les médias qu’il désire recevoir et le serveur transmet alors les médias
sélectionnés à l’utilisateur. Cette diffusion peut être contrôlée à distance de la même façon
9
multimédia
que sur un magnétoscope ou un lecteur de DVD (lecture, pause, arrêt, avance rapide, retour
rapide). Le plus souvent, ce sont des techniques de streaming3 qui sont employées pour
donner la possibilité aux utilisateurs de commencer la diffusion des média en même temps
que leur téléchargement. Ces applications multimédia distribuées sont proches de la
télévision, elles nécessitent donc des qualités d’images et de son élevées. Elles sont de plus en
plus répandues du fait qu’elles suscitent un large intérêt économique. Les grands groupes de
télédiffusion fournissent des systèmes de vidéo à la demande en échange d’une participation
pécuniaire de la part des utilisateurs [5].
2.2 Types des médias dans les applications multimédia distribuées

Un médium est une entité qui fait référence à une ressource pouvant être, par exemple, de
l'audio, du texte, une image ou bien une vidéo. Il est différencié selon la nature des
informations qu’il supporte et selon leur constitution.
Habituellement, on distingue les médias continus et des médias discrets dont nous allons
décrire les principales caractéristiques [5].
2.2.1 Médias continus

Les médias continus se composent d’une séquence d’échantillons continue et a priori infinie.
Chaque échantillon décrit une partie de l’information véhiculée par le média dans un format
de codage adéquat. Ils sont produits par échantillonnage périodique de données captées par
des périphériques d’acquisition tels que les caméras ou les microphones. Ces médias affichent
des caractéristiques de périodicité et de continuité qui impliquent qu’ils existent sous la forme
de flux de données appelés également flux continus [4], [5].
2.2.2 Médias discrets

Un média discret est constitué d’un ensemble de données indivisibles. La totalité des données,
représentées dans un format de codage adéquat, est nécessaire pour restituer l’information
véhiculée par un média discret. Ces données sont ponctuelles, c’est à dire qu’elles existent à
un moment précis et non de façon continue dans le temps comme pour les médias continus
[4], [5].
Dans ce type de media, le facteur temps n’est pas important comme pour les médias continus.
Ces médias ne présentent pas de dépendance temporelle forte. Lors de rétablissement des
3
Streaming : Technique permettant de diffuser des flux de vidéos notamment, en temps
réel et de manière continue.
10
multimédia
données, le seul point important à respecter est de disposer de l’intégralité des données. Ce
type de média est donc sensible aux pertes de données.
2.3 Quelques outils de description de contenus multimédia

Parmi les standards existants relatifs au multimédia et à la description, nous distinguons entre
ceux qui permettent de décrire un contenu multimédia ou mono-média et les modèles ou
langages qui permettent de décrire une scène multimédia. MPEG-7 [38] est un standard
appartenant à la première famille, tandis que Dublin Core [40], SMIL [39], MPEG-21 ou
encore ZyX [41] appartiennent à la seconde. Nous choisissons de décrire MPEG-7 et SMIL
car ils sont les plus utilisés en matière de description d’un média ou d’un DM composé.
2.3.1 MPEG-7 [10]

Le nom formel de MPEG-7 est « interface de description de contenu multimédia » [38,42]. Il
fournit un ensemble d’outils pour décrire un contenu multimédia facilitant la recherche, la
navigation et la consommation de ce contenu.
Ces outils MPEG-7 se traduisent par un ensemble d’éléments [10] :
• Descriptor (D): c’est un descripteur décrit les informations multimédia, les attributs ou
les groupes d’attributs d’un contenu multimédia. Il définit la syntaxe et la sémantique
d’une représentation d’un média (méta-données). Des descripteurs MPEG-7 peuvent
par exemple décrire la couleur, la texture, la forme, le mouvement ou le son d’un
média.
• DescriptorScheme (DS): c’est un schéma de description représentant la structure et la
sémantique des relations entre les descripteurs et les schémas de description. Par
exemple MPEG-7 est un schéma de description d’un segment d’une vidéo qui peut
être décrit avec les descripteurs cités plus haut.
• Description Definition Language (DDL) : Ce langage permet de créer de nouveaux
schémas de description et même des descripteurs. Il permet aussi la modification et
l’extension de schémas de description existants.
• Outils système: ces outils sont des supports pour le multiplexage des descriptions, la
synchronisation des descriptions avec le contenu, les mécanismes de fourniture du
contenu, et les représentations codées (format textuel et binaire) pour un stockage et
une transmission efficaces et pour la gestion et la protection de la propriété
intellectuelle des descriptions MPEG-7.
11
multimédia
Figure.1.1 Fragment de description de vidéo en MPEG-7 [54].
Une description MPEG-7 est donc un schéma de description (structure) et un ensemble de

valeurs de descripteurs (instanciations) décrivant les données (voir Figure 1.1). Plusieurs
outils (descriptions, descripteurs et schémas de description) ont été développés dans le cadre
de MPEG-7 afin de décrire [10] :
▪ Le contenu multimédia
▪ L’information générée par l’auteur qui est relative au processus de création /
production d’un contenu multimédia (comme le titre, le créateur, et le but de la
création).
▪ La structure temporelle et spatiale du contenu multimédia.
▪ La sémantique du contenu multimédia qui peut être utilisée pour décrire les mondes
narratifs représentés dans ou reliés au contenu multimédia en décrivant les objets, les
événements, les concepts, les places et le temps dans ces mondes narratifs.
▪ Les sommaires, résumés, vues du contenu, les partitions, les décompositions
temporelles, spatiales ou fréquentielle d’une image, d’une vidéo, ou d’un signal audio,
et les relations entre les différentes variantes des programmes multimédia. Ces outils
permettent la navigation et l’accès au contenu multimédia.
▪ Les préférences de l’utilisateur ainsi que l’historique d’usage des utilisateurs d’un
contenu, rendant l’utilisateur interactif et permettant la personnalisation de l’accès et
la consommation du contenu.
12
multimédia
2.3.2 SMIL
SMIL [1] (Synchronized Multimedia Integration Language) est un langage standard défini par
le W3C permettant de spécifier des présentations multimédia interactives. Celui-ci est basé
sur le langage XML et permet de décrire l’organisation temporelle d’objets multimédia, de
spécifier leur disposition spatiale et de définir des liens hypermédia [1].
Avec la version 2.1 de SMIL, un auteur peut décrire le comportement temporel d’une
présentation multimédia. La spécification de SMIL permet la réutilisation de sa syntaxe et de
sa sémantique au sein d’autres langages basés sur XML, plus particulièrement ceux qui ont
besoin de représenter des aspects temporels et de synchronisation tels que XHTML [38].
Un document SMIL est structuré de conteneurs temporels4, appelés également éléments
composites ou opérateurs. Un opérateur comprend une sémantique temporelle particulière
permettant de définir le placement temporel des objets média. Ces opérateurs sont les
éléments seq, par et excl. Le conteneur temporel seq (séquence) définit une présentation en
séquence des ressources médias. Le conteneur temporel par (parallèle) permet de jouer les
ressources en parallèle. Finalement, l’opérateur excl est basé sur l’opérateur par mais en
ajoutant la contrainte que seul un objet enfant soit joué à un moment donné [10].
2.4 Discussion
Dans cette partie nous présentons quelques exemples qui permettent d’illustrer les multiples
contraintes auxquelles sont soumises les applications multimédia distribuées. En effet, elles
cumulent le double inconvénient de devoir manipuler et transmettre de grandes quantités
d’informations en respectant des contraintes de temps et de synchronisation extrêmement
rigoureuses [5]. En outre, Les applications multimédia distribuées deviennent rapidement
inutilisables lorsqu’elles ne parviennent pas à offrir de manière constante une QoS
satisfaisante aux préférences des utilisateurs.
La classification proposée entre médias discrets et médias continus [5] est souvent utilisée car
elle reflète bien la diversité des types d’informations des DMs ainsi que celle des
caractéristiques qui doivent être prises en compte. Ces quelques remarques conduisent à la
nécessité de définir des critères plus adaptés à nos travaux qui sont présentés ici.
Dans cette partie, nous avons présenté le langage de description de DMs SMIL ainsi que le
langage MPEG-7. Ces deux langages sont standards et sont très largement utilisés sur
l’Internet. La plupart de ces langages se basent sur une syntaxe XML et sont présentés par un
4
Plus connues sous le nom en anglais time containers.
13
multimédia
schéma XML. Les différents outils associés à ces langages, permettent de visualiser
graphiquement la spécification et/ou d’exécuter le DM décrit en offrant une sémantique
opérationnelle.
3. Qualité de Service et Contexte

Avec l’évolution des technologies de communication et de l’informatique, les applications
multimédias distribuées sont devenues omniprésentes et la QoS, offerte par ces applications,
devient d’un intérêt fondamental. En effet, les applications multimédias manipulent un grand
nombre de ressources (en termes de mémoires, bandes passantes, etc…) et nécessitent donc de
les gérer, à différents niveaux, afin d’assurer une QoS ainsi qu’une utilisation équitable de ces
ressources. L’utilisateur peut négocier ces paramètres selon son contexte. Dans cette sous-
section, nous présentons la QoS ainsi que le contexte de l’utilisateur.
3.1 Notion de contexte
Il existe de multiples définitions du contexte [48], [59], [67]. Elles sont pour la plupart une
énumération de paramètres qui les rendent très abstraites, difficiles à exploiter ou au contraire
très spécifiques à un domaine. [43], [44].
« Quand les humains parlent avec d’autres humains, ils sont capables d’utiliser des
informations implicites de la situation, ou contexte, pour augmenter la bande passante de la
conversation » [43]. D’une manière plus générale, [44] voit le contexte comme : « toute
information qui peut être utilisée pour caractériser la situation d’une entité. Une entité est une
personne, un endroit ou un objet considéré comme pertinent lors d’une interaction entre
l’utilisateur et les applications elles-mêmes ».D’après [43], [44], [66] un système est dit
sensible au contexte s’il utilise le contexte afin de fournir l’information et/ou les services
pertinents à l’utilisateur, où la pertinence dépend de la tâche de l’utilisateur. Nous nous
inspirons de la définition du contexte de [43], [44] le définissant comme toute caractéristique
ou capacité d’une entité de l’environnement (utilisateur, terminal, réseau, environnement
naturel de l’utilisateur, état et caractéristiques des modules réalisant l’adaptation) qui peut
influer sur la manière de consommer un service (contenu multimédia) donné, et qui est
susceptible de changer dans le temps suite à des événements. La gestion du contexte s’appuie
d’une part sur un langage de description des éléments du contexte d’un utilisateur et d’autre
part sur les outils pour collecter ces données, les comprendre et les analyser. En général, ces
langages décrivent tout ou une partie des informations contextuelles telles que [43], [44]:
14
multimédia
• les informations du profil personnel de l’utilisateur (par exemple le nom, le prénom, l’âge et
les centres d’intérêt),
• les préférences de l’utilisateur en termes de présentation des contenus multimédia (par
exemple la taille et résolution souhaitée d’une image, la couleur d’affichage et la police de
caractère d’un texte et les formats préférés d’un contenu vidéo),
• les capacités de son terminal (par exemple la taille de l’écran, les codecs disponibles et la
résolution), et
• les caractéristiques de son réseau d’accès et de son environnement naturel (par exemple la
valeur de la bande passante, l’indice de luminosité et de bruit de l’environnement de
l’utilisateur).
Dans la partie qui suit, nous expliquons d’une manière brève les types de contexte.
3.1.1 Contexte d'utilisateur

Ce sont toutes les informations qui concernent ce que l'utilisateur veut pouvoir faire avec
l'application. L'utilisateur est très souvent intégré dans le contexte puisqu'il est, dans la plupart
du temps, le seul à percevoir le DM final.
Une application destinée à un utilisateur doit lui fournir des services. L'utilisateur veut
pouvoir émettre des souhaits quant à l'utilisation de l'application. L'application pourra alors
être modifiée en conséquence afin de lui fournir un service le mieux adapté possible.
Nous définissons donc le contexte comme étant l'ensemble des entités caractérisant les
souhaits de l'utilisateur [43], [44].
3.1.2 Contexte d'utilisation

Nous entendons par spécification tout ce qu'elle doit permettre et ce qu'elle ne doit pas
permettre dans son utilisation. Ce sont toutes les situations où ni l'utilisateur, ni son appareil
n'interviennent mais qui demandent tout de même une adaptation comme par exemple quand
une alarme se déclenche, quand un niveau sonore est trop élève, etc. Il s'agit de modifications
de l'environnement qui entrainent, à chaque occurrence, la même adaptation. Chaque fois
qu'une situation ainsi décrite est rencontrée, il faudra appliquer une règle bien définie.
[43], [44] définissent le contexte d'utilisation comme l'ensemble des entités intervenant dans
les prérequis de toutes les obligations et restrictions sur le fonctionnement des services
proposés par l'application. Ces entités ne font en aucun cas partie d'un autre contexte. Elles
sont indépendantes de l'utilisateur et des périphériques.
15
multimédia
3.1.3 Contexte d'exécution

Dans la plupart des travaux sur la prise en compte du contexte, c'est le contexte d'exécution
qui est le plus souvent cité. Comme le dit [43], [66], [63] lorsqu'on parle de contexte
d'exécution, il s'agit très souvent d'adapter l'application à l'évolution de l'état des ressources du
système sur lequel elle s'exécute. Dans ces ressources nous incluons toutes les propriétés liées
au réseau. Ainsi la mobilité fait partie des caractéristiques du contexte d'exécution au même
titre que les caractéristiques matérielles et logicielles.
Nous définissons le contexte d'exécution comme l'ensemble des propriétés permettant de
caractériser les conditions d’exécution de DM c'est à dire l'infrastructure du système qui
supporte les composants logiciels, les périphériques et le réseau. Ce sont toutes les propriétés
mesurables et mathématiquement comparables relatives aux ressources physiques du système
[43], [44].
3.2 Quelques outils de description de contexte
Il existe plusieurs standards dont le but est d’offrir des mécanismes pour décrire le contexte de
l’utilisateur. Nous décrivons dans cette sous-section CC/PP [68] et MPEG-21 [70] car ils
permettent de décrire une grande partie des informations contextuelles d’un utilisateur et
qu’ils sont largement utilisés dans les architectures étudiées [10].
Nous présentons donc en premier lieu le CC/PP qui permet de décrire les différents profils,
puis le standard MPEG-21.
3.2.1 CC/PP
CC/PP (pour Composite Capability/Preference Profiles) [68], [69] est né des efforts de
standardisation du W3C (World Wide Web Consortium). Le but de CC/PP est d’offrir les
moyens pour un client d’exprimer les capacités logicielles et matérielles de son terminal ainsi
que ses préférences. CC/PP est ainsi un standard de description du contexte pour la
négociation et l’adaptation de contenu. Malgré le fait que CC/PP soit pensé au départ pour les
terminaux mobiles, il reste cependant assez général pour décrire n’importe quel
environnement d’utilisateur (appelé profil de l'utilisateur dans la terminologie CC/PP) [10].
Pour ce faire, les profils CC/PP utilisent le Framework de description des ressources (RDF),
qui permet de représenter tout type d’informations sur Internet et de développer et
d’implémenter de manière indépendante un vocabulaire. Le vocabulaire d’un profil CC/PP se
base également sur des identificateurs (des adresses URI) qui désignent des capacités et des
préférences particulières.
16
multimédia
Le Framework CC/PP définit une structure et un vocabulaire. Une structure définit

l’organisation du profil sous forme d’arbre à 2 niveaux de hiérarchie. Cette structure inclut les
composants (components) et les attributs (attributes). Les composants possibles constituent la
plate-forme matérielle (Terminal Hardware), la plate-forme logicielle (Terminal Software) et
l’application qui récupère et présente le contenu à l’utilisateur tel que le navigateur (Terminal
Browser). Chaque composant est un sous-arbre dont les branches représentent les capacités et
les préférences de ce composant.
RDF (pour Resource Description Framework) a été conçu pour fournir un langage de
description de métadonnées. CC/PP utilise RDF, qui grâce aux schémas, lui permet de
développer et implémenter de manière indépendante un vocabulaire, et offre des moyens de
réutilisation et d’extensibilité des métadonnées. Un exemple d’un profil CC/PP est illustré par
la Figure 1.2 :
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp-schema#"
xmlns:ex="http://www.example.com/schema#">
<rdf:Descriptionrdf:about="http://www.example.com/profile#MyProfile">
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#TerminalHardware">
<rdf:type
rdf:resource="http://www.example.com/schema#HardwarePlatform"/>
<ex:displayWidth>320</ex:displayWidth>
<ex:displayHeight>200</ex:displayHeight>
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#TerminalSoftware">
<rdf:type
rdf:resource="http://www.example.com/schema#SoftwarePlatform"/>
<ex:name>EPOC</ex:name>
<ex:version>2.0</ex:version>
<ex:vendor>Symbian</ex:vendor>
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#TerminalBrowser">
<rdf:type
rdf:resource="http://www.example.com/schema#BrowserUA"/>
<ex:name>Mozilla</ex:name>
<ex:version>5.0</ex:version>
<ex:vendor>Symbian</ex:vendor>
<ex:htmlVersionsSupported>
<rdf:Bag>
<rdf:li>3.2</rdf:li>
<rdf:li>4.0</rdf:li>
</rdf:Bag>
</ex:htmlVersionsSupported>
</rdf:Description>
</ccpp:component>
</rdf:Description>
</rdf:RDF>
17
multimédia
Figure. 1.2 – Exemple de profil CC/PP [1], [69].
Cet exemple nous permette de voir une description d’un profil d'un utilisateur décrit en
CC/PP.
3.2.2 MPEG-21
MPEG-21 est une initiative du groupe MPEG (Moving Picture Experts Group- (ISO/IEC
JTC1 SC29WG11)) formellement appelé Framework de multimédia (Multimedia Framework)
[70] [71].MPEG-21 ou ISO/IEC 21000, plus récent des standards MPEG, offre plusieurs
éléments pour construire un cadre de travail ouvert pour la fourniture et la consommation du
contenu multimédia [10].
MPEG-21 décrit ces éléments en fournissant une « vue globale ». MPEG-21 a pour but de
permettre l’utilisation transparente et massive des ressources multimédia à travers une
multitude de types de réseaux et de terminaux utilisés par différentes communautés. Le cadre
de travail multimédia MPEG-21 repose sur deux concepts essentiels : le concept d’élément
numérique, (quoi), et le concept d’utilisateur interagissant avec cet élément numérique, le
(qui) [70].
Un utilisateur est toute personne qui interagit au sein de l’environnement MPEG-21 ou qui
manipule un élément numérique. Il peut être un créateur de contenu, un distributeur de
contenu ou un consommateur de contenu. MPEG-21 assure un cadre de travail pour les
interactions des utilisateurs à travers l’élément numérique [10]. Les spécifications qui nous
intéressent le plus, et surtout, celles qui répondent aux besoins de description du contexte d’un
usager sont les spécifications relatives à la déclaration et à l’adaptation des DMs.
3.3 Définition de la QoS
La démocratisation de l’utilisation des réseaux de communication a permis d’introduire la
notion de QoS qui se propose de fournir des services rendus par tout élément participant à une
interaction réseau (par exemple un protocole) en termes de niveau de qualité proposé. Ce
service ne fournit aucune garantie quant à la délivrance du service en termes de débits et de
temps de transmission dépend de la charge du réseau au moment où on l’utilise [5].
En raison de l’abondance des applications multimédia distribuées ces dernières années, Ce
type d'application concerne un large public, par conséquent il nécessite une production à
moindre coût. La QoS a tout naturellement fait son apparition dans les phases de conception
de ces dernières. En effet, les applications déployées sur un réseau sont fortement dépendantes
de son fonctionnement. Les applications multimédias distribuées déployées sur le réseau
Internet doivent donc pouvoir s’adapter à son mode de fonctionnement et aux environnements
hétérogènes (logiciels et matériels) qu’il supporte.
18
multimédia
De nombreux travaux de recherche [15], [19], [33] ont tenté de répondre à ces préoccupations.
Ces travaux s’inscrivent dans le domaine de la QoS dont l’objectif est de proposer des
niveaux de qualité différents aux utilisateurs des applications multimédias distribuées. De
plus, des travaux déjà menés sur la gestion de la QoS, comme [5], ont consisté à la définir
selon deux points de vue qui semblent intéressants pour décrire la QoS d’une application
multimédia distribuée, à savoir ceux de l’utilisateur et de l’environnement d’exécution.
La prise en charge de la QoS dans les applications multimédias distribuées nécessite de revoir
les méthodes de conception habituelles et donc de définir et de mettre en place des
mécanismes dédiés à la gestion de la QoS. Le choix d’une approche par rapport à une autre
dépend des caractéristiques dont on veut doter le système visé et des propriétés qu’il impose.
Ainsi, la QoS peut être abordée selon plusieurs points de vue car elle dépend de différents
paramètres. Les méthodes de spécification et de développement d’applications introduites par
le génie logiciel ont pour objectif de répondre à des besoins exprimés par des clients. Les
utilisateurs se trouvent alors au centre de ces approches puisqu’ils sont à la base de ces
démarches de conception. Il paraît donc évident de placer de même les utilisateurs au centre
de l’approche de QoS [5].
3.3.1 Point de vue de l’utilisateur

La QoS du point de vue de l’utilisateur se traduit par la perception qu’il a du DM demandé.
Nous appelons ce point de vue la QoS requise car il permet d’identifier les préférences et les
exigences de l’utilisateur vis à vis d’un fournisseur de DM. Ces exigences et ces préférences
sont propres à chaque utilisateur car chacun possède une perception différente des documents
offert par un fournisseur. En raison de sa subjectivité, ce point de vue est critique car il est
difficile à évaluer.
De fait, beaucoup d’applications multimédia distribuées ne le considèrent pas et préfèrent
orienter leur gestion de la QoS sur le point de vue de l’environnement d’exécution. Hafid et
al. [72] le définissent comme des critères de QoS subjectifs car ils ne sont pas directement
mesurables. Malgré cette difficulté, [5] pense qu’il est important de considérer les préférences
de l’utilisateur dans les applications multimédias distribuées car il en dépend de l’intérêt que
le public porte sur ces dernières. Certains travaux décident de le considérer dans une
démarche de QoS afin, par exemple, de définir des critères qualitatifs ainsi que des exigences
propres aux utilisateurs [5].
19
multimédia
3.3.2 Point de vue de l’environnement d’exécution

Le second point de vue est celui de l’environnement d’exécution d’un DM. Il traduit la
capacité du contexte d’exécution à supporter le document qui y sera montrée. Lorsque l’on
parle de contexte d’exécution, on considère l’environnement logiciel et matériel (réseau,
périphériques, etc…). Ce point de vue est également important car il va permettre de
déterminer si le DM demandé par un utilisateur peut être fourni. De plus si on le couple au
point de vue précédent, il permet également de vérifier que le DM requis par un utilisateur
peut être affiché ou pas.
Nous appelons ce point de vue la QoS fournie car il traduit les capacités des environnements
d’exécution à adapter un DM ou à l’afficher directement. Ces paramètres de QoS sont plus
faciles à évaluer que les précédents puisqu’ils sont directement observables et mesurables.
[72] parlent à ce sujet de critères de QoS par objectifs [5].
3.4 Gestion des contraintes de QoS
Gérer la QoS consiste à mettre en place des mécanismes qui vont permettre d’établir et de
maintenir une QoS globale dans les applications multimédias distribuées en fonction d’un ou
des deux points de vue définis précédemment.
La gestion de la QoS peut être mise en place à différents moments. Lorsqu’elle se situe avant
l’affichage ou l’envoi des DMs, on parle de gestion statique. Lorsqu’elle s’effectue pendant
l’affichage ou l’envoi des DMs, on parle de gestion dynamique. Dans un contexte statique, le
système de gestion doit essayer de prévoir si le DM pourra être affiché selon les préférences
de l’utilisateur et les paramètres collectés avant l’exécution. Dans un contexte dynamique,
l’application doit se doter d’un système de surveillance chargé de récupérer à tout moment les
paramètres pertinents, de détecter les variations de QoS et de proposer des plans d’actions afin
d’adapter la qualité fournie en considérant les paramètres collectés.
Les mécanismes de gestion de la QoS sont liés à l’implémentation non fonctionnelle d’une
application car ils concernent des aspects de l’application externes à sa fonctionnalité
première (celle pour laquelle elle a été développée). C’est pour cela que nous utiliserons le
paradigme de la programmation orientée aspect (POA). Cette dernière permet une séparation
claire et précise des aspects fonctionnels et les aspects non-fonctionnels d’une application.
Diverses solutions sont possibles pour l’implémentation de la gestion de la QoS. On peut par
exemple l’intégrer au code de l’application mais aussi définir une entité supplémentaire
chargée de mettre en œuvre ces mécanismes. Dans ce cas, on parle d’intergiciel, de
middleware ou de plate-forme d’exécution [5].
20
multimédia
Les mécanismes de gestion de la QoS peuvent être abordés de différentes façons. En effet, on
peut considérer que c’est l’environnement d’exécution d’un document qui doit s’adapter aux
besoins de cette dernière. Une autre façon de voir les choses est de dire que ce sont les DMs
qui doivent adapter à ce que permet l’environnement d’exécution. [5], donne un exemple de la
gestion de la QoS selon ces deux approches.
3.4.1 Réservation de ressources

Cette approche repose sur l’allocation et l’ordonnancement des ressources de l’environnement
d’exécution afin de permettre le déroulement d’une application selon des critères de QoS
définis. Ces critères sont ensuite exprimés en termes de besoins en ressources (processeur,
mémoire, bande passante, délai, gigue, etc…).
Le contrôle d’admission permet d’évaluer si les ressources requises par une application sont
disponibles. Dans le cas les ressources sont réservées pour l’application. Sinon, une phase de
négociation est établie entre l’application et l’environnement d’exécution. L’issue de cette
phase doit permettre de trouver un compromis entre les ressources disponibles et celles
requises par l’application afin de fournir une QoS négociée. Ces spécifications sont définies à
l’aide de contrats de QoS [5].Différents travaux préconisent ces solutions [73], [74], [75],
[76].
3.4.2 Adaptation de document multimédia
La seconde approche consiste à adapter le DM. L’objectif ici est de collecter les paramètres
de QoS que l’on veut gérer (QoS requise et/ou QoS fournie). Comme pour les systèmes de
réservation de ressources, elle va essayer d’évaluer à travers une phase de négociation de QoS
que pourra fournir le DM en fonction des paramètres collectés. Le DM peut alors être adapté à
l’aide d’un ensemble de politiques d’adaptation qui permet de traduire le compromis trouvé
en des phases d’adaptation à mener sur le DM. La plupart du temps, ces adaptations reposent
sur des phases de reconfiguration de la structure de document. Cette approche nécessite de
posséder des bases de données des descriptions de document afin de pouvoir réaliser ces
adaptations.
Diverses solutions sont utilisées pour mettre en œuvre cette politique de gestion de la QoS.
Les applications auto-adaptables modifient leur comportement afin de fournir la QoS
négociée. Des mécanismes à boucle de retour (feedback) permettent de surveiller un ou
plusieurs événements puis d’adapter les comportements qui sont liés à l’évolution de ces
derniers. Ces mécanismes sont basés sur les principes des systèmes pervasifs [77]. Certains
21
multimédia
travaux déploient des intergiciels, middlewares ou plates-formes d’exécution chargés de

procéder à la gestion de la QoS par adaptation de DM. Ces solutions se retrouvent dans de
nombreux travaux : [5], [22], [25], [37].
3.5 Discussion
Aujourd’hui, aucun profil ne décrit explicitement des contraintes sur la composition des DMs.
Nous avons choisi un vocabulaire étendu de CC/PP permettant de spécifier ce type de
contraintes d’adaptation.
Au terme de cette section, les différents travaux de recherche [63], [66], [75], [80] constatent
que le contexte (terminal, réseaux, utilisateur) et la QoS de DM sont indéniablement liés. Ils
ont considéré que toute modification du contexte peut être interprétée comme une
modification de la qualité du service rendu. Mais nous constatons que les préférences de
l’utilisateur apportent aussi des éléments essentiels sur l'évolution de la QoS globale de DM.
En effet, lorsqu'une modification des préférences survient, cela signifie que le contexte a été
modifié et par conséquent, le DM proposé n'est peut-être plus adapté dans sa globalité.
Cependant, Soocheol Lee et al. [67] ont proposé un modèle, qui utilise une valeur de
préférence de l’utilisateur (u-CVM) pour gérer la QoS de l’utilisateur, mais la QoS est
évaluée après le téléchargement de DM et l’utilisateur peut choisir un seul
type de media.
4. Techniques d’adaptation de document multimédia

À partir du document initial et du profil, l’adaptation est définie comme étant l’ensemble des
mécanismes de transformations utilisés afin de produire un document satisfaisant les
contraintes exprimées dans le profil [2].
4.1 Contraintes d'adaptation

Une contrainte d'adaptation est souvent associée à des capacités matérielles (par exemple, la
taille de l'écran), logicielles (par exemple, les types de ressources exécutables) ou des
préférences utilisateurs (par exemple, la langue de l'utilisateur). Ces contraintes sont
fortement liées aux objets multimédia du document ainsi qu'à leur composition [1].
Différents contextes de présentation multimédia introduisent différentes contraintes sur la
présentation elle-même. Par exemple, les limitations de la bande passante entre le client et le
22
multimédia
serveur peuvent conduire le client à ne pas jouer deux vidéos au même instant. Les limitations
dues à l’affichage peuvent mener à des contraintes similaires.
D’autres types de contraintes peuvent être introduits par les préférences de l’utilisateur, la
protection du contenu ou les capacités du terminal. Les contraintes imposées par le client sont
appelées le profil. Pour satisfaire ces contraintes, les DMs doivent être adaptés avant d’être
présentés [5].
4.2 Types d’adaptation

A partir du profil et du document initial, l’étape d’adaptation doit produire un document
satisfaisant les contraintes exprimées dans le profil. Cette adaptation est généralement réalisée
par un programme de transformation du document [9], [6]. Dans le processus d’adaptation de
DMs, une des premières questions soulevées concerne le quoi à adapter [2]. Plusieurs types
d’adaptation peuvent être envisageables comme l’adaptation locale c’est-à-dire celle qui est
liée aux différents objets multimédia et l’adaptation globale c’est-à-dire celle qui est relative à
l’organisation du contenu de la présentation.
4.2.1. Adaptation locale

Cette adaptation considère les médias individuellement. Elle consiste en toute transformation
physique portant sur les medias, [78] distingue trois grandes catégories d’adaptation :
transformation, transmodage, et transcodage. Nous montrons les types d’adaptation dans la
Figure 1.3.
Figure. 1.3 Adaptation en catégories

a) Transcodage
23
multimédia
La catégorie transcodage permet de changer la méthode de codage d’un média élémentaire

(Texte, image, audio, vidéo). En fait, pour l’image, l’audio et la vidéo, le transcodage est de
changer le type du format. On montre un exemple de transcodage des médias dans Tableau
1.1.
Tableau 1.1 : Exemple du transcodage
Cependant, pour le texte, le transcodage concerne l’encodage du caractère. Cela veut dire que
le transcodage du texte est le changement d’encodage du caractère, par exemple entre
l’encodage ASCII (American Standard Code For Information Interchange) et l’encodage
UTF-8 ( USC Transformation Format -8bits )[9].
b)Transmodage
La catégorie Transmodage consiste à changer le type de média. Par exemple, si un terminal ne
dispose pas de police de caractère lui permettant d'afficher convenablement un texte en
Cyrillique, on va lui préparer une image de ce texte. On a alors un transmodage de texte en
image [22].
c) Transformation
La catégorie transformation consiste à modifier un média sans en modifier le format de
codage. Par exemple, il s'agira de réduire la taille d'une image par changement d'échelle ou
par rognage des bords [50].
4.2.2 Adaptation globale

L’adaptation globale prend en considération la composition du DM. Elle concerne la
transformation de la synchronisation temporelle des médias et la transformation de leur
disposition spatiale dans le document, tout en gardant la sémantique du document adapté la
24
multimédia
plus proche possible de l’initial. C’est une modification de la structure abstraite du document
(généralement représentée par des relations spatiales, temporelles et hypermédia)[2].
5. Familles d’approches d’adaptation

Plusieurs approches ont été proposées pour l’adaptation des DMs et elles sont regroupées en
quatre familles [2], définis comme suit :
5.1 Approches basés sur spécification d'alternatives
Une première méthode d'adaptation de DMs consiste à solliciter l’auteur pour spécifier des
alternatives de présentation. Ce dernier définit un ensemble de critères sur certains éléments
du document. Si ces éléments satisfont les critères, ils sont sélectionnés puis présentés. Dans
le cas contraire, ils sont omis de la présentation.
Nous avons caractérisé les alternatives de présentation en trois types : (1) celles définis en
fonction du profil de la plate-forme cible, (2) celles définis en fonction du contenu du
document et (3) les approches mixtes [1].
5.1.1 Approches basées sur des profils cibles
Dans ce type d'approche, l'auteur du document définit des alternatives de présentation selon
les profils des plates-formes cibles. Par exemple, l'auteur peut identifier différentes
compositions de présentation selon les capacités matérielles d'une plate-forme cible comme la
taille de l'écran, différents encodages des objets multimédia déterminés selon les capacités
logicielles ou la bande passante disponible, ou bien les différentes versions d'objets
multimédia selon la langue de l’utilisateur. Un avantage certain de ce type d'alternative est
donc que l'adaptation est immédiate. Néanmoins, l’auteur doit prévoir toutes les contraintes
d'adaptation possibles et spécifier toutes les alternatives envisageables. Actuellement, la
diversité des profils et des plates-formes à considérer rend ce travail assez coûteux et
fastidieux [2].
5.1.2 Approches basés sur le contenu

Cette seconde approche permet à l'auteur de baser les alternatives sur le contenu de la
présentation. Pour cela, l'auteur agrémente son document de multiples annotations identifiant
les parties plus ou moins pertinentes en décrivant plus en détail le contenu de certaines
parties, etc. A l'aide des annotations, un filtrage peut ensuite être appliqué au document
permettant de sélectionner les parties qui répondent aux critères de sélection établis. Ainsi, ce
25
multimédia
type d'adaptation peut être qualifié d'adaptation a posteriori car l'auteur ne connait pas les
conditions de sélection qui seront effectivement appliquées à son document. Un avantage de
cette seconde classe d'alternatives est donc que plus le document sera annoté, plus
l’adaptation sera flexible. Cependant, l'auteur doit réaliser cet effort d'annotation. De plus, les
conditions de sélection sont fortement dépendantes du langage utilisé pour annoter le
document. Par conséquent, il est nécessaire d'utiliser un langage standard, sinon le document
ne s'adaptera que dans les contextes ou le langage utilisé sera connu [1].
5.1.3 Approches mixtes

Cette dernière approche fusionne les types d'alternatives présentés dans les sections
précédentes pour adapter un DM, c'est-à-dire les alternatives basées sur les profils des Plates-
formes cibles et celles basées sur le contenu de la présentation. Pour cela, l'auteur effectue un
double travail de spécification d'alternatives non seulement selon différents contextes
d’exécutions mais aussi en ajoutant des annotations au document. L'avantage de cette
approche permet de disposer d'une adaptation directe de certaines parties du document et de
bénéficier d'une flexibilité d'adaptation pour d'autres parties. Néanmoins, les inconvénients
des deux précédentes approches sont maintenus pour cette approche mixte [61].
5.2 Spécification de règles d'adaptation

Pour éviter à l'auteur de spécifier toutes les alternatives possibles de présentation de son
document, une autre approche d'adaptation consiste à disposer d'une base de règles de
transformation qui peuvent éventuellement être appliquées aux DMs. Par exemple, dans la
figure 1.4 nous souhaitons exécuter un bulletin météo composé d'une vidéo et d'un texte sur
un lecteur multimédia. Cependant, cette plate-forme cible n'accepte aucun format vidéo.
L'adaptation consistera alors à sélectionner dans la base de règles de transformations celles
qui satisferont le profil considéré et à les appliquer au document. Ici, la transformation T1
d'une vidéo en séquence d'images. L'avantage de cette méthode réside dans le fait que l'auteur
du document initial n'a pas à se soucier des contextes d'exécutions de son document. De plus,
ces règles peuvent être complétées si de nouveaux contextes apparaissent. Néanmoins, pour
que ce type d’adaptation soit efficace toutes les règles de transformation envisageables
doivent être spécifiées [1].
26
multimédia
Figure. 1.4 Un DM adapté à l'aide d'une base de règles de transformation [1].
5.3 Spécification de modèles de document flexibles

Pour disposer d'une adaptation la plus flexible possible et éviter de spécifier des règles de
transformations, une nouvelle thématique de recherche sur l'adaptation est apparue. Elle se
fonde sur la génération automatique de DMs à partir d’un ensemble non composé ou semi-
composé d'objets multimédia pour répondre aux problèmes d'hétérogénéité des contextes de
présentation. Pour cela, de nombreux travaux se sont attachés à définis des modèles de DMs
où l'auteur ne donne pas une représentation précise de la composition du document où des
objets multimédia à présenter mais plutôt une forme d'abstraction du document, voire
exclusivement son intention de discours de présentation. Par la suite, à l'aide du modèle de
document fourni, un module de formatage engendre une présentation multimédia. Les
contraintes d'adaptation exprimées dans les profils peuvent donc se situer à plusieurs niveaux
: à la fois sur l'abstraction du document mais aussi sur sa génération. Toutefois, les documents
à adapter doivent être spécifies dans ces modèles de description non standards et non
directement exploitables [1].
5.4 Approche sémantique et dynamique

Cette approche est basée sur les spécifications qualitatives du document. Chaque document
est considéré comme un ensemble d'exécutions potentielles et chaque profil comme un
ensemble d’exécutions possibles. L’adaptation du document s’effectue en fonction du
contexte au moment de son utilisation. Elle consiste à calculer l'intersection entre l'ensemble
d'exécutions potentielles (modèles de la spécification initiale) et l’ensemble d'exécutions
27
multimédia
possibles correspondant au profil défini. L’avantage de cette approche est qu’elle ne pose
quasiment aucune limite sur les contraintes du profil et qu’elle est indépendante des langages
de description de DMs [2]. De nombreux travaux basés sur cette approche, ont été proposée
[1], [2], [38].
6. Adaptation des contenus multimédia et les modèles architecturaux

Dans cette section, nous nous intéressons, à l’identification des différentes solutions existantes
relatives à la localisation des modules qui réalisent l’adaptation. Ceci peut justifier ou non, la
nécessité de la fonctionnalité de gestion de l’adaptation. Nous présentons par la suite les
différentes techniques d’adaptation et types d’adaptation pris en compte par une architecture
de fourniture de contenus multimédia adaptables. Cette présentation est basée sur la synthèse
effectuée par [10].
6.1 Modèle architectural Client / Serveur et adaptation

L'architecture client/serveur désigne un mode de communication entre plusieurs ordinateurs
d'un réseau qui distingue un ou plusieurs postes clients du serveur : chaque application cliente
peut envoyer des requêtes à un serveur. Un serveur peut être spécialisé en serveur
d'applications, de fichiers, de terminaux, ou encore de messagerie électronique.
Un serveur est passif (ou esclave), à l'écoute, prêt à répondre aux requêtes envoyées par des
clients. Dès qu'une requête lui parvient, il la traite et envoie une réponse.
Un client est, contrairement au serveur, actif (ou maître). Il envoie des requêtes au serveur,
attend et reçoit les réponses du serveur. Le client et le serveur doivent bien sûr utiliser le
même protocole de communication. Un serveur est généralement capable de servir plusieurs
clients simultanément [10].
Les architectures de fourniture de contenus adaptables basées sur le modèle client / serveur
implémentent leur logique d’adaptation soit au niveau du client soit au niveau du serveur.
Dans ce qui suit, nous décrivons comment est réalisée l’adaptation au niveau des clients et des
serveurs [47], [64].
6.1.1 Système d’adaptation au niveau du client
La logique d’adaptation dans ces architectures se situe au niveau du client. Dans ce cas, le
contexte de l’utilisateur, défini le plus souvent par ses préférences et les capacités de son
terminal, est stocké et analysé au niveau du client. Le serveur est ainsi déchargé de tout
traitement sur les médias qu’il envoie tels quels au consommateur.
28
multimédia
Plusieurs techniques d’adaptation peuvent être réalisées au niveau du terminal client si les
capacités logicielles et matérielles le permettent. La plus simple et également la plus courante
des adaptations orientées client est la transformation à la volée d’un contenu. Un exemple est
l’utilisation des feuilles de style telles que XSLT (Extensible Style Sheet Language) ou CSS
(Cascading Style Sheets) pour transformer des documents. Les auteurs introduisent des
changements aussi bien matériels, en introduisant par exemple une technologie d’affichage
(par exemple OLED Organic Light-Emitting Diode) qui crée des régions d’affichage
indépendantes les unes des autres en termes de consommation d’énergie. L’adaptation est
réalisée au sein d’une entité bien déterminée (le terminal client) et la fonctionnalité de gestion
de l’adaptation n’est pas indispensable [10], [47], [64].
6.1.2 Système d’adaptation au niveau du serveur

Ces systèmes implémentent la logique d’adaptation à la source, c’est-à-dire au niveau du
serveur de contenus. Il est intéressant de considérer cette solution lorsque l’adaptation ne peut
être réalisée au niveau du client et cela à cause de ses limitations logicielles et/ou matérielles,
ou lorsque l’utilisateur ne souhaite pas utiliser ses ressources pour autre chose que la
consommation du contenu demandé adapté à son contexte.
L’adaptation côté serveur trouve tout son intérêt lorsque le producteur de contenus
multimédia (serveur) est désireux de préserver ses droits d’auteur. Rajoutons à cela la
possibilité pour un producteur de sélectionner parmi ses versions de contenus ou de les
adapter. Le producteur est assuré ainsi d’offrir un contenu intègre à ses utilisateurs ce qui
n’est pas forcément le cas si l’adaptation se fait au sein d’une entité intermédiaire.
Le serveur dans ce cas possède deux fonctions : produire le document d’origine et en réaliser
plusieurs versions correspondantes aux différents contextes utilisateur. Adapter au niveau du
serveur suggère ainsi une très grande capacité de stockage et de traitement compte tenu de la
diversité des contextes utilisateurs. L’adaptation étant réalisée au sein d’une entité bien
définie (le serveur), la fonctionnalité de gestion de l’adaptation n’est donc pas indispensable
[10], [47], [64].
6.2 Modèle architectural client / intermédiaire (s) / serveur et adaptation
Les architectures C/I/S (client / intermédiaire(s) (proxies en anglais) / serveur) sont de plus en
plus adoptées au dépens du modèle classique C/S (client / serveur). Un module intermédiaire
est un nœud inséré entre le client et le serveur et est dédié, par exemple, à la découverte, à
l’annonce ou encore à l’adaptation d’un service, d’un contenu ou d’une ressource (ex : la
29
multimédia
recherche d’une référence dans une base de données, la gestion d’un annuaire distribué, le
transcodage d’une vidéo ou la réduction d’une image). L’intermédiation ainsi réalisée apporte
une vraie valeur ajoutée en évitant de charger le client et le serveur de tâches spécifiques
consommatrices de ressources sans rapport avec le service final offert.
L’intermédiaire interprète les requêtes de l’utilisateur, récupère et analyse le contexte de cet
usager et détermine la ou les adaptations nécessaires, en tenant compte éventuellement des
descriptions du contenu demandé. Ce même intermédiaire récupère le contenu depuis la
source, l’adapte et le retransmet au consommateur [10], [47], [64].
6.3 Modèle architectural pair-à-pair et adaptation

Le modèle architectural Pair-à-Pair (P2P) est un modèle où chaque nœud (pair) est à la fois
client et serveur. Les ressources sont ainsi annoncées par des nœuds et consommées par
d’autres nœuds, qui peuvent également jouer le rôle d’annonceur. Les ressources offertes sont
généralement des médias. L’adaptation peut être alors réalisée sur un ensemble du réseau de
pairs comme c’est le cas dans une adaptation au niveau des intermédiaires en tirant partie des
outils offerts par un tel modèle architectural tels que les outils d’annonce, de recherche et de
découverte des ressources. Dans ce cas, la fonctionnalité de gestion de l’adaptation est
indispensable car il faut chercher et trouver les bonnes ressources d’adaptation, les instancier,
les orchestrer et gérer leur disparition [10], [47], [64].
7. Techniques de consommation et d’adaptation de contenus multimédia

Kazi-Aoul [10] a décrit les principales fonctionnalités que doit avoir toute plate-forme
d’adaptation de contenus multimédia ainsi que les différents modèles architecturaux qu’elle
peut adopter. Cette section présente tout d’abord les différentes manières de consommer un
contenu multimédia. Elle illustre par la suite les différentes techniques d’adaptation et types
d’adaptation pris en compte par une architecture de fourniture de contenus multimédia
adaptables. Cela nous permet de situer notre travail par rapport aux techniques de
consommation et d’adaptation de contenus multimédia existantes. Consommer un contenu
multimédia pour un utilisateur peut se faire à l’aide de deux techniques définies dans [10] :
• Télécharger tout le contenu et le visualiser (téléchargement) : le contenu est stocké au
niveau du récepteur avant d’être consommé.
• Regarder le contenu au fur et à mesure (streaming) : le contenu est visualisé dès que
des ressources du terminal utilisateur et/ou du réseau sont disponibles.
30
multimédia
Les deux méthodes ont leurs avantages et leurs inconvénients. La première méthode ne
dépend pas des conditions réseaux. En revanche, elle requiert de l’espace de stockage au
niveau du receveur et est consommatrice en temps. La seconde méthode, bien qu’elle
économise du temps et de l’espace de stockage, dépend à tout moment des ressources réseau
disponibles. La QoS est ainsi difficilement garantie étant donné l’hétérogénéité des réseaux
d’accès, des terminaux et des conditions d’accès.
8. Synthèse
Cette partie donne une vision sommaire du domaine de l’adaptation et plus particulièrement
de l’adaptation des documents dans les applications multimédia. En effet, Deux mécanismes
possibles pour la gestion de la QoS sont abordés. Le premier propose une gestion par
réservation des ressources. Cette solution est très utilisée mais n’est pas envisageable dans
tous les cas. En effet, il est nécessaire que le contexte de l’utilisateur support de ces DMs
fournisse cette possibilité. Dès lors que l’on s’intéresse à des DMs à travers des réseaux de
type Internet, une telle solution ne peut être choisie car l’Internet ne permet pas la réservation
des ressources. Cette approche n’a donc pas été retenue et donc nous nous sommes orientés
vers une autre solution. La seconde approche propose une adaptation des documents aux
paramètres de QoS que l’on désire considérer. Cette solution consiste à rendre les DMs
malléables afin qu’elles puissent s’adapter à leurs contexte. Notre intérêt pour les DMs à
travers Internet nous a conduits à choisir ce type de solution pour la gestion de la QoS.
A l’image de cette étude, il est clair que plusieurs travaux de recherche ont utilisé l’adaptation
de DM pour la gestion de QoS tel que [43, 59, 80, 81], mais ils ne sont pas basés sur les
préférences de l’utilisateur. L’adaptation de DM d’après Soocheol Lee [67] qui est proche de
notre contribution en se basant sur les préférences de l’utilisateur. Mais, il a proposé d’adapter
le contenu après le téléchargement, et l’utilisateur peut changer ces préférences mais
l’approche proposée demande beaucoup de temps et de coût et elle ne prend pas en
considération ces préférences avant le téléchargement de DM.
31
multimédia
9. Conclusion
Dans ce chapitre nous avons effectué un survol sur les caractéristiques des architectures de
fourniture et d’adaptation de contenus multimédia. En effet, nous avons présenté les
applications multimédia ainsi que les types des medias dans ces applications.
Nous avons porté une attention particulière aux outils de description de contenus multimédia
et de contexte. Puis, nous avons abordé les outils de description de contexte qui permettent de
décrire une grande partie des informations contextuelles d’un utilisateur et qu’ils sont
largement utilisés dans les architectures étudiées.
Pour terminer, nous avons présenté un état de l’art sur la QoS et contexte. Puis, nous avons
étudié les différentes techniques d’adaptation et types d’adaptation pris en compte par une
architecture de fourniture de contenus multimédia adaptables. Dans la seconde partie de ce
chapitre, nous avons présenté un panorama des techniques et des familles d’approches
d’adaptation. Dans le chapitre suivant, nous avons étudié de quelques architectures
d’adaptation de contenu multimédia pour gérer la QoS et la programmation orienté aspect 5
(POA).
5
Plus connues sous le nom en anglais AOP pour Aspect-Oriented-Programming
32
Etude de quelques architectures
Chapitre
d’adaptation de contenu multimédia
02
pour gérer la QoS et apport de la POA
1. Introduction
Dans le chapitre précédent, nous avons présenté quelques concepts liés aux modèles
architecturaux et les outils de description de contenus multimédia et de contexte pour les
utiliser dans l’adaptation des données multimédia en fonction des contextes et de gestion de
QoS.
Cependant, l’adaptation de contenu multimédia a besoin de mécanismes efficaces pour
atténuer le problème d’hétérogénéité des composants logiciels, des dispositifs matériels, des
réseaux et des contraintes des environnements informatiques. En outre, l’adaptation permet de
fournir des données conformes aux préférences de l'utilisateur et au contexte de son
environnement.
Dans ce contexte, nous présentons dans ce qui suit quelques travaux en relation avec notre
problématique : la réalisation d’un système d’adaptation de contenus multimédia par rapport
aux contextes des utilisateurs. Rappelons que les architectures de fourniture de contenus
multimédia adaptés au contexte des utilisateurs proposent des solutions différentes mais
réalisent néanmoins les mêmes fonctionnalités [10] :
• la gestion du contexte et de sa description
• la gestion des contenus multimédia et de leurs descriptions
• la gestion de la prise de décision pour l’adaptation
• la gestion de l’adaptation, éventuellement distribuée
Ensuite, nous pouvons montrer les points forts et les points faibles de ces architectures. A la
fin, nous réaliserons une synthèse des avantages et des inconvénients de chaque architecture
d’adaptation.
33
Chapitre 2 Etude de quelques architectures d’adaptation de contenu multimédia pour gérer la
QoS et POA
Dans le but de permettre une meilleure réutilisation, le paradigme de la POA propose de

structurer les applications sur la base du concept d’aspect. Nous considérons que l’adaptation
est une préoccupation transversale. En conséquence, nous avons abordé les concepts du
langage de POA à la fin ce chapitre.
2. Architecture NAC
D’après [22], l’architecture NAC (Negociation and Adaptation Core) représente une
architecture flexible et supporte plusieurs organisations, selon l'affectation du module
d'adaptation et de négociation. Cette architecture assure, dans un environnement hétérogène,
une transmission de contenu adapté aux contraintes du contexte du client cible.
Figure.2.1 Organisation générale de l’architecture NAC [63]
2.1 Principes
NAC vise à assurer un système d'accès au contenu utilisé par l'application cliente. Par ailleurs,
le système tente de fournir une analyse et une gestion efficace du contexte de l'environnement
dont l'état peut changer d'un instant à un autre. L'aspect adaptation du système est donc
confronté aux contraintes causées par l'état du système, la diversité du contenu existant dans
le réseau, ainsi que par les capacités et les préférences de l’utilisateur final.
Vis-à-vis de l'analyse du contexte, le proxy représente l'entité idéale pour analyser le contexte
de l'environnement. En effet, les caractéristiques de toutes les entités de l'environnement
peuvent influencer l'accès au contenu par l'application client.
34
QoS et POA
2.2 Adaptation de DM pour la gestion de QoS

Du côté de l'adaptation du contenu pour la gestion de QoS, les processus d'adaptation essaient
généralement d'appliquer une réorganisation et une restructuration du contenu original. Le
format et la structure d'origine du contenu jouent donc un rôle principal dans le processus
d'adaptation. Afin de faciliter ce processus, le contenu ne doit pas être lié, au moment de sa
création, à une plate-forme particulière. Le modèle du contenu doit éviter d'inclure des
informations spécifiques à des caractéristiques particulières telles qu'une résolution donnée,
une grande taille d'écran, etc. Ces principes relatifs aux modèles de contenu sont appelés :
principes d'indépendance vis-à-vis des terminaux. Un suivi de ces principes dans la
conception et une adoption de modèles de contenu facilitent l'application des processus
d'adaptation et rendent l'adaptation plus universelle.
L'architecture NAC part de ces différents constats et principes pour proposer une solution au
problème de négociation et d'adaptation du contenu dans les systèmes hétérogènes.
L'architecture définit un ensemble d'entités et associe un ensemble de fonctionnalités à chacun
des composants du système. Ces entités sont organisées dans une architecture dont les
différents composants coopèrent en se basant sur la description et la gestion du contexte, les
techniques d'adaptation et les protocoles de communication et de négociation [25].
NAC manipule un format déclaratif des descriptions de l'environnement et des capacités des
processus et des méthodes d'adaptation du contenu. Cette manipulation est faite dans un cadre
extensible que ce soient les profils de description des clients qui peuvent évoluer ou les
mécanismes d'adaptation qui peuvent être ajoutés à n'importe quel moment afin d'enrichir les
capacités d'adaptation de l'architecture [27].
2.3 Gestion du contexte

Du côté de la description et de la gestion du contexte de l'environnement, l'approche
déclarative des contraintes utilisateur et de son environnement permet le traitement
automatique des descriptions. En effet, à partir des ensembles de descriptions des profils, cette
approche permet une extraction facile des caractéristiques nécessaires pour l'adaptation du
contenu dans un contexte particulier. L'organisation sémantique des contraintes de
l'environnent en utilisant des modèles de description tel que RDF [26], permet d'automatiser
le traitement des contraintes et, par conséquent, d'automatiser l'exécution des règles et des
processus d'adaptation qui dépendent des caractéristiques du client et de son contexte global.
35
QoS et POA
Le modèle de description manipule un ensemble de caractéristiques, ou des profils, décrits
selon un format déclaratif sous forme d'un marquage descriptif. Le modèle de description
assure la description des caractéristiques statiques et dynamiques. Les profils peuvent être
créés par édition d'un auteur ou par génération automatique à partir du contexte de
l'environnement.
Le modèle de description de NAC, appelé UPS (schémas universels pour la description des
profils) [25], utilise RDF pour représenter les différents profils de l'environnement hétérogène
en se basant sur un modèle de données. Formellement, RDF peut être défini par :
▪Un ensemble de ressources : des données décrites en RDF. Elles sont décrites à l'aide
d'expressions RDF et sont référencées par des URL.
▪Un sous-ensemble de ressources appelé propriétés : elles définissent les attributs ou
relations utilisés pour décrire les ressources.
▪Un ensemble de littéraux
▪Une assertion: elle assigne une valeur à une propriété pour une ressource.
C'est donc un triplet.
▪ RDF: Une déclaration RDF est un triplet constitué d'un sujet, d'une propriété et d'un
objet.
3. Architecture PAAM
Kazi-Aoul [10] a proposé une architecture fonctionnelle de PAAM (Peer-2-Peer architecture
for the provision of Adaptable Multimedia contents), pour mettre en œuvre une adaptation
distribuée sur différents nœuds du réseau évitant le schéma classique où l’adaptation est
dédiée à la source du contenu ou à un intermédiaire. C’est une architecture orientée services
qui adapte dynamiquement des DMs composites par rapport aux contextes des usagers, dans
un environnement où les ressources d’adaptations sont proposées par des participants à un
réseau (utilisateurs et/ou prestataires) [29]. PAAM est une généralisation du modèle
architectural Client/Intermédiaire/Serveur car tous les nœuds peuvent à la fois être
consommateurs de contenus multimédia (client), producteurs de contenus multimédia
(serveur) et adaptateurs de contenus multimédia (intermédiaire). PAAM est ainsi assez proche
du modèle architectural P2P (Peer-2-Peer) [10]. Elle est représentée dans la Figure 2.2.
36
QoS et POA
Figure. 2.2 L'architecture fonctionnelle de PAAM [10]
3.1 Principes
Nous distinguons deux principales fonctionnalités fortement connexes : Le traitement du
contexte et sa mise à jour.
Un système d’adaptation PAAM supporte un nombre fixe d’utilisateurs (consommateurs de
DMs composés). Il possède un planificateur utilisant ses propres politiques d’adaptation, son
propre algorithme d’adaptation et ses propres heuristiques. Par exemple, si un utilisateur
envoie la même requête à deux systèmes d’adaptation PAAM, il est possible que les
planificateurs respectifs ne produisent pas le même graphe d’adaptation et que le document
final ne soit pas le même. Un utilisateur peut ainsi changer de système d’adaptation PAAM,
s’il n’est pas satisfait du service d’adaptation rendu.

Cette architecture a pour but d’adapter les DMs composés au contexte des
usagers. L’une des originalités de cette architecture est de mettre en
place une adaptation distribuée sur différents nœuds du réseau en évitant
de dédier l’adaptation à un serveur ou à un intermédiaire. PAAM permet
d’intégrer aussi bien des fournisseurs de services d’adaptation que des
37
QoS et POA
particuliers qui se porteraient volontaires pour exécuter des fonctions
d’adaptation en donnant un peu de leurs ressources matérielles et
logicielles.

L’objectif de cette architecture n’est pas basé autour de la réalisation d’un système de gestion
du contexte. Dans notre architecture, nous proposons néanmoins une solution permettant de
décrire le contexte.
4. Architecture DCAF
DCAF (pour Distributed Content Adaptation Framework) est une architecture orientée
service qui a été développée au sein du laboratoire LIRIS (Laboratoire d’informatique en
Image et Systèmes d'information) à Lyon [31]. DCAF est une architecture d’adaptation de
contenu générique, extensible et interopérable. Elle est représentée dans la Figure .2.3
Figure. 2.3 Architecture DCAF [31]
4.1 Principes
L’architecture est basée sur des proxies locaux (Local Proxies : LP) qui prennent en charge la
récupération et le traitement des profils de contexte. Ces proxies décident du type et du
nombre de traitements adaptatifs, découvrent les services d’adaptation, planifient l’exécution
des services et les invoquent. Un élément fondamental du proxy local est le module de
négociation et d’adaptation de contenu (CNAM). Ce module détermine un schéma
38
QoS et POA
d’adaptation optimal et invoque les services d’adaptation ad hoc. Le module de négociation et
d’adaptation de contenu (CNAM) est responsable de la construction du graphe d’adaptation.
Les serveurs de contenus représentent des entrepôts standards de données, tels que des sites
Web, des bases de données et des serveurs multimédias.
Elle a proposé aussi les proxies de contenus (Content Proxies: CP) qui fournissent un accès
aux serveurs de contenus, formulent les requêtes des utilisateurs dans un format adéquat aux
sources, gèrent et livrent (en réponse aux requêtes des utilisateurs) des descriptions de
contenu (méta-données).
4.2 Adaptation de DM pour la gestion de la QoS

Pour adapter un DM, il utilise deux éléments suivant :
- Le répertoire des services d’adaptation (Adaptation Service Registry: ASR) est un
annuaire de services d’adaptation semblable à un annuaire UDDI. Il stocke les
descriptions fonctionnelles (profils) et non fonctionnelles (par exemple le coût) des
services d’adaptation multimédia et offre des APIs de recherche des services.
- Les services d’adaptation (Adaptation Services : AS) sont des serveurs hébergeant un
ou plusieurs service(s) d’adaptation. Les services d’adaptation sont implémentés en
tant que services Web et sont développés de manière indépendante de l’architecture
DCAF.

L’auteur a proposé le gestionnaire des profils utilisateurs (Context Profile Repository : CPR)
qui stocke les informations du contexte utilisateur, c’est-à-dire les caractéristiques et les
préférences de l’utilisateur, les capacités et les propriétés du terminal ainsi que les propriétés
du réseau. Les utilisateurs peuvent mettre à jour et modifier leur profil à tout moment. Les
informations contextuelles dynamiques telles que la localisation d’un utilisateur ou les
paramètres dynamiques du réseau sont déterminées lors de l’exécution des requêtes de
données.
5. Architecture APPAT
APPAT (pour Adaptation Proxies Platform) est une plateforme proposée par une équipe de
recherche du LIFC (Laboratoire d'Informatique de l'Université de Franche-Comté) [32].
APPAT est une architecture à base de proxies. Elle introduit la notion de distribution de
l’adaptation sur plusieurs hôtes appelés proxies d’adaptation. Ce travail a comme cadre de
39
QoS et POA
travail les applications collaboratives. La plateforme APPAT gère la coordination des proxies,
l’échange d’information et l’adaptation [10].
Figure. 2.4 Architecture de la plateforme APPAT [32]
5.1 Principes
Un client est connecté à la plateforme APPAT par l’intermédiaire d’un Proxy d’adaptation.
Son idée est de réaliser l’adaptation globale qui est définie comme «l’adaptation des données
en fonction de l’ensemble des paramètres impliqués par la multiplicité des utilisateurs». La
Figure 2.4 montre plusieurs entités amenées à collaborer afin de réaliser l’adaptation globale :
•Le Proxy d’adaptation (PA) est au cœur de la plateforme APPAT. Il renferme trois
fonctionnalités : la partie communication, la partie décision et enfin la partie adaptation.
•Un site est soit émetteur, soit récepteur. Ainsi, chaque site représente à la fois un serveur
et un client.
•Une Interface de Proxy d’adaptation (IPA) est le point d’accès de chaque site à la
Plate-forme.
•Un annuaire distribué est constitué de plusieurs instances d’annuaire (IA) qui partagent les
informations sur l’ensemble de la plateforme.
40
QoS et POA
Une IA contient des informations sur l’état de la plateforme notamment celles relatives aux
PA. Nous remarquons qu’il n’y a pas une gestion des préférences des utilisateurs pour
l’adaptation de DM.

L’approche d’adaptation n’est pas claire en ce qui concerne l’exécution des services
d’adaptation. Cependant, elle apporte plus de possibilités en termes de flexibilité,
d’évolutivité, d’équilibrage de la charge et de robustesse. APPAT propose trois façons, pour
un site ou un nœud, de communiquer ses préférences et les caractéristiques de son terminal
pour l’adaptation de DM. La première est d’envoyer un profil CC/PP dans l’en-tête http de la
requête mais il y a une absence de politique de gestion des profils. La deuxième est de
proposer une page de configuration située au niveau de l’interface du proxy d’adaptation à
travers laquelle les utilisateurs peuvent spécifier leurs préférences qui sont mémorisées. La
troisième consiste à avoir une application externe ou interne (plug-in) au client, indépendante
de la requête, et permettant le contrôle de chaque client. Le moteur de décision au niveau du
proxy d’adaptation (PA) permet de prendre des décisions sur l’adaptation. Il se base sur une
procédure de décision multicritère prenant comme paramètres des informations relatives aux
clients, aux PA, aux types de donnée à transmettre et à adapter. Trois cas peuvent se présenter
relativement au lieu d’adaptation: adapter au plus près de l’émetteur, adapter au plus près du
récepteur ou adapter au cœur de la plateforme. Chacun a une incidence sur l’état du réseau,
sur les transmissions, et sur la QoS ; les critères de QoS ne sont pas suffisants pour choisir les
meilleurs services d’adaptation.
Le gestionnaire d’adaptation met en place des mécanismes d’adaptation (propres à chaque
proxy d’adaptation), démarre, arrête des processus d’adaptation (des processus sont des
threads Java qui reçoivent et transmettent des données, adaptées ou non) et modifie des
paramètres d’adaptation. Une liste des processus en cours est mise à jour par ce gestionnaire
en archivant la référence de chaque processus en cours dans une table. Les mécanismes
d’adaptation introduits par ces travaux concernent le filtrage de données discrètes ou
continues, le transcodage et le mixage de flux continus [10].
41
QoS et POA
Lapayre J-C [43] a proposé le composant Session APPAT pour gérer le contexte. C’est un
module existant sur chaque PA et permettant de collecter les informations du contexte via
différentes interfaces :
- L’IA permet au PA de s’inscrire et de se désinscrire, de se mettre à jour pour les
informations communes et de localiser les autres PAs.
- L’IPA permet à chaque PA de communiquer avec un autre PA.
- L’interface client permet de réaliser la communication entre APPAT et un client

donné en gérant les requêtes, les négociations et les transmissions de données.
Les informations collectées par le composant Session APPAT à travers ces différentes
interfaces (qui correspondent aux informations partagées par l’annuaire distribué) sont
conservées dans des tables pendant une durée limitée (par exemple une session).
Des MIBs (pour Management Information Bases), qui sont des bases d’informations sur l’état
d’une machine, sont déployées au niveau des sites et des PAs afin de récupérer l’état de
l’activité réseau ainsi que celui des ressources des machines. Un client au sein du composant
Session APPAT met à jour ces MIBs. Il s’agit là d’une fonctionnalité appelée supervision des
ressources des machines. Elle intervient à deux niveaux. Dans un premier temps, lors de la
connexion d’un client, le moteur de décision trouve la meilleure configuration d’une
transmission en fonction de ses ressources. Dans un second temps, la supervision permet de
répondre aux variations des ressources locales et distantes pendant une transmission de
données continues. Donc on peut résumer qu’il y a trois niveaux de gestion de contexte :
- Au niveau du client (requête http contenant un profil CC/PP).
- Au niveau du Proxy.
- Au niveau d’une application interne ou externe (Plug-in).
6. Autre travaux liés à l’adaptation de DM
Plusieurs architectures ont été proposées pour l'adaptation des applications multimédia.
Nous résumons dans le Tableau .2.1 certains d'entre eux. L'architecture proposée dans
Kalimucho [43], où le choix est tombé sur l'adaptation dynamique au contexte comme un
outil de gestion de QoS. Les auteurs proposent une plate-forme pour la reconfiguration et le
déploiement d'applications dans le contexte de contraint d’environnement. Pour cette raison,
l'architecture est basée sur une classification des contextes afin d'examiner différentes
propriétés des applications omniprésentes, des dispositifs, la mobilité, l'environnement et les
42
QoS et POA
exigences de l'application elle-même. Cependant, Kalimucho [43] n’a pas proposés de
technique de gestion des préférences de l'utilisateur. Depuis la dernière décennie, plusieurs
travaux de recherche ont proposé et généralement regroupé en quatre catégories principales
[48], [64]: adaptation côté serveur, adaptation côté client, adaptation basée proxy, et
adaptation Peer-to-Peer.
• Adaptation du côté serveur : Certains appareils peuvent demander un serveur pour adapter
certains DMs. Une telle adaptation est sous sa responsabilité et peut exiger des connaissances
et des compétences avancées sur les utilisateurs connectés. Dans une telle situation, le serveur
devient généralement vite fastidieux, surchargé et prend du temps.
• Adaptation côté client : Pour une simple problématique, chaque dispositif peut être en
mesure d'adapter les documents par lui-même. Toutefois, certains dispositifs du côté client
peuvent ne pas être en mesure d'exécuter des opérations d'adaptation multiples à la fois en
raison de leurs capacités limitées, (par exemple la batterie), et sont souvent mal adaptées aux
situations où les contraintes de réseau sont difficiles.
• Adaptation basée Proxy : Un proxy entre un client et un serveur agit comme un médiateur.
Dans ce cas, de nombreuses communications peuvent être effectuées, car l’utilisateur négocie
l'adaptation à appliquer. Mais ses inconvénients sont liés au problème de sécurité et aux outils
d'adaptation, qui doivent être évalués.
• Peer-to-Peer adaptation : La venue de la technologie peer-to-peer contribue
fortement à modifier les architectures d'adaptation. Les contenus multimédia, les échanges de
conflits et les services sont indifféremment répartis entre les plate-formes mobiles. L'approche
distribuée correspond mieux avec les différentes caractéristiques des plates-formes mobiles
hétérogènes. En conséquence, cette approche prend tous les avantages du paradigme peer-to-
peer, l'équilibrage de charge et plus de choix de services.
Le Tableau 2.1 présente brièvement des différentes architectures d’adaptations décrites dans
la littérature qui assure, dans un environnement hétérogène, une transmission de contenu
adapté aux contraintes du contexte du client cible. Puis, nous détaillons les principales
fonctionnalités de chaque architecture utilisée. Nous avons défini des critères pour faire cette
comparaison entre les architectures :
- But: Il spécifie l'objectif de base de l'architecture proposée.
- Modèle: Il existe de nombreux types de modèles. Remarquons que cet aspect n'est pas
précisé dans certains travaux de recherche.
43
QoS et POA
- Description du profil: Il donne le modèle de description du profil utilisé par l'auteur.
- Gestion des préférences de l’utilisateur: cette fonction indique si l'auteur considère ou non
les préférences de l'utilisateur.
Tableau 2.1 Étude comparative entre les architectures d’adaptations existantes
Architecture But Modèle utilisé Description Gestion des

du profil préférences
de
l’utilisateur
Knowledge-based Proposer une méthode Ontologies MPEG-21 Non

multimedia déclaratives, la technologie
adaptation for basée sur les connaissances,
impliqués dans les
ubiquitous
communautés multimédias et
multimedia
élargit le champ d'application
consumption [54]
de Web sémantique
Multimedia contents Présenter des méthodes Overlapped Content MPEG-21 Oui

adaptation by actuelles pour l’adaptation DIA
Value(OCV)
modality conversion des contenus multimédias
with user preference par l’accommodement de
in wireless network modèle de la valeur de
[67] préférence de l'utilisateur (u-
CVM)
Automatic Proposer d’une ontologie Ontologies Non spécifie Non

Adaptation of spécifique pour l'adaptation
Multimedia au temps réel (runtime) de
Documents [47] documents multimédia
Padma: An Concevoir une architecture de Client/Server Non spécifie Non

Architecture for système basé sur la QoS pour
Adaptive soutenir une session de
Multimedia Systems multimédias de qualité
[66] adaptative.
Adaptive QoS Présenter un mécanisme de Agent MPEG-2 Non

Management Using gestion de QoS adaptative sur
44
QoS et POA
Layered Multi- la base des couches de
Agent System for système multi-agents (MAS).
Distributed
Multimedia
Applications [80]
Semantic Context- Proposer un (re) -Déployer et P2P RDF/XML Non

Aware Adaptation la stratégie de reconfiguration
Platform selon son système avec les
Architecture exigences de QoS, la
(KALIMUCHO) surveillance dynamique des
[48], [43] composants d'adaptation
PAAM (Kazi_Aoul Permettre que chaque P2P MPEG-21 Non

Z, 2006) participant doive être
SMIL
fournisseur, consommateur
ou adaptateur.
MARCH [49] Proposer que chaque Client / Server RDF Non

participant doive être
Consommateur, fournisseur
ou un adaptateur.
NAC [63], [22], [27] Assurer dans un Client/Intermédiaire(s) UPS Non

environnement hétérogène
/Server
une transmission de
contenu adapté par

négociation.
APPAT [32] Apporter plus de possibilités Client/Intermédiaire(s) RDF (CC/PP) Non

en termes de flexibilité,
/Server
d’évolutivité, d’équilibrage
de la charge et de robustesse
DCAF [79] Proposer un système évolutif Client/proxy/Server Non préciser Non

en termes de chemins
d’adaptation.
Un contexte d'utilisateur est spécifié par les préférences des terminaux, les capacités et les
caractéristiques du réseau d'accès de l'utilisateur. Certains de ces éléments contextuels
peuvent être dynamiques et changer en fonction du temps ou du lieu. Malheureusement, la
45
QoS et POA
plupart des architectures [50], [53] mettent l'accent sur l'hétérogénéité des données (taille et
type) et ne prennent pas en compte les choix et les préférences de l'utilisateur pour gérer la
QoS.
Un contexte de l’utilisateur est caractérisé par les préférences de l'utilisateur final, les
capacités et les caractéristiques du réseau d'accès. Certains de ces éléments contextuels
peuvent être dynamiques et peuvent être modifiés en fonction de temps ou de l’espace.
Malheureusement, la plupart des architectures Bouix et al. [50] et Derdour et al. [53] mettent
l'accent sur l'hétérogénéité des données (taille et type) et ne prennent pas en compte les choix
et les préférences de l'utilisateur pour gérer la QoS. D'après les travaux ci-dessus, qui ne se
sont pas intéressés par l'adaptation de DM basée sur les préférences de l'utilisateur, celles qui
suit présentées dans Shahadat et al [66], Alti et al [48], Cassagnes et al. [43] et Kosuga et al.
[51] se concentrent sur l'adaptation du DM pour la gestion de la QoS. Cependant, ces travaux
sont respectivement basés sur le modèle client / serveur et le paradigme de l'agent. En outre,
la gestion des préférences des utilisateurs n'est pas prise en compte. Autrement, Dietmar et
Klaus [54] et Alti et al. [47] sont basés sur le modèle ontologique. Plus précisément, ils
proposent des règles sémantiques permettant la génération automatique et dynamique de
MMD et une qualité de composition de composantes hétérogènes.
Dans MARCH [49], NAC [63], [97] et PAAM [59], des architectures d'adaptation de DM
sont proposées. Les approches proposées visent à résoudre les problèmes liés à l'adaptation du
contenu pour répondre aux exigences des utilisateurs en termes de limitations matérielles et
pour offrir des stratégies de négociation de contenu où celles du client et les caractéristiques
du contenu sont variées.
Contrairement aux architectures précédentes, Soocheol et al. [67] ont proposé une approche
systématique capable de convertir les objets de contenu d'un DM soumis à une contrainte de
source et à la préférence de l'utilisateur. Ils développent u-CVM, qui est un modèle de valeur
de contenu étendu sur la valeur (OCV) pour représenter la dépendance de la valeur du contenu
et la préférence de l'utilisateur. Cette proposition ne gère pas la QoS de DM. L'objectif
principal de ce travail est d'améliorer l’adaptation des DM en tenant compte des préférences
des utilisateurs, afin d'obtenir une meilleure QoS. En d'autres termes, cette architecture vise à
adapter des DMs en utilisant une interface utilisateur liée aux préférences. Généralement, les
architectures d'adaptation existantes gèrent les DMs qui sont envoyés depuis une machine
serveur vers un périphérique client. Cependant, l'architecture proposée a un double avantage:
accélérer le processus de négociation du contenu et éviter les échanges inutiles de messages
46
QoS et POA
entre le client et le serveur car les préférences de l'utilisateur sont données au début via notre
interface. Cette technique permet de réduire le temps d'attente du client.
7. Synthèse
Les contraintes d’adaptation liées à la composition des DMs sont assez limitées. En effet, les
approches présentées ne considèrent que des contraintes relatives à la taille de l’écran du
terminal cible ou bien au nombre d’objets multimédia qui peuvent être exécutés
simultanément ou enfin aux types d’objets multimédia qui peuvent être présentés. Cependant,
aucune approche ne considère les préférences des utilisateurs pour la gestion de la QoS.
Les éléments présentés dans la section 6 de ce chapitre nous permettent de comparer chacune
des architectures étudiées et de discuter leurs avantages et leurs inconvénients.
Ce chapitre donne un aperçu des quelques architectures de gestion de QoS par l’adaptation de
DM dans le but de dégager les points critiques et essentiels qu’il est nécessaire d’adresser
lorsque l’on s’intéresse au développement de ce type d’architectures.
En effet, le média est un concept central. Toutes les définitions et classifications que nous
avons données s’accordent sur ce point. Le réseau Internet fournit un environnement
hétérogène tant au niveau logiciel qu’au niveau matériel, ce qui rend son fonctionnement non
prévisible. Dans ce sens, les travaux basés sur la QoS tentent de donner une réponse en
essayant de garantir l’offre d’un DM adapté. Des travaux antérieurs abordent ce domaine.
Dans la littérature, tous les travaux basés sur la QoS de DM ne donnent pas le choix à
l'utilisateur de construire un DM. Ces travaux limitent les préférences de l'utilisateur en ce qui
concerne la capacité de son appareil et fournissent un document adaptable à leur contexte.
Depuis la dernière décennie, les travaux de recherche existants ont été proposés et ils sont
généralement regroupés en deux grandes catégories [88]:
- Dans la première catégorie, les travaux sont des architectures proposées qui sont
généralement basées sur l'un des types suivants: L'adaptation côté serveur, l'adaptation côté
client, l'adaptation basée proxy ou l'adaptation Peer-to-Peer. Ils prouvent leur efficacité par
rapport aux autres. Nous citons par exemple les travaux: [66], [49], [22], [59].
- Dans la deuxième catégorie, les travaux portent sur la compatibilité de DM avec les
contraintes de contexte et les transformations appliquées aux médias. Les auteurs de ces
travaux veulent prouver une des transformations suivantes:
47
QoS et POA
- Transformation structurelle: cette catégorie de techniques est liée aux transformations
appliquées à l'organisation globale (spatiale ou temporelle) ou à la logique arborescente du
document.
- Transformation des médias (contenu): dans cette catégorie, nous trouvons les méthodes de
transformation sur l'adaptation des médias et leur codage, par exemple celles des images et
des vidéos à l'aide d'une réduction de la couleur, d'une réduction de taille ou d'une conversion
du format d'encodage.
- Adaptation sémantique: afin d'assurer une adaptation produisant un contenu cohérent, les
techniques d'adaptation doivent prendre en compte l'aspect sémantique du contenu source.
Pour cette catégorie, nous citons les travaux: [53], [48], [43], [47].
Dans notre travail, nous proposons un processus d'adaptation qui est nécessaire pour être géré
par les préférences de l'utilisateur et de considérer les limites utilisateur (handicap physique,
par exemple: les sourds ne veulent pas de son), en s'assurant que le document adapté satisfait
l'utilisateur. Nous voyons l’adaptation de DM comme une propriété transversale. Pour cette
raison nous présentons, dans la section suivant, le paradigme aspect.
8. Programmation Orientée Aspect (POA)

Du fait de ses nombreux atouts (encapsulation, polymorphisme, modularité, …), la
programmation par objets constitue indéniablement une technologie importante pour aider à la
construction d’applications complexes. En effet, elle favorise la réutilisation et permet ainsi la
réduction des délais de développement et de maintenance.
Cependant, cette réutilisation n’est pas toujours aisée. C’est notamment le cas pour les
applications dont la construction ne se limite pas à la simple définition d’un ensemble de
services donnés, mais nécessite également la prise en compte de différentes propriétés non-
fonctionnelles (ou d’infrastructure) telles que la distribution et la persistance. Dans de telles
applications, l’implémentation des services réalisés et celle des différentes propriétés non-
fonctionnelles se trouvent intimement enchevêtrées. De ce fait, la réutilisation se trouve
compromise. En effet, il n’est pas toujours possible de réutiliser les différents aspects (i.e.
services ou propriétés non fonctionnelles) d’une application, indépendamment les uns des
autres [21].
Il est à noter que la POA est indépendante de la programmation par objets. En effet, il est
possible d’utiliser la programmation par aspects conjointement à d’autres paradigmes de
programmation (fonctionnelle, impérative, …) [21].
48
QoS et POA
Dans cette section nous rappellerons d’abord les problèmes résolus par la POA, suivie d’une
présentation de ses concepts. Nous terminons ce chapitre par la présentation des
caractéristiques du langage AspectJ.
8.1 Problèmes résolus par la POA

Le but principal de l’ingénierie du logiciel est d’obtenir la qualité d’un logiciel. Les approches
traditionnelles telles que les approches objet fournissent un support important de
décomposition permettant d’offrir la réutilisation, et pour améliorer la qualité logicielle, grâce
à l’encapsulation, le polymorphisme, l’héritage et la délégation. Cependant, quelques
préoccupations, appelées préoccupations transverses dans la terminologie orientée aspect,
entravent la réutilisation des modules [62].
L’objectif de la POA est la séparation des préoccupations (voir Figure. 2.5). La contrainte
principale est la dispersion des préoccupations transversales à travers le code métier [06].
Dans cette sous-section nous expliquons les problèmes résolus par la programmation orientée
aspect.
Figure. 2.5 Dispersion du code d’une fonctionnalité [21]
49
QoS et POA
8.1.1Fonctionnalités transversales
Une préoccupation est l’abstraction d’un but particulier ou une unité modulaire d’intérêt. Un
système typique admet principalement deux types de préoccupations : des préoccupations
fonctionnelles et des préoccupations techniques (non fonctionnelles). Dans [17], nous
trouvons comme exemple un cas de contrainte d’intégrité référentielle : un objet client ne peut
être supprimé s’il n’a pas honoré toutes ses commandes. Comme la classe Client n’est pas
censée connaitre les contraintes imposées par les autres classes et que la classe Commande
n’a aucune raison de permettre la suppression d’un client, nous nous retrouvons face à un
problème quant à la séparation indépendante des tâches. C’est ce que l’on appelle une
fonctionnalité transversale (crosscutting concern). Alors que le découpage des données en
classes a pour but de rendre les classes indépendantes entre elles, les fonctionnalités
transversales telles que les contraintes d’intégrités référentielles viennent se superposer à ce
découpage et brisent l’indépendance des classes [21].
8.1.2 Dispersion du code

En programmation orientée objet, on peut noter une différence entre les services offerts par
une classe et les services utilisés (respectivement les méthodes et les appels de méthodes).
Alors qu’il est facile de rassembler des services offerts dans une classe, il est impossible de
rassembler l’utilisation d’un service. Ainsi, l’implémentation d’une méthode est clairement
localisée (puisqu’elle est dans une classe), alors que les appels vers celle-ci se retrouvent
dispersés dans différentes classes. Dés lors, la modification de la méthode est aisée mais pas
la modification de sa signature [21].
Une modification de la signature d’une méthode implique la modification de toutes les classes
invoquant cette méthode, ce qui rend la maintenance et l’évolution du code difficile. Outre le
problème de mélange de code, la réutilisation d’une propriété non-fonctionnelle est d’autant
plus difficile que sa définition se trouve dispersée. De ce fait, elle ne peut être isolée pour être
réutilisée. En effet, une même propriété non-fonctionnelle peut toucher plusieurs objets [62].
8.2 Concepts de la programmation orientée aspect

Dans cette sous-section, nous introduisons les concepts de ce nouveau paradigme. Nous
expliquons les constituants de l’aspect, comme les ‘points de jonction’, les coupes, le ‘code
advice’, ‘Tissage d’aspects’, ‘Mécanisme d’introduction’ .
50
QoS et POA
8.2.1 Aspect
La POA propose l’utilisation d’aspects qui permettent d’implémenter des fonctionnalités
transversales, ou dont l’utilisation s’avère dispersée dans le code, en intégrant aux classes des
éléments (comme des méthodes ou des données) supplémentaires. L’intégration de ces
éléments supplémentaires dans les classes se fait au moyen de codes advices et de coupes qui
permettent de spécifier le code de la fonctionnalité et où celui-ci va s’appliquer. Ainsi, les
aspects résolvent le problème d’indépendance des classes puisqu’ils se chargent des
fonctionnalités transversales et permettent de réduire la dispersion de code dont nous avons
parlé grâce à une localisation de l’utilisation des services [62].
8.2.2 Point de jonction

Les aspects définissent les endroits du code où ils vont intégrer les fonctionnalités
transversales. Cette spécification se réalise à l’aide de coupes qui sont elles-mêmes spécifiées
à l’aide de points de jonction. Un point de jonction est un point dans l’exécution d’un
programme autour duquel un ou plusieurs aspects peuvent être ajoutés. Il représente un
événement dans l’exécution du programme qui peut être intercepté pour exécuter un code
advice correspondant. Pour cela, plusieurs types d’événements peuvent faire figures de points
de jonction :
• Méthode : Les méthodes sont les éléments principaux qui structurent l’exécution des
programmes orientés objets.
• Constructeur : Les constructeurs peuvent être considérés comme des méthodes
particulières. Il s’agit de méthodes invoquées lorsqu’un objet est instancié.
• Attribut : La lecture et la modification d’attributs constituent également des points de
jonction.
• Exception : Les événements de levée et de récupération d’exceptions peuvent aussi
constituer des points de jonction. Le code à exécuter lors de la levée de cette exception
sera défini dans un aspect.
8.2.3 Coupes
Une coupe désigne un ensemble de points de jonction [21]. Points de jonction et coupes sont
conceptuellement fort différents. Alors qu’un point de jonction représente un point dans
l’exécution d’un programme, une coupe est un morceau de code défini dans un aspect, c’est à
elle qu’est attribué le rôle de définir la structure transversale d’un aspect.
51
QoS et POA
8.2.4 Advice
Un aspect définit une fonctionnalité transversale. Comme nous l’avons vu, il spécifie le
caractère transversal grâce aux coupes. La fonctionnalité est, quant à elle, spécifiée par des
codes advices.
Un code advice définit donc un bloc de code qui va venir se greffer sur les points de jonction
définis par la coupe à laquelle il est lié. Un aspect nécessite souvent plusieurs codes advices
pour caractériser la fonctionnalité transversale. Il y a différentes manières de greffer un code
advice sur un point de jonction. Les trois principaux types de greffe de codes advices sont :
– Avant les points de jonction
– Après les points de jonction
– Autour des points de jonction
8.2.5 Tissage d’aspects

Comme nous l’avons vu, les aspects définissent des morceaux de code et les endroits de
l’application où ils vont s’appliquer. Un traitement automatique est donc nécessaire pour
intégrer ces aspects dans l’application afin d’obtenir un programme fonctionnel fusionnant
classes et aspects. Cette opération se nomme le tissage (weaving) et il est réalisé par le tisseur
d’aspects (aspect weaver).
8.2.6 Mécanisme d’introduction

Le mécanisme d’introduction de la POA permet d’étendre des classes en y ajoutant des
éléments. Ces éléments sont essentiellement des attributs ou des méthodes, mais ce ne sont
pas les seuls exemples. AspectJ propose notamment l’ajout d’interfaces Java et même l’ajout
d’une superclasse.
A la différence de l’héritage en POO, l’introduction ne peut étendre les classes qu’en rajoutant
de nouveaux éléments, il n’est donc pas possible de redéfinir une méthode, par exemple.
8.3 Aperçus sur le langage AspectJ

AspectJ est Le langage de POA le plus utilisé, il ajoute des mots clés au langage Java qui est
actuellement le plus utilisé pour la programmation par aspects. Les deux projets les plus
avancés sont AspectJ et JAC. Il s’agit en fait de tisseurs pour l’aspect avec un environnement
de programmation [62].
52
QoS et POA
Un aspect est une entité logicielle qui capture une fonctionnalité transversale à une
application. Des aspects pour AspectJ sont déclarés dans des fichiers avec extension .aj.
Comme Java, les aspects peuvent être définis dans une classe. A la différence de Java, l'aspect
ne doit pas avoir le même nom que la classe qui le contient ni celle de la classe Java auquel il
sera appliqué.
Les aspects sont déclarés comme les classes:

public aspect monAspect {}[21]
Un aspect est défini dans un fichier qui porte le même nom que celui de l’aspect. Ce fichier
porte l’extension .java, mais il peut porter aussi l’extension .aj ou .ajava. En général, .aj ou
.ajava sont utilisés pour désigner les fichiers aspects et .java pour désigner les fichiers classes.
8.4 Apport de la POA à l’adaptation de DM

Nous proposons de voir l’adaptation comme une propriété non fonctionnelle assurée par un
aspect. Des approches [89], [90], [91], [92] permettant la séparation des préoccupations
fonctionnelles ont été proposées dans le but de capitaliser les besoins fonctionnels dans des
entités modulaires. Dans cette perspective plusieurs idées ont été proposées.
Parmi les architectures logicielles pour l’adaptation de DM on trouve les architectures
logicielles à base de composants, qui présentent l’intérêt de permettre le raisonnement sur des
applications multimédia à un niveau abstrait. Les propriétés fonctionnelles et/ou non
fonctionnelles peuvent concerner des composants assemblés dans les architectures ou bien les
assemblages eux-mêmes.
L’adaptation qui représente l’objet de notre travail est l’une des propriétés non fonctionnelles
à développer, et que doivent par des aspects. Ce choix est justifié du fait que l’adaptation est
un problème générique qui n’est pas lié à un utilisateur spécifique.
Dans notre travail de recherche, nous présentons une approche de programmation orientée
vers l'aspect qui réduit considérablement ces efforts d’adaptation de DM. La POA permet aux
développeurs d'étendre facilement les politiques d’adaptation de DM existants avec la
capacité de transmission de données efficace sans modifier les documents d'origine, tout en
conservant les avantages d’adaptation.
9. Conclusion
Dans ce chapitre, nous avons présenté et comparé les architectures de fourniture de contenus
multimédia adaptables existantes par rapport aux fonctionnalités de base qu’elles réalisent (la
53
QoS et POA
gestion du contexte, la gestion des contenus multimédia, la gestion de la prise de décision
pour l’adaptation et la gestion des préférences des utilisateurs pour une QoS satisfaisante).
Toutes ces architectures proposent des solutions différentes pour répondre aux besoins
fondamentaux de l’adaptation de contenus multimédia. Cependant, nous constatons que
certains besoins ne sont pas ou que partiellement atteints telles que la prise en compte des
préférences de l’utilisateur et des caractéristiques spécifiques d’utilisateur comme le handicap,
ou encore la prise en compte de contenus multimédia riches et composés.
Nous avons présenté aussi quelques concepts de la POA pour les utiliser dans l’adaptation des
données multimédia en fonction des contextes, ce qui permet d’avoir les services nécessaires
pour mettre en place une politique d’adaptation des flux multimédia.
54
Un modèle formel d’adaptation
de document multimédia pour
Chapitre
gérer la QoS
03
1. Introduction
Aujourd'hui, afin de pouvoir fournir et consommer des contenus multimédia de manière
transparente, il est important de disposer d’une infrastructure d'adaptation. Sans une telle
infrastructure, les créateurs de contenus et les fournisseurs de services sont confrontés à
plusieurs problèmes pour fournir un contenu multimédia à leurs consommateurs.
Une infrastructure d’adaptation nécessite une description des contenus multimédia et du
contexte de l’utilisateur ainsi qu’un ensemble d’informations guidant le processus
d’adaptation.
De plus nous devons faire face aujourd'hui à une demande grandissante pour des DMs de plus
en plus riches et personnalisés. Le défi est de pouvoir proposer ces documents qui s'adaptent
tant aux souhaits des utilisateurs qu'à l'environnement physique. Avec l'arrivée des approches
formelles, ce type de document et l’adaptation de ce dernier doivent être représentés par des
concepts formels. La présentation formelle de tels DMs devient une nécessité et elle permet
de proposer aux utilisateurs des services mieux adaptés à leur situation courante et à leurs
préférences.
Après avoir dressé un état de l’art sur les différents concepts liés aux
applications et aux DMs, nous essayons d’utiliser ces concepts pour
pallier aux limites de présentation et d’adaptation de DM.
Dans ce chapitre, notre objectif est la présentation formelle des concepts
de la technique d’adaptation de DMs qui est une étape très important dans
le processus de présentation. A travers cette présentation, nous essayons
55
d'améliorer cette technique en tenant compte des préférences de l'utilisateur, car l'adaptation
du contenu multimédia via les préférences des utilisateurs est un aspect important de la qualité
de service.
Notre travail de recherche comporte deux contributions qui recouvrent les
principales étapes d’adaptation en commençant par la présentation formelle
des concepts d’adaptation. Puis, nous proposons une architecture de
fourniture de contenus multimédia adaptables au contexte des utilisateurs,
qui sera présentée dans le quatrième chapitre.
2. Motivations
Les problèmes de gestion de QoS et d’adaptation de DM ne sont pas nouveaux
car ils constituent des domaines de recherche auxquels s'intéressent
plusieurs communautés dont celle des applications multimédia, celle des
systèmes pervasifs, etc. Plusieurs approches, standards et/ou technologies
ont été proposés pour résoudre ces problèmes. Dans le cas où un DM ne
satisfait pas un profil plus particulier des préférences d’un
utilisateur, une solution consiste à adapter automatiquement ce document,
c’est-à-dire lui faire subir un ensemble de transformations lui permettant
de s’exécuter correctement compte tenu d’un profil donné et des
préférences. Pour garantir une qualité d’adaptation, un ensemble de
concepts doivent être définis.
Dans le cadre de nos travaux, nous considérons la présentation formelle d’adaptation comme
une étape essentielle incluant les préférences de l’utilisateur (en se basant sur le principe de
Pham Hai Q et al. [64]) tout en nous focalisant sur les conflits d’adaptation, et nous décidons
qu'il est préférable de gérer l’adaptation de DM par rapport aux préférences de l’utilisateur.
Quand un conflit est détecté entre les propriétés de DM et les profils de l’utilisateur et les
préférences, une technique est définie pour sélectionner les meilleures politiques d’adaptation
résolvant ces conflits.
Dans le chapitre 2, nous avons présenté quelques travaux relatifs aux
architectures d’adaptation. Ces travaux ne définissent pas une
présentation formelle de DM, ils ne proposent pas une séparation des
56
préoccupations, et ils ne spécifient pas une démarche complète pour
l’adaptation de ces documents. C’est ce qui a attiré notre attention.
Cependant, certains chercheurs formulent et définissent quelques concepts.
La première critique que nous pouvons apporter au travail de Pham Hai Q et
al. [64] est qu’aucun concept n’a été présenté pour gérer la qualité de
service et de minimiser le nombre des conflits.
Dans ce chapitre, nous présentons une modélisation formelle des concepts
d’adaptation de DM pour gérer les conflits.
3. Fondements de notre approche

L’adaptation de DMs permettant leur exécution sur n’importe quel terminal représente un vrai
défi. Les solutions proposées actuellement ne s’attaquent pas au problème de l’adaptation de
la composition des DMs de manière complète, mais essaient de fournir des solutions, souvent
manuelles ou explicites, face à des ensembles de contraintes d’adaptation très spécifiques. Ces
solutions sont aussi très souvent basées sur des langages de description de DMs rendant
l’adaptation plus ou moins flexible [1].
Par conséquent, il apparaît important de rendre l’adaptation plus indépendante face à tous les
systèmes de négociation de DMs et plus flexible pour ainsi couvrir de nombreuses contraintes
d’adaptation et notamment celles qui portent sur la composition des DMs. De plus, nous
remarquons que les approches existantes ne couvrent pas tous les types de contraintes
d’adaptation et offrent des stratégies d’adaptation explicites.
Pour que les documents soient correctement présentés sur chaque appareil il est nécessaire de
les adapter. Nous nous intéressons plus particulièrement aux DMs, c’est-à-dire des documents
structurés qui contiennent plusieurs médias.
Notre chapitre propose d’abstraire les DMs en une structure exprimant l’ensemble des objets
du document ainsi que leurs propriétés et les préférences de l’utilisateur. Puisque les conflits
entre objets sont détectés entre certaines propriétés de DMs et contraintes du profil, nous
proposons de minimiser le nombre pour présenter un document adapté. L'idée de base de
notre proposition est la suivante. Tout d'abord, un utilisateur demande un DM. Les propriétés
de contenu du document et des caractéristiques du profil de l’utilisateur sont comparées afin
de détecter quelque conflit. Puis, à partir de l'ensemble des préférences de l’utilisateur, un
algorithme détermine lequel des politiques d'adaptation doivent être exécutées afin de
57
transformer le document initial. Enfin, la QoS est estimée et le document adapté est fourni à
l'utilisateur.
4. Concepts formels d’adaptation de documents multimédia

Les composants de notre système collaborent pour maximiser la QoS. Un système de
distribution devrait utiliser des méthodes d'adaptation qui préservent la sémantique de
contenu. Un DM peut être composé de différents types de contenus, comme des vidéos, du
son, des textes et des images [61]. Des exemples typiques sont les pages Web, qui
comprennent des séquences de la vidéo, du son, d’image et/ou du texte.
Dans un travail antérieur [87], nous avons défini un ensemble de concepts liés à la
technique d'adaptation des DMs. Dans cette section, nous proposons un modèle complet avec
extension de leur définition avec une représentation formelle basée sur le travail de Pham Hai
et al. [64], accompagné des règles qui doivent être respectées pour la mise en œuvre du
mécanisme d'adaptation.
4. 1 Définition 1: Document Multimédia (MD)

Un document multimédia (MD) est un ensemble de médias mi. Plus formellement:
MD = {mi / 1 <i <N_cm} (1)
Où N_cm représente le nombre total de contenus multimédias. Un MD est toujours décrit

comme un assemblage par un scénario spécifié, appelé média statique traditionnel (texte,
image), ainsi qu'un support continu (audio et vidéo).
Cet ensemble devrait respecter les règles suivantes:
- Règle 1: Le nombre d'éléments de média dans un document doit être fini.
- Règle 2: Si un document ne contient qu'un seul type de support (texte ou seulement images)
l'adaptation est faite par ordre ou aléatoirement.
Par exemple, un DM peut contenir trois images, une vidéo, deux textes, un de type son. Afin
de faire une différence entre les différents types de médias, nous utilisons ii pour les images,
vi pour les vidéos, ti pour les textes et si pour le son.
MD = {i1, i2, i3, v1, t1, t2, s1}
L'utilisateur peut préférer certains objets média à d'autres. Ces informations sont généralement
spécifiées dans les Préférences de l’Utilisateur (UP) (voir Définition 4.2). Un document peut
se référer à un ensemble de propriétés dont chacune est liée à un média spécifique. Ces
58
informations sont généralement spécifiées dans les Propriétés des Médias (MP) (voir
Définition 4.3).
4. 2 Définition 2: Préférences de l'Utilisateur (UP)

Dans le DMM, il existe de nombreux types d'objets multimédia, mais l'utilisateur peut
préférer certains types à d'autres. Le rôle de la Préférence d’Utilisateur (UP) est de permettre
à l'utilisateur de gérer le processus d'adaptation.
Nous offrons à l'utilisateur une échelle de préférence uj ϵ [0..4] (4 le nombre de type de
média). Elle est utilisée pour attribuer une priorité à chaque type de support. L'utilisateur met
zéro pour les formats non prioritaires (il donne zéro pour les formats qui ne sont pas sur le
document et il ne veut pas faire des adaptations sur elles).
UP = {mi ϵ MD / (mi, uj)} (2)

Cet ensemble devrait vérifier les règles comme suit:
- Règle 1: Si l'utilisateur donne la même valeur de préférence à tous les médias (valeur non
nulle), alors l'adaptation sera faite sans la préférence de l'utilisateur.
- Règle 2: Si l'utilisateur donne une valeur de préférence nulle à tous les types de média, alors
un message d’erreur sera affiché.
- Règle 3: Si l'utilisateur donne la même valeur de préférence à deux types de médias, alors un
politique de conflit de service d'adaptation (voir Définition 4.7) s'appliquera.
- Règle 4: Si l'utilisateur oublie de donner une valeur de préférence à un type de support, alors
une valeur de zéro sera affectée.
Par exemple, l'utilisateur veut voir le document MD sur son ordinateur portable et l'imprimer,
de sorte qu'il donne aux médias les valeurs priorité suivantes : u1 = 3 pour l'image, u2 = 4 pour
le texte et mettre 0 à u3, u4 pour la vidéo et le son.
UP = {(i1, u1), (i2, u1), (i3, u1), (v1, u3), (t1, u2), (t2, u2), (s1, u4)}.
Notre technique a besoin de trouver la meilleure adaptation du DM, optimisé en termes de

temps ou coût de service, qui peut fournir les demandes aux utilisateurs.
4. 3 Définition 3: Propriétés des médias (MP)

Les Propriétés de Média (MP) est un ensemble de propriétés pq qui référencent les médias.
Plus formellement:
59
MP = {mi∈ MD / (mi, pq = vmp)} (3)
Où 1≤q≤N_mp, N_mp correspond au nombre total de propriétés du média, telles que les
formats, les tailles et les langues des médias.
Cet ensemble devrait respecter les règles suivantes:
- Règle 1: Un ensemble est fini.
- Règle 2: Toutes les propriétés des médias doivent être connues.
Par exemple, un DM peut contenir:
- Images {format = BMP}.
- Texte {language = fr}.
- Vidéo {format = avi, language = fr}.
- Son {format = mp3, language = fr}.
4. 4 Définition 4: Contexte de l'utilisateur (UC)

Un contexte utilisateur (UC) est un ensemble de contraintes ck, qui sont liées à un dispositif et
/ ou des contraintes utilisateur. Il se compose de trois profils (voir chapitre 4, section 3). Plus
formellement:
UC = {ck / (ck = vuc)} (4)
Lorsque 1≤k≤N_c, N_c est le nombre total de contraintes et vuc est la valeur des contraintes de
périphérique qui doit être satisfaite afin d'exécuter correctement un DMM.
Cet ensemble doit vérifier les règles suivantes:
- Règle 1: Un ensemble est terminé.
- Règle 2: Toutes les contraintes de contexte utilisateur doivent être connues
Par exemple, le contexte de l'utilisateur peut spécifier que:
c1 = (type-device = ordinateur portable)
c2 = (résolution des médias <résolution du périphérique)
c3 = (vidéo-format = mov)
c4 = (média-langage = arabe)
c5 = (image-format = JPEG)
c6 = (son format = non).
Par conséquent, afin d'exécuter correctement un DM sur un dispositif spécifique et de

satisfaire les préférences de l'utilisateur (QoS pour l'utilisateur). Chaque média mi qui a un uj
supérieur à zéro doit vérifier la condition suivante: Chaque propriété média pq doit se
60
conformer à une contrainte ck spécifiée dans UC. Si cette condition n'est pas satisfaite, un
conflit de propriété de média (MPC) (voir définition 4.5) est détecté.
4. 5 Définition 5: Conflit de la Propriété des Médias (MPC)
Un Conflit des Propriétés de Media (MPC) est un triplet <p, m, c>. Plus formellement:
MPC = {xf / <pq, mi, ck>} (5)
Lorsque pq est une propriété liée à un élément média mi (ou à l'ensemble du document), telle
que la valeur de pq ne soit pas conforme à la contrainte ck [64]. Nous considérons uniquement
le conflit créé pour le média avec une valeur de UP supérieure à zéro (uj> 0).
Cet ensemble doit vérifier les règles suivantes:
- Règle 1: Le nombre de conflits est limité.
- Règle 2: Le conflit doit être pour un média dont la valeur de UP est supérieure à zéro.
- Règle 3: Les conflits doivent être ordonnés selon UP.
- Règle 4: Le conflit est entre une propriété média et une contrainte utilisateur.
Prenons les exemples donnés dans les définitions 4.1, 4.2, 4.3 et 4.4. Trois conflits peuvent
être détectés entre les propriétés des médias et le contexte de l'utilisateur: x1 = <format =
BMP, i, image_format = JPEG> pour les trois images dans le document, x2 = <language= fr,
t1, language = ar>et x3 = <Résolution = HighRes, i, deviceRes> pour les trois images. Pour
résoudre ces conflits, il existe des Services d’Adaptation (AS) (voir Définition 4.6) qui
peuvent transformer le document initial en un autre adapté aux préférences de l'utilisateur.
4. 6 Définition 6: Service d'Adaptation (AS)

Nous avons enrichi le service d'adaptation avec le paramètre coût pour évaluer l'adaptation
pour choisir le conflit adapté quand il y a un choix entre les conflits. Il devient un 7-tuple:
AS = <id, inp, outp, ap, at, w, qos> (6)
• id: un identifiant de service (par exemple, un URI).

• Paramètres d'entrée (inp): les caractéristiques du contenu qui seront traitées par le service.
• Paramètres de sortie (outp): les caractéristiques de contenu adapté qui seront calculées par le
service.
61
• Propriété d’Action (ap): la propriété de document que le service est en train de modifier.
• Type d'action (at): un service d'adaptation gère trois types d'actions:
oTranscodage: il modifie le format d'un contenu multimédia dans l'autre, tout en préservant
le type de support, par exemple, une image JPEG modifiée à une image PNG.
oTransmodage: il modifie le type de contenu multimédia dans un autre, par exemple, un
contenu textuel modifié à un contenu audio.
o Transformation: elle modifie le contenu des médias, tout en préservant le format et le
type de médias, par exemple, la modification d'une résolution d'image PNG.
• Poids (w): elle correspond à la disponibilité actuelle du service.
• propriétés de QoS (QoS): démontrer la qualité de service de média adaptés.
- coût: le coût de ce service d'adaptation.
-temps: le temps de ce service d'adaptation.
-espace: l'espace des médias adaptés.
Un conflit peut être résolu par un AS dans lequel, nous pouvons utiliser une séquence de
services et calculer, en même temps, le coût et le temps de l'adaptation.
Le tableau 3.1 présente un exemple de AS appelé ADP, où le coût du service est en DA et le
temps de service est en ms.
Tableau 3.1 Exemple de AS, Paramètres d'entrée et Paramètres de sortie
service Propriété Paramètres Paramètres Propriété de Qos

d’Adaptation d’Action d’entrés de sorties
coût Temps
ADP1 Format BMP JPEG 2 128
ADP2 Langage FR AR 4 64
ADP3 Résolution JPEG JPEG 3 250
ADP4 Format AVI MP4 8 300
ADP5 Type MP4 MOV 5 125
4. 7 Définition 7: Conflit de Service d’Adaptation (ASC)
Un Conflit de Service d’Adaptation (ASC) est appliqué s'il existe un conflit entre l'ordre de
résolution de MPC pour les médias qui ont la même valeur de préférence, nous définissons
une politique qui nous permet d’ordonner les MPCs en utilisant : maximum préférence de
l’utilisateur, minimum coût ou temps.
ASC = Max (UserPreferences), Min (QosProperty) (7)
62
Le Conflit de Service d'Adaptation (ASC) peut être détecté dans les cas suivants:
- Cas 1: Si l'utilisateur donne une même valeur de préférence à plus d'un type de support.
- Cas 2: S'il existe plusieurs médias du même type (par exemple image: i1, i2 ...).
Nous proposons cette équation pour fournir aux utilisateurs un DM contenant plusieurs
médias (Min (QosProperty)) et les médias les plus préférables pour eux (Max
(UserPreferences)).
4. 8 Proposition: Services de Dépendance (SD)

Les deux services d'adaptation nommés ADP4 et ADP5 peuvent avoir une dépendance de
service(SD) (par exemple, ADP4--> ADP5) si les paramètres de sortie de l’ADP4
correspondent aux paramètres d'entrée de l’ADP5. A partir de ces SDs, une représentation
graphique peut être utilisée afin de représenter toutes les combinaisons possibles entre les
ASs. Par conséquent, les chemins du graphe sont créés en faisant correspondre les paramètres
d’entrée et de sortie d’ADP, jusqu'à ce que les paramètres de sortie soient égaux au contenu
adapté. Dans le scénario où nous avons un nombre total d’ADP est égal à cinq, nous
supposons que les paramètres d'entrée et de sortie pour chaque ADP sont comme dans le
tableau 3.1. Le coût des services est en DA et de temps de service en ms.
Figure 3 .1Graphe d’adaptation des scenarios
Ainsi, en fonction de leurs paramètres d'entrée et de sortie, les services d'adaptation peuvent
être enchaînés afin de résoudre un conflit spécifique par trouver un chemin dans le graphe de
63
représentation des dépendances de service. Le graphe d’adaptation pour le scénario est
semblable à la Figure 3.1, qui contient trois chemins différents. Nous avons effectué une
comparaison de l'adaptation en utilisant notre technique et celle fournie dans [81] (voir le
tableau 3.2).
Les résultats du tableau 3.2 sont obtenus en utilisant l'algorithme présenté à la Figure 3.2 et
les données du tableau 3.1.
Tableau 3.2 Comparaison de l'adaptation en utilisant notre technique et la technique de

(Shahidi M. et al, 2010) [81]
(Shahidi M.et Our technique
chemin Conflit de la service Coût Temps al,2010) [81]
propriété des d’adaptation Coût Temps Coût Temps
médias
Path1 X1 ADP1,ADP3 5 378
22 867 9 442
Path2 X2,X3 ADP2 4 64
Path3 ADP5,ADP6 13 425
4. 9 Définition 9: Chemin d'Adaptation (AP)
Un chemin d'adaptation (AP) est une chaîne de services d'adaptation qui permet de résoudre
un conflit. Cette chaîne doit satisfaire les conditions suivantes:
• Le nœud de démarrage représente le contenu multimédia d'origine.
• Le nœud de fin représente le DM adapté pour l'utilisateur.
• Le premier chemin doit contenir la valeur maximale des préférences de l'utilisateur de
médias.
• Le premier élément de chemin doit être capable d'effectuer le DM d'origine.
• Le chemin doit contenir un service d'adaptation qui permet de résoudre le conflit.
• Le dernier élément de chemin ne doit pas introduire de nouveaux conflits.
• La valeur totale de la propriété de la QoS doit être inférieure ou égale à la valeur donnée par
l'utilisateur.
Pour chaque conflit, plusieurs chemins d'adaptation peuvent être spécifiés. Certes, différentes
stratégies peuvent être déterminées afin de sélectionner les meilleures solutions (par exemple,
64
plus court chemin, valeur minimale de propriété QoS, en préservant les types de média
d'origine). Évidemment, quand tous les conflits ont été résolus, cela signifie que l'appareil est
capable d'exécuter correctement le DM adapté.
5. Propriétés du graphe d’adaptation

La méthode de conception que nous détaillons dans la présente section permet de décrire les
propriétés de graphe d’adaptation (voir Figure 3.1). Elle consiste à identifier les rôles que
possèdent un graphe d’adaptation puis les liens entre ces rôles. Les rôles décrivent des
adaptations pouvant être réalisées par une ou plusieurs politiques d’adaptation. Les arcs
représentent les flux de média que les rôles échangent afin de réaliser leur adaptation. Cette
méthode se base sur une représentation des spécifications fonctionnelles à l’aide de graphes
d’adaptations.
L’objectif de cette section est de montrer que cette méthode d’adaptation impose la définition
de deux entités fonctionnelles nécessaires pour l’adaptation. La première entité sera définie
pour la définition des nœuds. Elle correspondra à la notion d’adaptateur. La seconde entité
permettra de transporter les flux de médias entre les nœuds, elle correspondra à la notion
d’arc. Ainsi, à l’aide de ces entités nous pourrons définir un graphe d’adaptation comme une
interconnexion de nœuds (politique d’adaptation) et des arcs. Ces nœuds sont utilisés pour
décrire l’adaptation comme un ensemble des politiques d’adaptation interagissant entre eux.
5.1 Rôles
Dans la structure d’un graphe telle que nous l’avons définie, chaque nœud participe à la
réalisation d’une adaptation et donc permet d’améliorer la QoS.
Nous appelons rôle une fonction identifiable rendue par un ensemble d’adaptateurs. Cette
abstraction est utilisée par les graphes d’adaptation. Nous appelons rôle atomique une
fonction qui peut être rendue par un seul adaptateur.
En général, les sous-groupes constituent une QoS d’une adaptation. Ceci traduit le fait que la
QoS introduite peut être observée par les utilisateurs. Ces sous-groupes incorporent donc des
adaptateurs identifiables. Ainsi, nous définissons un rôle observable comme un rôle associé à
un adaptateur observable. Grâce à ce type de ce dernier, les utilisateurs peuvent percevoir la
QoS rendue, ils remplissent par conséquent un rôle essentiel. Les graphes sont donc composés
d’un ensemble de rôles pour l’adaptation représentés par des nœuds.
5.2 Nœuds
65
Les nœuds sont notés ni ϵ N, où N est l’ensemble des nœuds du graphe. Chaque nœud
représente l’un des rôles de graphe d’adaptation.
Ces graphes sont polaires, c’est-à-dire ils introduisent deux nœuds fictifs appelés nœud
source, noté E, et nœud puit, noté S. Ces deux nœuds sont reliés respectivement aux premiers
et derniers nœuds de graphe d’adaptation. Ils représentent de manière conceptuelle l’origine et
la destination des flux de médias dans un DM. Les autres nœuds du graphe sont des
successeurs et des prédécesseurs des nœuds sources et puits. Les nœuds des graphes sont
reliés entre eux par des flux de média représentés par des arcs.
5.3 Arcs
Les arcs sont notés aijϵ A ou A est l’ensemble des arcs du graphe. aij représente l’arc qui sort
du nœuds ni et qui rentre dans le nœud nj. Ces arcs symbolisent les échanges d’informations
entre les rôles d’un graphe d’adaptation. Ils représentent les flux de média de DM. Nous
symbolisons de la sorte les dépendances entre les rôles à respecter lors des choix d’adaptation
offrant des niveaux de QoS différents.
6. Construction du graphe d’adaptation

Un graphe d’adaptation est un ensemble d’adaptateurs assemblés en parallèle ou en séquence.
Ce graphe est utilisé en entrée du gestionnaire d’adaptation. Celui-ci recherche les
adaptateurs, les instancie, les compose, et si cela est nécessaire, les recompose dans le cas où
un ou plusieurs adaptateurs n’existent pas. Il gère également la disparition des adaptateurs
instanciés.
Les graphes sont orientés selon la direction des flux de données. Tous les chemins du graphe
trouvent leur origine dans le nœud source et se dirigent vers le nœud puits. Les graphes sont
donc composés d’un ensemble de politiques d’adaptation représentées par des nœuds.
Les nœuds sont notés ADPiϵ P, où P est l’ensemble des nœuds du graphe. Chaque nœud
représente une politique d’adaptation.
7. Recherche des Conflits

La recherche des conflits est effectuée entre les propriétés du média et le contexte de
l’utilisateur. Nous cherchons l’inégalité entre les propriétés de chaque média et le contexte de
l’utilisateur. Mais avant de commencer cette étape, nous éliminons les média qui ont une
valeur de préférence égale à zéro (c’est-à-dire on supprime les médias de la liste des DMs
66
même si le type et la forme de media sont accordés avec le contexte de l’utilisateur). Ensuite
nous trions les medias par rapport à sa valeur de préférence. Nous traitons séparément les
conflits liés au chaque type de média. Ainsi, grâce à ces sous-ensembles de conflits, il est
maintenant possible de rechercher des politiques d'adaptation en parallèle.
8. Processus d’adaptation de document multimédia

À partir d'un ensemble de conflits entre un DM et les propriétés d’un profil, nous avons
spécifié une procédure qui récupère et combine les politiques d'adaptation pertinentes. Les
principales étapes de cette procédure sont présentées comme suit:
Étape 1: Eliminer les médias non préférés.

Pour chaque média, l’utilisateur donne une valeur de préférence. Les médias mi, ayant une
valeur de préférence de l'utilisateur uj égale à zéro, seront éliminés de la liste UP. Cette
élimination permet de minimiser le nombre de conflits.
Étape 2: Regrouper les conflits liés au même média en sous-ensembles.

La recherche des conflits s’effectue entre les propriétés du média (Définition 4.3) et le
contexte de l’utilisateur (Définition 4.4). Nous trouvons les conflits pour chaque média. Nous
allons traiter séparément les conflits liés au chaque type de média. Ainsi, grâce à ces sous-
ensembles de conflits, il est maintenant possible de rechercher dans certains politiques
d'adaptation en parallèle.
Étape 3: Rechercher les services d'adaptation qui pourraient résoudre les conflits.
Pour chaque xf non résolu identifié lors de l'étape 2, nous vous proposons de rechercher un
AS qui permet de résoudre directement ce dernier. Comme présentée dans la section 4, la
propriété pq impliquée dans un conflit est testée avec l’action property de tous les services
d’adaptations, puis avec la QoSproperty demandée par le client.
La notion de conflit est ici aussi très utile car elle permet de récupérer rapidement des services
d'adaptation (avant de chercher des voies d'adaptation possibles). Il peut également éviter
67
d’informer un utilisateur dans le cas d'un DM qui ne peut pas être correctement présenté sur
son appareil par l’utilisation des valeurs de préférences.
Etape 4: Définir des chemins d'adaptation pour la production d'un DM adapté.

Pour chaque sous-ensemble de conflits liés à un média, nous calculons un chemin d'adaptation
afin de présenter en outre un contenu adapté. Pour déterminer les chemins d'adaptation, nous
avons utilisé la politique présentée dans la définition 4.7 explorant les possibilités de
combinaison des services qui ont été préalablement sélectionnés pour résoudre les conflits.
Bien sûr, cet algorithme exploite les dépendances de services, par exemple, ceux qui sont
illustrés dans la Figure 3.2. En outre, il vérifie le critère défini dans les définitions 4. 6, 4.7 et
4.9:
• Il vérifie si les paramètres d'entrée du premier service dans la chaîne satisfaisant toutes les
propriétés de médias impliqués dans le conflit;
• Il vérifie si les paramètres de sortie du dernier service de la chaîne sont conformes avec les
contraintes de profil, à savoir, il ne crée pas de nouveaux conflits.
9. Algorithme d’adaptation de document multimédia

Nous proposons un algorithme qui fournit toutes les solutions d’adaptation qui satisfont un
profil cible et les préférences de l’utilisateur et qui sont proches d’une spécification de DMs
initial. Cet algorithme est basé sur une technique de séparation/ adaptation des médias,
Algorithme : Adaptation de document multimédia
Début
QoS-pref <= y; /* y est la valeur de la propriété préférée par l'utilisateur */
QoS-v=0; i=0; /* Qos-v Calculer */
Etape 1: SearchMax (UserPreferences) in UP; /* Rechercher les médias qui ont une valeur de
préférence utilisateur maximal*/
Si Nbr-media = 0 Alors, aller à Etape 5; /*Nbr-media, Nombre des médias trouvés */
Si Nbr-media = 1 Alors, aller à Etape 2;
Si Nbr-media >= 1 Alors, aller à Etape 3; /* Si plusieurs médias ont la même valeur de préférence
d’utilisateur */
Etape 2: Si ((i<= N_mc) et (QoS-v<y) et (mi in MPC)) Alors aller à Etape 4;
/* N_mc, Le nombre total de contenus multimédia*/
Sinon Si i> N_mc Alors aller à Etape 1;
Si Qos-v>=y Alors aller à Etape 5;
Si mi not in MPC Alors aller à Etape 4;
Etape 3: SearchMin (QosProperty) in AS; /*Rechercher les médias qui ont une valeur de propriété de
QoS minimal/
Si media-min=0 Alors aller à Etape 1;
68
Si media-min=1 Alors aller à Etape 4;
Etape 4: Si (mi in MPC) Alors SearchAdp (ADPj in AS, xi in MPC); /* Rechercher le politique
d’adaptation qui permet de résoudre le conflit xi*/
Qos-v=Qos-v+QoS-v(ADPj);
Si QoS-v<=QoS-pref Alors
{Path=Path U {ADPj}; /* Ensemble de service d'adaptation du chemin le plus court */
MD=MD-{mi};
i=i+1;
Aller à Etape 2;}
Sinon Aller à Etape 5;
Etape 5: return QoS-v, Path; /* Renvoie la QoSProperty calculée et le chemin le plus court trouvé */
Fin
Figure 3 .2 Algorithme général d'adaptation du MD aux préférences de l'utilisateur.
Dans cet algorithme, nous définissons trois méthodes de recherche qui sont SearchMax
(UserPreferences), SearchMin (QosProperty), SearchAdp (ADPj in AS, xi in MPC). Ces
méthodes nous permettant de trouver, respectivement, le type de media le plus préféré par
l’utilisateur, le media qui a la minimale valeur de propriété de QoS, le politique d’adaptation
adéquat à résoudre le conflit xi.
En entre, cet algorithme demande tous les ensembles des concepts définis dans la Section 4.
En sortie, il fournit comme résultat l’ensemble des politiques d’adaptation qui résolvent les
conflits avec une QoS maximale qu’il traduise les préférences de l’utilisateur.
10. Exemple d’application de notre approche

Afin de mieux cerner notre approche d'adaptation qui peut se présenter, imaginons le DM
suivant :
Ce document est composé de trois contenus vidéo, deux textes, trois images, et un son.
MD = {i1, i2, i3, v1, v2, v3, t1, t2, s1}
Dans ce cas elle choisit l’ordre de leur priorité défini est :

1. Images
2. Texte
0. Vidéo
0. Son
Donc, les valeurs de préférence pour chaque média sont les suivantes : u1=1, u2=0, u3=2,
u4=0. L’utilisateur veut voir le document MD sur sa tablette. Ainsi l’ensemble UP est défini
de le suivante :
UP = {(i1, u1), (i2, u1), (i3, u1), (v1, u2),(v2, u2), (v3, u2), (t1, u3), (t2, u3), (s1, u4)}.
69
Ce DM possède les propriétés des medias suivantes :
Images {format = JPEG}.
Texte {format=PS, language = fr}.
Vidéo {format = avi, language = fr}.
Son {format = mp3, language = fr}.
Le contexte de l'utilisateur peut spécifier ainsi:
c1 = (type-device = tablette)
c2 = (résolution des médias <résolution du périphérique)
c3 = (vidéo-format = mov)
c4 = (média-langage = arabe)
c5 = (image-format = PNG)
c6 = (son-format = WAV).
c7= (texte-format = PDF)
Dans cet exemple, cinq conflits peuvent être détectés entre les propriétés des médias et le
contexte de l'utilisateur: x1 = <format = JPEG, i, image_format = PNG>pour les trois images
dans le document, x2 = <language= ar, t, language = en>,x3 = <format = PS, t, texte-format
= PDF >, x4 = <format = MPEG, v, vidéo-format = MOV>et x5 = <format = MP3, s, son-
format =WAV>. Pour résoudre ces conflits, il y a des politiques d'adaptation capable de
transformer le document initial à un document adapté aux préférences de l'utilisateur. Ces
politiques d’adaptations sont présentés dans le tableau.
Tableau 3.3 Exemple de service d'adaptation (ADP).

Service Propriété Paramètres Paramètres Propriété de Qos
d’Adaptation d’Action d’entrées de sorties
Coût Temps
ADP1 Type PS TXT 7 50
ADP2 Type JPEG PNG 5 200
ADP3 Type MPEG MOV 9 250
ADP4 Type MP3 RA 8 120
ADP5 Langage AR EN 5 70
ADP6 Langage AR FR 4 64
ADP7 Type TXT PDF 7 50
ADP8 Type RA WAV 2 25
S’il y’a un conflit entre les services d'adaptation, nous utilisons la politique définie: la
préférence de l'utilisateur max, le coût ou le temps min selon le choix de l'utilisateur désigné
dans la préférence de l'utilisateur.
70
ASC = Max (UserPreferences), Min (QosProperty) (7)
Le coût des services est en DA et de temps de service en ms.
Figure 3.3 Graphe d’adaptation des scenarios de l’exemple
Ainsi, en fonction de leurs paramètres d'entrée et de sortie, les services d'adaptation peuvent
être enchaînés afin de résoudre un conflit spécifique pour trouver un chemin dans le graphe de
représentation des dépendances de service. Le graphe d’adaptation pour le scénario est
semblable à celui de la Figure 3.2, qui contient quatre chemins différents. Nous avons effectué
une comparaison de l'adaptation en utilisant notre technique et celle définie dans [81] (voir
Tableau 3.4).
Tableau 3.4 Comparaison d'adaptation de DM

(Shahidi M.et Our technique
Chemin Conflit de la Service d’Adaptation Coût Temps al,2010) [81]
propriété des Coût Temps Coût Temps
médias
Path1 X4 ADP3 9 250
Path2 X1 ADP2 5 200 43 765 24 370
71
Path3 X3,X2 ADP1,ADP7,ADP5 19 170
Path4 X5 ADP4,ADP8 10 145
11. Conclusion
Nous avons présenté dans ce chapitre la présentation formelle des concepts
d’adaptation de DM qui est à la base de notre technique d’adaptation.
Nous avons expliqué comment un DM et un contexte de l’utilisateur sont
comparés pour déterminer un conflit. Nous avons vu également comment
utiliser les valeurs de préférence de l’utilisateur pour minimiser le
nombre de conflits et construire le graphe d’adaptation.
Dans le chapitre suivant, nous allons mettre en exergue l’architecture
d’un système d’adaptation des DMs. Puis nous détaillons les principales
fonctionnalités de ses différents modules. Diverses techniques et méthodes
d’adaptation pouvant être utilisées pour l’adaptation de contenu et de la
structure du document existant : transcodage, transmodage et
transformation. Nous avons présenté aussi, comment nous avons utilisé la
programmation orienté aspect pour la gestion d’adaptation des DMs.
72
Une architecture d’Adaptation des documents
multimédia pour la gestion de QoS basée sur les
préférences de l’utilisateur
1. Introduction
Actuellement, les documents multimédia doivent pouvoir être exécutés sur de nombreuses
plates-formes (téléphones portables, PDA, ordinateurs de bureau, lecteurs de salon. . .). Cette
diversification des utilisations et des supports nécessite l’adaptation des documents à leur
contexte d’exécution, parfois imprévisible au moment de la conception du document.
Comme nous avons pu le constater dans les chapitres précédents, la présentation formelle de
DMs interprète chaque document comme un ensemble d’objets et de relations entre eux,
structurés dans un graphe d’adaptation. Ce graphe est par la suite utilisé dans l’adaptation en
fonction du profil d’une plate-forme cible.
La QoS est la principale préoccupation de l’utilisation, en particulier, dans le domaine des
applications multimédias. En effet, dans ce cas, le support essentiel, l’Internet, n’est pas
parfaitement adapté à la transmission des documents multimédia. Afin de résoudre ce
problème, nous plaçons la QoS au centre de notre méthode de conception. Ainsi, pour
continuer à assurer une QoS correcte à l’utilisateur malgré les variations du contexte
d’exécution, nous nous appuyons sur un développement à base de composants logiciels.
Dans le chapitre 2, nous avons présenté plusieurs architectures ayant pour but d’adapter des
contenus multimédia au contexte des utilisateurs. La plupart de ces solutions suivent le
modèle architectural C/S comme c'est le cas pour [66] et [49], le modèle architectural C/I/S
comme c'est le cas pour [32], [79], [63] et [22], le modèle architectural P2P comme c’est le
cas pour [48], [51] et [10], ou encore le modèle agent ou l’ontologie pour [80], [54] et [47].
Cependant, notre objectif est de concevoir et implémenter une architecture basée sur les
préférences des utilisateurs pour l’adaptation de DMs en assurant la QoS.
73
Chapitre 4: Une Architecture d’Adaptation des documents Multimédias pour la gestion de
qualité de service basée sur les préférences de l’utilisateur
2. Motivation
L’adaptation de documents multimédia permettant leurs exécutions sur n’importe quel

terminal représente un vrai défi [1]. En effet, les solutions proposées actuellement ne
s’attaquent pas au problème de l’adaptation des documents multimédia aux préférences de
l’utilisateur de manière complète, mais essaient de fournir des solutions, souvent manuelles
ou explicites, face à des ensembles de contraintes d’adaptation très spécifiques. Ces solutions
sont aussi très souvent basées sur des langages de description de documents multimédia
rendant l’adaptation plus ou moins flexible.
Par conséquent, il apparaît important de rendre l’adaptation plus dépendante face à toutes les
préférences des utilisateurs et plus flexible pour ainsi couvrir de nombreuses contraintes
d’adaptation et notamment celles qui portent sur la QoS des documents fournis aux
utilisateurs.
A cet effet, nous avons développé une Architecture d’Adaptation des Documents Multimédias
basée sur les Préférences de l’Utilisateur, baptisée AAMDUP6. Elle constitue une plate-forme
d'adaptation pour les documents multimédia qui permet aux clients d’utiliser des dispositifs
hétérogènes pour atteindre les différents contenus du serveur. Elle permet les fonctions
suivantes:
• L'adaptation du document multimédia selon les préférences de l'utilisateur : le concept
d'adaptation est motivé par l'hétérogénéité des préférences des utilisateurs et pas seulement du
matériel. Notre architecture devrait adapter dynamiquement le document multimédia à la
variation, la disponibilité des ressources et aux préférences de l'utilisateur.
• La gestion des profils d'utilisateurs : notre architecture doit être en mesure de recueillir les
différentes informations concernant les utilisateurs, leur environnement et le contexte dans
lequel ils sont. Cette information (le profil) doit être représentée dans un formulaire standard
qui peut être utilisé et manipulé lors du processus d'adaptation.
• La gestion de l'hétérogénéité des DMs : AAMDUP se veut gérer une diversité de DMs (de la
plus simple à la plus complexe), et leur adaptation doit être faite d'une manière transparente
pour l'utilisateur.
Pour développer notre architecture, nous nous basons sur les architectures : PAAM [10] et
NAC [22]. Le système d’adaptation AAMDUP possède en entrée un DM composé et un
6
AAMDUP en anglais: Adaptation Architecture of Multimedia Document based on User’s Preferences
74
contexte. Il prend alors les décisions d’adaptation, cherche les adaptateurs nécessaires, les
compose éventuellement et pilote l’adaptation.
3. Aperçu de l’approche proposée

Un DM est une combinaison d'objets multimédias présentés à des utilisateurs via Internet. Il
est disponible sur le Web par l'intermédiaire d'une base de données et l'utilisateur peut
interagir avec lui par ses interfaces. La base de données doit stocker des structures spécifiques
et génériques des documents. Il doit également fournir le contexte des médias stockés dans
une base de données nommée "Media Profile".
Cependant, pour adapter dynamiquement un DM au contexte de l'utilisateur, nous
utilisons un gestionnaire de la QoS permettant au composant de l'adaptation de choisir des
scénarios de contenu multimédia demandé par l'utilisateur. Le gestionnaire de la QoS utilise
comme entrée, le profil de terminal et le profil de réseau dans le contexte de l'utilisateur. Il est
également basé sur les préférences de l'utilisateur pour traiter les DMs. Toutes les
informations sont saisies par l'interface et sont transmises par le gestionnaire de documents
multimédia. Le contexte des médias est présenté comme un élément clé du processus invoqué
pour assurer la QoS.
Dans les environnements hétérogènes, tels que les systèmes pervasifs, la sensibilité au
contexte est un concept clé pour répondre aux différents besoins des composants. Pour
satisfaire cette fonctionnalité, les informations de contexte doivent être collectées et
présentées à l'application au moment de l'adaptation. Basé sur toutes les informations utilisées
comme entrée, le gestionnaire d’adaptation définit la liste des scénarios possibles. Lorsque
l'utilisateur se connecte via l'interface appropriée, cette composante reflète le contexte de
l'utilisateur d'une manière explicite et implicite et les stocke dans une base de données appelée
“Contexte utilisateur". C'est pourquoi une modélisation des contextes manipulés est
nécessaire à l’adaptation de contenus. Pour représenter la structure hiérarchique des contextes,
nous avons utilisé un diagramme de classe UML (voir Figure 4.1). Les contextes peuvent être
classés en trois catégories :
• Le profil de l'utilisateur qui est composé des caractéristiques statiques (nom, etc.), des
caractéristiques évolutives qui sont définies par l'environnement (lieu, temps, etc.) et des
préférences (texte, image ou vidéo);
• Le profil de terminal qui a, d'une part, le contexte du matériel (type de dispositif, taille de
l'écran, etc.), et d'autre part, le contexte du logiciel (système d'exploitation, formats, etc.);
75
• Le profil de réseau qui expose des informations sur le type de réseau, des caractéristiques,
etc.
Le diagramme de classes de la Figure 4.1 décrit les classes constituant le contexte ainsi que
leurs relations.
Figure. 4.1: Modèle de description d’un contexte
Il existe plusieurs standards que nous avons vus dans le chapitre 1permettant d’offrir les bons
mécanismes pour décrire le contexte de l’utilisateur tels que MPEG-21[33], CC/PP [33]. Pour
décrire le contexte de nos applications, nous avons utilisé le standard CC/PP, qui est la
première recommandation fondée sur RDF. L'utilisation de RDF pour CC/PP présente de
nombreux avantages : vocabulaires extensibles, vocabulaires décentralisés, intégration
simplifiée des informations à partir de différentes sources. La Figure 4.2 fournit un exemple
de la description du contexte de l’utilisateur avec CC/PP.
76
Figure. 4.2: Exemple de description du contexte avec CC/PP
Cette description contient deux parties: TerminalHardware et TerminalSoftware.

La première partie nous permette de présenter la description matérielle et la deuxième de
présenter la description logicielle du terminal.
L'interaction entre l'utilisateur et le DM n’est pas directe, mais elle est gérée par un
gestionnaire de DM via une interface. Lorsque l'utilisateur commence une interaction avec les
documents multimédias, le gestionnaire de document multimédia vérifie la compatibilité entre
le contexte de l'utilisateur et le contexte des médias. Si ces deux contextes ne sont pas
compatibles, le gestionnaire de DM déclenche le gestionnaire de QoS.
Pour gérer la QoS, nous offrons à l'utilisateur une échelle de préférences (entre 1 et 4)
qu'il utilise pour affecter une priorité à chaque support de format (son, image, vidéo et texte)
(voir chapitre 03). L'utilisateur met à zéro les formats non prioritaires. La requête est envoyée
77
au gestionnaire de DM pour rechercher des documents requis, alors que parallèlement le

superviseur construit les profils de base (utilisateur, terminal, et de réseau). Si le DM est
trouvé, il sera envoyé au gestionnaire de QoS. Ce dernier vérifie si le DM contient les formats
de médias que l'utilisateur met sa valeur de préférence égale à zéro. Si elle constate, à partir
de la description des médias de document (profil média), le gestionnaire de QoS supprime les
médias non désirés par l'utilisateur. Le résultat de la description et la liste des contenus des
objets médias dans le document sont transmis au gestionnaire d'adaptation.
Le gestionnaire d'adaptation utilise une présentation formelle de concepts de technique
d'adaptation du document multimédia pour trouver le plus court chemin directement à partir
des profils de l’utilisateur, des valeurs des préférences et des politiques d'adaptation qui sont
utilisés pour construire le graphe d'adaptation avec tous les chemins possibles. A la fin, le
gestionnaire effectue l'adaptation nécessaire et construit le document multimédia adapté.
Ensuite, le gestionnaire de DM envoie le document résultat à l'utilisateur.
4. Architecture globale du système
L’architecture proposée est capable d’adapter les documents multimédia aux exigences des
utilisateurs en considérant les capacités de l’environnement d’exécution et aussi les
préférences des utilisateurs. Cette adaptation est dynamique afin de considérer les évolutions
possibles de ces paramètres. Cet objectif ne peut être atteint que si l’on dispose d’une
architecture logicielle malléable que l’on puisse modeler aux exigences de QoS.
Dans cette section, nous présentons les composants de notre architecture qui peut gérer
l'adaptation dynamique de documents multimédias au contexte de l'utilisateur.
L’architecture que nous proposons s’attaque aux limitations des projets précédemment décrits,
en proposant, en particulier, une technique permettant l’adaptation dynamique de DM basée
sur les préférences de l’utilisateur. Certains projets proposent des mécanismes de recherche et
de composition d’adaptateurs mais ne gèrent pas les préférences de l’utilisateur et ne traitent
pas le même type de contenus que notre architecture. En effet, AADMUP a pour objectif de
contribuer à l'adaptation des contenus en prenant en considération les limitations des
terminaux, les contraintes de leurs environnements et les préférences de l’utilisateur. La
Figure 4.3 illustre notre architecture AAMDUP.
78
Figure 4.3 Architecture générale d’AAMDUP.
5. Description des différents composants de notre architecture

Dans notre architecture du système d’adaptation de document multimédia, les choix
d’adaptation sont des diverses techniques et méthodes d’adaptation qui pouvant être utilisées
pour l’adaptation de contenu et de la structure de document existent : transcodage,
transmodage et transformation. L’avantage de notre architecture est de pouvoir manipuler
toutes les données de la même façon et donc de simplifier l’adaptation de document. Ainsi, les
relations temporelles entre des données de différents types pourront être conservées.
Dans cette section, nous présentons les composants de notre architecture qui peut gérer
l'adaptation dynamique de documents multimédias au contexte de l'utilisateur.
Comme le montre la Figure 4.3, la présentation et l'adaptation de documents multimédias
constituent le cœur des fonctionnalités offertes par cette architecture. Notre solution est basée
sur l’architecture C/S et composée des éléments suivants: Interface Utilisateur, Gestionnaire
de DM, Gestionnaire d'adaptation, Gestionnaire de QoS, Superviseur de contexte d’utilisateur.
79
5.1 Interface utilisateur (IU)

Le composant interface utilisateur capte le contexte utilisateur, et il est le responsable de
l’interaction de l'utilisateur avec le gestionnaire de DM.
L’IU fournit toutes les fonctionnalités de connexion et la communication avec le serveur,
ainsi que les caractéristiques pour afficher les DMs. Après avoir recueilli le contexte de
l'utilisateur (les préférences de l'utilisateur, le profil de terminal, le profil de réseaux), il
l’envoie au gestionnaire de DM. Pour représenter la structure hiérarchique du contexte de
l'utilisateur, nous utilisons le langage de modélisation UML (Unified Modeling Language)
(voir Figure. 4.2). L’IU est utilisée par un environnement hétérogène et elle joue un rôle
majeur dans l'architecture. Elle permet au terminal de communiquer avec le reste du système
pour recevoir le contenu et de le présenter à l'utilisateur, qui peut à tout moment modifier des
préférences à l'aide de l'interface utilisateur de notre architecture.
5.2 Gestionnaire de Document Multimédia (GDM)

Ce composant intervient dans le processus de découverte et de recherche de DMs. Il gère la
coordination des fonctions nécessaires pour une présentation de DM personnalisés et sensibles
au contexte. Il assure également la transmission des demandes des clients vers les serveurs de
la même manière et le serveur répond aux demandes des clients. Souvent, ces réponses (DM)
sont adaptées ou modifiés avant d'être livrées à leur destination finale. La diversité des
médias, leurs propriétés et leurs différentes utilisations suggèrent, ce qui est nécessaire plus
que jamais, de définir une description abstraite pour représenter les différents types de médias.
Le profil de médias contient des informations relatives à chaque type de médias, tels que le
format disponibles, la transition possible entre le format et le type de l'adaptation possible.
Deux bases de données sont associées au gestionnaire de document multimédia : profil des
médias et des flux multimédias. Ce composant permet l'ajout du document multimédia dans la
base de données de médias et la création de versions pour chaque document multimédia. Cette
fonctionnalité comprend la recherche d'une version adaptée du document multimédia dans la
base de données des médias. Le GDM reçoit le nom du document multimédia et vérifie son
existence. Si le DM n’existe pas, le GDM envoie un message d'erreur, et le client sera invité à
reformuler sa demande. Si le DM existe, le GDM construit le UP (voir chapitre 3, section
4.2) et lance le processus de gestion de la QoS.
80
5.3 Gestionnaire de QoS (GQoS)

Le Gestionnaire de Qualité de Service (GQoS) récupère le contexte de l'utilisateur, le UP et le
DM donné par GDM. Il vérifie s’il y a un conflit par le déclenchement automatique de
l’aspect de détection de conflit (voir Figure 4.7). Si la QoS est suffisante, le GQoS envoie le
DM à le GDM. Sinon, il construit le MPC (voir chapitre 3, section 4.5) puis l’envoie avec le
DM et le UP au GA pour l’adapter.
5.4 Gestionnaire d'Adaptation (GA)

Ce composant assure l'adaptation du contenu des DMs et permet le choix de la meilleure
politique d'adaptation et de la mise en œuvre de cette politique. Ceci est réalisé grâce à
l'utilisation d’un algorithme d'adaptation (voir chapitre 3, Figure 3.2). L’adaptation, dans la
plupart des cas, est dynamique. Il est possible que les propriétés de l'appareil du client ne
permettent pas d'afficher tout type de média (son, vidéo ou image). Dans ce cas, nous pouvons
supprimer ce média à partir du document, sans influencer la synchronisation du document.
Une fois que les éléments multimédias sont choisis, nous les adaptons afin qu'ils
correspondent le mieux possible aux préférences des clients. Ce composant effectue une
adaptation au cours de laquelle les médias sont sélectionnés. Ensuite, le document multimédia
est analysé et qui choisit la meilleure politique d'adaptation. Ensuite, un graphe d'adaptation
est créé.
En effet, le nouveau DM est envoyé au composant GQoS pour vérifier la Qos et l’envoyer au
GDM pour l'enregistrer dans la base de données des médias. Ce composant permet également
la création de versions de DM, selon les exigences des préférences de l'utilisateur. Les
applications multimédias nécessitent un support de système avec des garanties de qualité de
service. Cette notion de qualité de service peut être exprimée en utilisant un ensemble de
paramètres.
5.5 Superviseur de Contexte de l'Utilisateur (SCU)
Ce composant recueille le contexte de l'utilisateur. Son rôle est de fournir le maximum
d'informations au composant GQoS afin de l'aider à prendre les bonnes décisions. Il comprend
l'ajout, la suppression ou la mise à jour des profils de l'utilisateur, la récupération des
informations du client et leur traduction sous forme de profils, et de la gestion des historiques
d'utilisation pour chaque utilisateur.
81
Le choix de la norme dans notre architecture a été porté sur CC/PP (Composite
Capability/Preference Profiles) [68]. Le superviseur du contexte utilisateur utilise une gestion
de la mémoire cache pour garder une trace des caractéristiques des terminaux et change leur
subissent. L'identification de ces caractéristiques (profils) est basée sur l'adresse IP du
terminal. Pour décrire la description de nos utilisateurs, nous avons utilisé le CC/PP avec une
proposition d’une extension pour prendre en considération les caractéristiques physiques de
l'utilisateur et nous ajoutons les préférences de l’utilisateur et les propriétés de qualité de
service. Dans la Figure 4.5, nous avons précisé en rouge les propriétés à ajouter pour la
gestion de QoS. Nous avons ajoutez deux type de propriétés, UserPreferences et QoSProperty.
[User_Profile]
|
+--ccpp:component-->[Terminal]
||
| +--rdf:type----> [Plateforme_Materiel]
| +--display_Width--> ".........."
| +--display_Height--> "........."
| +--display_color--> "0/1"
| +--capacity memory--> "........."
| +--CPU speed--> "........MH"
| +--Connexion_supported--> [Types]
|| +--Media_Accepted--> [Types]
|
+--Audio----->"0/1"
+--Vidéo----->"0/1"
+--Text----->"0/1"
+--Image----->"0/1"
|
+--ccpp:component-->[Logiciel_Used]
+--ccpp:component-->[Navigateur_Used]
+--ccpp:component-->[physical_Used]
+--ccpp:component-->[Need_Media]
|
+--rdf: UserPreferences ---> [Types]
+--Audio----->{"0","1","2","3","4",}
+--Vidéo-----> {"0","1","2","3","4",}
+--Text----->{"0","1","2","3","4",}
+--Image----->{"0","1","2","3","4",}
+--rdf: QoSProperty ----> [Types]

+--cost----->”………..”
+--time-----> "……...."
Figure+--space----->"………."
4 .5 Description de contexte de l‘utilisateur.
82
Le Framework de Description de Resource (RDF) fournit une base de domaines neutre sur
lequel les ensembles d'éléments extensibles peuvent être définis et exprimés dans une notation
standard [52]. L'utilisation de RDF pour CC/PP présente de nombreux avantages: les
vocabulaires évolutifs, les vocabulaires décentralisés, et l'intégration simple de l'interface à
partir de différentes sources.
6. Technique d’adaptation de DM
Un DM est toujours décrit comme étant un assemblage, selon un scénario spécifié, de médias
traditionnels dits statiques (texte, graphique), tout aussi bien que des médias continus
(animation, audio et vidéo), des médias structurés (documents HTML, SMIL, SVG), et même
des programmes comme des applets ou scripts. Un bon scénario est celui qui se caractérise
par une bonne combinaison de plusieurs éléments multimédias pouvant donner un meilleur
résultat de présentation des informations [5].
Un cycle d’adaptation de DM est initié par un utilisateur qui envoie une requête, composée
d'une référence à un document multimédia et d'une référence au contexte (voir Figure 4.6).
A partir du profil et du document initial, l’étape d’adaptation doit produire un document
satisfaisant les contraintes exprimées dans le profil. Cette adaptation est généralement réalisée
par un programme de transformation du document [82,83]. L'adaptation de contenu est définie
généralement comme le processus qui transforme un contenu de son état initial vers un état
final afin de satisfaire un ensemble de contraintes [27].
83
Figure 4 .6 Processus d’adaptation de document multimédia.
En effet, les chercheurs [10], [27], [84], [85] s’intéressant à ce domaine distinguent deux
types d’adaptation :
(i) adaptation de la logique de services comme les travaux exposés dans [84] et [85] où le
service est représenté par un ensemble de composants. L’adaptation vise alors à modifier
l’assemblage de ces composants en ajoutant, en supprimant ou en remplaçant un composant.
(ii) adaptation du contenu du service [27]. Il s’agit de l’ensemble des formes d’adaptabilité
qui choisissent le changement du contenu fourni par le service selon le contexte. Une forme
typique de l’adaptation du contenu est le changement de l’encodage d’un flux multimédia ou
le changement de la présentation d’un service selon le contexte.
Afin de modéliser l’aspect d’adaptation de l’architecture, nous avons utilisé un diagramme de
séquence qui nous permet de présenter les différents messages envoyés entre les composants
de l’architecture (voir Figure 4.7). Nous avons pris la définition d’un composant proposé par
[10] qui a défini un composant comme un ensemble de méthodes interagissent entre eux afin
de réaliser l’objectif du composant. Ainsi, un composant est une agrégation d’un ou plusieurs
méthodes.
84
Figure 4.7 Diagramme de séquence pour un scenario typique.
Pour décrire le modèle dans lequel le document multimédia sera adapté, nous utilisons le
langage UML fournissant le modèle indépendant de contexte. Le diagramme de séquence
présente les flux échangés au sien de notre système d’une manière visuelle.
7. Adaptation des documents multimédia basée sur le paradigme ‘Aspect’ (POA)

POA a été promue comme un moyen pour la manipulation de la modularisation de systèmes
logiciels en élevant le niveau d'abstraction et de réduire la dispersion des préoccupations
transversales. Les études de la littérature ont montré l'utilité et l'application de l'AOP dans
différents domaines de recherche [65]. La connexion ou la gestion des droits, la distribution,
la gestion des traces, la sécurité, et la gestion des transactions ont été présentés comme des
exemples de préoccupations transversales ainsi abordés par AOP [46].
La séparation de préoccupation non fonctionnelle pour la QoS de service des applications
multimédias nécessite une bonne maîtrise des langages de programmation orientée aspect et
de tous les détails de leur utilisation. Néanmoins, AOP pourrait conduire à résoudre les
85
problèmes d'adaptation des documents multimédia [45]. Par exemple, afin de raisonner sur la
politique d'adaptation de médias, les développeurs peuvent avoir à envisager la mise en œuvre
d'un aspect. En fait, en se référant à des détails d'implémentation de classe dans le domaine de
la POA, on pourrait inhiber le raisonnement modulaire et le compromis variabilité, nécessitant
des modifications des médias à être pleinement conscient des aspects touchant les médias. Par
exemple, le développeur peut avoir besoin de vérifier tous les aspects afin de confirmer que
l'extraction d'une politique d'adaptation des médias ne sera pas conduite à ne pas se joindre à
un point. Ce critère a été montré pour être un moyen prometteur pour faire face aux
spécificités liées aux essais de techniques de programmation modernes comme la POA [56].
Nous proposons la construction de deux ensembles l’un contient les médias non préférés et
supprime et l’autre comprend des conflits des propriétés de média (MPC) par l’utilisation des
aspects. Parce que dans le processus d’adaptation nous examinons uniquement le conflit créé
pour le média avec une valeur d’UP supérieure à zéro (voir Figure 4.8).
before ():
execution (void M(mi,uj )) && within(MD) {
if (uj==0) {
throw newDeleteMediaException();
}
Figure 4.8 Aspect d’élimination des medias non prioritaires.
Nous considérons que les préférences de l'utilisateur sont des préoccupations transversales et
nous présentons une transformation des conflits de la propriété des médias vers les aspects.
Les conflits de la propriété des médias doivent être satisfaits avant toute exécution de
document multimédia. S’il n’est pas satisfait, il conduit à une séquence infaisable.
L'adaptation est donc considérée comme une propriété non fonctionnelle, ce qui implique
l'intégration des aspects d'adaptation dans les composants.
Par exemple, nous pouvons traduire le concept de propriétés de média(PM) sur AspectJ. Le
code AspectJ (voir Figure 4.9) vérifie la propriété des médias mi. L’exemple de la Figure 4.9
fournit un DM avec un média mi avec une propriété pq :
86
before ():
execution (void mi ()) && within(MD) {
if (!pq) {
throw newPropertyConflitViolationException();
}
}
Figure 4.9 Aspect de détection de conflit
Cet extrait de code, qui fait partie d'un aspect, déclare un advice qui est appelé avant chaque
exécution de médias M du MD. L’advice vérifie la propriété γ, et lève une exception si elle est
violée, il signifie qu’il y a un conflit donc il va conduire directement ver le concept conflit de
la propriété des médias (MPC) (voir Figure 4.10).
aspect Adapt {
pointcut conflit() :call(* MethexecutMediai(...)) &&
if (!proprityverified());
before() : {calladppolici(Media)
countQoS();
}
Figure 4.10 Aspect de résolution de conflit
Les advices spécifient le code exécuté lorsque l'on atteint un pointcut donné. AspectJ dispose
de trois manières d'associer un ‘advice’ avec un ‘joinpoint’: avant (‘before’), après (‘after’) et
autour (‘around’). L’advice ‘Adapt’ de type ‘before’ est exécuté juste avant l'arrivée sur un
joinpoint qui a défini dans le pointcut nommé conflit, tandis qu'un ‘advice’ de type ‘after’
sera exécuté juste après.
87
8. Conclusion
Dans ce chapitre, nous avons présenté une architecture de gestion de QoS des DMs que nous
avons appelée AAMDUP. Puis, nous avons détaillé les principales fonctionnalités de ses
différents composants, les différentes techniques et méthodes utilisées pour l’adaptation de
contenu et de la structure de document existantes : transcodage, transmodage et
transformation. Nous avons présenté, comment nous avons utilisé la POA pour la gestion
d’adaptation des documents multimédia. En effet, l’objectif principal de ce chapitre était de
montrer comment réaliser une architecture d’adaptation des documents multimédias basée sur
le contexte utilisateur à travers notre architecture.
Néanmoins, une étude de cas est nécessaire pour l’évaluation des différentes idées présentées
dans un environnement réel. Nous illustrons, dans le chapitre suivant, l'approche proposée par
une étude de cas.
88
Chapitre 5 : Etude de cas et quelques aspects d’implémentations
Etude de cas et quelques aspects
Chapitre d’implémentations
05
1. Introduction
Après avoir présenté nos deux contributions dans les deux chapitres précédents, à savoir la
présentation formelle d’adaptation de DMs (voir chapitre 3) et l’architecture d’un système
d’adaptation de contenus pour la gestion de QoS basée sur le contexte d’utilisateur (voir
chapitre 4), nous présentons et motivons dans ce chapitre nos choix technologiques liés à
l’implantation de notre solution proposée. Nous abordons, aussi, l’implémentation de
quelques aspects de notre architecture. L’objectif est d’obtenir une vue directement
implémentable des applications multimédia dans laquelle seront introduites de manière
explicite les préférences des utilisateurs.
La dernière étape de ce travail consiste à fournir un rapide aperçu du prototype que nous
avons développé afin de valider les différents modèles et leurs principales caractéristiques
proposées précédemment. Pour ce faire, nous avons choisir un langage de programmation
cible. Notre intérêt est focalisé sur les environnements distribués fortement hétérogènes.
Afin de réaliser cette implémentation des différents composants, nous nous sommes tournés
vers un langage de programmation orientée objet (Java) et un langage de POA (AspectJ). Un
critère déterminant dans le choix du langage est la possibilité de déployer les applications
multimédia sur des environnements hétérogènes. En effet, il faut que l’implémentation
proposée puisse être déployée sur des environnements différents tant au niveau système qu’au
niveau matériel.
89
2. Outils technologiques utilisés

Dans cette section, nous présentons le langage de programmation utilisé pour la
réalisation, l’environnement de développement ainsi que l’outil permettant la visualisation
de notre prototype.
2.1 Langage de programmation

Le langage utilisé pour la réalisation de notre outil est le langage orienté objet « Java » qui a
été créé à la fin des années 80 lorsque bill Joy, cofondateur de Sun Microsystems en 1982,
commença à imaginer un nouveau langage. Java est le nom d’une technologie mise au point
par Sun Microsystems (racheté par Oracle en 2010) qui permet de produire des logiciels
indépendants de toute architecture matérielle. Cette technologie s’appuie sur différents
éléments qui, par abus de langage.
Notre choix s’est posé sur ce langage compte tenu des multiples avantages qu’il offre, entre
autres :
❖Java est un langage dynamique, simple et robuste.
❖ Le langage Java est un langage de programmation orienté objet ;
❖La sémantique du langage Java est indépendante de la plateforme. Donc un programme
écrit en Java fonctionne de manière indépendante de l’architecture matérielle.
❖Les logiciels développés avec le langage Java sont facilement portables sur plusieurs
systèmes d’exploitation.
❖Java reprend en grande partie la syntaxe du langage C++, très utilisé par les
informaticiens. Néanmoins, Java a été épuré des concepts les plus subtils du langage C++ et à
la fois les plus déroutants, tels que l’héritage multiple qui a été remplacé par les interfaces.
Les concepteurs ont privilégié l’approche orientée objet de sorte qu’en Java, tout est objet à
l’exception des types primitifs (nombres entiers, nombres à virgule flottante, etc.).
❖Java a donné naissance à un ensemble d’environnements de développement (Eclipse,
Netbeans, etc.), des machines virtuelles (MSJVM, JRE) applicatives multi-plateformes
(JVM), une plateforme java de base (java SE) avec des API pour la création des interfaces
graphiques (AWT, Swing). La portabilité du code Java est assurée par la machine virtuelle.
90
2.4 Environnement de développement

L’environnement de programmation utilisé pour le développement de l’outil est «NetBeans »,
qui nous a apparu comme étant l’environnement le plus approprié pour la réalisation de notre
application grâce aux facilités qu’il offre. Ainsi, NetBeans intègre :
•La gestion basique des projets et codes Java purs avec interfaces graphiques.
•La gestion des diagrammes UML de toutes sortes.
•La gestion des paquetages et déploiement d’applications.
•La gestion de différents serveurs et bases de données, etc.
En plus de Java, NetBeans permet également de supporter différents autres langages, comme
C, C++, JavaScript, PHP, HTML … Il comprend toutes les caractéristiques d'un IDE moderne
(éditeur en couleur, projets multi-langage, refactoring, éditeur graphique d'interfaces et de
pages Web).
Conçu en Java, NetBeans est disponible sous Windows, Linux, Solaris, Mac OS X ou sous
une version indépendante des systèmes d'exploitation (requérant une machine virtuelle Java).
Un environnement Java Development Kit (JDK) est requis pour les développements en Java
[34]. Pour la programmation des aspects, nous avons utilisé AspectJ comme nous avons
expliqué dans le chapitre 04.
2.5 Affichage graphique

Pour représenter le prototype de notre architecture, nous avons fait appel à l’outil «Tomcat».
Ce dernier est un serveur qui gère exclusivement des requêtes HTTP. Tomcat a été écrit
en langage Java. Il peut donc s'exécuter via la machine virtuelle Java sur n'importe
quel système d'exploitation la supportant. Il comporte également un serveur http.
3. Présentation de l’étude de cas

Après avoir présenté quelques détails relatifs à la phase de réalisation, nous présentons, dans
cette section, l’énoncé de notre étude de cas et la présentation de notre prototype de l’interface
de l’architecture proposée.
Nous allons montrer comment notre solution va apporter de l’aide aux utilisateurs en
exploitant la présentation formel et l’architecture que nous avons exposée (chapitre 3 et 4) sur
un environnement opérationnel.
Cette étude de cas vise à exposer les différents concepts rencontrés dans les chapitres
précédents. Pour cela, un exemple d’un scénario a été proposé et qui sera appliqué dans notre
91
pays, l’Algérie.
3.1. Enoncé
Afin de mieux cerner les situations d'adaptation qui peuvent se présenter, imaginons le
scénario suivant :
Une artiste anglaise Yora a voulu participer à la manifestation de Constantine, capitale de la
culture arabe. Elle commence devoir un DM concernant cette ville sur son ordinateur de
bureau. Ce document est composé d’un contenu vidéo, d’un texte, et 5 images, la taille de ce
document est 28,45 Mo (voir Figure 5.1).
Figure. 5.1 Document source présentant la ville de Constantine
Yora doit alors quitter son bureau. Ayant une tablette, elle a la possibilité de continuer à
visionner le document. Elle allume donc sa tablette et demande à "récupérer" le service qu'elle
utilise depuis son ordinateur de bureau, quand la batterie de sa tablette est faible (il reste 10%
qui a besoin de 2 minutes au maximum), et l’espace libre dans sa mémoire vive est : 20Mo.
3.2 Présentation de Prototype

Comme nous l’avons souligné dans le chapitre précédant (Chapitre 04), l’AAMDUP est une
plate-forme proposée permettant aux clients d'utiliser des dispositifs hétérogènes pour
atteindre les différents DM du serveur [88].
Dans ce dernier, les utilisateurs finaux peuvent être des personnes normales ou des handicapés
(sourd ou aveugle) comme le montre la Figure 5.2.
92
Figure. 5.2 Place du système AAMDUP.
Nous simulons la plate-forme d’exécution à l’aide d’interfaces graphiques permettant de

provoquer le serveur des DMs et de récupérer ces derniers adaptés au contexte d’utilisateur.
Nous avons commencé par détailler le fonctionnement global d’architecture. Dans une
seconde étape, nous présenterons une étude de cas le prototype d’interface de notre
architecture afin de tester des propriétés telles que la reconfiguration, l’adaptation de DM, etc.
Nous avons développé en Java un prototype permettant d’adapter des documents
multimédia spécifiés avec le langage XML. Ce prototype se base sur l’architecture présentée
dans la Figure 5.3. L’interface qui s’affichera au responsable du poste est la suivante
93
Figure.5.3 Interface d’accueil de l’utilisateur
La Figure 5.3 présente une copie d’écran de notre prototype d’architecture d’adaptation DM.
Le frame « Fichier Original » correspond à l’affichage de documents multimédia avant
l’adaptation. Le frame « Fichier Adapter » correspond à l’affichage de documents multimédia
adapter. Les frames « Priorité » et « Espace réservé » correspondent respectivement aux
préférences de l’utilisateur et à l’espace mémoire.
La section suivante présente l’implémentation de quelque concept de ce système d’adaptation.
4. Implémentation
Dans cette section, nous avons présenté l’implémentation de quelques aspects de notre
architecture liée au domaine des applications multimédia présenté au niveau du chapitre 1
section 2.
L'interface du prototype se présente sous la forme d'un outil de conception où l'utilisateur
choisit le type des différents médias. La Figure 5.4 donne un exemple d’implémentation de la
94
méthode run() d’un SCU qui permet de générer les contextes d’utilisateur.
public void run()

{
while(MD != null)
{
mi=tentativeLecture(fluxMedia[0]);
if(mi==null)
this.yield();
else
{
mi=(media)mi.echantillons();
x=mi.getmedia (DM);
y=mi.getpreference (DM);
tableauUP=new int[x*y];
try
{
pg.grabPixels();
}
catch(InterruptedException ie)
{
System.err.println("Interruption pendant le traitement de media " + ie);
}}
Figure 5.4 Extrait du code de la méthode run() de construction de UP
Afin de construire l’ensemble MPC, nous avons utilisé deux types d’advice: after returning et
after throwing . after returning est appliqué lorsque la vérification retourne normalement sans
lancer aucun conflit. D'autre part, lorsque l'exécution des média se termine par un conflit,
l’advice after throwing est appelé pour ajouter le conflit xf à l’ensemble MPC.
La méthode insérée à vérifier les propriétés de DM avec les contraintes est présentée dans la
Figure 5.5 la suivante.
95
after(DM current)returning(Media mi) :

execution(!static * mi.*(..)) && within(mi) && this(current){
/*Il vérifie la propriété, s'il détecte tout conflit
, alors qu'il jette un ViolationException,
sinon il retourne normalement.*/
if (!current.check_Conflit_DM()){
throw new ConflitViolationException();
}}
after(C current)throwing(Throwable throwable) :
execution(!static * mi.*(..))&&within(mi) && this(current){
if(throwable instanceof pq){
throw(pq)throwable;
}
if(throwable instanceof pq){
if (!current.check_Conflit_DM()){
throw new ConflitViolationException();
}
else{
throw(pq)throwable;
}}}
Figure 5.5 Extrait du code d’aspect de construction de MPC
L’advice après le retour sont exécutés. Il vérifie la compatibilité des propriétés de media avec
les contraintes de contexte et si elle détecte un conflit de propriétés. Il exécute un
ConflitViolationException (), sinon retourne normalement.
Le contexte d’utilisateur est décrit à l’aide d’une classe abstraite qui permet d’afficher ses
différentes contraintes. Cette classe implémente l’interface ControleContexte afin que le
contexte puisse être contrôlé par le SCU qui va le contenir.
Lors de la mise en place de cette application, la Figure 5.6 décrit comment capturer la taille
mémoire pour l’utiliser pour la gestion de QoS. Une interface dédiée permet de régler les
paramètres du traitement réalisé.
96
Figure 5.6 Extrait du code de méthode de capture de la taille mémoire.
Figure 5.7 Extrait du code de méthode de capture et d’affichage de contexte d’utilisateur.
97
public void getpage (int indexCat,String titre,JEditorPane af,JLabel taiileFiciher)
try {
ResultSet resultats = null;
String requte = "SELECT * from Pages where id_cat =

"+Integer.toString(indexCat)+" and titre = '"+titre+"'";
Statement stmt;
stmt = this.connexion.createStatement();
resultats = stmt.executeQuery(requte);
while (resultats.next())
{ try {
af.setPage(resultats.getString("url_page"));
System.out.println(resultats.getString("titre"));
File f = new File(resultats.getString("emp_fichier"));
taiileFiciher.setText(Integer.toString((int)f.length()));
System.out.println("Taille en octet " + f.length( ) + " bytes.");
} catch (IOException ex) {
Logger.getLogger(ObjetBD.class.getName()).log(Level.SEVERE, null, ex);
} catch (SQLException ex) {
Logger.getLogger(ObjetBD.class.getName()).log(Level.SEVERE, null, ex);
Figure 5.8 Extrait du code de méthode recherche DM par GDM.
98
Le morceau de code (spécification partielle) de la Figure 5.7 montre l’implémentation du

module de DM demandé par l’utilisateur. Ce module est présenté dans notre architecture et est
dérivée de la classe GDM, elle s’exécutera donc continuellement. Une fois qu’une requête est
arrivée, le module de recherche interprète les informations obtenues.
5. Application de l’architecture proposée

Quand Yora lance l’application, les capacités de sa tablette (matériel et logiciel) seront
affichées au bas de l’interface.
Ensuite Yora veut sélectionner le document de la ville de Constantine parmi les documents
qui existent dans la base de données. Lorsque le document est sélectionné, leur taille serra
affichée au bas de l’interface.
Voici un aperçu de document sélectionné avec leur taille (Figue 5.9) :
Figure.5.9 Choix de document multimédia
A partir des capacités de sa tablette et la taille de DM, Yora décide des priorités optes pour
son choix, et elle sélectionne l’espace mémoire qu’elle a besoin d’utiliser. Dans ce cas elle
choisit :
99
• Son ordre de ses priorités qui est défini de la figure précédente :

1. Images
2. Texte
3. vidéo
• L’espace utilisé est: 10 Mo.
La Figure 5.10 illustre comment Yora choisit ses priorités des média et son espace réservé
pour adapter le DM.
Figure. 5.10 Choix de préférences de l’utilisateur
L’adaptation de DM de « Constantine » est réalisée par l’algorithme de la prise de décision

au niveau GA. À partir de la description de contexte de l’utilisateur, celle de DM et des choix
d’adaptation de notre système, la Figure 5.11 illustre le document adapté au contexte de
l’utilisateur.
100
Figure. 5.11 Document adapté au contexte de l’utilisateur.
Nous déduisons de ce scénario, les besoins suivants :

• Fournir un système d’adaptation flexible et pouvant être déployé à large échelle,
compte tenu du nombre croissant d’utilisateurs des applications d’échange de contenus
multimédia et l’évolutivité de ces contenus.
• Prendre en compte les caractéristiques personnelles ou les besoins spécifiques de
l’utilisateur (Yora ne veut pas de son) : peu de solutions répondent aujourd’hui à ce
besoin.
• Réaliser une adaptation au niveau de serveur: l’accroissement des utilisateurs des
terminaux à capacités réduites telles que les assistants personnels (par ex. PDA ou
blackberry) exclut une adaptation côté client (ou utilisateur final).
• Gérer les disparitions des ressources d’adaptation : ce besoin est une conséquence de
l’adaptation distribuée.
101
6. Discussion
Notre étude de cas est liée au domaine d’application comportant des documents multimédia,
qui est un environnement ouvert et dynamique et qui opère sur des utilisateurs d’information
hétérogènes.
L’implémentation du système est basée sur la plate-forme NetBeans qui permet de simplifier
le développement les systèmes. Aussi, nous avons utilisé les standards RDF et XML pour
représenter les contextes et les préférences des utilisateurs.
Notre architecture offre plusieurs autres intérêts. En effet, elle est :
✓ Portable : car elle est programmée en Java ;
✓ Générique: facilement adaptable à d’autres applications grâce au concept du protocole
d’interaction.
Notre architecture peut être appliquée dans plusieurs types de terminaux. Notre proposition
d’ajouter les préférences de l’utilisateur et la création des aspects pour détecter les conflits
offre beaucoup d’avantages, notamment, la réutilisation et la facilité de la maintenance des
Aspects et les changements des préférences. En plus, elle évite d’encombrer les messages de
négociation.
Bien que notre architecture offre plusieurs avantages, elle peut connaître des améliorations.
Cette étude de cas ne démontre qu’un exemple partiel d’applications qui peuvent être
développée au-dessus de notre approche. C’est ainsi que nous prévoyons d’inclure deux
nouveaux mécanismes : un mécanisme pour la gestion des profils des utilisateurs entrant dans
le système et un autre mécanisme pour l’adaptation sémantique des documents multimédia
pour la gestion de QoS.
7. Conclusion
Dans ce chapitre, nous avons présenté quelques détails relatifs à la réalisation de notre outil.
Nous avons essayé de rapprocher l’aspect de mise en œuvre de notre architecture proposée.
Nous avons choisi le langage de programmation Java pour des raisons de compatibilité avec
les concepts orientés objet d'UML d'un côté et orientés aspect d’un autre côté. Aussi, de par
ses multiples caractéristiques de simplicité, robustesse et portabilité. Java est un langage
standard et dynamique. Le développement que nous avons réalisé permet une certaine
souplesse pour des éventuels changements ou améliorations de modèle. Ainsi, nous avons
décrit un scénario de cas d’étude. Aussi, nous avons utilisé la plate-forme NetBean pour le
102
développement de cette architecture, ce qui nous a permis d’effectuer des simulations par
l’utilisation de Tomcat. En effet, nous avons pu montrer l’aspect de gestion de QoS par
l’implémentation quelques aspects par l’utilisation de AspectJ. L’utilisation de RDF pour la
description du contexte permet de les visualiser dans un navigateur WEB, puisque NetBean
fournit des outils en extension permettant l’exécution des aspects.
103
Conclusion Générale
Conclusion et bilan du travail

Au terme de ce travail de recherche, nous pouvons affirmer que l'apparition récente d'une
grande variété de moyens de communication, accompagnée d'un accroissement important de
l'information multimédia rend l'adaptation des contenus nécessaire. Cette nécessité se justifie
par une demande croissante d'accès à l'information en tout lieu et sur des plates-formes très
hétérogènes.
Notre objectif principal est de développer une approche permettant de gérer la QoS de
documents multimédia afin que chaque utilisateur puisse consommer ces contenus quel
que soient ses préférences (par exemple sa langue parlée, son handicap et leurs priorités)
et les capacités de son terminal (par exemple, la taille de l’écran du terminal et son système
d’exploitation), en d’autres termes, quel que soit son contexte. Idéalement, tout usager devrait
pouvoir accéder à ces contenus et les recevoir dans un format adapté au contexte dans lequel
il travaille. Il faut donc un système qui adapte les contenus multimédia par rapport au contexte
des usagers et à ses préférences.
Nous avons essayé à travers cette thèse d’inventorier les principales techniques et
architectures proposées dans la littérature abordant l’adaptation des documents multimédias
basés sur le contexte utilisateur tel que : PAAM, NAC, DCAF, APPAT. Toutes ces
architectures proposent des solutions différentes pour répondre aux besoins fondamentaux de
l’adaptation de contenus multimédia. Cependant, nous constatons que certains besoins ne
sont pas ou sont partiellement atteints.
Nous avons proposé une architecture d’adaptation des documents multimédias baptisée
AAMDUP basée sur le modèle architectural C/S, et utilisée le paradigme POA.
Nous avons également abordé la problématique de la gestion de la QoS des documents
multimédia dans le domaine des applications multimédia comme une propriété non-
fonctionnelle assurée par des aspects qui sont intégrés pour adapter les documents
multimédia. Pour cela nous nous sommes intéressés aux différentes définitions de la QoS
ainsi qu'à l'adaptation des documents multimédia. La plupart des travaux concernant la QoS se
focalisent sur un aspect particulier.
En effet, c'est l'aspect réseau comme le temps de latence qui est pris en compte. Dans les
applications multimédias c'est plutôt l'aspect utilisateur qui est pris en compte, et plus
particulièrement sa satisfaction face au service rendu. Dans les applications pour
104
périphériques contraints c'est l'aspect matériel relatif à la consommation de ressources qui est
privilégié. Concernant l'adaptation structurelle, nous pouvons constater que l'utilisation des
intergiciels et des plates-formes de supervision est très répandue. Chacun de ces aspects de
QoS est influencé par différents éléments regroupés sous le nom commun ‘contexte’ : type de
connexion, nombre de couleurs, débit de transfert, langue, localisation, mémoire disponible,
etc. Chaque élément n'influence qu'une partie de la QoS de l'application.
Perspectives envisagées
Bien que le travail présenté ait fourni quelques solutions pour la gestion de QoS des
documents multimédia, plusieurs aspects sont soumis à de nouvelles améliorations et à des
approfondissements. Certains de ces aspects ont fait l’objet d’études dans des travaux et des
thèses au sein de notre équipe du laboratoire (LIRE) de l’université de Constantine 2. D'autres
travaux futurs peuvent s'orienter dans de nombreuses et différentes directions tant pour des
aspects pratiques que théoriques, à savoir :
- La proposition d’un système d’adaptation sémantique des documents multimédia pour

la gestion de QoS : l’abstraction des documents en une structure exprime l’ensemble
des relations entre objets du document. Les relations entre objets peuvent êtres d’ordre
temporel, spatial, hypermédia voire inter-dimensionnel, et peuvent être de nature
qualitatives. Cette structure capture la sémantique des documents car elle est capable
de couvrir chacune de ses exécutions potentielles. Dans ce contexte, l’adaptation
consiste à calculer un ensemble d’exécutions le plus proche possible de ces exécutions
potentielles qui satisfont les contraintes d’adaptation imposées par une plate-forme
cible. À cet effet, nous voulons, aussi, ajouter la sémantique aux préférences de
l'utilisateur.
- La définition d’une Ontologies des documents multimédia : proposer une ontologie des
documents multimédia. Cette ontologie devrait faciliter la reconstruction de document.
- La prise en compte de la gestion de ‘Streaming’ : l'adaptation des DM doit être
complétée avant la livraison à l'utilisateur final. L'une des perspectives est de prendre
en compte cet aspect du streaming.
105
Bibliographie
[1] Laborie Sébastien, « Adaptation sémantique de documents multimédia », Thèse de

Doctorat Université Joseph Fourier- Grenoble 1. 2008.
[2] Laborie S., Euzenat J. and Layaïda N. Semantic adaptation of multimedia documents.
Multimedia Tools Appl. 55(3): 379-398, 2011.
[3] Dick Bulterman, Guido Grassel, Jack Jansen, Antti Koivisto, Nabil Layada, Thierry
Michel, Sjoerd Mullender et Daniel Zucker , «Synchronized Multimedia Integration
Language (SMIL 2.1) ». W3C, 2005. http://w3.org/TR/SMIL/.
[4] Ilhem Labed , « Méthodes et Outils pour la Construction de Scènes Multimédia
Distribuées », thèse doctorat, Université Constantine 2 - Abdelhamid Mehri, 2007.
[5] Emmanuel Bouix , « Modèles de Flux et de Composants pour Applications Multimédias
Distribuées Dynamiquement Reconfigurables », Thèse de doctorat, Université de Pau et
des Pays de l’Adour, 2007.
[6] http://www.Wikipédia.org
[7] http://abderrazakmkadmi.free.fr/liens/TIC_archives/Multimedia.htm
[8] A. K. Dey. “Understanding and using context”. Personal and Ubiquitous Computing,
5(1):4–7, 2001.
[9] NGUYEN Cong Kinh , «Démonstrateur de l'adaptation distribuée de documents
multimédia par composition de web services », Rapport de stage, 2008.
[10] Zakia Imane Kazi-Aoul , « Une architecture orientée services pour la fourniture de
documents multimédia composés adaptables », thèse doctorat, École Nationale
Supérieure des Télécommunications Au département Informatiques et Réseaux Paris,
2008.
[11] Y.Y. Al-Salqan & C.K, Chang. «Temporal Relations and Synchronization v Agents»,
IEEE Multimedia, 1996. , p. 30–39
[12] A.Golaup & H. Aghvami, «Multimedia Traffic Modeling Framework for Simulation-
Based Performance Evaluation Studies», Elsevier Computer Networks, 2006. N.50, p.
2071-2087.
[13] T. D. C. Little & A. Ghafoor, « Interval−Based Conceptual Models for Time−Dependent
Multimedia Data», IEEE Transactions on Knowledge and Data Engineering (Special
Issue : Multimedia Information Systems) ‘,1993. N. 4, p.551-563.
106
[14] C. Mourlas, «Specification and Verification of Quality Requirements in Distributed
Multimedia Presentations», Proceedings, the 22nd International Conference on
Distributed Computing Systems Workshops (ICDCSW‟02), IEEE, 2002.
[15] B. Rogge, J. Bekaert& R. Van de Walle. «Timing Issues in Multimedia Formats
‘Review of the Principles and Comparison of Existing Formats», IEEE Transactions On
Multimedia, 2004.
[16] Ilhem Labed & Mahmoud Boufaida. O2DM: An Object Oriented Model for Multimedia
Authoring Systems, Proceedings: ACIT’04, pp. 667, Constantine- Algerie, 12-15
Décembre 2004.
[17] I. Labed I & P. Barril. Towards a model supporting synchronization of multimedia data
and cost estimation, ISPS’99 Alger, pp. 42- 51, 18- 20 Octobre 1999.
[18] J. M. Almeida, D. L.Eager, M. K. Vernon &S. J. Wright. «Minimizing Delivery Cost in
Scalable Streaming Content Distribution Systems», IEEE Transactionson Multimedia,
2004, N. 2, p.356-365.
[19] J. Jin & K. Nahrstedt. « QoS Specification Languages for Distributed Multimedia
Applications’ ,Survey and Taxonomy , ‘ IEEE MultiMedia, Feature Article’, EEE
Computer Society , 2004.
[20] J. Edwards & L. Dai ley Paulson. « Smart Graphics: A New Approach to Meeting User
Needs», Computer, 2002, N.5,p,18-21.
[21] Bettou Farida, Gestion de la qualité de service lors du développement des logiciels
orientés aspect, Mémoire de Magister en Informatique, Université Constantine 2 –
Abdelhamid Mehri, 2009.
[22] Lemlouma T. (2004), « Architecture de Négociation et d'Adaptation de Services
Multimédia dans des Environnements Hétérogènes », PhD thesis, National Polytechnic
Institute, Grenoble.
[23] Jan G. et Dave B. « RDF Test Cases, W3C Proposed Recommendation »,
http://www.w3.org/TR/rdf-testcases/, 2003.
[24] Lemlouma T. « UPS Client Repository », http://wam.inrialpes.fr/people/lemlouma/-
MULTIMEDIA/UPS-Client-Repository/ups-client-repository.html
[25] Lemlouma T. et Layaïda N, « Universal Profiling for Content Negotiation and
Adaptation in Heterogeneous Environments», W3C Workshop on Delivery
Context,W3C/INRIA Sophia-Antipolis, France ,2002.
[26] «Resource Description Framework (RDF) Model and Syntax Specification, W3C
Recommendation », http://www.w3.org/TR/1999/REC-rdf-syntax’, 1999
107
[27] Brain D M., «Concepts for Service adaptation, scalability and QoS handling on
mobility enabled networks», in IST-1999-10050 project, deliverable 1.2., 31 Mars 2001.
[28] SOAP Version 1.2Part1: Messaging Framework, W3C Recommendation,
http://www.w3.org/TR/2003/REC-soap12-part1-20030624/, 2003.
[29] J.-C. Moissinac, I. Demeure et Z.-I. Kazi-Aoul, Services d’adaptation de contenus
multimédia, composition de services et pair-à-pair, CRIMES 09, Saint-Denis de La
Réunion, France, Novembre 2009.
[30] R. Montanari, E. Lupu, C. Stefanelli , «Policy based Dynamic Reconfiguration of
Mobile-code Applications», IEEE Computer’, 2004, p 73-80.
[31] Hagos B., Lionel B.,Pierson J-M , «Planning-Based multimedia Adaptation Services
Composition for Pervasive Computing», 2nd International Conference on Signal-Image
Technology & Internet based Systems (SITIS'2006), Hammamet (Tunisie).
[32] Lapayre J-C., Renard F., « Appat : a New Platform to Perform Global Adaptation »,
Actes de la 1st IEEE International Conference on Distributed Frameworks for
Multimedia Applications (DFMA'2005), Besançon, 6-9 février 2005, pages : 351-358.
[33] Rezoug abdellah , «adaptation des présentations multimédias pour une optimisation de la
consommation d’énergie», thèse de magistère université M’hamed Bugara- Boumerdés
,2007.
[34] Pierre Lachevre, Christophe Rimbert, Thiphaine Dubocage, Pierre Grancher, Ibra
Ndyaye, ‘ Site d’aide à la compréhension de l’anglais (SACA)’ Rapport de Projet,2011 .
[35] © Microsoft Access ‘ Utilisation de base’, Fac Similé, Manuel de référence ‘Tsoftediteur
‘ ,2007 .
[36] http://www.w3.org/TR/smil20/smil-basic .html
[37] MARIE Sophie, «Conception d’architectures logicielles pour intégrer la qualité de
service dans les applications multimédia réparties», thèse de doctorat, Université de pau
et des pays de l’adour, 2006.
[38] José M. Martínez, Rob Koenen, and Fernando Pereira. « MPEG-7: The generic
Multimedia Content Description Standard », part 1, IEEE multimedia volume 9, issue, Avril
2002, pages 78-87.
[39] Page d’accueil de SMIL : http://www.w3.org/TR/REC-smil/.
[40] Site officiel de Dublin Core : http://dublincore.org/.
[41] Susanne Boll, Wolfgang Klas, «ZyX : A Multimedia Document Model for Reuse and
Adaptation of Multimedia Content, in IEEE Transactions on Knowledge and Data
Engineering», Volume 13 , Issue 3, Mai 2001, pages : 361 - 382.
108
[42] Neil Day and José M. Martinez, «Introduction to MPEG-7 (v4.0) », ISO/IEC
JTC1/SC29/WG11 N4675, Jeju, Mars 2002.
[43] Cassagnes C, Roose P, Dalmau M, Louberry C.(2009), «KALIMUCHO :software
architecture for limited mobile devices». ACM SIGBED Review», Vol 6, No 3, Special
Issue on the 2nd Workshop on Adaptive and Recongurable Embedded System, Grenoble,
France.
[44] Christine Louberry, « KALIMUCHO : Adaptation au Contexte pour la Gestion de la
Qualité de Service », Thèse doctorat Université de pau et des pays de l’adour, 2010.
[45] Angelo F, Libero N, Francesco P, «Multimedia synchronization based on aspect oriented
programming», Microprocessors and Microsystems, 2004, Vol 28, Issue 2,pp 47-56.
[46] Alberto C, Rodrigo B, Márcio R, Carlos E, Paulo B and Fernando C, «A design rule
language for aspect-oriented programming», The Journal of Systems and Software, 2013, Vol
86,pp 2333– 2356.
[47] Alti A, Laborie S, and Roose P, «Automatic Adaptation of Multimedia
Documents»,Procedia Computer Science, 2013, Vol 19, pp 992-997.
[48] Alti A, Sébastien L, Philippe R, «Semantic Context-aware Adaptation Platform
Architecture». 4th International Symposium on Frontiers in Ambient and Mobile Systems
(FAMS-2014), 2014, pp 959-964.
[49] Ardon S., Gunningberg P., Landfeldt B., Ismailov Y., Portmann M. and Seneviratne A.
« MARCH: A distributed content adaptation architecture». International Journal of
Communication Systems. 2003,Vol. 16, No1,pp. 97-115.
[50] Bouix E. M. Dalmau, P. Roose, F. Luthon. « A Component Model for transmission and
processing of Synchronized Multimedia Data Flows » . In Proceedings of the 1st
International Conference on Distributed Frameworks for Multimedia Applications, Besançon,
France, 2005, pp.45-53.
[51] Letian Rong, Ian Burnett, Dynamic Resource Adaptation in a Heterogeneous Peer-to-
peer Environment, Consumer Communications and Networking Conference (CCNC
2005), Second IEEE, January 3rd to 6th, 2005, pp : 416 - 420.
[52] Charlotte J, Mike J, Peter B, Jon W ,« Automatic RDF metadata generation for resource
discovery », Computer Networks, 1999, Vol31, Issues 11–16, pp 1305-1320.
[53] Derdour M., Dalmau M., Roose P.and GhoualmiZine N. « Typing of Adaptation
Connectors in MMSA Approach Case Study: Sending MMS ». International Journal of
Research and Reviews in Computer Science(IJRRCS), 2010, Vol. 1, No. 4, pp.39-49.
109
[54] Dietmar J, Klaus L., « Knowledge-based multimedia adaptation for ubiquitous
multimedia consumption », Journal of Network and Computer Applications, 2007, Vol 30,
Issue 3, pp 958-982.
[55] Éric T, Ismael F, Nicolas T (2014), « Execution levels for aspect oriented programming:
Design, semantics, implementations and applications », Science Computer Programing, 2014,
Val 80, pp311-342.
[56] Fabiano C F, Awais R and José C M, « Towards the practical mutation testing of AspectJ
programs », Science of Computer Programming, 2013, Vol 78, Issue 9, pp 1639-1662.
[57] Fadi W, Sudipto G, Leo R. V, « An approach and tool for measurement of state variable
based data-flow test coverage for aspect-oriented programs », Information and Software
Technology, 2015, Vol 59,pp 233-254.
[58] Graham Klyne et al, Composite Capability/Preference Profiles (CC/PP): Structure and
Vocabularies,http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/,W3C
Recommendation, 15 January 2004.
[59] Kazi_Aoul Z., Demeure I. and Moissinac J_C. (2006), « Towards a Peer-to-peer
Architecture for the provision of Adaptable Multimedia Composed Documents ». In The 2nd
International Conference Distributed Frameworks for Multimedia Applications
(DFMA’2006), IEEE, Computer Society Malaysia, Penang, Malaysia, pp 1-8.
[60] Kehua G, Wei P, Mingming L, Xiaoke Z and Jianhua M, « An effective and economical
architecture for semantic-based heterogeneous multimedia big data retrieval », Journal of
Systems and Software, 2015, Vol 102, pp 207-216.
[61] Laborie S., Jérôme E., Layaïda N., « Semantic adaptation of multimedia documents
». Multimedia Tools and Application. 2011, Vol 55,No 3,pp 379-398.
[62] Bettou Farida, Boufaida Mahmoud & Labed Ilhem: Un modèle en étoile orienté aspect
pour la gestion de la qualité de service de logiciels, CISC’11 The Second International
Conference on Complex Systems, Jijel, Algérie, 06-08 Dec, 2011.
[63] Layaïda N., Lemlouma T., Quint V. « NAC: An Architecture for Multimedia Content
Adaptation for Mobile Devices », ERCIM (The European Research Consortium for
Informatics and Mathematics), ERCIM News. 2003, No. 54.
[64] Pham Hai Q., Laborie S., Roose P.(,2012), « On-the-fly Multimedia Document
Adaptation Architecture ». Procedia Computer Science, Vol 10.pp. 1188-1193.
[65] Reza M P, Abdul A, Sai P L (2015), « Automated test generation technique for aspectual
features in AspectJ », Information and Software Technology, Vol57, pp 463-493.
110
[66] Shahadat K, Kin F. Li and Eric G. M (1997), « Padma: an architecture for adaptive
multimedia systems », Communications, Computers and Signal Processing, 10 Years
PACRIM 1987-1997 - Networking the Pacific Rim. 1997 IEEE Pacific Rim Conference,Vol1 ,
pp105-108.
[67] Soocheol L, Seungmin R and Jong H P, « Multimedia contents adaptation by modality
conversion with user preference in wireless network » ,Journal of Network and Computer
Applications, (2014), Vol 37, pp 25-32.
[68] Graham Klyne, Franklin Reynolds, Chris Woodrow, Hidetaka Ohto, Johan Hjelm, Mark
H. Butler et Luu Tran , Composite Capability/Preference Profiles (CC/PP) : Structure and
Vocabularies 1.0. W3C, 2001. http://www.w3.org/TR/CCPP-struct-vocab/.
[69] www.w3.org/TR/CCPP-struct-vocab/
[70] Ian Burnett, Ric Van de Walle, Keith Hill, Jan Bormans, Fernando Pereira, « MPEG-21 :
Goals and Achievements », IEEE Multimedia, Octobre-Novembre 2003, vol 10 N°6, pages
60-70.
[71] Vetro A., « MPEG-21 Digital Item Adaptation : Enabling Universal Multimedia
Access », IEEE Multimedia, janvier-mars 2004, vol. 11, n° 1, pp : 84-87.
[72] A. Hafid, G. von Bochmann, R. Dssouli. « Distributed Multimedia Application and
Quality of Service: A Review ». Electronic Journal on Networks and Distributed Processing,
n°6, pp. 1-50, 1998.
[73] D. P. Anderson. « Metascheduling for Continuous Media ». ACM Transactions on
Computer Systems, vol. 11, n°3, pp. 226-252, août 1993.
[74] V. Baiceanu, C. Cowan, D. McNamee, C. Pu, J. Walpole. « Multimedia Applications
Require Adaptive CPU Scheduling ». In Proceedings of the 1996 Workshop on Resource
Allocation Problems in Multimedia Systems, Washington DC, Etats-Unis, 3 décembre 1996.
[75] E. Garcia. « Une plate-forme de développement pour applications coopératives
multimédia intégrant la gestion de la qualité de service ». Thèse de Doctorat, Université
de Franche- Comté, Besançon, France, novembre 2001.
[76] H. Tokuda, Y. Tobe, S. T-C. Chou, J. M. F. Moura. « Continuous Media
Communication with Dynamic QOS Control Using ARTS with an FDDI Network ». In
Proceedings of the Conference on Communications Architecture and Protocols,
Baltimore, Etats-Unis, 17-20 août 1992.
[77] S. Cen. « A Software Feedback Toolkit and its Application in Adaptive Multimedia
Systems ». Thèse de Doctorat, Institut des Sciences et Technologies, Portland, Etats-Unis,
octobre 1997.
111
[78] Kimiaei Asadi, « Mariam : Adaptation de Contenu Multimédia avec MPEG-21:
Conversion de Ressources et Adaptation Sémantique de Scènes ». Thèse de Doctorat
soutenue le 30 Juin 2005 à l’ENST.
[79] G. Berhe, L. Brunie, JM. Pierson , « Distributed Content Adaptation for Pervasive
Systems ». Dans les actes de IEEE International Conference on Information Technology,
ITCC 2005, 4-6 Avril 2005, Las Vegas, Nevada, USA, Vol.2 pages : 234-241.
[80] Masakatsu Kosuga, Tatsuya Yamazaki, Nagao Ogino, Jun Matsuda, « Adaptive QoS
Management Using Layered Multi-Agent System for Distributed Multimedia Applications
». ICPP 1999: 388-394.
[81] Shahidi M., Ning Li, Hamid Aghvami A.(2010), « Selection Algorithm for Multimedia
Adaptation Mechanisms in Ubiquitous Service Environments », iiwas2010 Proceedings
Mobile and Ubiquitous Systems. .(2010), pp. 768-771.
[82] Lemlouma T. & Layaïda N, « The negotiation of multimedia content services in
heterogeneous environments ». In Proc. 8th International Conference on Multimedia
Modeling (MMM01), Amsterdam (NL), 2001, p. 187–206.
[83] Villard L, « Authoring transformations by direct manipulation for adaptable
multimedia presentations ». In Proc. ACM Symposium on Document Engineering
(DocEng’01), Atlanta (US), 2001, p. 125–134.
[84] Marquet B., Gustave C., Lefebvre A., Nemchenko S., Chassande-Barrioz S., « Secured
services in a multi-tier architecture, in World Telecommunications Congress », WTC
2002, Paris, Septembre 2002.
[85] Antoine MAROT, « L’animation d’algorithmes en programmation orientée aspect »,
Mémoire présenté en vue de l’obtention du grade de Licencié en Informatique, université
libre de Bruxelles, 2005–2006.
[86] Bettou Farida, Boufaida Mahmoud & Labed Ilhem, « An adaptation architecture of
multimedia documents for management of the quality of service », the 15th International
Conference on Enterprise Information Systems (ICEIS),pp154-159,4-7
July,2013,ESEO,Angers Loire Valley,France.
[87] Bettou Farida, Boufaida Mahmoud, « An adaptation technique for multimedia
applications based on the user context to manage the service quality », 2nd International
Conference on Multimedia and Human-Computer Interaction (MHCI’14),pp. 63-1--63-8
August 14-15, 2014, Prague, Czech Republic.
[88] Bettou Farida, Boufaida Mahmoud, “An adaptation architecture dedicated to
personalized management of multimedia documents”, The International Journal of
112
Multimedia Data Engineering and Management (IJMDEM), Vol 8, Issue 1, pp.21-41,
2017.
[89] Dominik Seiler, Ernst Juhnke, Ralph Ewerth, Manfred Grauer, Bernd Freisleben,
“Efficient Data Transmission Between Multimedia Web Services via Aspect-Oriented
Programming”, MMSys’11, February 23–25, 2011, San Jose, California, USA. Copyright
2011 ACM
[90] Allen, R., Garlan D., (1997). « A Formal Basis for Architectural Connection », ACM
Transactions on Software Engineering and Methodology, vol. 6, no 3, 1997, p.213–249.
[91] E. M. Maximilien and M. P. Singh. Self-Adjusting Trust and Selection for Web
Services. In Proceedings of International Conference on Autonomic Computing (ICAC),
pp 385–386, Seattle, WA, 2005. IEEE Computer Society.
[92] Attiogbé, C. André, P. and Messabihi, M. Correction d’assemblages de composants
impliquant des interfaces paramétrées. 3ième Conférence Francophone sur les
Architectures Logicielles. Hermès, Lavoisier. (2009).
[93] Böszörményi L., Hellwagner H., Kosch H., Libsie M., Podlipnig S., « Metadata driven
adaptation in the ADMITS project », EURASIP Signal Processing : Image
Communication Journal, vol 18, n° 8, Septembre 2003, pages : 749-766.
[94] Bertrand Mathieu, Michael Kleis, Meng Song : A P2P Approach for the selection of
Media Processinf Modules for Service Specific Overlay Networks, dans les actes de la
conference AICT-ICIW 2006, 19-25 Février 2006, pages 103.
[95] Site du projet ISIS http://isis.rd.francetelecom.com/
[96] Thèse de João Miguel da Costa Magalhães, Universal Multimedia Content Based on the
MPEG-7 Standard, soutenue en Juin 2002 à l’institut supérieur technique de l’université
technique de Lisbonne.
[97] Lemlouma T., Layaïda N., « Context-Aware Adaptation for Mobile Devices », Actes de
la IEEE International Conference on Mobile Data Management (MDM2004), Berkeley,
19-22 janvier, 2004.
113

BETTOU Farida

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

BETTOU Farida

Transféré par

Droits d'auteur :

Formats disponibles

République Algérienne Démocratique et Populaire

Ministère de l’enseignement supérieur

Présentée par : BETTOU Farida Dirigée par : Pr. BOUFAIDA Mahmoud

Soutenue à Constantine le : 15/ 05/2017

Tout d’abord, je tiens à remercier et exprimer toute ma reconnaissance auprès de mon

Je tiens aussi à remercier Monsieur Mr. MAAMRI Ramdane, Professeur à l'université

• Monsieur Mr. FARAH Nadir Professeur à l’université de Annaba,

Mots-clés: Qualité de Service (QoS), Adaptation de documents multimédia, contexte

Gestion de la qualité de service dans les applications multimédia basée sur

Chapitre 1 : Caractéristiques des architectures de fourniture et d’adaptation de contenus

3.5 Discussion …………………………………………………………………………. 22

10. Exemple d’application de notre approche………………………………...…………... 69

Chapitre 5 Etude de cas et quelques aspects d’implémentations

Conclusion et Perspectives...........................................................................…………. 104

Liste des Figures

Liste des Tableaux

Tableau 1.1 : Exemple du transcodage…………………………………………..……………………..24

Tableau 2.1 Étude comparative entre les architectures d’adaptations existantes…………………….....44

efficaces en termes de temps d'exécution, ou être le plus proche possible de l'intention de

présentation (téléphones portables, PDA, ordinateurs de bureau, ordinateurs portables, etc…).

2. Applications multimédias distribuées

2.1 Classification des applications multimédia

2.2 Types des médias dans les applications multimédia distribuées

2.2.1 Médias continus

2.2.2 Médias discrets

2.3 Quelques outils de description de contenus multimédia

2.3.1 MPEG-7 [10]

Figure.1.1 Fragment de description de vidéo en MPEG-7 [54].

Une description MPEG-7 est donc un schéma de description (structure) et un ensemble de

3. Qualité de Service et Contexte

3.1 Notion de contexte

3.1.1 Contexte d'utilisateur

3.1.2 Contexte d'utilisation

3.1.3 Contexte d'exécution

Le Framework CC/PP définit une structure et un vocabulaire. Une structure définit

Figure. 1.2 – Exemple de profil CC/PP [1], [69].

3.3.1 Point de vue de l’utilisateur

3.3.2 Point de vue de l’environnement d’exécution

3.4.1 Réservation de ressources

travaux déploient des intergiciels, middlewares ou plates-formes d’exécution chargés de

4. Techniques d’adaptation de document multimédia

4.1 Contraintes d'adaptation

4.2 Types d’adaptation

4.2.1. Adaptation locale

Figure. 1.3 Adaptation en catégories

La catégorie transcodage permet de changer la méthode de codage d’un média élémentaire

4.2.2 Adaptation globale

5. Familles d’approches d’adaptation

5.1.2 Approches basés sur le contenu

5.1.3 Approches mixtes

5.2 Spécification de règles d'adaptation

Figure. 1.4 Un DM adapté à l'aide d'une base de règles de transformation [1].

5.3 Spécification de modèles de document flexibles

5.4 Approche sémantique et dynamique

6. Adaptation des contenus multimédia et les modèles architecturaux

6.1 Modèle architectural Client / Serveur et adaptation

6.1.2 Système d’adaptation au niveau du serveur

6.3 Modèle architectural pair-à-pair et adaptation

7. Techniques de consommation et d’adaptation de contenus multimédia

Dans le but de permettre une meilleure réutilisation, le paradigme de la POA propose de

Figure.2.1 Organisation générale de l’architecture NAC [63]

2.2 Adaptation de DM pour la gestion de QoS

2.3 Gestion du contexte