Facult des Sciences de Tunis TELECOM et Management SudParis

Rapport de Stage lve Ingnieur en Informatique

I NGNIERIE

DIRIGE PAR LES MODLES ET COMPOSANTS SENSIBLES AU CONTEXTE

Mehdi Z AIER Responsable de stage : Chantal TACONET

Juin 2008

Ce stage dingnieur a t ralis au sein du laboratoire CNRS Samovar, quipe MARGE du dpartement Informatique de TELECOM et Management SudParis

Remerciements
Cest une tche trs agrable, mais bien dlicate, de prsenter mes remerciements tous ceux qui mont aid dans la ralisation de ce travail.

Quil me soit permis dexprimer en premier lieu ma gratitude Madame Chantal TACONET Matre de Confrences au TELECOM et Management SudParis (ex INT), qui a propos le sujet, a accept de mencadrer et ma fait proter de son savoir et de sa grande exprience. Quelle trouve, ici, le tmoignage de ma sincre reconnaissance et mes vifs remerciements.

Monsieur Samir MOALLA est lorigine de cette aventure . Comment doser, non seulement dans son enseignement, mais aussi dans les conversations que nous avons eues, lapport considrable dont jai bnci. Je le remercie aussi pour lintrt quil ma toujours manifest.

Ce travail sera examin et valu par mes chers professeurs, quils soient vivement remercier pour avoir accept de faire partie du Jury. Jexprime ma trs haute considration et mes vifs remerciements tous mes enseignants du Dpartement des Sciences de lInformatique pour les enseignements quils mont prodigus tout au long de mes annes de formation dans la lire Ingnieur en Sciences de lInformatique et en premire anne de Mastre de Sciences de lInformatique.

Ce travail a t ralis au sein de lquipe MARGE au Dpartement Informatique du TELECOM et Management SudParis, pendant une dure denviron 4 mois et demi. Je tiens donc tmoigner toute ma reconnaissance tous les

Enseignants, Personnels administratifs et techniques de cette Institution pour lassistance et laide quils mont prodigu pour raliser ce travail. Je remercie particulirement Messieurs Samir TATA, Denis CONAN, Bruno DEFUDE, Mesdames Sophie CHABRIDON, Brigitte HOUASSINE et mes collgues Zied, Mahmoud, Lon, Mounis, Salah, Mohamed, Soumaya, Wided, Ines, Marie, etc.

Durant mon sjour Evry, jai pu bncier dune allocation de la part du TELECOM et Management SudParis. cette occasion, je veux remercier tous les Responsables de cette Institution pour lensemble des facilits qui mont t offertes.

Je me dois de remercier vivement Messieurs Hassen AMRI et Khaled BSAIESS respectivement Doyen de la Facult des Sciences de Tunis et Directeur du Dpartement des Sciences de lInformatique davoir facilit ma mission. Il serait injuste de ne pas y associer Madame Dorra AMMAR GARGOURI Sous Directrice des Relations avec lEnvironnement, Insertion Professionnelle et Formation Continue lUniversit de Tunis El Manar.

De trs nombreuses personnes dont les noms ne sont pas cits mont aid, encourag, conseill. Jespre pouvoir un jour leur tmoigner ma reconnaissance.

Enn, je tiens exprimer mes affectueuses reconnaissances ma sur Sonia et mes parents pour laide et les encouragements quils mont prodigus particulirement tout au long de cette priode.

ii

Table des matires

Remerciements Introduction Gnrale 1 Problmatique et Objectifs du Stage 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Prsentation du projet CASAC . . . . . . . . . . . . . . . . . . . 1.2.1 Description du travail mettre en uvre . . . . . . . . . . . . . . . . i 1 4 4 5 6 7 8 9 10 10 12 12 13 15 17 18

1.2.2 Description des diffrentes tches raliser

1.3 Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Modlisation de contexte 2.1 Introduction aux Applications ubiquitaires . . . . . . . . . . . . . 2.2 Applications sensibles au contexte . . . . . . . . . . . . . . . . . 2.3 Modles de contexte : Objectifs et terminologie . . . . . . . . . . 2.3.1 Objectifs des modles de contexte . . . . . . . . . . . . . 2.3.2 Dnitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Modles de contexte et systmes sensibles au contexte . . . . . 2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Gestion des informations de contexte avec COSMOS

iii

3.1 Motivations et objectifs de COSMOS . . . . . . . . . . . . . . . . 3.2 Gestion de contexte . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Architecture du gestionnaire de contexte . . . . . . . . .

19 21 21 23 23 24 24 27 30 31 32 33 33 34 35 36 36 38 41 42 45 47 50 54

3.2.2 Composition dinformations de contexte avec COSMOS . 3.3 Nud de contexte . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Le concept nud de contexte . . . . . . . . . . . . . . . . 3.3.2 Proprits dun nud de contexte . . . . . . . . . . . . . 3.3.3 Architecture dun nud de contexte . . . . . . . . . . . . 3.4 Modle de composant Fractal . . . . . . . . . . . . . . . . . . . . 3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Mise en uvre 4.1 Description des mthodes proposes . . . . . . . . . . . . . . . 4.2 Prsentation des outils de dveloppement utiliss . . . . . . . . 4.2.1 Eclipse Modeling Framework (EMF) . . . . . . . . . . . . 4.2.2 Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Subversion (SVN) . . . . . . . . . . . . . . . . . . . . . . 4.2.4 JAVA Emitter Template (JET) . . . . . . . . . . . . . . . . 4.3 Prsentation du Mta-modle de sensibilit au contexte . . . . . 4.4 Description de la solution labore . . . . . . . . . . . . . . . . . 4.4.1 Modle conforme au mtamodle . . . . . . . . . . . . . 4.4.2 Diagramme de classes et dtail des fonctionnalits . . . . 4.4.3 Implmentation . . . . . . . . . . . . . . . . . . . . . . . . 4.4.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion et Perspectives

iv

Table des gures

3.1 Architecture de gestion de contexte . . . . . . . . . . . . . . . . . 3.2 Modle de composant Fractal . . . . . . . . . . . . . . . . . . . . 3.3 Modle de composant Fractal . . . . . . . . . . . . . . . . . . . . 4.1 Organisation gnrale dEMF . . . . . . . . . . . . . . . . . . . . 4.2 Les tapes de la gnration avec JET . . . . . . . . . . . . . . . 4.3 Les paquetages du mta-modle . . . . . . . . . . . . . . . . . . 4.4 Interactions modle-intergiciel . . . . . . . . . . . . . . . . . . . . 4.5 Entits et lments observables de notre modle . . . . . . . . . 4.6 Diagramme de classe de la solution envisage . . . . . . . . . . 4.7 Constructeur de la classe CAControlerDynamicModel . . . . . . 4.8 Mthode createAllBridges() . . . . . . . . . . . . . . . . . . . . . 4.9 Mthode createBridge() . . . . . . . . . . . . . . . . . . . . . . . 22 28 29 34 37 39 40 44 48 51 52 53

Introduction gnrale
Le prsent travail sinscrit dans le cadre de la ralisation dun projet de n dtude des lves ingnieurs en Sciences de lInformatique de la Facult des Sciences de Tunis. Il est ralis au sein de lquipe MARGE ( Middleware pour Applications Rparties avec Gestion de lEnvironnement ) au Dpartement Informatique de lInstitut TELECOM SudParis ; suite une convention tripartite signe entre le Dpartement Informatique de la Facult des Sciences de Tunis, le Dpartement Informatique TELECOM et Management SudParis et moi mme pour une dure denviron quatre mois et demi. Le Stage propos porte sur lIngnierie Dirige par les Modles et composants sensibles au contexte. Il entre dans le cadre dun projet de lInstitut TELECOM intitul CASAC (Composants Auto-adaptables Sensibles Au Contexte) dans lequel est aussi implique lquipe CAMA de TELECOM Bretagne. Lencadrement au dpartement informatique de lINT a t assur par Madame Chantal TACONET, Matre de confrences dans cette Institution.

Depuis quelques annes, nous assistons lmergence de nouvelles plates-formes distribues, qualies dubiquitaires, qui ne sont plus limites une interconnexion de stations de travail dnissant un rseau stable. Ces plates-formes intgrent ventuellement des machines puissantes et robustes mais aussi, et de plus en plus, des quipements mobiles et faibles ressources (ordinateurs portables, PDA, tlphones mobiles, capteurs ...). Bien que ce type de rseaux soit de plus en plus rpandu, leur exploitation effective constitue encore un d. Il reste en effet difcile de construire, de dployer et de maintenir des applications distribues dans les environnements pervasifs en tenant compte de lhtrognit, de la mobilit ou de la volatilit des 1

quipements. Dans un contexte gnral o la mobilit des utilisateurs et lubiquit des applications se gnralisent, les fournisseurs de logiciels souhaitent offrir des applications adaptables, appeles aussi applications sensibles au contexte ; cest dire dont la structure ou le comportement change en fonction de situations de contextes. Les modles et plates-formes de composants logiciels actuels ne permettent ladaptation au contexte que par un contrleur extrieur. Cette approche ne permet pas aux composants adaptables dtre auto-sufsants. Cela rend plus complexe lcriture et la maintenance des applications adaptables et diminue grandement la possibilit de rutiliser un composant (adaptable) dune application dans une autre.

