Télécharger le fichier original (Mémoire de fin d’études)
Adaptation de données multimédia
La gestion des données multimédia recouvre de nombreux aspects: extensibilité du système, accès et intégration des données (en termes d’indexation et d’exécution de requêtes dans un environnement distribué fortement hétérogène), optimisation de l’utilisation des ressources et de la qualité de service (bande passante réduite, discontinuité du service). Enfin, l’adaptation de contenus multimédias constitue certainement l’un des mécanismes principaux dans la mise en œuvre effective des applications pervasives. 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.
La fourniture et l’échange du contenu multimédia est un sujet de recherche qui a suscité de nombreux travaux. Nous limiterons notre discussion aux questions liées au problème de l’adaptation de contenu et nous montrerons comment on peut résoudre les problèmes nés des caractéristiques inhérentes à l’informatique pervasive. L’adaptation de contenu est un processus de personnalisation du contenu permettant son adaptation à l’utilisateur et au contexte de l’environnement. En résumé, la nécessité de l’adaptation du contenu en environnements pervasifs est motivée par la disponibilité limitée des ressources, les préférences des utilisateurs, et le contexte d’utilisation.
La figure 2 montre le compromis entre la qualité de service d’adaptation et la qualité de données multimédia en fonction de la correspondance entre les données multimédia et les ressources disponibles. Dans les applications multimédia, la qualité d’un service d’adaptation (e.g : compression) dépond de la qualité de la données (e.g : image). Par exemple un service de compression avec perte est plus rapide qu’un service de compression sans perte, aussi la taille de la données est plus petite par rapport à la taille donnée par un service sans perte. Donc, une qualité de données supérieure implique une qualité de service inférieur, ainsi selon l’adéquation entre les ressources et les données multimédia on décide l’adaptation nécessaire.
L’adaptation du contenu multimédia doit être assurée par rapport au type de terminal, à l’utilisateur et à l’environnement, afin de garantir une utilisation confortable des applications dans ces nouveaux environnements pervasifs. Pour réaliser ces adaptations, plusieurs paramètres entrent en jeu :
Profil réseau : dans les réseaux sans fil, la bande passante est limitée, les connexions ne sont pas stables, la qualité de service n’est pas évaluée de la même façon, etc.
Profil réseau : dans les réseaux sans fil, la bande passante est limitée, les connexions ne sont pas stables, la qualité de service n’est pas évaluée de la même façon, etc.
Profil utilisateur : l’utilisateur est devenu le point central de la conception des applications pervasives. En effet, des contraintes d’utilisabilité et d’ergonomie se présentent aux concepteurs de ce genre d’application. Ainsi, doit-on prendre en considération les préférences, l’emplacement géographique, le profil, etc.
Profil terminal : la diversité des appareils mobiles influe sur la conception de ces applications. Le comportement de ces deniers doit s’adapter aux capacités matérielles et logicielles de ces appareils.
Tous ces paramètres constituent des contextes d’utilisation différents [SHA90]. Dans la plupart des cas, ces paramètres n’ont pas été pris en compte lorsque l’application a été développée. Ceci oblige généralement les concepteurs à reconsidérer le cycle depuis le début pour prendre en compte ces nouveaux paramètres.
Un grand nombre d’applications pervasives est développé selon une approche à base de composants et/ou services. Malheureusement, ces approches sont essentiellement basées sur l’aspect fonctionnel et ne prennent pas en compte l’hétérogénéité des données (de type : image, son, texte, vidéo et de format d’encodage pour chaque type). Prenons deux exemples simples :
On dispose sur une machine personnelle d’un composant de capture de photo au format JPG et d’un composant de transmission. On dispose sur un PDA d’un composant de restitution d’images au format PNG. L’assemblage fonctionnel entre ces trois composants est parfaitement envisageable, néanmoins il ne peut fonctionner pour cause d’incompatibilité de format. Il est nécessaire de réaliser une adaptation soit à la source, soit à la destination (voire même sur un hôte jouant le rôle de proxy).
Le deuxième exemple est celui d’un composant d’acquisition qui réalise des captures en 1024×768, format incompatible avec la taille de l’écran du PDA, capable de n’afficher que du 640×480, ceci se traduira par un affichage tronqué. Fonctionnellement, l’assemblage est cohérent même au niveau du format d’encodage, ce qui se pose là est un problème de qualité de service, le service rendu par l’affichage n’est pas celui souhaité. Il faut donc pouvoir résoudre, au-delà du format d’encodage, le problème de la donnée et de sa pertinence.
Approche à base de composant
Les progrès technologiques récents ont vu 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. Les composants d’accès à l’information ont subi une véritable révolution. En effet, Les utilisateurs veulent accéder au même contenu en utilisant des appareils très divers : ordinateurs portables, assistants personnels, téléviseurs, téléphones cellulaires, PDA, capteurs, etc. La communication iner-composants devient de plus en plus complexe, et parfois impossible, à cause d’une part, de l’hétérogénéité des moyens et des composants d’accès à l’information et, d’autre part, de l’évolution importante des contenus. Par ailleurs, le contenu peut être trop complexe et hétérogène pour qu’un appareil ayant des capacités limitées, puisse le traiter et le présenter correctement.
L’approche à base de composants est largement utilisée pour construire des systèmes complexes en s’appuyant sur les caractéristiques de modularité et d’autonomie pour le choix des éléments et la caractéristique de la compossibilité pour relier et attacher ces élément dans un bloc cohérent. Ces approches reposent sur des langages de description d’architecture qui aident à la conception et la définition de la configuration, ces langages viennent compléter la notion de composant en permettant la description d’architectures. De nombreux langages de ce type sont développés au sein des universités et des instituts de recherche. On peut citer les projets : UniCon [SHA95], Wright [ALL97], ASEOP [GAR95] et ACME [GAR00] de l’Université de Carnegie-Mellon, Rapide de l’Université de Stanford, xADL de l’Université de Californie, etc. Ils fournissent différentes définitions d’un noyau de concepts maintenant largement adopté : en tout premier lieu, la notion même de composant, mais aussi les notions de connecteurs, de ports, de rôles, etc. qui expriment les services fournis et requis par les composants et les interactions entre eux à travers les interfaces. Ces notions se présentent sous forme graphique, textuelle, ou les deux à la fois.
Approche à base de composant et applications multimédia
Dans les applications multimédia basées composants, les composants manipulent et échangent des données multimédia de différents types et formats, ce qui exige de prendre en considération le comportement des composants lors du choix des composants et lors de la configuration pour assurer la cohérence et le bon fonctionnement de ces applications.
Le développement d’une application multimédia à base de composants logiciels nécessite de répondre à deux questions principales :
1. Comment concevoir l’application elle-même pour qu’elle s’adapte aux comportements des composants ?
2. Comment concevoir un système garantissant l’adaptation au contexte dynamique en cours d’exécution ?
La première question nécessite une réflexion dans le processus de développement des applications. Le problème d’hétérogénéité doit être réglé d’abord au niveau interne, entre composants de l’application, afin d’avoir des applications homogènes. Puis penser à l’adaptation de ces applications au contexte extérieur. Dans un tel contexte, les applications obtenues par assemblage de composants doivent s’adapter automatiquement à cette évolution. Il faut une spécification de composants correcte (complète, statique et homogène) qui est assez difficile à réaliser en réalité. Il est nécessaire que la structure du système conçue par les concepteurs de composants ne soit pas remise en cause par ces changements.
L’adaptation et les applications basées composants
L’adaptation des applications basées composants peut avoir lieu avant l’exécution (phase de conception et de développement), au lancement (phase de déploiement) ou pendant l’exécution de l’application. Des règles de cohérence structurelle, comportementale et sémantique sont nécessaires pour l’adaptation à l’exécution des composants.
Selon le moment où l’adaptation intervient (e.g. conception, déploiement, exécution) et qui l’opère, on distingue trois types d’adaptation [BRU01] :
• Adaptation statique, qui intervient avant l’exécution (pendant la conception ou le déploiement).
• Adaptation dynamique, qui intervient tout au long de l’exécution.
• Auto-adaptation qui est initiée par le système lui-même.
L’adaptation statique convient à des systèmes basés composants ou orientés services dans lesquels on connait les descriptions et les conditions d’exécution des composants et des services.
L’adaptation dynamique des composants est étudiée dans différents contextes d’exécution (par exemple sans ou avec mobilité). Elle fait appel à des concepts variés (canevas, patrons de conception ou bus logiciels génériques). Elle met en œuvre différentes notions (la sémantique de la communication, la réflexion des systèmes complexes via la réification, l’introspection et l’intercession) appartenant aux aspects tant fonctionnels que non fonctionnels.
L’auto-adaptation est généralement considérée comme une adaptation dynamique qui se distingue par le fait qu’elle est déclenchée par le système à adapter. L’auto-adaptation est très intéressante dans certains environnements très dynamiques tels que les réseaux mobiles où la qualité de transport est versatile. L’auto-adaptation a toutefois un coût non-négligeable sur les performances dans la mesure où elle alourdit le travail demandé au système. Ce dernier doit en effet, en plus des tâches qui lui incombent, maintenir à jour sa connaissance de l’environnement d’exécution et réaliser les adaptations nécessaires.
Les ADL et la notion d’adaptation
Des approches comme [ALL97, BER00, MAX05, ATT09] permettant la séparation des préoccupations fonctionnelles ont été proposées dans le but de capitaliser les besoins fonctionnels des composants. Dans cette perspective plusieurs idées ont été proposées. On distingue principalement deux catégories d’approches pour les architectures logicielles : celles inspirées du développement de logiciel à base de composants (CBSE) et celles orientées services (SOA). Dans le premier cas [SZY97, ALL97, BER00], l’accent est mis sur la structure statique du système : les éléments logiciels sont des composants assemblés par des connecteurs dans des configurations. Dans le second cas [PAP03, MAX05, ATT09, ASR09], l’accent est mis sur la structure fonctionnelle du système : les éléments logiciels sont des fonctionnalités (des services) liés par des relations de type collaboration ou composition.
Les ADL permettent d’analyser et de vérifier très tôt dans le cycle de développement les propriétés que le futur système devra satisfaire, en particulier les propriétés d’homogénéité et de compatibilité des composants manipulant divers médias. En effet, les applications actuelles telles que les systèmes embarqués incluent la notion de média comme une caractéristique importante de leur comportement [AVI 04, BAL 03]. La plupart des ADL existants tels que SPT-UML [GRA 04], MARTE [OMG 06], fractal [BRU04], SCA [BAR07], Kmelia [ATT09] et AADL [SAE08] ne prennent en compte ni l’adaptation ni les propriétés liées aux flux multimédia lors de la conception du logiciel. Certains, traitent le problème d’hétérogénéité par modification de paramètres de la configuration (ajout, retrait ou remplacement de composants) [MAR04] ou par un métamodèle qui vérifie l’adéquation du service à son contexte et recherche la stratégie d’adaptation [MAR07]. Au niveau dynamique, Plusieurs projets de recherche récents proposent des architectures d’adaptation multimédia telles que l’architecture basée Wrapper proposé par Metso [MET01], MAPS [LIE03], M21 [VET04], APPAT [LAP05], DCAF [BER05], NAC [LAY05] et PAAM [ZAK06], s’inspirant d’un modèle P2P amélioré.
En ce qui concerne la mise en œuvre de l’adaptation proprement dite (i.e., l’adaptation des composants), deux approches sont possibles [MSK04] :
• L’adaptation comportementale qui consiste à rendre le code paramétrable afin de pouvoir modifier le comportement d’un service ;
• L’adaptation architecturale qui repose sur des liaisons, ou assemblages, dynamiques entre les composants logiciels pour rendre possibles ces changements de comportement. L’adaptation architecturale a l’avantage de ne pas nécessiter de connaissances particulières sur le comportement interne du module logiciel
Aperçu de la proposition
Dans cette thèse, nous nous intéressons à la problématique de l’adaptation de contenus multimédias dans le cadre des systèmes d’information pervasifs. le sujet sera abordé selon deux facettes différentes : la première est au niveau architectural, elle touche beaucoup plus les composants logiciels d’une application, et cherche à assurer l’interopérabilité entre ces composants à partir d’une analyse des propriétés et des caractéristiques des flux de données échangés, la deuxième est au niveau de la mise en œuvre et de l’exécution, c’est l’adaptation dynamique, elle touche l’interaction de l’application constituée des composants logiciels et matériels avec le monde extérieur.
Le point de départ de cette recherche a été la conception d’un système d’information pour assurer l’adaptation des flux multimédia échangés entre les composants d’une application ubiquitaire. Au cours de cette recherche nous avons constaté que l’hétérogénéité des composants en matière de caractéristiques physique, logique et en matière de flux multimédia doit être traitée à un niveau plus haut dans le cycle de vie de développement des applications, plus précisément au niveau de la configuration. Ce qui permet : de choisir les meilleurs composants logiciels constituant l’application, de détecter les points d’hétérogénéité entre ces composants et de se préparer à résoudre les problèmes survenant après l’intégration des composants matériels.
Les principales contributions de cette thèse sont les suivants:
1. Dans un premier temps, un métamodèle d’architecture logicielle pour applications multimédia intégrant les propriétés des flux de données multimédia. L’adaptation des flux de données est déportée sur des connecteurs appelés connecteurs d’adaptation. Ces derniers intègrent les services d’adaptation nécessaires ainsi que des extensions qualitatives de ces services afin d’offrir une mesure de QdS reflétant l’évolution du flux de données suite aux adaptations.
2. Dans un deuxième temps, nous proposant une plate-forme pour l’adaptation et l’auto-adaptation des applications multimédia configurées avec l’approche MMSA, cette plate-forme contient tous les services nécessaires au : suivi de l’exécution, contrôle de qualité, changement de contexte, adaptation de composants, etc. elle s’appuie sur des mécanismes d’auto-adaptation pour intégrer de nouveaux connecteurs et services d’adaptation et composer à la demande des services d’adaptation complexes à partir des services d’adaptation existants. Ainsi, la construction dynamique de connecteurs d’adaptation des flux de données multimédia en fonction du contexte d’exécution est rendue possible.
Cette thèse est organisée en deux parties :
1. Partie consacrée à l’adaptation statique : cette partie est organisée autour de trois chapitres. Le premier chapitre représente un état de l’art de quelques ADL, suivi d’une étude comparative. Le deuxième chapitre introduit notre métamodèle pour les applications à base de composants multimédia, il permet la modélisation de ces applications tout en prenant en considération l’hétérogénéité des composants lors de l’échange de flux multimédia. Le troisième chapitre présente une projection vers UML en utilisant le mécanisme d’extension Profil-UML et une implémentation de ce profil en utilisant l’outil RSM de IBM (Rational Software Modeler), ce qui offre une vérification automatique de l’assemblage des composants constituant une application.
2. Partie consacrée à l’adaptation dynamique : cette partie est organisée autour de trois chapitres. Le premier chapitre présente les différentes architectures et plateformes d’adaptation selon l’approche utilisée, ainsi que les avantages et les inconvénients de chaque architecture et une comparaison entre les différentes approches. Le deuxième chapitre présente les différents descripteurs de données (contexte et données multimédia) et de traitements (service d’adaptation et composant) utilisés par notre plate-forme d’adaptation. Le troisième chapitre présente notre plate-forme d’auto-adaptation des applications multimédia basées composant, ainsi que le processus de choix et d’intégration des services d’adaptation.
3. La thèse s’achève par les conclusions et les perspectives permettant d’améliorer notre proposition et qui donnent d’autres pistes de recherche liées aux domaines d’adaptation, d’architecture basées composants et d’applications multimédia.
Connecteur
En se basant sur les définitions proposées dans la littérature pour les connecteurs, nous proposons la définition ci-après qui combine les points essentiels de celles-ci.
Les connecteurs sont des entités architecturales de communication qui modélisent de manière explicite les interactions (transfert et contrôle de données) entre les composants. Ils contiennent des informations concernant les règles d’interaction entre les composants. Ainsi, l’objectif des connecteurs est d’atteindre une meilleure réutilisabilité lors de l’assemblage des composants. En effet, la raison de l’existence des connecteurs est de faciliter le développement d’applications à base de composants logiciels. Les composants s’occupent du calcul et stockage tandis que les connecteurs s’occupent de gérer les interactions (communication/coordination) entre les composants.
Les connecteurs peuvent décrire des interactions simples (appel de procédure) d’une manière directe entre des interfaces de même type ou des interactions complexes en jouant le rôle d’adaptateurs d’interfaces. Medvidovic [MED00] a classé les services d’interaction offerts par les connecteurs en quatre types. Chaque type de connecteur offre un ou plusieurs services d’interaction. Ces services sont les suivants :
• Le service de communication : Un connecteur assure ce service s’il s’occupe des transmissions de données entre composants.
• Le service de coordination : supporte le transfert de contrôle entre composants. Les appels de fonctions sont un exemple de cette catégorie de connecteurs.
• Le service de conversion : convertit les interactions inter-composant si nécessaire. Il permet aux composants hétérogènes d’interagir. L’inadéquation d’interaction est un obstacle majeur dans la composition des grands systèmes. Les services de conversion permettent aux composants qui n’ont pas été spécialement conçus pour fonctionner les uns avec les autres, d’établir et de mener des interactions.
• Le service de facilitation : négocie et améliore l’interaction entre composants.
Les connecteurs adaptateurs fournissent des fonctionnalités pour favoriser l’interaction entre des composants qui n’ont pas été conçus pour être interopérables. Ils impliquent des politiques de communication et des protocoles d’interaction entre les composants (conversion). Ces connecteurs sont nécessaires à l’interopérabilité des composants dans des environnements hétérogènes tels que les différents langages de programmation ou les plates-formes informatiques. La conversion peut également être réalisée afin d’optimiser les interactions de composants pour un environnement d’exécution donné. Plusieurs exemples de connecteurs d’adaptation ont été réalisés tels que : l’adaptateur de Yellin et Strom [YEL94] qui permet la correspondance entre des protocoles d’interaction incompatibles ; les tables de fonctions virtuelles utilisées pour la liaison dynamique de méthodes d’appels polymorphes [DRI95] et les packages de DeLine [DEL99] qui permettent à un concepteur de reporter certaines décisions au sujet d’interaction de composant jusqu’au au moment d’intégration de système. L’XMI (XML metadata interchange) peut constituer un support à l’échange de modèles entre les applications et à la conversion de présentation de données [OMG98].
Ainsi, nous pouvons dire que les connecteurs sont des logiciels de communication capables d’adapter les besoins associés aux spécifications d’interfaces requises et fournies (objectif de notre travail). On parle alors de la sémantique des interactions et des flux échangés.
Configuration
Les composants et les connecteurs sont assemblés à partir de leurs interfaces (ports et rôles) pour former une configuration particulière. Une configuration est un agencement, une topologie ; en d’autres termes, il s’agit d’un graphe de composants et de connecteurs qui décrit une structure architecturale permettant de déterminer si les composants et les connecteurs sont correctement composés.
Langage de description d’architecture ADL
Il n’y a pas de définition officielle de ce qu’est un ADL. La définition admise est qu’un ADL spécifie les composants d’un système, leurs interfaces, les connecteurs (lieux d’interaction entre les composants), et la configuration architecturale. A partir de cette définition minimale, chaque ADL possède des caractéristiques de modélisation propres liées à sa motivation et à son usage [MED00].
Un ADL doit fournir les possibilités de configuration suivantes :
• Spécification compréhensible : Dans un ADL, la syntaxe du modèle topologique doit être simple et intuitive. Dans ce cas, la lecture seule de la configuration doit suffire à la compréhension du système sans avoir besoin de détails sur les composants et les connecteurs.
• Composition hiérarchique : Un ADL doit supporter le fait qu’une architecture entière peut être représentée comme un seul composant dans une autre architecture plus large. Ainsi, il est crucial qu’un ADL supporte la propriété de composition hiérarchique dans laquelle un composant primitif est une unité non décomposable et un composant composite est composé de composants (composites ou primitifs).
• Raffinement et traçabilité : Un ADL doit offrir la possibilité de raffiner une configuration à chaque étape du processus de développement. La traçabilité permet de garder la trace des changements successifs entre les différents niveaux d’abstraction.
• Hétérogénéité : L’un des buts des architectures est de faciliter le développement de grands systèmes avec des composants et des connecteurs ayant différents degrés de granularité, implémentés par différents développeurs dans des langages (de programmation ou de modélisation) différents et sur des systèmes d’exploitation différents. Un ADL doit alors permettre de réutiliser l’existant et de spécifier une architecture indépendamment des supports techniques utilisés.
• Passage à l’échelle : Un ADL doit permettre de réaliser des applications complexes et dynamiques (dont la taille peut devenir importante).
• Evolution : Un ADL doit permettre l’évolution de la configuration pour qu’elle puisse prendre en compte de nouvelles fonctionnalités. Cela se traduit essentiellement par la possibilité d’ajouter, de retirer ou de remplacer des composants ou des connecteurs.
• Dynamique d’une application : La dynamique de l’application se traduit par les changements qu’elle subit lors de son exécution tels que la création ou la suppression d’instances de composants, au contraire de l’évolution où les changements sont effectués en atelier (offline).
• Contraintes : Les contraintes qui décrivent les dépendances entre les composants et les connecteurs dans une configuration sont aussi importantes que celles spécifiées dans les composants et les connecteurs eux-mêmes et viennent les compléter. Le concepteur spécifie ces contraintes, ce qui revient à définir des contraintes globales, c’est-à-dire des contraintes qui s’appliquent à tous les éléments d’une application.
• Propriétés non fonctionnelles : Les propriétés non fonctionnelles qui ne concernent ni les connecteurs ni les composants doivent être spécifiées au niveau de la configuration. Par conséquent,
un ADL doit pouvoir définir les contraintes liées à l’environnement d’exécution au niveau de la configuration.
L’ensemble de ces critères permet de faire une comparaison entre les différents ADL, et de choisir l’ADL adéquat relativement à la nature de l’application et à la satisfaction des besoins recherchés.
Après avoir défini les éléments de base des ADL et les propriétés générales de chaque constituant d’une architecture logicielle, nous allons présenter, dans la section suivante, quelques ADL de différentes natures offrant des philosophies diverses pour différentes préoccupations.
Quelques ADL
Différents langages de description d’architecture logicielle existent. Même s’ils possèdent parfois des caractéristiques communes, ils diffèrent sur d’autres relatives aux composants, à la composition de composants, à leurs cycles de vie, etc. Les ADL peuvent être classés en trois catégories différentes [AMI09] : les ADL sans connecteurs, les ADL avec un ensemble prédéfini de connecteurs, et les ADL avec des types de connecteurs explicites. Dans le dernier cas, les ADL fournissent des connecteurs en tant qu’éléments du premier ordre du langage tels que : Wright [ALL97b] [MED99], ACME C2 [GAR00], XADL [DAS05], AADL [ALL02], Cosa [SME04], etc. Tous ces langages cherchent à améliorer la réutilisabilité des composants et des connecteurs en séparant le calcul et la coordination.
Rapide
Rapide [LUC95] a pour but initial de vérifier par la simulation la validité d’une architecture logicielle donnée. Une application est construite sous la forme de modules ou composants communiquant par échange de messages ou évènements. Le simulateur associé à Rapide permet ensuite de vérifier la validité de l’architecture. Les concepts de base du langage Rapide sont les événements, les composants et l’architecture.
Evénements
Le concept de base de Rapide est l’événement qui est une information transmise entre composants. L’événement permet de construire des expressions appelées Event patterns. Ces expressions permettent de caractériser les évènements circulant entre les composants. Par exemple, si A et B sont des événements, A>B signifie que B sera envoyé après A. La construction de ces expressions se fait par l’utilisation d’opérateurs qui définissent les dépendances entre événements.
Composants
Le composant est défini par une interface. Cette dernière est constituée d’un ensemble de services fournis et d’un ensemble de services requis. Les services sont de trois types :
• les Provides peuvent être appelés de manière synchrone par les composants,
• les Requiers sont les services que le composant demande de manière synchrone à d’autres composants. Un composant peut donc communiquer de manière synchrone avec un autre composant si leurs services requiers et provides sont connectés,
• les Actions correspondent à des appels asynchrones entre composants. Deux types d’actions existent
: les actions in et out qui correspondent respectivement à des événements acceptés ou envoyés par un composant.
L’interface contient également une section de description du comportement (clause behavior) du composant. Cette dernière correspond au fonctionnement observable du composant, par exemple l’ordonnancement des événements ou des appels aux services. C’est grâce à cette description que Rapide est en mesure de simuler le fonctionnement de l’application.
De plus, Rapide permet de spécifier des contraintes (clause constraint) qui sont des patrons d’évènements qui doivent ou non se produire pour un composant lors de son exécution. Par exemple, une contrainte peut fixer un ordre obligatoire pour une séquence d’événements d’un composant. En général, ces contraintes permettent de spécifier des restrictions sur le comportement des composants.
Une application est représentée par son architecture. Une architecture consiste en des déclarations d’instances de composants, des connexions entre ces instances et des contraintes sur le comportement de l’architecture. Voici la structure d’une architecture :
ArchitectureName is
// Déclarations Connections
// Connexions [constraints]
// Contraintes optionnelles
EndName
Les connexions entre les instances de composants sont régies par des règles. Une règle d’interconnexion est composée de deux parties. La partie gauche contient une expression d’événements qui doit être vérifiée. La partie droite contient également une expression d’événements qui doivent être déclenchés après la vérification de l’expression de la partie gauche.
Table des matières
INTRODUCTION GENERALE
Les systèmes d’information pervasifs
1. Caractéristiques des systèmes pervasifs
2. Problème d’hétérogénéité
Adaptation de données multimédia
Approche à base de composant
1. Approche à base de composant et applications multimédia
2. L’adaptation et les applications basées composants
3. Les ADL et la notion d’adaptation
Aperçu de la proposition
Plan de la thèse
CHAPITRE 01 : LANGAGES DE DESCRIPTION D’ARCHITECTURE ET INGENIERIE DIRIGEE PAR LES MODELES
Introduction
Définitions
1. Composant
2. Connecteur
3. Configuration
4. Langage de description d’architecture ADL
Quelques ADL
1. Rapide
2. Fractal
3. SCA (Service Component Architecture)
4. Kmelia
5. COSA
Ingénierie dirigée par les modèles
1. Apport de l’ingénierie dirigée par les modèles
2. Modèle de composants UML2.0
3. Architectures logicielles et UML
4. Profils UML Vs DSL
Travaux connexes sur les connecteurs
1. Conception et mise en oeuvre d’un langage à composants
2. C3 (Component Connector Configuration)
Synthèse
CHAPITRE 02: MMSA UNE APPROCHE POUR LES APPLICATIONS MULTIMEDIA
Introduction
Problème de l’interopérabilité
Motivation pour une approche multimédia
Données multimédia et MMSA
1. Modèle de flux de données
2. Techniques d’adaptations des données multimédia
3. Le méta modèle d’architecture logicielle MMSA
4. Adaptation de flux de données avec MMSA
Eléments d’implantation de l’architecture MMSA
1. Composants MMSA
2. Connecteur MMSA
3. Attachement/Liaison
4. Configuration
5. Propriétés (fonctionnelles et non fonctionnelles)
6. Mécanisme de vérification syntaxique des configurations MMSA
MMSA et les langages de description d’architecture
Synthèse
CHAPITRE 03: UN PROFIL UML POUR LE MMSA
Introduction
Définition d’un profil UML2.0 pour MMSA
1. Avantages du Profil MMSA
2. Les paquetages de MMSA
3. La validation des modèles en MMSA
Outil de validation pour les architectures logicielles multimédia
1. Exemple illustratif : un système de vidéosurveillance
2. Implémentation du profil
Synthèse
CHAPITRE 04: ARCHITECTURE ET PLATEFORMES D’ADAPTATION
Introduction
Architecture d’adaptation des données multimédia
1. Caractéristiques des architectures d’adaptation de contenu
2. Approches d’adaptation
3. Evaluation des architectures d’adaptation
Plateformes d’auto-adaptation des applications basées composants
1. Classification des plateformes d’auto-adaptation
2. Quelques plates-formes existantes d’auto-adaptation
3. Evaluation des plateformes d’auto-adaptation
Synthèse
CHAPITRE 05: DESCRIPTEURS DES ELEMENTS DU SYSTEME D’ADAPTATION
Introduction
Définition des concepts
1. Multimédia
2. Contexte
3. Adaptation
Descripteurs
1. Descripteurs de données Multimédia
2. Descripteurs des traitements
Synthèse
CHAPITRE 06: CSC UNE PLATEFORME D’ADAPTATION DES APPLICATIONS BASEES COMPOSANTS
Introduction
Une Approche d’Adaptation pour l’Informatique Ubiquitaire : CSC (Component Service Connector)
1. Introduction à CSC
2. Description de CSC
L’infrastructure de la plateforme CSC
1. Couche Application
2. Couche Configuration
3. Couche d’Adaptation
Qualité de service dans CSC
1. Métamodèle pour la qualité des adaptations
2. Données multimédia et modèles de qualité
3. Calcul et évaluation des QdS
Processus d’adaptation dans la plateforme CSC
1. Définition du graphe d’adaptation
2. Optimisation du graphe d’adaptation
3. Choix du chemin d’adaptation
Synthèse
CONCLUSIONS & PERSPECTIVES
1. Rappel des principaux manques constatés dans l’état de l’art
2. Bilan
3. Perspectives
LISTE DES PUBLICATIONS
BIBLIOGRAPHIE