Suite ce constat, le projet CASAC sest intress proposer une approche gnrique pour permettre un composant de devenir sensible au contexte. Pour cela, le composant fournit une description des informations de contexte dont il a besoin. La plate-forme dexcution peut alors synthtiser les sondes ncessaires la collecte de ces informations. Ainsi, le contrle de ladaptation du composant peut tre embarqu dans le composant lui-mme qui devient alors un composant auto-adaptable. Les solutions proposes et dveloppes durant ce stage sintgrent dans un cadre logiciel gnrique pour le dveloppement et lexcution des applications sensibles au contexte. Lapproche explore dans ce stage consiste intgrer la sensibilit au contexte ds la modlisation de lapplication. Il sagit de dnir dans la phase de modlisation des applications, les observables collecter, les situations dadaptation identier et les ractions dadaptation.

Un mta-modle de sensibilit au contexte a t ainsi propos pour cela par lquipe MARGE du Dpartement Informatique de lInstitut Tlcom SudParis.

Ce mta-modle sera utilis pour explorer les modles dapplications pour gnrer une partie du code ncessaire la gestion de la sensibilit au contexte de lapplication. Lobjectif de notre travail durant cette priode de stage est dtendre le mta-modle de sensibilit au contexte dune part et dcrire des gnrateurs de code de gestion de sensibilit au contexte dautre part.

Dans un premier temps, ce mta-modle sera revu et complt au vu des besoins exprims pour lexpression de compositions de contextes et pour modliser des ractions dadaptation qui seront mises en uvre dans la membrane dun composant pour quil devienne sensible au contexte. Dans un deuxime temps, le modle de sensibilit au contexte propre un composant applicatif servira la gnration de code extra-fonctionnel de la membrane du composant auto-adaptable pour la liaison avec des sondes dobservation et pour la ralisation des adaptations.

Nous commenons dans ce rapport par dtailler, dans un premier chapitre, la problmatique et les objectifs du projet. Dans le deuxime chapitre, nous dnissons la sensibilit au contexte ainsi que la modlisation du contexte qui sont les lments cls de notre travail. Dans le troisime chapitre, nous dcrivons le composant COSMOS et la manire avec laquelle il gre les information de contexte. Il sagit dun type de collecteur de contexte qui utilise les lments observables an de collecter linformation de contexte et permettre lapplication de sadapter aux diffrents changements. Nous dtaillons dans le quatrime chapitre notre dmarche et le processus de dveloppement que nous avons adopt pour introduire la sensibilit au contexte au niveau dun composant. Enn, nous terminons par la conclusion et les perspectives de nos travaux.

Chapitre 1 Problmatique et Objectifs du Stage

Pour commencer, nous prsentons dans la premire section, le projet CASAC ainsi que les motivations pour lesquelles ce projet a t mis en uvre. Nous dtaillons, dans la deuxime section, les diffrents lots quil comporte et nous situons notre travail par rapport ces diffrents lots. La troisime section cite les diffrents impacts attendus par notre projet.

1.1 Motivation
Dans un contexte gnral o la mobilit et lubiquit deviennent des exigences des utilisateurs, les fournisseurs de logiciels souhaitent pouvoir offrir des applications adaptables leurs clients. Or, les technologies et mthodes actuelles tant assez rudimentaires, le cot de ralisation dune application adaptable est relativement lev (par rapport aux autres types dapplications). Pire encore, les composants adaptables sont difciles rutiliser dans le cadre dautres applications ou dautres plates-formes. 4

Globalement, lobjectif du projet est de faciliter la ralisation dapplications adaptables et donc, den diminuer le cot de ralisation. Pour cela, il sera question de :

Rendre plus simple la conception de composants (et donc dapplications) auto-adaptables ; Sparer les proccupations entre lobservation des donnes de lenvironnement et leur utilisation pour dcider des adaptations ventuellement ncessaires ; Rendre dclarative la dnition de lobservation par le composant. Le langage employ doit tre simple, donc ddi au domaine, an denvisager par la suite dajouter une analyse de la cohrence des informations de contexte obtenues ; Rendre explicite les exigences dobservation du contexte au sein de larchitecture.

1.2 Prsentation du projet CASAC

Le contenu du projet CASAC couvre trois lots. Le premier lot concerne la dnition dun langage de description dobservation du contexte. Il sagit donc de dnir un langage ddi qui facilite la composition dinformations de contexte. Le deuxime Lot consiste introduire la notion de qualit dans les observations de contexte an de les rendre plus prcises et ainsi amliorer ladaptation. Le troisime lot, qui relie les deux autres tudes, applique une approche dingnierie des modles pour modliser la sensibilit au contexte dans des composants applicatifs. Le prsent travail sintresse au troisime lot. Nous dcrivons dans 5

la premire sous-section ce troisime lot. la deuxime sous-sction dtaille les diffrentes tches quil contient. la n, nous consacrons une section pour prsenter les impacts attendus par ce projet.

1.2.1 Description du travail mettre en uvre

Lingnierie logicielle dirige par les modles permet de sparer les proccupations mtier, des proccupations lies aux plates-formes dexcution. La logique mtier de lapplication est dcrite un niveau dabstraction lev. Grce aux techniques de transformation de modles, le modle de lapplication permet de produire une partie du code de lapplication. Certaines des adaptations au contexte de lapplication doivent tre dnies au niveau du modle de lapplication. Lapproche adopte consiste intgrer dans le processus de modlisation de lapplication une phase de dnition de sa sensibilit au contexte. Le mta-modle de contexte propos dans CASAC dnit les mta-classes de dnition de contexte, ainsi que leurs associations avec les lments du mta-modle de lapplication qui dnissent leurs politiques dadaptation.

Le mta-modle de contexte labor par lquipe MARGE durant un autre projet intitul ITEA S4ALL (Services-for-All) sera donc repris et tendu pour les besoins du projet CASAC. Le modle de sensibilit au contexte de chacun des composants applicatifs sera utilis par la chane de production de la membrane du composant Fractal auto-adaptable : pour la liaison avec des sondes dobservation des collecteurs de type COSMOS et pour la ralisation des adaptations.

1.2.2 Description des diffrentes tches raliser

La premire tche tant de bien tudier le mta-modle de contexte fourni, de le revoir et le complter au vu des diffrents besoins pour lexpression de politiques de contexte COSMOS ainsi que pour modliser des ractions dadaptation qui seront mises en uvre dans la membrane Fractal pour quil devienne sensible au contexte.

partir de ce mta-modle, il sagit de construire pour une application donne, un modle conforme ce mta-modle. Le modle construit nous permet de connatre la liste des nuds de contexte et leur mode dinteraction avec lapplication. Le modle dirige aussi les diffrentes interactions avec les collecteurs COSMOS.

Parmi les principales interactions entre lapplication et les collecteurs, nous citons titre dexemple : La dtermination des diffrents lments observables associs au modle de lapplication. Lenregistrement auprs des nuds de contexte COSMOS an de recevoir les notications concernant les variations. ventuellement, lobservation directe de ces nuds de contexte, si lapplication a besoin de savoir ltat de son environnement. La gestion des diffrents types de messages COSMOS reus et la ralisation des tches prvues pour chacun de ces types de messages.

Nous distinguons deux modes dutilisation du modle : Utilisation dynamique pendant linitialisation du composant. Il sagit dans cette mthode de parcourir dune manire gnrique le modle crit avec 7

les APIs gnres par le mta-modle. Cette mthode offre la possibilit de modier le modle pendant lexcution pour une meilleur adaptation. Utilisation statique lors de la compilation pour la gnration du code dinteraction. Le code gnr avec cette mthode est spcique lapplication. Il sagit dun code rduit transportable sur petit matriel.

Il sagit de raliser les deux mthodes an de comparer les rsultats trouvs en terme de temps dexcution et dempreintes mmoires.

1.3 Impact
Les rsultats attendus du projet sont de nature enrichir loffre existante en termes de composants logiciels avec sensibilit au contexte. Ceci vise faciliter le dveloppement dapplications dans de nombreux domaines tels que linformatique ubiquitaire, les rseaux ambiants, la tlsurveillance, et ouvre la voie de multiples applications tirant parti de la sensibilit au contexte. Des exemples de telles applications sont les guides touristiques avec navigation contextuelle, les applications dannotations contextuelles ou encore les applications avec enrichissement contextuel et ralit augmente telles que les jeux multi-joueurs. Depuis quelques annes, de nombreux projets internationaux se sont intresss la sensibilit au contexte des applications.

La particularit du projet est dintgrer la modlisation de la sensibilit au contexte dans la phase de conception des applications et dutiliser ces descriptions pendant lexcution pour diriger la sensibilit au contexte.

Chapitre 2 Modlisation de contexte

Il existe de nombreux travaux lis la modlisation de contexte. Cest pourquoi cette tude commence par une prsentation des domaines de la modlisation. Ltude de recherche prsente ici sappuie sur ltat de lart dun projet intitul CAPUCCINO ( Construction et Adaptation daPPlications Ubiquitaires et de Composants dINtergiciels en environnement Ouvert pour lindustrie du commerce ) [11].

Dans ce chapitre, nous dtaillons les travaux de la modlisation de contexte. La premire section introduit la notion dapplications ubiquitaires ainsi que limportance de ladaptation au contexte pour ce genre dapplication. La deuxime section sintresse aux applications sensibles au contexte et aux mcanismes quelles emploient pour assurer leurs adaptations. Nous dtaillons dans la troisime section la notion du modle du contexte et nous prsentons diffrentes dnitions an de clarier cette notion. Dans la dernire section, nous faisons le lien entre les modles de contexte et les systmes sensibles au contexte .

2.1 Introduction aux Applications ubiquitaires

La multiplication des terminaux mobiles et la gnralisation des rseaux sans l ncessitent des changements dans la manire dont les applications logicielles sont conues et exploites. Ce nouveau d, appel informatique ubiquitaire, soulve de nombreux problmes savoir lhtrognit des quipements, la limite des ressources, la distribution des applications, la mobilit des terminaux, la scurit, la dcouverte des services, le dploiement automatique du logiciel sur le terminal, etc. Il nexiste actuellement pas de solution gnrale qui couvre le cycle complet du processus de construction des applications ubiquitaires, de la conception lexploitation.

An dadapter ces applications aux diffrents contextes, il faut leur fournir de nouvelles informations en plus de celles quelles traitent. Lapplication doit donc avoir conscience de lenvironnement dans lequel elle sexcute, sur quel type de terminal, de quel type de rseau elle dispose pour la communication, quel endroit se situe le terminal mobile. Toutes ces informations constituent le contexte dexcution de lapplication et forment un nouveau type dinformation traiter.

2.2 Applications sensibles au contexte

Les applications ubiquitaires sont caractrises par le fait quelles sexcutent dans des environnements variables. La modlisation de contexte doit donc permettre de reprsenter de manire abstraite les diffrents environnements dexcution de ces applications, an didentier les contextes dexcution des applications, et aussi de dnir la sensibilit des applications

10

 leur contexte dexcution. Dans cette section nous prsenterons la notion dapplication sensible au contexte, la terminologie et les exigences en ce qui concerne la modlisation de contexte.

Les applications sensibles au contexte sont, daprs la dnition de Brown [2], des applications dont le comportement peut varier en fonction du contexte. Dans le cadre des applications sensibles au contexte, Dey [7] a fourni cette dnition du contexte : Le contexte est toute information qui peut tre utilise pour caractriser la situation dune entit. Une entit est une personne, un lieu, ou un objet qui est considr comme pertinent pour linteraction entre un utilisateur et une application, incluant lutilisateur et lapplication elle-mme . Suivant la dnition de Dey, le contexte peut caractriser lapplication elle-mme, mais aussi des entits extrieures lapplication. Les informations de contexte peuvent ainsi tre de nature diverse. Dans les applications traditionnelles, seuls les utilisateurs interagissent avec lapplication. Dans les applications sensibles au contexte, lapplication peut voluer aussi avec le contexte dans lequel elle sexcute.

De manire ce quune application soit sensible au contexte, il faut la doter de mcanismes qui lui permettent dobtenir et danalyser les informations de contexte en premier lieu et puis de raliser les adaptations aux situations de contexte dans un second lieu. Lors du dveloppement des premires applications sensibles au contexte, le dveloppeur de lapplication grait entirement la sensibilit au contexte depuis linteraction avec les capteurs dacquisition des donnes de contexte jusquaux oprations dadaptation. Linconvnient de cette approche est que le fort couplage entre les capteurs et lapplication rend difcile la modication des applications lors de changement de technologies de

11

capteurs par exemple.

Les intergiciels (en anglais, Middleware) de nouvelles gnrations doivent faciliter le dveloppement dapplications sensibles au contexte et prendre en charge une partie de la gestion de la sensibilit au contexte. Cette prise en charge ne peut senvisager que si lintergiciel peut sappuyer sur des services de gestion de contexte qui eux-mmes peuvent sappuyer sur la modlisation des informations de contexte. Lintergiciel, lui-mme, peut sappuyer sur ces techniques pour tre sensible au contexte. Sappuyer sur un modle de contexte doit permettre dajouter plus facilement de nouveaux types de contexte, de nouveaux types de capteurs, de nouvelles techniques danalyse de situations de contexte, et de nouveaux modes dadaptation et de sensibilit au contexte dans les applications.

2.3 Modles de contexte : Objectifs et terminologie

2.3.1 Objectifs des modles de contexte
La modlisation de contexte permet de dnir, pour chaque application, les contextes qui ont une inuence sur lapplication et les interactions entre le contexte et lapplication. Cette modlisation dpend bien sr du contexte mme o lapplication est utilise et de la nalit de la modlisation. La question qui se pose est de savoir si il est prfrable davoir une modlisation de contexte ddie une application ou une classe dapplications, ou plutt une modlisation gnrique applicable tout type dapplication. Le modle gnrique est probablement une qute impossible, cependant il semble intressant davoir 12

une base ou un support de modlisation commun.

Le cur de modlisation doit tre sufsamment ouvert pour que des extensions puissent tre ajoutes pour diffrents domaines dapplications. Il est souhaitable que le modle de contexte puisse voluer pendant le cycle de vie de lapplication. Lapplication doit pouvoir puiser les informations ncessaires son adaptation sans pour autant quil soit ncessaire de toucher au code mtier de lapplication.

2.3.2 Dnitions
Les dnitions suivantes seront utilises pour parler des lments dcrits dans notre modle de contexte.

Systme sensible au contexte Un systme sensible au contexte est un systme dont le comportement ou la structure peut varier en fonction de ltat de lespace des informations de contexte . Le terme espace des informations de contexte est dni ci-dessous. Le terme systme sensible au contexte est plus gnral que applications sensibles au contexte. Le systme peut tre une application, mais aussi lintergiciel ou le systme dexploitation. Les dnitions qui suivent sont relatives un systme sensible au contexte.

Entit (observable) lment reprsentant un phnomne physique ou logique (personne, concept, etc.) qui peut tre trait comme une unit indpendante ou un membre dune catgorie particulire, et auquel des lments observables (terme dni ci-dessous) peuvent tre associs.

13

(lment) Observable Un lment observable est une abstraction qui dnit un type dinformations observer. Pour un systme donn, un lment observable est rattach une entit observable. Un lment observable donne lieu des observations (dni ci-dessous). Par exemple, partir de lentit observable terminal , sont associs les lments observables suivants : mmoire vive disponible (type entier), liste des dispositifs dinteraction avec lutilisateur (type : ensemble de chanes de caractres), liste des connexions rseaux (type : ensemble de chanes de caractres), connexion rseau disponible (type boolen).

(lment) Observable Composite Un lment observable composite est un lment observable dont les observations sont obtenues par une fonction prenant en entre les observations dun ou plusieurs lments observables.

Observation Chaque lment observable est associ une ou plusieurs observations, chaque observation dnit un tat de llment observable.

lment observable immuable Un lment observable immuable est un lment observable dont les observations auront la mme valeur pendant toute la dure de vie du systme.

Espace des informations de contexte Lespace des informations de contexte dun systme est caractris par ltat des diffrents lments le caractrisant : les entits observables, les lments observables et ltat des observations attaches aux lments observables.

Situation dadaptation Une situation dadaptation est un lment obser-

14

vable qui permet de reprer un changement dtat dans lespace des informations de contexte. Ce changement dtat signicatif pour le systme ncessite une raction dans le systme. Cette raction est appele adaptation. Une situation dadaptation est un lment observable dont les changements dtat gnrent une modication dans le systme sensible au contexte.

2.4 Modles de contexte et systmes sensibles au contexte

Nous parlons de mta-modles de contexte pour la dnition de la structure des informations de sensibilit au contexte (quels sont les lments qui seront prsents dans le modle et quelles sont les relations entre ces diffrents lments).

Nous parlons de modles de contexte pour dcrire les informations propres une application ou un domaine dapplication. Un modle dcrira par exemple les entits observables et les lments observables dun systme donn. Les instances de modles correspondront quant eux une ralit pendant les diffrentes excutions de systmes sensibles au contexte (une instance par excution). Pendant une excution, nous observons non pas un terminal mais le terminal utilis par lutilisateur X.

Un modle de contexte utilis par un intergiciel, doit non seulement identier les entits observables, les lments observables, mais aussi, tre complt pour dcrire les mthodes de collecte du contexte, les lments permettant lanalyse de situations dadaptation et les informations permettant de raliser

15

les adaptations des applications pour quil puisse raliser la prise en compte de la sensibilit au contexte des applications.

Notre mta-modle se diffrencie par les entits du modle mais aussi par les relations exprimes entre ces diffrents lments. Les relations entre les diffrents lments du modle sont essentielles pour parcourir les diffrents lments du modle. Elles sont dterminantes pour lutilisabilit du mtamodle.

Certains systmes sensibles au contexte ont seulement besoin didentier un prol dutilisation. Par exemple, certaines applications ont besoin leur dmarrage de connatre le type du mobile sur lequel elles sont utilises. Pour ces applications, il sagit didentier les caractristiques immuables du mobile sur lesquelles elles sont utilises. Pour ces applications, une interrogation du prol du terminal mobile utilis leur permet dadapter leur conguration. Dautres systmes doivent tre utiliss avec un gestionnaire ou collecteur de contexte. Dans ce dernier cas, le modle de contexte peut dnir les interactions entre lapplication et le collecteur de contexte : identication des collecteurs de contexte, identication du mode dinteraction synchrone/asynchrone, priodicit des interactions, qualit des informations collectes.

Certains mta-modles de contexte permettent danalyser lespace des informations de contexte an didentier des situations dadaptation. Cest le cas des ontologies utilises conjointement avec un moteur dinfrence qui laide de rgles permettent didentier des situations dadaptation en parcourant les instances de modle de contexte.

16

Enn, un mta-modle de contexte peut tre complt par un mta-modle de sensibilit au contexte qui permet de dnir les adaptations du systme qui pourront tre appliques en fonction de situations dadaptation.

2.5 Conclusion
Ce chapitre nous a permis de bien assimiler la notion de la modlisation de contexte qui dnit pour chaque application, les entits observables, les lments observables ainsi que les situations dadaptations permettant lapplication de tenir compte des diffrents changements et de sadapter en consquence. Introduire cette notion dadaptation depuis la phase de modlisation, permet une meilleure gestion de la sensibilt au contexte des applications surtout dans un environnement ubiquitaire.

17

Chapitre 3 Gestion des informations de contexte avec COSMOS

Dans notre travail, nous utilisons un ensemble de collecteurs dinformations de contexte an de dterminer les diffrentes variations des lments observer et ainsi permettre lapplication de prendre conscience de ces diffrentes variations. Nous travaillons avec des collecteurs de type COSMOS ( COntext entitieS coMpositiOn and Sharing ) qui est une proposition de Conan [4]. Il sagit dun collecteur qui compose linformation de contexte et permet de construire des gestionnaires de contexte dans des environnements ubiquitaires. Nous dtaillons dans ce chapitre ce collecteur COSMOS. La premire section prsente ses motivations et ses objectifs. La deuxime section, dnit la faon avec laquelle COSMOS gre les informations de contexte. La troisime, dtaille le nud de contexte, qui est le concept cl de COSMOS, elle montre ses proprits et son architecture. La dernire section dcrit le modle de composant Fractal sur lequel COSMOS se base.

18

3.1 Motivations et objectifs de COSMOS

Comme nous avons dja mentionn dans le chapitre prcdent, les environnments ubiquitaires imposent des contraintes fortes sur la conception et le dveloppement des applications. Ces applications doivent continuellement grer le contexte dans lequel elles sexcutent an de dtecter les situations dadaptation [5]. Nous rappelons que le contexte est constitu de diffrentes catgories dentits observables (ressources logicielles telles que les ressources systme et les prfrences des utilisateurs, et ressources matrielles telles que les capteurs), des rles de ces entits dans le contexte et des relations entre ces entits.

La prise de dcision pour dclancher une adaptation au contexte est un problme complexe pour lequel peu de solutions existent. Cette dcision repose sur une collecte, une analyse et une synthse des nombreux paramtres physiques et logiques fournis par le contexte dexcution [13, 6, 5]. Pour cela, COSMOS a t propos pour la gestion des informations de contexte. Il sagit dun canevas logiciel orient composant pour la gestion dinformations dans des applications sensibles au contexte. Il permet de construire des gestionnaires de contexte en environnements ubiquitaires. Cette gestion de contexte ne peut pas tre transparente aux applications, au risque dtre contre-productive pour certaines dentre elles en ne prenant pas en compte leur smantique. Lapplication et lintergiciel doivent donc sorganiser [10]. Pour organiser cette organisation, le paradigme composant/conteneur est bien adapt. Lintergiciel surveille les ressources et signale au composant de lapplication tout changement signicatif via le conteneur. Le composant de lapplication, quant lui, fournit les politiques de gestion de contexte par

19

lintermdiaire de son conteneur.

COSMOS est dvelopp selon trois principes, savoir : la sparation entre les activits de collecte et de synthse des donnes de contexte, lorganisation des politiques de gestion de contexte en assemblages de composants logiciels et enn lutilisation systmatique de patrons de conception. Loriginalit de COSMOS est lexpression de la composition de contexte dans un langage de dnition darchitecture logicielle. Ainsi, les objectifs de COSMOS sont clairement identis : Composer des informations de contexte de manire dclarative grce un langage ddi au domaine. Ceci doit faciliter la conception par composition, ladaptation et la rutilisation des politiques de gestion de contexte ; Isoler chaque couche de larchitecture de gestion de contexte des autres couches an de promouvoir la sparation des proccupations et des cycles de vie des informations de contexte ; Fournir les concepts systme pour grer nement les ressources consommes par les diffrents traitements.

COSMOS est utilis pour adapter les applications. Il est conu de faon tre lui-mme adaptable selon le besoin. Il facilite la conception, la composition, ladaptation et la rutilisation des politiques de gestion de contexte. La puissance de COSMOS lui permet dtre appliqu mme pour la composition dinformations de contexte de ressources systme (processeur, mmoire, rseau, etc.).

20

3.2 Gestion de contexte

Dans cette section nous prsentons larchitecture de gestion de contexte et nous introduisant par la suite le concept de Composition dinformations de contexte avec COSMOS.

3.2.1 Architecture du gestionnaire de contexte

Larchitecture globale du gestionnaire de contexte inspire de [5, 6, 13] prsente 3 niveaux (comme le montre la gure 3.1). Les briques de base les plus proches du systme dexploitation sont la rication des ressources systme, des capteurs proximit du terminal et des prfrences de lutilisateur, et la distribution des informations de contexte dans le rseau de terminaux mobiles. Ces canevas logiciels fournissent les donnes de contexte la base du traitement par ce qui est appel processeur de contexte. La sensibilit au contexte de lapplication, quant elle, est gre par les conteneurs des composants applicatifs. Dans la boite la plus haute.

En termes de fonctionnalits, la rication des ressources systme permet de collecter des donnes brutes, souvent numriques, comme la qualit du lien rseau. Le processeur de contexte en dduit des informations de contexte de plus haut niveau, souvent des donnes symboliques comme le mode de connectivit (connect, partiellement connect ou dconnect) et permet didentier des situations comme la perte prochaine de la connectivit rseau. Les politiques dadaptation, quant elles, sont gnralement gres en collaboration avec lapplication au niveau du conteneur : par exemple, lexploitation consiste avertir lutilisateur du mode de connectivit laide dun icne ddi.

21

F IG . 3.1 Architecture de gestion de contexte

COSMOS introduit des cycles indpendants collecte / interprtation / identication de situations dans chacune des couches de larchitecture (cf. partie droite de la gure 3.1). Donc, de tels cycles complets sont prsents dans les collecteurs de contexte, plusieurs autres dans le processeur de contexte, et de mme pour le conteneur sensible au contexte. En dautres termes, cela revient ajouter dans chaque couche o boite une notion de temps dans lidentication de situations.

Dans COSMOS, les diffrentes couches sont indpendantes quant la gestion des ressources systme (mmoire, activits) quelles consomment pour leurs traitements. Ainsi le systme obtenu est faiblement coupl et facilement recongurable par les concepteurs de gestionnaires de contexte et dapplications sensibles au contexte.

22

3.2.2 Composition dinformations de contexte avec COSMOS

Cosmos sappuie sur les principes de base de construction dintergiciels : le canevas logiciel est construit partir dlments gnriques, spcialisables et modulaires an de composer plutt que de programmer. Il sagit donc dune approche base de composants.

Cette approche apporte une vision unie dans laquelle les mmes concepts (composant, liaison, interface) sont utiliss pour dvelopper les applications et les diffrentes couches intergicielles et systme sous-jacentes. Cette vision unie en facilite galement la conception et lvolution. Elle autorise galement une vision hirarchique dans laquelle lensemble canevas et application peut tre vu diffrents niveaux de granularit.

Par ailleurs, la notion darchitecture logicielle associe lapproche oriente composant permet dexprimer la composition des entits logicielles indpendamment de leurs implantations, rendant ainsi plus aise la comprhension de lensemble. La notion darchitecture logicielle favorise aussi la dynamicit en autorisant la rednition des liaisons de tout ou partie du canevas, voire de lapplication lexcution. La reconguration et ladaptation des contextes nouveaux non prvus au dpart en sont facilites.

3.3 Nud de contexte

Dans cette section, nous dtaillons le nud de contexte qui est le concept de base de COSMOS.

23

3.3.1 Le concept nud de contexte

Un nud de contexte est une information de contexte modlise par un composant. Les nuds de contexte sont organiss en une hirarchie avec possibilit de partage. Tous les composants de la hirarchie sont potentiellement accessibles par les clients de COSMOS. Ce sont tous des composants composites. Le concept de nud de contexte est le concept structurant du canevas logiciel COSMOS :

Un nud de contexte est reprsent par un composant et la composition dinformations de contexte par un graphe (hirarchie avec partage) de composants. Les relations entre les nuds sont donc des relations dencapsulation. Le graphe reprsente lensemble des politiques de gestion de contexte utilises par les applications clientes du gestionnaire de contexte.

Le partage de nuds de contexte correspond la possibilit de partage ou dutilisation dune partie dune politique de gestion de contexte par plusieurs politiques. Les nuds de contexte feuilles de la hirarchie encapsulent les informations de contexte lmentaires, par exemple les ressources systme du terminal (mmoire vive, qualit du lien WiFi, etc.). Leur rle est disoler les infrences de contexte de plus haut niveau, qui deviennent donc indpendantes du canevas logiciel utilise pour la collecte des donnes brutes.

3.3.2 Proprits dun nud de contexte

Passif ou actif Chaque nud peut tre passif ou actif avec excution priodique de tches dans des activits. Un nud passif est un nud de traitement utilis par des activits extrieures au nud qui linterrogent pour obtenir

24

une information. Un nud actif peut contrario initier un parcours du graphe. Le cas dutilisation le plus frquent des nuds actifs est la centralisation de plusieurs types dinformations et la mise disposition de ces informations an disoler une partie du graphe daccs multiples trop frquents.

Observation ou notication Les rapports dobservation contenant les informations de contexte circulent du bas vers le haut de la hirarchie dans des messages (dont les constituants lmentaires sont typs). Lorsque la circulation seffectue la demande dun nud parent ou dun client, cest une observation (en anglais pull) ; dans le cas contraire, cest une notication (en anglais push).

Passant ou bloquant Lors dune observation ou dune notication, le composant qui traite la requte peut tre passant ou bloquant. Lors dune observation, un nud de contexte passant demande dabord un nouveau rapport dobservation ses enfants, puis calcule un rapport dobservation pour le transmettre (en retour) vers le haut de la hirarchie.

Lors dune notication, un nud de contexte passant calcule un nouveau rapport dobservation avec la nouvelle notication, puis passe vers le haut ce rapport en notiant ses parents. Dans le cas bloquant, le nud observ fournit linformation de contexte quil dtient sans observer les nuds enfants, et le nud noti modie son tat interne sans notier les nuds parents.

Enn, lorsque les informations de contexte des nuds enfants ne peuvent pas tre collectes, par exemple parce que la ressource systme interface rseau WiFi nexiste pas, une exception est remonte vers les nuds parents.

25

La remonte de cette exception peut bien sur tre bloque par un nud de contexte donn pour masquer lindisponibilit de linformation de contexte aux nuds parents.

Oprateur Un nud de contexte rcupre des informations de contexte de nuds enfants de la hirarchie et infre une information de plus haut niveau dabstraction en appliquant un oprateur. COSMOS propose des oprateurs gnriques classs selon la typologie de [9] : oprateurs lmentaires pour la collecte, oprateurs mmoire comme le calcul de la moyenne, de traduction de format, de fusion de donnes avec diffrentes qualits, dabstraction ou dinfrence comme ladditionneur , et oprateurs a seuil comme un dtecteur de connectivit [12] ou un valuateur de prol nergie, dure prvisible de connexion, espace mmoire [1] .

Il est noter que, dans une architecture de gestion de contexte classique, les premiers oprateurs lmentaires pour la collecte feraient partie de la couche collecte et la plupart des autres oprateurs de la couche interprtation tandis que les derniers oprateurs seuil seraient dans la couche identication de situations . Dans COSMOS, ils peuvent tre utiliss dans toutes les couches.

Cycle de vie et gestion des ressources Tous les nuds de contexte de la hirarchie sont grs nement, tant au niveau de leur cycle de vie quau niveau de la gestion des ressources quils consomment. Le cycle de vie des nuds de contexte enfants est contrl par les nuds de contexte parents. Pour la gestion des taches, les nuds de contexte actifs enregistrent leurs taches auprs dun gestionnaire dactivits. Ainsi, le gestionnaire dactivits, lui-mme

26

paramtrable, peut crer une activit par tache (observation ou notication) ou bien une activit par nud de contexte actif ou encore une activit pour tout ou partie de la hirarchie. Pour la consommation despace mmoire, un gestionnaire de messages gre des rserves (en anglais, pools) de messages et autorise aussi bien les duplications par rfrence que par valeur .

Nommage Pour faciliter les parcours dans le graphe et les recongurations, les nuds de contexte possdent un nom. Puisque un gestionnaire de contexte construit avec COSMOS est local un terminal, les noms sont locaux. Ces noms doivent aussi tre uniques.

3.3.3 Architecture dun nud de contexte

Avant de prsenter larchitecture dun nud de contexte, nous introduisons quelques concepts gnraux et les notations graphiques utilises pour lapproche composant.

Comme prsent dans la gure 3.2, un composant est une entit logicielle qui fournit et requiert des services. Ces services sont regroups au sein dinterfaces. Il y a deux types dinterfaces, celle dites serveur qui fournissent des services, des celle dites client qui sont la spcication des services requis. Un composant possde un contenu. Celui-ci peut tre compos dun ensemble de sous-composants. Dans ce cas, le composant est dit composite. Au dernier niveau, les composants sont dits primitifs. Il est ainsi possible de construire des hirarchies de composants offrant une vision avec diffrents

27

F IG . 3.2 Modle de composant Fractal niveaux de granularit.

Les composants inclus dans plusieurs Composites sont dits partags. Cette notion reprsente de faon naturelle le partage de ressources systme (segments de mmoire, activits [en anglais, threads], etc.). Les composants sont assembls laide de liaisons. Une liaison reprsente un chemin de communication entre deux composants, plus prcisment entre une interface requise (client) et une interface fournie (serveur) compatible. Enn, les compositions de composants sont dcrites avec un langage de description darchitecture (ADL pour Architecture Description Language).

Architecture dun nud de contexte Toutes les informations de contexte sont des composants tendant le composite abstrait ContextNode (cf. gure 3.3). Les interfaces Pull et Push sont respectivement, les interfaces pour lobservation et la notication. Les rapports dobservation sont des messages, constitus de sous-messages et de blocs (en anglais, chunks) types. Dans COSMOS, 28

toutes les informations lmentaires des rapports dobservation des entits observables lies aux collecteurs donnent lieu un bloc type : par exemple, la qualit du lien rseau WiFi est mmorise dans un bloc de type LinkQualityChunk.

F IG . 3.3 Modle de composant Fractal

Les possibilits de conguration des nuds de contexte sont exprimes par des attributs au niveau du composant primitif ContextOperator. Ainsi, le composant ContextNode est spcialisables via des attributs pour la gestion des taches dobservation et de notication, et pour la proprit passant/bloquant. Par dfaut, les nuds sont passifs et passants pour lobservation et la notication.

Les nuds de la hirarchie se classent ensuite en deux catgories : les feuilles et les autres. Pour les feuilles, le ContextNode est tendu pour contenir, en plus de loprateur et des gestionnaires dactivits et de messages, un composant primitif qui encapsule laccs la couche du dessous dans larchitecture en couches du gestionnaire de contexte. Cette couche peut tre le 29

systme dexploitation ou un autre canevas logiciel construit ou non laide de COSMOS.

3.4 Modle de composant Fractal

Fractal [3]est un modle de composant du consortium ObjectWeb pour le domaine des intergiciels en logiciel libre. Cest un modle de composant hirarchique, indpendant des langages de programmation et extensible. Contrairement aux modles de composant EJB, CCM ou COM+/.NET, le modle de composant Fractal ne suppose pas que les services techniques fournis aux composants soient gs. Tout composant Fractal est sous la responsabilit dune membrane. Celle-ci est compose dun ensemble de contrleurs. Chaque contrleur fournit un service technique lmentaire. Il existe ainsi de faon standard des contrleurs pour grer les liaisons, le cycle de vie ou les attributs des composants. De nouveaux contrleurs et de nouvelles membranes peuvent tre dvelopps. Les composants sont alors adaptables des domaines ou des environnements dans lesquels les services techniques varient. Plusieurs implantations du modle de composant Fractal existent dans diffrents langages de programmation : Java, C, C++... Le modle de composant Fractal est associ au langage de description darchitecture appel Fractal ADL. Bas sur une syntaxe XML, ce langage permet dexprimer des assemblages de composants Fractal. La dnition du type du document (DTD pour Document Type Denition) et la chane de traitement de ce langage peuvent tre tendues.

Plusieurs bibliothques de composants Fractal existent. COSMOS utilise particulirement la bibliothque Dream [8]. Celle-ci permet de construire des systmes orients message et de grer de faon ne des activits concur30

rentes organises en rserves (pool). Dream est un systme faiblement coupl, dynamique et recongurable. Les composants de contexte ContextNode actifs enregistrent leurs taches auprs dun gestionnaire dactivits Dream (ActivityManager) via un contrleur, un second contrleur servant alors appeler priodiquement les taches (observation ou notication). Le gestionnaire dactivits est charg de faire la correspondance entre les taches dnies par les composants et les units concrtes dexcution fournies par le systme (typiquement des activits). Cette correspondance peut tre mise en uvre de diffrentes faons, par exemple en attribuant des priorits diffrentes aux tches ou en excutant les tches laide dune rserve dactivits. En outre, le gestionnaire de messages Dream (MessageManager) est aussi utilis.

3.5 Conclusion
Ce chapitre nous a permis de comprendre le composant COSMOS. Ce composant reprsente le collecteur dinformations de contexte qui permet lapplication dtre sensible au contexte. Ce chapitre nous a aussi permis dassimiler la faon avec laquelle COSMOS compose linformation de contexte. Cette information de contexte est parmi les lmnts cls de notre projet.

31

Chapitre 4 Mise en uvre

Nous rappelons que lobjectif principal de notre travail, est de rendre un composant donn sensible au contexte. Cette sensibilit au contexte sera introduite depuis la phase de modlisation. Ds le dbut, nous dnissons les lments observables collecter, les situations dadaptations identier et enn les ractions dadaptations mettre en uvre. Il sagit dcrire le code permettant de raliser cette sensibilit au contexte et de lintgrer dans la membrane dun composant pour quil devienne sensible au contexte.

Dans ce chapitre, nous dtaillons le processus de dveloppement que nous avons adopt an de mettre en uvre ce travail. Nous commenons dans la premire section, par dcrire les deux mthodes proposes an datteindre les objectifs dja xs par notre projet. La deuxime section cite les principaux outils permettant la ralisation de notre travail. La troisime section prsente le mta-modle sur lequel nous nous sommes bass. La quatrime section dtaille les tapes par lesquelles nous sommes passs pour implmenter la premire mthode.

32

4.1 Description des mthodes proposes

Pour rpondre aux besoins de notre projet, nous proposons principalement deux modes de fonctionnement. Le point de dpart de notre travail, est dditer un modle en utilisant les APIs gnres par le mta-modle. Ce modle reprsente toutes les entits observables, les lments observables, les collecteurs dinformations de contexte ainsi que les situations dadaptation (cf. section suivante).

Le premier mode de fonctionnement propos, utilise le modle dja dit dune faon dynamique pendant linitialisation du composant. Il sagit de parcourir le modle dune manire gnrique et dobserver tous les changements qui peuvent avoir lieu. Cette mthode offre la possibilit de modier le modle pendant lexcution pour une meilleur adaptation. Elle peut tre utilise dans des environnements complexes et trs variants.

Le deuxime mode de fonctionnement, utilise le modle dune faon statique lors de la compilation pour la gnration du code dinteraction. Le code gnr avec cette mthode est spcique lapplication. Il sagit donc dun code rduit transportable sur petit matriel.

4.2 Prsentation des outils de dveloppement utiliss

Dans cette section, nous citons les diffrents outils utiliss lors de llaboration de ce travail. Les trois premiers outils (EMF, MAVEN, SVN) concernent 33

simultanment les deux modes de fonctionnements dcrits dans la section prcdente. Le dernier outil (JET) concerne seulement le deuxime mode de fonctionnement.

4.2.1 Eclipse Modeling Framework (EMF)

EMF est un outils logiciel sous Eclipse qui traite des modles : cela peut sentendre ici sous le sens que EMF offre ses utilisateurs un cadre de travail pour la manipulation des modles. Il permet de stocker les modles sous forme de chier pour en assurer la persistance. EMF permet aussi de traiter diffrents types de chiers : conformes des standards reconnus (XML, XMI) et aussi sous des formes spciques (code Java) ou avec des diagrammes UML.

Comme le montre la gure 4.1, lobjectif gnral de EMF est de proposer un outillage qui permet de passer du modle au code Java automatiquement. Pour cela, EMF sarticule autour dun modle ECORE (Core Model).

F IG . 4.1 Organisation gnrale dEMF

34

Cet outil propose plusieurs services : La transformation des modles dentre ( gauche sur la gure 1), prsents sous diverses formes, en Core Model, La gestion de la persistance du Core Model, La transformation du Core Model en code Java.

EMF peut de base grer en entre des modles prsents sous trois formats : UML, XMI et code Java Annot. Nous avons utilis dans notre travail directement le Core Model. Il sagit l, dditer un mta-modle Ecore, et par la suite, gnrer les APIs JAVA. Ces APIs nous permettent dditer des modles conformes au mta-modle dune part, et de manipuler les modles construits dautres part.

4.2.2 Maven
Maven est un outil open-source pour la gestion et lautomatisation de production des projets logiciels Java. Il nous permet de produire un logiciel partir de ses sources, en optimisant les taches ralises cette n et en garantissant le bon ordre de fabrication. Maven utilise une approche dclarative, o la structure et le contenu du projet sont dcrits, plutt quune approche par tche utilise par exemple par les chiers make traditionnels. Cela aide mettre en place des standards de dveloppements et rduit le temps ncessaire pour crire et maintenir les scripts de build .

Cet outil utilise un paradigme connu sous le nom de POM (Project Object Model) an de dcrire un projet logiciel, ses dpendances avec des modules externes et lordre suivre pour sa production. Il est livr avec un grand nombre de taches prdnies, comme la compilation du code Java ou encore 35

sa modularisation.

Maven nous permet de grer les dpendances entre les modules constituant notre projet ainsi que les bibliothques dont il dpend. Il nous offre aussi la possibilit dautomatiser les diffrentes tches et ainsi nous aurons la possibilit de gnrer automatiquement des tests unitaires. Cest donc un outil trs riche qui facilite le dveloppement des projets.

4.2.3 Subversion (SVN)

SVN est un logiciel de gestion de sources et de contrle de versions. Il permet des utilisateurs distincts et souvent distants de travailler ensemble sur les mmes chiers. Il sappuie sur le principe dun dpt centralis et unique dans lequel les utilisateurs peuvent dposer des donnes, les rcuprer ou publier leurs modications. SVN garde un historique des diffrentes versions des chiers dun projet, il permet aussi le retour une version antrieure quelconque. Cet outil nous offre une meilleure gestion du travail en collaboration.

4.2.4 JAVA Emitter Template (JET)

JET est un outil pour la gnration de code JAVA au sein dEMF partir de chier modle en utilisant des templates. Ces templates sont constitus par du texte et des commandes JET permettant dextraire des informations partir du modle dentre.

JET contient principalement quatre librairies de commandes savoir : Commandes de Contrle : Utilises pour accder au modle dentre et pour contrler lexcution du template. 36

 Commandes de format : Utilises pour modier le format du texte dans les modles selon certaines rgles. Commandes Java : Ce sont des balises utiles pour gnrer du code Java. Commandes de Workspace : Utilise pour la cration de ressources dans lespace de travail, telles que des chiers, des dossiers et des projets.

Comme le montre la gure 4.2,la gnration du code se fait partir du chier modle, JET Builder permet dobtenir les paquetages et les classes java correspondantes. Cette gnration utilise deux classes : JETCompiler : Cest la classe de base pour la traduction des modles JETEmitter : La mthode generate() de cette classe combine la traduction des modles et la gnration dans une seule tape.

F IG . 4.2 Les tapes de la gnration avec JET

Donc cet outil nous donne la possibilit de gnrer automatiquement le code spcique un composant sensible au contexte

37

4.3 Prsentation du Mta-modle de sensibilit au contexte

Dans cette section, nous prsentons le mta modle sur lequel nous nous sommes bass pour laborer ce travail. Ce mta-modle a comme principal objectif dautomatiser la sensibilit au contexte des applications et la rendre dclarative plutt que programmative. De plus, laspect sensibilit au contexte est pris en charge par lintergiciel qui fait la liaison avec les collecteurs de contexte dune part et interagit avec lapplication dautre part. Parmis les adaptations de lapplication prises en charge par lintergiciel, nous pouvons citer titre dexemple : la mise jour de diffrentes variables, une modication du comportement de lapplication, ou encore une modication de lassemblage. Le mta-modle dnit la structure des modles de sensibilit au contexte des applications ubiquitaires qui sont conformes au mta-modle.

La gure 4.3, montre une vue densemble de notre mta-modle. Certaines parties du mta-modle sont partages par toutes les applications ubiquitaires, savoir les deux paquetages ContextView et CollectorView. Dautres parties sont dnir par lapplication sensible au contexte, savoir le paquetage ContextAwarenessView.

Dautre part, lintergiciel interagit avec le modle an de dterminer les informations de contexte ncessaires ladaptation. Parmi les principales interactions, nous pouvons citer par exemple, la dtermination des diffrents lments observables associs au modle. Ces observables nous permettent de rcuprer les informations de contexte. Ajoutons cela, lenregistrement du 38

UML2

Composant Diagramme de squences Dploiement

ContextAwarenessView
ContextAwareSystem CASystemObservableEntity Binding VariationPoint

ContextView

ObservableEntity ObservableElement AdaptationSituation

CollectorView
Collector QoC

F IG . 4.3 Les paquetages du mta-modle composant un nud de contexte (il sagit du collecteur COSMOS) pour recevoir les notications concernant les diffrentes variations qui peuvent arriver dans le systme. Lapplication peut aussi observer les nuds de contexte, si elle a besoin de connaitre une information de contexte un moment donn. La gure 4.4 illustre les interactions entre le modle et lintergiciel.

Maintenant, nous dtaillons les diffrents paquetages construisant notre mta-modle. Le paquetage ContextView comprend les modles conformes au mta-modle des domaines indpendant de lapplication. Nous pouvons citer comme principales classes : ObservableEntity : des exemples de cette classe sont computer, user, networkinterface, etc. ObservableElement : nous citons par exemple computerIdentication, 39

username, bandwidth Observation : cette classe manipule des valeurs dates AdaptationSituation : connect au rseau

Interfaces Applicatives Entre

membrane

Code applicatif Modification tat Opration ractive

callback

Interfaces Applicatives Sortie

Modles Package Package

Liaisons

Interface de contrle pull pull

Enregistrement/notification ou lecture
push

Collecteur

Collecteur

Collecteur

F IG . 4.4 Interactions modle-intergiciel

Notre mta-modle se diffrencie par les entits du modle mais aussi par les relations exprimes entre ces diffrents lments. Les relations entre les diffrents lments du modle sont essentielles pour parcourir les diffrents lments du modle. Elles sont dterminantes pour lutilisabilit du mtamodle.

Le paquetage CollectorView dnit des possibilits dinteractions entre les applications et les observables via les collecteurs. Il dnit aussi les collecteurs disponibles pour un mme type dobservable, chaque collecteur prsente des units diffrentes, des interfaces diffrentes, des qualits de contextes QoC 40

diffrentes. Pendant lexcution de lapplication, ce paquetage dnit comment retrouver ou dcouvrir un collecteur dj existant, il sagit donc dun premier mode de fonctionnement. Le deuxime mode consiste instancier un nouveau collecteur pour collecter les informations de contexte. Ce paquetage dnit aussi le type dinteraction entre lapplication et le collecteur. Les deux types dinteraction mises en uvre sont les pushs et les pulls qui ont t dnis prcdemment. Il est aussi noter, que nous envisageons diffrents types de collecteurs. Nous distinguons donc les collecteurs COSMOS des autres collecteurs.

Le paquetage ContextAwarenessView dnit des entits observables concrtes associes lapplication. Ce paquetage soccupe de la slection des observables parmi ceux dnis pour ce type dentit observable et pour chaque observable, il slectionne le collecteur correspondant. Ce paquetage a aussi comme rle de dnir les interactions entre lapplication et les observables. Il dnit aussi les ractions mettre en uvre lors dune dtection dune situation dadaptation. Parmi les diffrentes ractions, nous pouvons citer titre dexemple un basculement vers le rseau wi lorsque celui-ci devient disponible.

4.4 Description de la solution labore

Cette section sintresse essentiellement llaboration de la premire mthode du parcours dynamique du modle de lapplication, dj prsente au dbut de ce chapitre. Nous dtaillons dans ce qui suit les tapes par lesquelles nous sommes passs pour raliser cette solution de ldition du modle de sensibilit au contexte jusqu lcriture du code JAVA qui sera intgr dans la 41

membrane du composant Fractal.

4.4.1 Modle conforme au mtamodle

Le modle diter est une reprsentation de lensemble du systme. Il cilite la manipulation ainsi que lobservation de ce systme. Pour diter notre modle, nous utilisons les classes gnres partir du mta-modle. EMF nous permet de crer facilement un modle conforme au mta-modle.

Nous travaillons avec un ensemble dentits observables. Chacune de ces entits dispose dun ou plusieurs lments observables et dune situation dadaptation. Il est noter que chaque lment observable dispose de son propre collecteur de contexte. Pour chaque Collecteur, nous spcions toutes les informations qui le caractrisent et particulirement la famille laquelle il appartient. Dans notre travail, nous utilisons des collecteurs de type COSMOS, mais il est possible dajouter dautres types de collecteurs et de spcier le traitement correspondant.

La gure 4.5 montre le modle sur lequel nous nous sommes bass. Nous dtaillons dans cette partie les diffrents lments composant notre modle an de mieux le clarier. Les entits observables que nous utilisons dans le modle sont : lentit Computer , qui dispose dune entit Printer , il est utilis par une entit User et appartient une entit NetworkInterface . Lentit ComputerPrinter permet davoir une relation entre le Computer et le Printer .

Nous passons maintenant aux lments observables : llmnt Color est associ lentit Printer , il permet dobtenir les couleurs utiliss par 42

cette imprimante. Llment Proximity est li lentit ComputerPrinter , il permet de trouver les imprimantes proches dun ordinateur donn. Llmnt UserAgent-Id est associ lentit Computer , il permet davoir lidentiant de lutilisateur du PC. Llmnt GeographicalLocation est li la fois Computer et Printer , il permet davoir la localisation gographique de lordinateur, et de limprimante. Cet lment est driv partir dun autre lmnt City . Ce dernier est li lentit Computer et permet de savoir dans quelle ville elle se trouve. Pour lentit NetworkInterface , nous disposons dun lment observable Bandwidth permettant davoir la bande passante du rseau. et enn lentit User dispose de 4 observables, savoir : Identity , Activities , Health , IdentityPapers pour dtrminer respectivement, lidentit de lutilisateur, ses activits, sa sant et nalement ses papiers didentit.

43

ObservableEntity AdaptationSituation GeographicalLocation Proximity UserAgentId Color ComputerPrinter City

ObservableElement

derivedFrom

Printer

*
Computer

1..*

NetworkInterface

Available Identity

F IG . 4.5 Entits et lments observables de notre modle

Il nous reste maintenant dtailler les situations dadaptation. Notre modle

*
Activities User Bandwidth Health IdentityPapers Connected

44
*
ProximityUserUpdate

proximityUsers

en contient 3, qui sont : La situation Available relative lentit NetworkInterface , elle est utile pour savoir si un rseau est disponible ou non. La situation Connected relative Computer , ainsi que NetworkInterface , pour savoir si ces entits sont connects ou non. La dernire situation dadaptation est ProximityUserUpdate , elle est relative un utilisateur et consiste mettre jour la liste de ses utilisateurs voisins.

4.4.2 Diagramme de classes et dtail des fonctionnalits

Cette sous section prsente le diagramme de classes de la solution implmenter. Nous avons prvu lutilisation des deux mthodes statique et dynamique . Notre diagramme de classe est compos de 3 paquetages : eu.it-sudparis.cacomp.cacontroler eu.it-sudparis.cacomp.cacontroler.cosmos eu.it-sudparis.cacomp.cacontroler.tests

La gure 4.6 montre essentiellement les 2 premiers paquetages. Le premier paquetage contient lensemble des classes utilises pour assurer les diffrentes fonctionnalits :

Dans le cas de la premire mthode, nous commenons tout dabord par charger le modle. La classe ModelAccesor soccupe du chargement du modle et cre une ressource reprsentant le modle parcourir. Pour une meilleure souplesse, nous sauvegardons dans un chier de proprits, les principaux paramtres ncessaires lexcution de notre code, comme par exemple le chemin daccs au modle parcourir, tout en prvoyant des valeurs par dfaut si jamais le chier nexiste pas. Ainsi ces paramtres seront chargs lors de lexcution. 45

La classe CAControlerDynamicModel soccupe du parcours du modle proprement dit et cre les bridges collecteurs qui font linteraction avec lapplication travers leurs interfaces. Le parcours consiste retrouver les diffrentes entits observables, pour chaque entit, parcourir la liste des lments observables. Comme nous avons dj prcis, chaque lment observable dispose dun collecteur. Lorsque nous arrivons au niveau du collecteur, un COSMOSBrdigeCollector sera cr si le collecteur trouv est de type COSMOS. Dans le cas contraire, une exception est lance. Pour le moment nous travaillons seulement avec les collecteurs de type COSMOS. Le COSMOSBridgeCollector cr aura comme but de collecter linformation de contexte. Lapplication peut utiliser ces collecteurs pour faire des observations (PULL) par exemple, ou encore recevoir des notications(PUSH) des variations des lments observables. Nous sauvegardons linterface de ces collecteurs dans une map tout en leur attribuant une cl an de les retrouver en cas de besoin.

Nous mettons laccent sur le fait quil y a deux modes de cration. Le premier mode est par dcouverte, les observables peuvent dcouvrir des collecteurs dja existant et les utiliser pour collecter les informations de contexte. Nous utilisons la classe DiscoveryInformation dans ce premier mode. Le deuxime mode est par instanciation, les observables peuvent instancier leurs propres collecteurs et les utiliser aussi pour la collecte dinformations. Dans ce deuxime cas, nous utilisons la classe InstantiationInformation.

Le deuxime paquetage est utilis pour grer les collecteur de type COSMOS. Nous faisons appel la classe COSMOSBridgeCollector de ce paque-

46

tage lors de le cration dun collecteur COSMOS. Enn, nous utilisons le troisime paquetage pour tester lensemble de notre application. Ce paquetage fait appel aux diffrentes classes pour charger un modle, le parcourir et enn crer les BridgeCollector qui collectent linformation de contextes.

4.4.3 Implmentation
Dans notre travail, nous crivons du code en utilisant le langage JAVA. Nous manipulons aussi, des composants COSMOS lors de linstanciation dun collecteur donne. Dans ce qui suit, nous montrons une partie de notre code JAVA. Il sagit de la partie relative la premire mthode seulement (mthode dynamique). Cette partie soccupe du parcourt un modle aprs son chargement et cre les CosmosBridgeColecteurs pour collecter linformation de contexte.

Comme le montre la gure 4.7, dans le constructeur de la classe CAControlerDynamicModel , nous faisons appel la classe ModelAccessor (ligne 52) qui soccupe du chargement du modle dont le chemin dacces est pass en paramtre. Ltape suivante consiste appeler la mthode createAllBridges (ligne 53) an de crer un BridgeCollector pour chaque lment observable.

Concernant la mthode createAllBridges , son rle est de parcourir le modle charg. Elle dtermine, ensuite, les ntits observables et pour chacune delle, elle parcourt les lments observables correspondants. Pour chaque observable, elle cre le Bridge Collecteur en faisant appel la mthode 47

F IG . 4.6 Diagramme de classe de la solution envisage 48

 createBridge , puis linsre dans une map de Icollector en lui associant une cl pour pouvoir le retrouver. La gure 4.8 dtaille le code de cette mthode.

La mthode createBridge dtermine le collecteur correspondant llement observable pass en paramtre. Ensuite, elle teste le type de ce collecteur. Pour le moment, nous grons des collecteurs COSMOS, mais il est possible dtendre lapplication et dajouter dautres types de collecteurs. Pour ces collecteurs COSMOS, cette mthode vrie si le mode utilis est par dcouverte ou par instanciation pour savoir comment les crer. Le code de cette mthode est dtaill dans la gure 4.9.

49

4.4.4 Discussion
Dans ce chapitre, nous avons dtaill la dmarche que nous avons suivie an de raliser ce travail. Nous nous sommes concentrs, en premier lieu, sur ltude du mta-modle de la sensibilit au contexte. Ensuite, nous avons dit un modle conforme ce mta-modle. Ce modle reprsente les lments observables, les collecteurs des informations de contexte et les ractions dadaptations de lapplication rendre sensible au contexte. Aprs ldition du modle, nous avons distingu deux modes dutilisations ; le premier mode parcours le modle lors de linitialisation du composant pour obtenir les divers changements qui peuvent avoir lieu, il est utilis dans des environnements ubiquitaires. Le deuxime mode utilise le modle dune manire statique pour gnrer un code JAVA propre lapplication, ce code est transportable sur petits matriels. Dans le cadre de notre travail, nous avons implment le premier mode seulement, mais nous avons prvu dans notre conception lutilisation des deux modes, ainsi que les outils ncessaires la ralisation. Le dveloppement du deuxime mode nous permettra dobtenir des rsultats intressant dans ce domaine.

50

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

package eu.it_sudparis.cacomp.cacontroler; import java.util.Collection; import java.util.Collections; import java.util.Iterator; import java.util.Properties; import java.util.Set; import org.eclipse.emf.common.util.EList; import collectorView.Collector; import collectorView.CollectorDiscoveryFactory; import collectorView.CollectorFamilyValues; import collectorView.CollectorInstantiationFactory; import collectorView.impl.CollectorInstantiationFactoryImpl; import contextAwareness.CAObservableElement; import contextAwareness.CASystemObservableEntity; import contextView.EntityRelation; import contextView.ObservableElement; import contextView.ObservableEntity; import eu.it_sudparis.cacomp.cacontroler.cosmos.CosmosBridgeCollector; import java.io.*; import java.util.logging.*; /** * This class browse dynamically the given model.For each CAObservableEntity * it get the CAObservableElements and create the correspondent collector * and save it into a map * @author Zaier Mehdi and Chantal Taconet */ public class CAControlerDynamicModel extends eu.it_sudparis.cacomp.cacontroler.CAControler implements ICAControlerDynamicModel { /** * Java logger. */ private static Logger log=Logger.getLogger("CAControlerDynamicModel"); private static ModelAccessor model; Iterator<CASystemObservableEntity> iterator2; /** * Constructor of the CAControlerDynamicModel class * * @param path */ public CAControlerDynamicModel(String path) { String newLevel = System.getProperty("level", "ALL"); Level level = Level.parse(newLevel); try { Handler hand=new FileHandler("CAControler.log",false); log.addHandler(hand); } catch (IOException e) { // Impossible to open the log file log.warning("new FileHandler IOException: " + e); } log.setLevel(level); model = new ModelAccessor(path); createAllBridges(); }

F IG . 4.7 Constructeur de la classe CAControlerDynamicModel

51

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

/** * Browse all observable entities and get the correspondent observable * elements */ public void createAllBridges() { ICollector iCollector = null; Iterator<CASystemObservableEntity> iterator; CASystemObservableEntity cASystemObservableEntity = null; iterator = model.iteratorCASOE; // browse all CASystemObservableEntities while (iterator.hasNext()) { cASystemObservableEntity = iterator.next(); // Get all observable elements EList<CAObservableElement> cAObservableElements = cASystemObservableEntity .getObservableElementSubset(); Iterator<CAObservableElement> iteratorOBE = cAObservableElements.iterator(); CAObservableElement cAObservableElement = null; // browse all cAObservableElements while (iteratorOBE.hasNext()) { cAObservableElement = iteratorOBE.next(); System.out.println(""); log.info("The observable element is :" + cAObservableElement.getObservableElement()); try { // Create the iCollector iCollector = createBridge(cAObservableElement); } catch (CollectorInstantiationException e) { // TODO Auto-generated catch block e.printStackTrace(); } // creating a key (collectorIdentifier) for the collector CollectorIdentifier collectorIdentifier = new CollectorIdentifier(cASystemObservableEntity .getName(),cAObservableElement.getObservableElement() .getName()); // add an iCollector in the map map.put(collectorIdentifier, iCollector); log.info("The number of collectors in the map is " + map.size()); } } }

F IG . 4.8 Mthode createAllBridges()

52

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

/** * this method create a collector and form the corresponding key and save * the pairs (key,collector) into the map * @param cAObservableElement * @return ICollector */ public ICollector createBridge(CAObservableElement cAObservableElement) throws CollectorInstantiationException { // Get the collector Collector collector = cAObservableElement.getCollector(); log.info("The collector of the observable element" + cAObservableElement.getObservableElement().getName() + " is :" + collector); switch (collector.getCollectorFamily().getValue()) { // Cosmos collector case CollectorFamilyValues.COSMOS_VALUE: if (collector.getCollectorFactory() instanceof CollectorInstantiationFactory) { log.info("Collector is on instanciation mode "); CollectorInstantiationFactory collectorInstantiationFactory= (CollectorInstantiationFactory) collector .getCollectorFactory(); String instantiationArtifact = collectorInstantiationFactory .getInstantiationArtifact(); InstantiationInformation instanciationInformation = new InstantiationInformation(instantiationArtifact); return new CosmosBridgeCollector(instanciationInformation); } else { if (collector.getCollectorFactory() instanceof CollectorDiscoveryFactory) { log.info("Collector is on discovery mode "); CollectorDiscoveryFactory collectorDiscoveryFactory= (CollectorDiscoveryFactory) collector .getCollectorFactory(); String discoveryIdentifier = collectorDiscoveryFactory .getDiscoveryIdentifier(); DiscoveryInformation discoveryInformation = new DiscoveryInformation(discoveryIdentifier); return new CosmosBridgeCollector(discoveryInformation); } } // not a cosmos collector default: throw new CollectorInstantiationException(); } }

F IG . 4.9 Mthode createBridge()

53

Conclusion et Perspectives
La ralisation de notre travail concernant lIngnierie Dirige par les Modles et Composants Sensibles au Contexte, sest tale sur une priode denviron quatre mois et demi au Dpartement Informatique de TELECOM et Management SudParis .

Au cours de cette priode jai intgr un milieu de recherche, mais aussi de dveloppement au sens vrai du terme. Cette intgration ma t trs bnque, dans la mesure o elle ma permis dacqurir une exprience tant sur le plan thorique que sur le plan pratique ; suite lacquisition et la matrise de nouvelles technologies et des nouveaux aspects dans le domaine de la sensibilit au contexte.

Notre travail sest intress tudier la sensibilit au contexte dexcution et proposer une approche gnrique pour rendre un composant donn auto-adaptable. Lintgration de cette sensibilit au contexte est ralise depuis la modlisation de lapplication. Dans cette phase de modlisation, nous commenons par dnir tous les lments observer, les collecteurs permettant de les observer, ainsi que les ractions dadaptations.

Nous avons bien prcis au dbut de notre rapport que nous envisageons dimplmenter deux modes de fonctionnement. Le premier est un mode dynamique qui parcourt dune manire gnrique le modle de lapplication lors de linitialisation du composant. Le parcours permet de collecter linformation de contexte permettant de raliser ladaptation. Le travail auquel nous avons abouti, permet de raliser ces diffrentes tches. Pour tester notre code, 54

nous avons utilis un scnario dun modle. Toutefois, lapplication laquelle nous avons abouti reste ouverte toute volution dans la mesure o lapport des nouvelles informations contribuera son amlioration. Une telle tche ncessite beaucoup plus de temps que celui qui nous a t accord.

Revenons au deuxime mode de fonctionnement, nous envisageons dutiliser statiquement le modle de lapplication pour gnrer le code de linteraction. Nous rappelons que le code gnrer est spcique lapplication. Dans notre travail, nous navons pas encore dvelopp ce deuxime mode, mais nous avons prvu de lintgrer dans notre application. De plus, nous avons aussi trouv loutil qui permet de gnrer le code ncessaire ce mode ( Il sagit de loutil JET dj dtaill dans le dernier chapitre). La mise en uvre de ce deuxime mode, nous permettra de faire des comparaisons ainsi que des valuations trs intressante sur ces deux modes. La poursuite de ce travail reste donc entreprendre trs prochainement partir du mois prochain.

Enn, nous sommes convaincus que la ralisation de ce travail est une exprience trs fructueuse pour notre formation pratique et acadmique. Les connaissances thoriques que nous avons acquises tout au long de notre formation la Facult des Sciences de Tunis (FST) ont t parfaitement consolides. Par la mme occasion, ce stage constitue une trs bonne exprience humaine et sociale travers le contact avec les enseignants, les doctorants ainsi que les stagiaires de diffrentes nations.

55

Bibliographie
[1] M. Boulkenafed and V. Issarny. A middleware service for mobile ad hoc data sharing, enhancing data availability. in m. endler and d. schmidt, editors, proc. ip/acm/usenix international middleware conference, volume 2672 of lecture notes in computer science. June 2003. [2] P.J. Brown, J.D. Bovey, and X. Chen. Context-aware Applications : from the Laboratory to the Marketplace. IEEE Personal Communications, 4(5) :58 64, October 1997. [3] . Bruneton, T. Coupaye, M. Leclercq, V. Quma, and J.-B. Stefani. The Fractal Component Model and Its Support in Java. special issue on Experiences with Auto-adaptive and Recongurable Systems, 36(11) :1257 1284, sep 2006. [4] D. Conan, R. Rouvoy, and L. Seinturier. COSMOS : composition de nuds de contexte, GNU Lesser General Public License. July 2007. [5] Coutaz, J. and Crowley, J.L. and Dobson, S. and Garlan, D. The disappearing computer : Context is Key. Communications of the ACM, 48(3) :4953, 2005. [6] A. Dey, D. Salber, and G. Abowd. A conceptual framework and a TOOLKIT for supporting the rapid prototyping of context-aware applications, 2001. [7] A.K. Dey. Providing Architectural Support for Building Context-Aware Applications. PhD thesis, College of Computing, Georgia Institute of Technology, December 2000. [8] V. Quma M. Leclercq and J.-B. Stefani. Dream : a component framework for the construction of resource-aware, congurable moms. sep 2005. [9] G. Rey and J. Coutaz. Le Contexteur : Capture et distribution dynamique dinformation contextuelle. In Actes de la 1re Confrence ACM Francophone Mobilit et Ubiquit, volume 64 of ACM International Conference Proceeding Series. pages 131138, June 2004. [10] M. Satyanarayanan. The Many Faces of Adaptation. IEEE Pervasive Computing, pages 45, July 2004. 56

[11] C. Taconet. tat de lart cappucino(construction et adaptation dapplications ubiquitaires et de composants dintergiciels en environnement ouvert pour lindustrie du commerce), March 2007. [12] L. Temal and D. Conan. Dtections de dfaillances, de connectivit et de dconnexions. in actes de la 1re confrence acm francophone mobilit et ubiquit, volume 64 of acm international conference proceeding series. pages 9097, June 2004. [13] Stephen S. Yau, Fariaz Karim, Yu Wang, Bin Wang, and Sandeep K. S. Gupta. Recongurable context-sensitive middleware for pervasive computing. IEEE Pervasive Computing, 1(3) :3340, 2002.

57