Gestion du contexte pour des applications mobiles

dédiées aux transports

Dana Popovici

To cite this version:

Dana Popovici. Gestion du contexte pour des applications mobiles dédiées aux transports.
Autre. Université de Valenciennes et du Hainaut-Cambresis, 2012. Français. <NNT :
2012VALE0039>. <tel-00834969>

HAL Id: tel-00834969

https://tel.archives-ouvertes.fr/tel-00834969
Submitted on 17 Jun 2013

HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non,
lished or not. The documents may come from émanant des établissements d’enseignement et de
teaching and research institutions in France or recherche français ou étrangers, des laboratoires
abroad, or from public or private research centers. publics ou privés.
 Thèse de doctorat

Pour obtenir le grade de Docteur de l’Université de

VALENCIENNES ET DU HAINAUT-CAMBRESIS

Discipline, spécialité selon la liste des spécialités pour lesquelles l’Ecole Doctorale est accréditée :

Informatique

Présentée et soutenue par Dana POPOVICI.

Le 10/12/2012, à Valenciennes

Ecole doctorale :
Sciences Pour l’Ingénieur (SPI) Université Lille Nord-de-France – 072

Equipe de recherche, Laboratoire :

Laboratoire d’Automatique, de Mécanique et d’Informatique Industrielles et Humaines (LAMIH)

Gestion du contexte pour des applications mobiles dédiées aux

transports

JURY

Président du jury
– DONSEZ, Didier. Professeur. Université Joseph Fourier - Grenoble I.

Rapporteurs
– DONSEZ, Didier. Professeur. Université Joseph Fourier - Grenoble I.
– LAFOREST, Frédérique. Professeur. Université Jean Monnet.

Examinateurs
– GRANSART, Christophe. Chargé de recherche. IFSTTAR-LEOST.
– LE SOMMER, Nicolas. Maître de conférences. Université de Bretagne Sud.

Directeur de thèse (et co-directeur de thèse le cas échéant, ou co-encadrant)

– LECOMTE, Sylvain. Professeur (directeur de thèse). Université de Valenciennes.
– DESERTOT, Mikaël. Maître de conférences (co-encadrant). Université de Valenciennes.
Remerciements

Je remercie mes parents, Cristina et Mihai Popovici, qui m’ont toujours incitée à ap-
prendre et à me perfectionner. Sans leur amour, je ne serais pas arrivée où je suis aujourd’hui.

Je remercie mes encadrants, Sylvain Lecomte et Mikaël Desertot, qui m’ont guidée
pendant ces trois années de thèse. Leurs conseils précieux m’ont permis d’avancer et de
perfectionner mon travail. Sylvain et Mikaël ont toujours su se rendre disponibles pour moi,
malgré leurs emplois du temps chargés.

J’exprime toute ma gratitude envers ceux qui ont accepté de valider ce travail de thèse.
Leurs questions et remarques pertinentes m’ont permis d’améliorer le manuscrit ainsi que
de préparer ma soutenance. Je remercie Frédérique Laforest et Didier Donsez pour avoir
accepté de rapporter mon manuscrit dans une période aussi chargée et dans un délai assez
court. Je remercie également Nicolas Le Sommer et Christophe Gransart pour l’intérêt
qu’ils ont témoigné par la lecture de mon manuscrit et par leur présence à la soutenance
publique.

Je remercie tous mes collègues du LAMIH et plus particulièrement l’équipe DIM.

J’ai vécu de bons moments au sein de l’équipe, en travaillant ensemble ou en faisant
des pauses café animées par des discussions “philosophiques”. Je tiens à remercier en
particulier Codruţa pour son amitié, son support et ses conseils depuis que je suis arrivée à
Valenciennes. Je remercie également Nicolas Péon pour l’aide précieux qu’il a apporté pour
la mise en œuvre du prototype de ma thèse.

Je remercie Nico, pour ses encouragements et sa patience, pour avoir toujours su me

rassurer dans les moments difficiles.

Enfin, je remercie mes amis et ma famille. Vã mulţumesc !

i
Résumé

De nos jours, la façon d’utiliser les applications mobiles dans le domaine des transports
offre de nouveaux défis liés aux spécificités de l’environnement, comme la forte mobilité des
terminaux, leur répartition, ou encore le réseau instable de communication. La plupart des
applications existantes ont des contraintes de fonctionnement qui les rendent inadaptées si
les conditions d’exécution évoluent rapidement. Cela rend intéressant l’utilisation d’un cadre
unifié de conception et d’exécution, capable de gérer ces applications.
Nos travaux portent, dans un premier temps, sur une étude des applications mobiles et
de leur comportement, en fonction du contexte d’exécution. Nous considérons le cas des
applications dédiées aux transports, conçues pour accompagner et assister un usager dans
son déplacement (navigation, sécurité routière, applications des moyens de transports, etc.).
Nous identifions les éléments du contexte propres aux applications fortement mobiles et les
modélisons.
Dans un second temps, nous proposons un cadre dynamique et sensible au contexte,
permettant le déploiement de nouveaux services « à la volée » ainsi que leur adaptation pour
une meilleure utilisation des ressources dans des milieux très évolutifs. Nous nous focalisons
sur le côté réactif, permettant d’adapter le comportement des applications à leurs nouvelles
conditions d’utilisation. Les applications sont décomposées en services de base avec un
couplage lâche pour une plus grande flexibilité. Nous utilisons une architecture orientée
service, qui permet la réutilisation des services communs à plusieurs applications mais aussi
la gestion du contexte au travers de services équivalents mais capables de fonctionner dans
des conditions différentes.
Nous montrons, grâce au prototype de notre plateforme CATS (Context-Aware Transporta-
tion Services), d’abord la faisabilité d’une plateforme à services sur des terminaux portables.
Nous testons ensuite plusieurs scénarios afin de démontrer la réactivité des adaptations
aux changements de contexte. Dans cette thèse nous proposons une vue d’ensemble sur la
création et la gestion des applications sensibles au contexte pour le domaine des transports.
Le but de notre démarche est d’assurer le bon fonctionnement de l’ensemble des applications
d’un utilisateur, malgré les changements dynamiques du contexte.

Mots clefs :
Contexte ; Application sensible au contexte ; Architecture orientée service ; Mobilité.
Abstract

The use of mobile applications in the transportation domain raises a multitude of

challenges, related to the specific execution environment: highly mobile and distributed
devices, unstable communication networks, etc. Most of the existing applications are not
flexible enough to cope with the rapidly changing environment. It would be interesting to
provide a unified frame for the design and execution of such applications, offering management
capabilities as well.
We propose a study of the mobile applications and their behavior in relation with the
context. We consider a certain type of applications, designed to accompany and assist users
on the move (navigation, traffic security, applications related to a means of transport, etc.).
We identify the context elements which are characteristic to highly mobile applications and
we propose a context model for the transportation domain.
In order to handle multiple applications at a time, we propose a dynamic and context-
aware framework, capable of deploying services “on the fly”. We consider applications built
through the assembly of services, allowing them to adapt to the execution environment and
make the best use of the available resources. We focus on the reaction of the applications
to the changes in the environment. Applications are built of services and thus benefit from
loose coupling, allowing them to be flexible. A service oriented architecture brings further
advantages, notably that services can be shared between applications and that a service
can have multiple implementations. We manage the adaptation to new conditions of use
through equivalent services built for different context situations.
The framework that we have proposed, called CATS (Context-Aware Transportation
Services), has been tested thanks to a prototype. We were able to prove the feasibility of
the framework as well as evaluate several testing scenarios, showing the reactivity of the
applications to context changes. This work proposes a complete view of the design and
management of context-aware applications for the transport domain. Our goal is to enhance
user experience by ensuring the well functioning of his/her applications despite the ever
changing context.

Keywords:
Context; Context-aware applications; Service Oriented Architecture; Mobility.
Table des matières

Introduction 1
Contexte général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Motivations et but de cette thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Organisation du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

I État de l’art et Problématique 5

1 L’informatique d’aujourd’hui : omniprésente, mobile, complexe ! 7

1.1 L’informatique ubiquitaire (omniprésente) . . . . . . . . . . . . . . . . . . . . . . 7
1.2 L’informatique actuelle et la localisation . . . . . . . . . . . . . . . . . . . . . . 8
1.3 La découverte et l’accès à des services en mobilité . . . . . . . . . . . . . . . . 9
1.4 L’informatique mobile et les réseaux ad hoc . . . . . . . . . . . . . . . . . . . . 10
1.5 Questions de sécurité et qualité de service . . . . . . . . . . . . . . . . . . . . . 12
1.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Tout le monde parle de « contexte » 15

2.1 Qu’est ce que le contexte ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Comment le contexte est-il défini ? . . . . . . . . . . . . . . . . . . . . . 15
2.1.2 Que veut dire « context-aware » ? . . . . . . . . . . . . . . . . . . . . . . 16
2.1.3 Tout le monde parle de contexte . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Des modèles de contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Quand et comment le contexte est-il utilisé ? . . . . . . . . . . . . . . . . . . . 21
2.3.1 Des systèmes sensibles au contexte et l’accès au contexte . . . . . . . 22
2.3.2 Des exemples d’applications sensibles au contexte . . . . . . . . . . . 23
2.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Réagir au contexte : applications et architectures adaptables 27

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

vii
 3.2 Des modèles, standards, pratiques et architectures . . . . . . . . . . . . . . . . 28
3.2.1 Les modèles à composants . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.2 L’architecture orientée service et la programmation orientée service . 29
3.2.3 Composants versus services . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.4 Autonomic computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.5 Lignes de Produits (SPL) . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.6 Utilisation d’un intergiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 D’autres préoccupations de l’informatique récente . . . . . . . . . . . . . . . . 33
3.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 Problématique des applications dans le domaine des transports 35

4.1 Les applications sensibles au contexte d’aujourd’hui . . . . . . . . . . . . . . . 35
4.1.1 Le contexte – manque d’une classification en informatique . . . . . . . 36
4.1.2 Manque d’un cadre de conception et d’exécution . . . . . . . . . . . . . 36
4.2 Vers une solution pour des applications dédiées aux transports sensibles au
contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.1 Le domaine des transports et l’informatique mobile . . . . . . . . . . . 37
4.2.2 L’exemple : un conducteur, son téléphone et ses applications . . . . . 38
4.2.3 Les caractéristiques des applications considérées . . . . . . . . . . . . 41
4.2.4 Les problématiques abordées . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

II Contributions 45

Propositions 47
Un modèle de contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Une méthodologie pour la conception des applications . . . . . . . . . . . . . . . . . 48

5 Modélisation du contexte pour des applications dédiées aux transports 49

5.1 Quel contexte est important ? Quand ? Pourquoi ? . . . . . . . . . . . . . . . . . 49
5.1.1 L’influence de l’environnement . . . . . . . . . . . . . . . . . . . . . . . . 50
5.1.2 Quelles fonctionnalités peut-on utiliser ? . . . . . . . . . . . . . . . . . . 52
5.1.3 Des applications adaptées au terminal . . . . . . . . . . . . . . . . . . . 52
5.1.4 Des applications personnelles . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1.5 Vue d’ensemble sur le contexte pour le domaine des transports . . . . 54
 5.2 L’utilisation du contexte pour améliorer les applications . . . . . . . . . . . . . 55
5.2.1 Installation d’une nouvelle fonctionnalité . . . . . . . . . . . . . . . . . . 55
5.2.2 Pendant l’exécution : réagir aux changements de contexte . . . . . . . 56
5.3 Les caractéristiques des différents éléments de contexte . . . . . . . . . . . . 57
5.3.1 Des éléments de contexte avec une évolution dynamique . . . . . . . . 58
5.3.2 Des éléments de contexte sans évolution dynamique . . . . . . . . . . 58
5.4 Modélisation du contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4.1 Modélisation initiale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4.2 Modélisation d’un élément de contexte (CE) . . . . . . . . . . . . . . . . 60
5.4.3 Vers l’intégration du contexte dans les applications . . . . . . . . . . . 62
5.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6 Un cadre flexible pour des applications sensibles au contexte 65

6.1 Des applications modulaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.1.1 Des applications composées de services . . . . . . . . . . . . . . . . . . 66
6.1.2 Des services dépendants du contexte (CDS) . . . . . . . . . . . . . . . . 69
6.1.3 Description des modules et des services . . . . . . . . . . . . . . . . . . 71
6.1.4 Mécanisme d’adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.1.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2 Une plateforme d’exécution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.2.1 Plateforme pour des Services de Transports Sensibles au Contexte . 76
6.2.2 Le gestionnaire de contexte : Context Manager . . . . . . . . . . . . . 77
6.2.3 Le gestionnaire d’exécution : Execution Manager . . . . . . . . . . . . 79
6.2.4 Le courtier : Trader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.2.5 Fonctionnement de la plateforme CATS . . . . . . . . . . . . . . . . . . 82
6.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

III Prototypage et Evaluations 83

7 Mise en œuvre de la plateforme CATS 85

7.1 Technologies et matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.1.1 OSGi – une couche de modularité pour Java . . . . . . . . . . . . . . . 86
7.1.2 iPOJO – un gestionnaire de composants orientés services . . . . . . . 89
7.1.3 Android et OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
 7.1.4 Matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.1.5 Travaux connexes utilisant Android et OSGi . . . . . . . . . . . . . . . . 92
7.2 CATS – le prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.2.1 Plateforme, applications, services, modules, bundles . . . . . . . . . . . . 94
7.2.2 Implémentation des modules de la plateforme CATS . . . . . . . . . . . 95
7.2.3 Des handlers iPOJO pour la plateforme CATS . . . . . . . . . . . . . . 97
7.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

8 Evaluation du prototype CATS 101

8.1 Une plateforme pour des applications modulaires . . . . . . . . . . . . . . . . . 101
8.1.1 Matériel de test et scénario pour les évaluations initiales . . . . . . . 102
8.1.2 Résultats numériques du lancement de CATS et ses modules . . . . . 103
8.1.3 Conclusions des évaluations initiales . . . . . . . . . . . . . . . . . . . . 103
8.2 Des applications capables d’acquérir des nouvelles fonctionnalités . . . . . . 104
8.2.1 Matériel de test et scénario pour le téléchargement de services . . . 104
8.2.2 Résultats numériques du téléchargement et des adaptations . . . . . 105
8.2.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
8.3 Des applications réactives aux changements du contexte . . . . . . . . . . . . 108
8.3.1 Test 1 : Matériel de test et scénarios d’échange de service . . . . . . 109
8.3.2 Test 1 : Résultats numériques . . . . . . . . . . . . . . . . . . . . . . . . 111
8.3.3 Test 1 : Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
8.3.4 Test 2 : Matériel de test et scénarios d’évaluation . . . . . . . . . . . . 116
8.3.5 Test 2 : Résultats numériques . . . . . . . . . . . . . . . . . . . . . . . . 118
8.3.6 Test 2 : Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
8.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Conclusions et perspectives 123

Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Le contexte, élément clef des applications mobiles ! . . . . . . . . . . . . . . . 123
La plateforme d’exécution et de gestion pour les applications mobiles . . . . 124
Un prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Nouvelles fonctionnalités pour la plateforme CATS . . . . . . . . . . . . . . . . 126
Vers une application universelle dédiée aux transports . . . . . . . . . . . . . 127
Une vision du futur des applications mobiles ! . . . . . . . . . . . . . . . . . . . 127
Table des figures

2.1 Les couches des systèmes sensibles au contexte. . . . . . . . . . . . . . . . . . 22

3.1 Un composant SCA [Cha07]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1 La dépendance des applications de leur contexte d’exécution. . . . . . . . . . 40

5.1 Les caractéristiques de l’environnement . . . . . . . . . . . . . . . . . . . . . . . 50

5.2 Les caractéristiques d’un terminal mobile . . . . . . . . . . . . . . . . . . . . . . 53
5.3 Vue d’ensemble des éléments de contexte. . . . . . . . . . . . . . . . . . . . . . 54
5.4 XML schéma et un exemple d’instance du XML . . . . . . . . . . . . . . . . . . 60

6.1 Une application constituée par assemblage de services . . . . . . . . . . . . . 67

6.2 Partage des services entre les applications . . . . . . . . . . . . . . . . . . . . 69
6.3 Service avec plusieurs versions équivalentes . . . . . . . . . . . . . . . . . . . . 70
6.4 La plateforme CATS avec deux exemples d’applications. . . . . . . . . . . . . . 77
6.5 Le Context Manager et les Context Monitors. . . . . . . . . . . . . . . . . . . . 78
6.6 L’Execution Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.7 Le Trader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7.1 Le cycle de vie d’un bundle OSGi. . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7.2 Exemple de bundles OSGi et leurs dépendances. . . . . . . . . . . . . . . . . . 88
7.3 Un bundle OSGi avec iPOJO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.4 Le cycle de vie d’une instance de composant iPOJO. . . . . . . . . . . . . . . . 90
7.5 La plateforme CATS – prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.6 Structures de données du Context Manager. . . . . . . . . . . . . . . . . . . . . 96
7.7 Structures de données de l’Execution Manager. . . . . . . . . . . . . . . . . . . 97
7.8 Métadonnées d’un bundle exposant un service. . . . . . . . . . . . . . . . . . . 98
7.9 Métadonnées pour déclarer l’utilisation d’un handler. . . . . . . . . . . . . . . 99

8.1 Temps moyen d’installation et démarrage des bundles sur HTC Hero. . . . . 103

xiii
8.2 Comparaison du temps de téléchargement en fonction de la taille du module
sur Samsung 551 et HTC Hero, à petite distance. . . . . . . . . . . . . . . . . . 105
8.3 Comparaison du temps d’échange complet pour des smartphones Samsung et
HTC, avec un service de 20 kB, en variant la distance entre les téléphones. . 106
8.4 Comparaison du temps d’échange complet versus le temps de téléchargement
pour des smartphones Samsung, avec un service de 20 kB, en variant la distance.107
8.5 Comparaison du temps de téléchargement en fonction de la taille du module
et la distance, pour des smartphones Samsung. . . . . . . . . . . . . . . . . . . 107
8.6 Configuration de test pour la mesure du temps d’indisponibilité. . . . . . . . . 109
8.7 Temps moyens d’adaptation pour test 1A, 1B et 1C . . . . . . . . . . . . . . . . 112
8.8 Tests 1A, 1B et 1C (« register », « start » et « install ») – distribution des
valeurs pour le temps d’échange sur chaque terminal de test et consommation
de mémoire. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.9 Tests mixtes de consommation de la mémoire. . . . . . . . . . . . . . . . . . . . 115
8.10 Mesures expérimentales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
8.11 Temps (A), (B) et (C) pour un échange entre deux versions du service RPS. . 118
8.12 Temps d’adaptation à partir du changement de contexte. . . . . . . . . . . . . 119
8.13 Temps (A) sur le téléphone Sony avec des services légers et lourds. . . . . . 120
Liste des tableaux

5.1 Représentation d’un élément de contexte (CE) . . . . . . . . . . . . . . . . . . . 60

5.2 Exemples des Éléments de Contexte (CE) de chaque type . . . . . . . . . . . . 61

6.1 Exemples de services dépendants de différents éléments de contexte. . . . . 70

6.2 Description d’un module d’application. . . . . . . . . . . . . . . . . . . . . . . . 72
6.3 Exemples fictifs de précisions absolues et relatives des services . . . . . . . . 73
6.4 Description d’un module d’application. . . . . . . . . . . . . . . . . . . . . . . . 74

7.1 Caractéristiques du matériel de test. . . . . . . . . . . . . . . . . . . . . . . . . 93

8.1 Les écarts types des tests d’adaptation 1A, 1B et 1C en valeur absolue (ms)
et pourcentage (%) par rapport à la moyenne. . . . . . . . . . . . . . . . . . . . 113
8.2 Consommation de mémoire (kB) après 100 répétitions. . . . . . . . . . . . . . . 115
8.3 Moyenne et écart type pour les temps (A), (B) et (C), avec le service RPS. . 119

xv
xvi
Introduction

Dans ce chapitre nous présentons le contexte général dans lequel ce

travail de thèse a été accompli, à savoir les avancées technologiques
de l’informatique récente. Dans un monde où un très grand nombre
d’applications est proposé aux utilisateurs, la prise en compte du contexte
d’exécution devient de plus en plus importante. Dans cette thèse, nous
nous intéressons aux applications fortement mobiles et à l’adaptation de
leur comportement en fonction de l’évolution du contexte.

Contexte général

Depuis des années, l’informatique s’immisce de plus en plus dans la vie de tous les
jours. Cela a commencé avec des ordinateurs de la taille de plusieurs pièces, pour arriver
aujourd’hui, au début du 21ème siècle, à des ordinateurs ultra-portables de la taille d’un
cahier A4. De plus, les nouveaux terminaux informatiques, tels que les tablettes tactiles
et les smartphones, ont connu une importante évolution et un énorme succès récemment.
Tous ces outils font partie de nos vies pour le travail, le divertissement (multimédia, jeux,
. . . ), mais aussi pour un nouveau type de communication, grâce aux réseaux sociaux. Avec la
croissance connue par le marché des terminaux mobiles, de plus en plus de personnes sont
accompagnées en permanence par ces outils. Les ventes totales de smartphones dans le
monde ont été de 172 millions d’unités vendues en 2009, 296 millions vendues en 2010 et
472 millions vendues en 2011 1 .
Ces petits « téléphones intelligents » sont de véritables concentrés de technologies :
communication (par le réseau téléphonique 3G ou 4G, Wi-Fi, Bluetooth) ; positionnement
GNSS 2 ; écran tactile ; appareil photo ; des processeurs de plus en plus puissants, etc. Toutes
ces capacités ouvrent des possibilités pour la création d’applications de plus en plus variées,
que les fabricants de téléphones, mais aussi les développeurs individuels, exploitent. Depuis
2007, il existe des « marchés d’applications » pour chacun des plus importants systèmes
d’exploitation mobiles (IOS avec AppStore, Android avec Google Play, . . . ). Ces marchés
permettent d’installer de nombreuses applications sur les téléphones, pour divers buts,
gratuitement ou en payant.
À côté de toutes ces avancées technologiques de l’industrie, la recherche n’est pas
restée indifférente. Des nouveaux domaines de recherche ont émergé, en liaison avec
l’informatique qui est présente partout et qui est devenue mobile. Les domaines d’intérêt
1. Conforme au consultant IT Gartner, www.gartner.com
2. En anglais : Global Navigation Satellite System (GNSS). Pour le moment, le plus répandu système est le
Global Positioning System (GPS), mis à disposition par le Département de la Défense des États-Unis.

1
actuels comprennent l’informatique ubiquitaire, les réseaux ad hoc mobiles (MANET et
VANET), le routage dans de réseaux ad hoc, Internet of Things, et beaucoup d’autres !

Motivations et but de cette thèse

Actuellement, parmi les domaines de recherche porteurs, on retrouve la notion de

contexte et plus particulièrement les applications sensibles au contexte. Depuis des années
ce sujet est évoqué et traité, le plus souvent dans des cas particuliers : Kirsch-Pinheiro et
al. [KPVOGM05], qui s’attaquent au contexte dans les environnements coopératifs nomades,
Bocquet [Boc08], qui considère le contexte des réseaux de communication ou Santos et
al. [SCF+ 10], qui collectent le contexte de l’utilisateur pour l’envoyer aux serveurs de services,
ce ne sont que quelques exemples. Le contexte représente toutes les informations qui peuvent
influencer l’exécution d’une application ou l’interprétation de son résultat [DA99]. Par exemple
une horloge qui fonctionne parfaitement ne va pas donner la bonne heure si on l’emmène
dans un pays avec un fuseau horaire différent. A cause du contexte, l’information n’est plus
pertinente. Nous aussi, nous considérons le contexte d’exécution comme un élément important
dans la conception et dans l’utilisation des applications. Notre intérêt porte surtout sur le
domaine des applications dédiées aux transports, avec ses contraintes particulières dues à
des utilisateurs fortement mobiles.
Ce travail de thèse a été effectué au sein de l’équipe « Décision, Interaction et Mobilité »
(DIM), thème « Systèmes Mobiles et Embarqués » (SyME), du Laboratoire d’Automatique, de
Mécanique et d’Informatique Industrielles et Humaines (LAMIH). La thématique de recherche
du laboratoire est axée autour des transports de surface. Notre équipe intègre des aspects
de l’informatique mobile et du transport. Dans le travail que nous présentons ici, nous
considérons un ensemble d’applications qui peuvent s’exécuter sur un terminal mobile, et
qui accompagnent et assistent l’utilisateur dans ses déplacements. Ces applications peuvent
être : la navigation, la recherche de points d’intérêt (boutiques, restaurants, etc.), des
notifications du trafic (accidents, véhicules d’urgence, etc.), la gestion de places de parking,
des informations aux arrêts du bus, etc. L’utilisateur peut être dans des situations différentes,
notamment à pied, dans un moyen de transport, ou en train de conduire sa voiture. De
plus, ces situations changent pendant le voyage, car l’utilisateur peut faire des parties de
son trajet à pied et d’autres en voiture ou dans les transports en commun. Au cours de
ses déplacements, le contexte change, et les applications utilisées devraient adapter leur
fonctionnement en concordance. Considérons un utilisateur qui est en ville et cherche une
boutique de chaussures en utilisant une application. Peu de temps après, il change d’avis et
repart sur l’autoroute sans arrêter son application. Son terminal devrait gérer seul l’arrêt
des fonctionnalités qui ne sont plus utiles afin de ne pas consommer la batterie. Dans le
même temps, une fois sur l’autoroute, l’utilisateur devrait profiter des fonctionnalités de
sécurité routière même s’il a oublié de démarrer les applications correspondantes.
Le but de cette thèse est de proposer une architecture logicielle permettant d’assurer
un fonctionnement cohérent de l’ensemble des applications qui accompagnent une personne
lors de ses déplacements. Nos utilisateurs doivent profiter de leurs applications avec des
bonnes performances dans toutes les conditions. Ils doivent aussi pouvoir bénéficier de
nouvelles applications, spécifiques à un endroit ou à une entité, tel qu’un parking ou
un arrêt de bus. Vue la nature de ces applications, nous touchons à plusieurs domaines
de l’informatique. Nous nous intéressons à des aspects divers du transport, allant de
la navigation jusqu’aux horaires des moyens de transport en commun. Nous considérons
également les applications véhiculaires que nos utilisateurs pourraient employer, qui se

2
basent sur des réseaux ad hoc. Un utilisateur possède plusieurs applications dont il se sert
en se déplaçant. Son environnement et la situation dans laquelle il utilise ses applications
changent dynamiquement, influençant la façon dont les applications doivent réagir. Nous
devons prendre en compte les différents aspects de contexte afin d’étudier leur influence sur
les applications mobiles.
Bien que les applications sensibles au contexte soient étudiées depuis environ une
décennie, ce domaine reste très vaste, avec de multiples pistes encore à explorer. Il est
difficile – voire impossible – de créer un modèle global de contexte, qui soit utilisable par
toute application informatique. Nous devons donc concentrer nos efforts sur un domaine
de recherche. Il existe plusieurs aspects liés au contexte des applications mobiles, variant
des préférences de l’utilisateur à l’environnement où il se trouve ou encore à l’état de son
terminal mobile. L’utilisation des informations de contexte diffère également : une préférence
en terme de musique peut servir à proposer un catalogue en ligne personnalisé, pendant que
la localisation de l’utilisateur, près d’un accident, peut servir à l’avertir du danger. Notre plus
grand intérêt porte sur la prise en compte du contexte dans le cadre des applications dédiées
aux transports, dans le but d’assurer un bon fonctionnement des applications d’un utilisateur
fortement mobile. Nous étudions donc le contexte dans ce domaine, son influence sur les
applications et la manière dont nous pouvons l’utiliser afin d’améliorer les applications.
Etant donnée l’évolution dynamique du contexte, nous allons voir que les applications ont
besoin de changer leur comportement ou d’acquérir de nouvelles fonctionnalités pour servir
l’utilisateur au mieux. Dans ce travail, nous allons étudier le contexte et l’architecture des
applications dédiées aux transports afin de rendre ces dernières flexibles et adaptables aux
changements de contexte.

Organisation du mémoire

Dans une première partie, nous présentons l’état de l’art sur les avancées de la recherche
dans les domaines connexes. Nous passons en revue quelques-unes des directions de la
recherche en informatique mobile dans le chapitre 1. Ensuite nous nous intéressons aux
travaux existants sur le contexte dans le chapitre 2 et aux architectures qui permettent
de rendre les applications adaptables dans le chapitre 3. Nous précisons les problèmes
auxquels nous tentons de répondre dans le chapitre 4.
Nous présentons nos contributions dans la deuxième partie de ce manuscrit. Dans le
chapitre 5, nous introduisons notre approche sur la prise en compte du contexte et sa
modélisation. Dans le chapitre 6, nous décrivons notre proposition pour une architecture
permettant l’adaptation du comportement des applications au contexte.
Dans la troisième partie de ce travail, nous présentons le prototype de recherche
(chapitre 7) mis en œuvre, ainsi que les évaluations réalisées (chapitre 8), qui montrent
la faisabilité et les performances de notre solution. Nous finissons le manuscrit par les
conclusions et les perspectives (page 123).

3
4
 Première partie

État de l’art et Problématique

5
Chapitre 1

L’informatique d’aujourd’hui :
omniprésente, mobile, complexe !

De nos jours, l’informatique n’est plus liée à un poste de calcul fixe : nos
téléphones sont devenus de petits ordinateurs, et même d’autres objets
autour de nous sont informatisés. De plus, les systèmes informatiques
gagnent en complexité : un très grand nombre d’entités participent à
l’interaction, plusieurs utilisateurs se trouvent dans des bâtiments intelli-
gents, nous avons besoin d’accéder à des services à distance, etc. Nous
passons ici en revue quelques-uns des domaines qui sont reliés à nos
recherches : l’informatique ubiquitaire, les questions de localisation et
d’accès aux services, les réseaux véhiculaires ou encore les questions de
sécurité et de qualité de service.

1.1 L’informatique ubiquitaire (omniprésente)

Dans l’informatique ubiquitaire, les capacités informatiques s’intègrent dans la vie de

tous les jours, dans les différents objets qui nous entourent, tels que des imprimantes, nos
vêtements, les appareils électroménagers, etc. Le terme de « ubiquitous computing » a été
utilisé une des premières fois en 1991 par Mark Weiser [Wei91], scientifique chez Xerox PARC.
Il considère l’informatique omniprésente comme la troisième vague de l’informatique, après
la première, celle de l’ordinateur central 1 et la deuxième, celle de l’ordinateur personnel. Le
but de cette nouvelle tendance en informatique est de faciliter et augmenter la qualité des
interactions d’un utilisateur, que ce soit avec des objets informatiques ou avec les autres
personnes (les collègues de bureau, les amis, etc.) à proximité ou à distance.
Aujourd’hui, plusieurs termes sont utilisés pour désigner des concepts similaires, comme
l’observent Friedewald et Raabe [FR11] : ubiquitous computing, pervasive computing, ambient
1. En anglais : mainframe computer – un ordinateur de grande puissance utilisé par plusieurs personnes

7
1.2. L’informatique actuelle et la localisation

intelligence ou encore the Internet of Things (IoT). Malgré toutes ces dénominations, l’idée
centrale reste la même, l’informatique est omniprésente dans notre environnement, avec
de nouveaux avantages mais aussi de nouveaux défis. Dans le même travail, les auteurs
résument les principales caractéristiques de l’informatique ubiquitaire :
– Ce sont des systèmes décentralisés, basés sur des réseaux décentralisés.
– Le matériel informatique et les logiciels sont embarqués dans des objets de tous les
jours, disparaissant dans l’environnement.
– L’utilisateur reçoit de l’assistance mobile à travers des services informatiques présents
n’importe où, n’importe quand !
– Les systèmes sont sensibles au contexte et s’adaptent aux besoins d’information.
– Les systèmes font une reconnaissance automatique et un traitement autonome des
tâches répétitives.
Les terminaux participant aux interactions sont des plus divers. Ils varient de serveurs
fournissant des services, aux ordinateurs portables, téléphones (smartphones) et jusqu’aux
puces informatiques (tag RFID 2 ). Le nombre et l’hétérogénéité des appareils rendent les
systèmes informatiques de nos jours encore plus complexes.
Friedewald et Raabe [FR11] évoquent quelques domaines d’application de l’informatique
ubiquitaire. Par exemple, la vente, la gestion des matériaux et la production industrielle ou
encore le transport logistique peuvent profiter des nouvelles tendances en informatique. Dans
tous ces cas, la technologie RFID peut être utilisée pour suivre les différentes marchandises
durant leur parcours, améliorant ainsi leur gestion. Cette technologie consiste à mémoriser
des informations dans une puce électronique qui est suffisamment petite pour être attachée à
différents objets. Les informations peuvent ensuite être récupérées à travers les ondes radio,
même à quelques mètres de distance. D’autres domaines d’application de l’informatique
ubiquitaire utilisant le RFID sont l’identification personnelle et les services de santé, où
l’informatique pourrait alléger les tâches administratives grâce à l’identification et le suivi
automatisé. Enfin, l’informatique ubiquitaire peut influencer la mobilité et les transports de
différentes façons. Pour le transport public, plusieurs améliorations peuvent être apportées,
dont par exemple des services d’assistance pour la réservation des billets ou des services
d’information sur les itinéraires. En ce qui concerne le transport individuel, trois domaines
sont identifiés [FR11] : (i) la sécurité routière ; (ii) l’optimisation de la circulation et (iii) le
confort des passagers (par exemple avec un accès internet dans la voiture). Chacune de ces
préoccupations est étudiée en tant que sujet de recherche à part entière.
L’informatique ubiquitaire désigne une tendance de l’informatique actuelle. Satyana-
rayanan [Sat01] et Kakousis et al. [KPP10] identifient les précurseurs de l’informatique
ubiquitaire, l’informatique distribuée et mobile. Par rapport à ses précurseurs, le ubiquitous
computing introduit de nouvelles exigences, comme la limitation des interactions avec l’utili-
sateur (invisibilité) ou les espaces intelligents (des bâtiments informatisés). Dans la suite
nous allons passer en revue quelques sous-domaines de l’informatique récente – ubiquitaire
ou non –, leurs défis et les solutions que l’on trouve dans la littérature.

1.2 L’informatique actuelle et la localisation

Les utilisateurs et leurs terminaux portables sont mobiles, et peuvent se trouver n’importe
où. La localisation est devenue, de nos jours, l’un des éléments les plus importants de
2. La radio-identification, désignée par le sigle RFID (de l’anglais Radio Frequency IDentification)

8
 Chapitre 1. L’informatique d’aujourd’hui : omniprésente, mobile, complexe !

l’informatique, et aussi l’un des aspects le plus étudié. Un très grand nombre d’applications
dépend de cette fonctionnalité pour fournir des services pertinents aux utilisateurs. La
navigation ou les requêtes de type « quel est le restaurant le plus proche ? » ne sont que
deux exemples parmi les applications de la localisation.
Bellavista et al. [BKH08] étudient les services géodépendants 3 et leurs évolutions au
cours du temps. Ce type de service a pour but de proposer des résultats en fonction de
l’endroit où l’utilisateur se trouve, et s’est développé surtout après l’intégration des modules
GNSS dans les smartphones. Mais les préoccupations liées à la localisation sont plus variées
que la simple utilisation d’un module GNSS qui fournit des coordonnées géographiques.
Même si c’est l’un des moyens les plus précis de localisation, il s’avère parfois inefficace
ou juste trop compliqué. Un premier problème est posé par la compréhension humaine de
l’information reçue : il nous faut une traduction par rapport à ce que nous connaissons, par
exemple le nom d’une rue. Un deuxième problème apparait à l’intérieur des bâtiments, où le
signal GNSS n’est plus disponible. De plus, dans un bâtiment nous raisonnons en fonction
des couloirs et pièces, et non pas en fonction des coordonnées géographiques ou rues.
Parfois le problème de localisation se pose totalement différemment : on a juste besoin
de savoir quand on est très proche d’une certaine entité. D’autres technologies peuvent
s’avérer utiles dans ce cas, par exemple le RFID. En effet, on peut trouver des applications
comme celles de visites guidées de musées, qui fonctionnent de cette manière. Devant les
œuvres se trouve une puce RFID destinée à initier une explication audio au moment où
le visiteur s’approche. Cette technologie permet d’aller encore plus loin, par exemple pour
assurer des plans d’urgence en cas de sinistre, afin de sauver des vies et le patrimoine.
Sailhan et al. [SAM+ 09] proposent une telle solution de localisation et surveillance à base
de RFID actif. Ce type de localisation appartient au domaine de la communication en
champ proche 4 . C’est une technologie de communication sans-fil à courte portée, qui permet
l’échange d’informations entre des terminaux à une distance inférieure à 10 cm. Pesonen et
Horster [PH12] présentent les différents aspects de cette technologie : le business model,
les applications, la sécurité et les problèmes.
Dans cette section nous avons voulu donner un aperçu de la complexité de la localisation
sous ses différentes formes : position relative ou absolue (coordonnées géographiques), à
l’intérieur ou à l’extérieur, etc. Nous allons revenir sur la localisation dans le paragraphe 2.2
(page 18), pour discuter plus en détail de son influence sur les applications en tant qu’élément
de contexte.

1.3 La découverte et l’accès à des services en mobilité

Dans le contexte actuel, l’informatique est devenue partie intégrante de nos vies. Mais
les domaines de recherche restent vastes, avec des problèmes qui doivent encore être résolus.
Un de ces problèmes est qu’on n’arrive pas toujours à bien accéder aux services, malgré
l’omniprésence des capacités informatiques dans nos villes et bâtiments. La principale cause
est l’hétérogénéité des appareils, services et protocoles. La mobilité des usagers ne fait
qu’accroître la difficulté pour accéder aux services, car la connexion peut être perdue à
n’importe quel moment.
Pour accéder à un service, le grand nombre de protocoles de communication peut poser
des défis. De plus, les protocoles sont parfois spécifiques à un cas d’utilisation, d’autres fois

3. En anglais : Location-Based Services (LBS)

4. En anglais : Near Field Communication (NFC)

9
1.4. L’informatique mobile et les réseaux ad hoc

ils sont propriétaires aux fournisseurs de services. Bocquet [Boc08] propose dans son travail
de thèse un intergiciel pour améliorer l’accès à des services tels que RMI ou des Services
Web, tout en étant mobile. Il propose une infrastructure multi-modèles, à travers laquelle
le code métier est découplé du code de répartition. Cette solution permet au terminal de
l’utilisateur de s’adapter au grand nombre de protocoles de communication.
Les communications à partir d’un terminal mobile peuvent se faire avec ou sans une
infrastructure de communication. Le deuxième cas est représenté par les réseaux ad hoc,
définis par Toh [Toh01] comme des « ensembles de deux ou plus de terminaux mobiles,
avec des capacités de communication et de réseau ». Dans ce type de structure il n’y a
pas de point central, le réseau s’organisant seul. Le monde ad hoc arrive avec un défi
supplémentaire pour la communication, la mobilité des nœuds. On se retrouve entouré par
des entités informatisées et des services, mais il faut encore pouvoir communiquer avec
ceux-ci, découvrir les services quand ils apparaissent et savoir quand ils ont disparus.
Sassi et Le Sommer [SS09a, SS09b] présentent des méthodes de découverte et d’invoca-
tion de services, dans le cadre des réseaux ad hoc dynamiques. Ils montrent l’importance de
la géolocalisation des services pour un meilleur délai d’invocation ainsi qu’une amélioration
du trafic du réseau. Ils se basent en outre sur la technique store-carry-forward pour per-
mettre aux nœuds dans les réseaux mobiles d’accéder à des « infostations », même si ces
derniers sont hors de leur portée. Dans un cadre similaire, Lenders et al. [LMP05], proposent
une approche différente pour la découverte de services dans les réseaux ad hoc. Les auteurs
attribuent des potentiels positifs aux nœuds qui fournissent des services et négatifs aux
nœuds qui requièrent des services. Ainsi, les requêtes sont dirigées d’un nœud négatif vers
le plus grand potentiel qui se trouve à proximité.
Un autre problème causé par la multitude de services disponibles est lié à leur pertinence
pour chaque utilisateur. Une personne n’aura pas besoin à tout moment de tous les services
auxquels elle pourrait accéder. Rasch et al. [RLS+ 11] s’intéressent à la découverte personna-
lisée de services, en employant le contexte de l’utilisateur pour choisir les services les plus
pertinents. Les auteurs proposent un modèle formel de contexte, basé sur les préférences
de l’utilisateur et les descriptions des services, afin de faire une recherche pro-active de
services adéquats.
Plusieurs autres travaux s’intéressent à la découverte de services, que ce soit des
Services Web [JAS10], des services dans les réseaux ad hoc [MBB09a] ou encore des services
dans les réseaux de capteurs [HTC11]. D’autres travaux encore font des états de l’art sur ce
sujet, comme par exemple [ZMN05, VP08]. Pour ce domaine seul, la découverte et l’accès
à des services en mobilité, nous remarquons un grand nombre d’aspects à traiter, liés au
type de service (Service Web, en ad hoc, réseau de capteurs), à la mobilité des usagers, ou
encore à leurs préférences. Tous ces aspects à prendre en considération lors de la création
d’applications rendent de plus en plus complexes les systèmes informatiques de nos jours.

1.4 L’informatique mobile et les réseaux ad hoc

Avec les nouveaux terminaux, de plus en plus petits et mobiles, les réseaux aussi ont
changé. Parmi les domaines d’application de l’informatique mobile on retrouve les MANETs :
Mobile Ad hoc NETwork. Varshavsky et al [VRdL05] les décrivent comme « un groupe de
nœuds mobiles sans fil, capables de s’auto-configurer pour communiquer des informations
au-delà de leur portée en acheminant les paquets grâce aux nœuds intermédiaires ». Les
MANETs sont un sujet de recherche depuis les années ’90, avec un Working Group IETF

10
 Chapitre 1. L’informatique d’aujourd’hui : omniprésente, mobile, complexe !

existant depuis 1997 5 .

Une spécialisation des MANETs sont les VANETs : Vehicular Ad-Hoc NETwork. Ce sont
des réseaux mobiles dédiés aux véhicules, prenant en considération les contraintes spéci-
fiques liées à la mobilité. Le but de ce genre de réseaux est d’améliorer la sécurité, l’efficacité
et la commodité du trafic. Willke et al. [WTM09] étudient les protocoles de communication
inter-véhicules (IVC) 6 et leurs utilisations. Ils proposent de diviser les applications VANET
en quatre catégories, en fonction des besoins des protocoles de communication :

1. Services d’information générale. Ce sont des services qui ont pour but d’acheminer
des informations ou même du contenu multimédia aux véhicules.

2. Services d’information pour la sécurité routière. Ces services consistent à offrir des
notifications importantes sur l’état du trafic, telles que des accidents, des freinages,
etc.

3. Contrôle de mouvement individuel à travers la communication inter-véhicules. Ce type

d’application a pour but d’intervenir activement dans la conduite, en déclenchant des
actionneurs (accélération, freinage) afin d’éviter des situations dangereuses.

4. Contrôle de mouvement de groupe à travers la communication inter-véhicules. De

façon similaire au cas précédent, ce sont des applications qui peuvent intervenir sur
la conduite pour coordonner un groupe de véhicules.

Dans un autre travail sur les réseaux véhiculaires, Sichitiu et Kihl [SK08] font un état de
l’art sur les systèmes de communication inter-véhicules, les applications qu’ils supportent
et les technologies (de communication) qui les rendent possibles. Ils proposent une autre
classification des types d’applications pour les réseaux véhiculaires, en fonction de leur but :
la sécurité publique ; la gestion du flot de trafic ; la coordination du trafic (par exemple à
travers le platooning 7 ) ; assurer des informations pour les voyageurs ; assurer le confort des
voyageurs (par exemple à travers une connexion internet).
Une très grande partie des applications mobiles se basent sur la connaissance de la
position exacte du véhicule. Depuis que la technologie GNSS est utilisée largement, les
coordonnées géographiques sont devenues indispensables pour un grand nombre d’applica-
tions. Elles permettent de connaitre où l’on se trouve, mais aussi de calculer les distances
vers d’autres entités à proximité, de garder un historique du chemin parcouru ou encore
prédire une position future. Les réseaux véhiculaires utilisent le Wi-Fi pour communiquer et
partager des événements, en précisant la localisation exacte de l’événement. Des nouveaux
standards sont crées afin d’améliorer la communication inter-véhicules, comme par exemple
ceux proposés par IEEE 1609 8 .
Dans le cadre des réseaux MANET et VANET, les applications informatiques sont, comme
on peut le constater, assez variées. Pour les réseaux véhiculaires, les conditions sont plus
difficiles et les contraintes sont plus strictes que dans d’autres domaines. Les utilisateurs
sont fortement mobiles et les enjeux plus importants, surtout pour les applications de sécurité
routière.

5. Working Group Mobile Ad-hoc Networks (MANET), http ://datatracker.ietf.org

6. En anglais : Inter-Vehicle Communication (IVC)
7. Un regroupement très serré de véhicules qui se déplacent ensemble.
8. IEEE 1609 Dedicated Short Range Communication Working Group : Standards for Wireless Access in
Vehicular Environments (WAVE) – le group de travail pour la communication dédiée courte portée, fournissant
des standards pour l’accès sans fil dans les environnements véhiculaires, http ://vii.path.berkeley.edu/1609_wave/

11
1.5. Questions de sécurité et qualité de service

1.5 Questions de sécurité et qualité de service

Toujours dans le contexte de l’informatique omniprésente, la recherche a deux autres

axes importants à explorer : la sécurité des applications et la qualité de service. En effet, les
nouvelles applications, surtout pour les smartphones et tablettes, se développent tellement
rapidement, que des failles sont inévitables. Le grand nombre de services et de terminaux
rend le contrôle de qualité et la sécurité des applications difficile.

Sécurité

En 2001, Luo et al. [LKZ+ 01] attirent l’attention sur les problèmes de sécurité des
applications en environnement mobile. Ils identifient trois défis pour la sécurité : (i) la facilité
d’attaquer les réseaux sans fil ; (ii) les utilisateurs mobiles qui souhaitent des services
« anywhere, anytime » – n’importe où, n’importe quand ; (iii) le besoin d’une solution de
sécurité extensible à grande échelle. Les auteurs proposent une solution à base de certificats,
adaptée aux réseaux ubiquitaires.
D’autres travaux, comme Chen et al. [CLV12], s’intéressent à l’accès sécurisé aux services
à travers un réseau. Les auteurs proposent l’utilisation des communautés virtuelles pour
restreindre la portée des services et assurer que seuls les utilisateurs authentifiés en
profitent. Une autre approche utilise l’historique d’exécution des services afin d’aboutir à des
compositions sûres. Costa et al. [CDM11] proposent une telle solution qui est utilisable même
pour des réseaux ouverts, où des utilisateurs inconnus peuvent participer aux interactions.
Jones et Hamlen [JH11] proposent une approche orientée service pour la sécurité du code
binaire mobile. Ils utilisent la procédure d’inlining pour faire des contrôles de sécurité
pendant l’exécution du code considéré à risque.
La sécurité n’est pas abordée dans le travail présenté ici, mais cela pourrait être intégré
dans les futures versions du projet. Nous observons que plusieurs travaux traitent ce sujet
de manières différentes (certificats, communautés virtuelles, historique ou encore inlining).
L’intégration d’une de ces méthodes à notre solution fait partie de nos perspectives (voir
page 127).

Qualité de service (QdS)

La qualité des services 9 qui sont offerts aux utilisateurs intéresse la recherche et
l’industrie depuis longtemps. En 1994, l’ITU 10 définit le standard de qualité de service
en téléphonie. La notion se propage en informatique pour garantir un certain niveau de
performance. Malgré les avancées récentes dans la qualité de service, le sujet reste d’actualité.
Par exemple, les réseaux ad hoc posent toujours des problèmes à cause de leur caractère
dynamique et du fait qu’ils n’ont pas été créés pour assurer une qualité de service. Afin de
garantir la bonne transmission des paquets, Sondi [SO10] propose d’intégrer des aspects
liés à la qualité de service dans les MANETs, dès la conception du protocole de routage.
La vision de l’informatique axée sur les services 11 [PG03] consiste à assurer des fonction-
nalités pour les utilisateurs, à travers la composition de services. Il est possible d’intégrer des
notions de QdS à ce niveau, grâce à des services avec des coûts ou des qualités de service

9. En anglais : Quality of Service (QoS)

10. International Telecommunication Union, recommandation E.800, http ://www.itu.int/
11. En anglais : Service-Oriented Computing (SOC)

12
 Chapitre 1. L’informatique d’aujourd’hui : omniprésente, mobile, complexe !

différentes. Les fournisseurs peuvent donc proposer des versions d’un même service avec une
QdS différente. Dans une approche similaire, Jiang et al. [JHB+ 10] décrivent l’intégration
de Service Level Agreement (SLA) pour garantir la qualité de service dans des systèmes
auto-adaptifs.
Dans certains cas, les besoins des applications en terme de ressources peuvent être
très importants. Par exemple, Verbelen et al. [VSS+ 11] s’intéressent aux applications de
réalité augmentée, qui utilisent souvent du contenu multimédia. Les auteurs proposent
donc d’assurer la meilleure qualité de service possible en employant plusieurs versions des
services. De cette manière, la configuration des applications peut être adaptée aux ressources
disponibles et à la connexion. Dans un autre travail, Jureta et al. [JHF09] proposent un
modèle de qualité de service pour exprimer les besoins des clients, ainsi que les capacités
des fournisseurs. Les entités qui s’occupent de la composition des services peuvent ainsi
choisir les services pour atteindre la meilleure qualité.
Nous pouvons considérer que notre travail contribue à la qualité de service au niveau
des applications. En effet, nous ne nous focalisons pas sur les couches plus basses, comme
le réseau, mais plutôt sur le comportement des applications. L’adaptation au contexte assure
un meilleur comportement des applications en fonction des conditions externes.

1.6 Conclusions

Nous avons présenté brièvement quelques-uns des axes de la recherche actuelle en

informatique mobile. Comme nous pouvons le constater, l’informatique de nos jours est
omniprésente, mobile et donc complexe. En effet, le grand nombre d’aspects à prendre
en considération (localisation, communication, sécurité, etc.) fait que la conception des
systèmes informatiques est devenue une tâche très compliquée. Les domaines de recherche
se chevauchent et les limites ne sont pas toujours claires, rendant la classification des types
d’applications encore plus difficile. Par exemple, est-ce que les VANET font partie de la
recherche liée aux réseaux ou à l’informatique ubiquitaire ?
Parmi tous les sujets de l’informatique mobile, nous nous intéressons principalement aux
applications dédiées aux transports et à l’adaptation de leurs comportements, quand des
éléments de contexte changent. La localisation, la découverte de services ou les réseaux ad
hoc sont tous des domaines connexes à ce travail. Par contre, les deux aspects clefs concernent
le contexte et les architectures logicielles qui permettent de prendre en considération ce
contexte et d’adapter les applications en conséquence. Par la suite, nous présentons l’état
de l’art touchant à ces sujets.

13
1.6. Conclusions

14
Chapitre 2

Tout le monde parle de « contexte »

Dans ce chapitre, nous nous penchons sur la notion de contexte et sa

liaison avec l’informatique. Qu’est-ce que le contexte ? Quel est son rôle
dans l’informatique de nos jour ? Pourquoi est-ce que tout le monde parle
de contexte ? – Ce sont les questions auxquelles nous tentons de répondre
dans ce chapitre, sans oublier de donner des exemples de la prise en
compte du contexte dans des systèmes informatiques actuels.

2.1 Qu’est ce que le contexte ?

Nous avons, en tant qu’humains, une compréhension intuitive du contexte. Nous ré-
agissons différemment en fonction d’éléments tels que : l’heure, la météo, l’expression du
visage de l’interlocuteur, etc. Hoareau et Satoh soulignent dans leur travail [HS09] le fait
que nous utilisons souvent, parfois même de manière inconsciente, des informations de
contexte. Ils remarquent que pour y arriver, nous sommes dotés d’un système sensoriel
complexe, constitué par des capteurs (les yeux, la peau, etc.) et une unité centrale qui traite
les informations (le cerveau). Ainsi, en fonction des informations reçues nous adaptons notre
comportement aux conditions externes.
Dans les deux dernières décennies, avec l’évolution de l’informatique mobile, la notion
de contexte est également devenue très importante dans la recherche. Nos terminaux
informatiques nous suivent partout et se doivent d’intégrer cette nouvelle notion, pour nous
proposer des applications pertinentes.

2.1.1 Comment le contexte est-il défini ?

Dans cette section, nous nous intéressons aux définitions du contexte dans la littérature
spécialisée. Des travaux très pertinents sont fournis en 1999-2001 par Dey (et Abowd)

15
2.1. Qu’est ce que le contexte ?

[DA99, DAS01, Dey01]. Les auteurs essayent d’améliorer la compréhension des notions
context et context-aware en faisant une synthèse des travaux existants à l’époque, mais
aussi en proposant leurs propres définitions. D’après ces travaux :
« Le contexte est toute information qui peut être utilisée pour caractériser
la situation d’une entité. Une entité est une personne, un lieu ou un objet qui
est considéré pertinent pour l’interaction entre l’utilisateur et l’application, y
compris l’utilisateur et l’application. »
Cette définition généralise les précédentes, qui se contentaient d’énumérer des éléments de
contexte tels que : la position, l’identité des personnes et des objets voisins, les changements
de voisins, la saison, la température, le temps, etc. (dans [ST94, BBC97, RPM98]). La définition
donnée par Dey et Abowd permet de juger si une certaine information fait partie du contexte
ou non. De plus, le contexte est considéré par rapport à chaque application (ou activité).
Dans le travail de Dey et Abowd [DAS01], les entités impliquées dans des interactions
sont divisées en trois catégories : des lieux (bâtiment, pièce, etc.), des personnes (individus
ou groupes) et des objets (objets physiques, ordinateurs). Une certaine information fait
partie du contexte si elle influe sur une interaction entre deux entités.
Dans les travaux qui touchent au sujet du contexte, les auteurs ont des approches
différentes en terme de modèle ou domaine d’application, comme nous allons le présenter
dans la suite. Par contre, une grande partie des chercheurs s’appuient sur les définitions
données par Dey et ses co-auteurs : [GPZ04], [BCQ+ 07], [BDR07], [BBH+ 10], [EKT12], etc. 1
Nous retenons la définition de Dey comme guide pour comprendre le contexte.

2.1.2 Que veut dire « context-aware » ?

Le terme anglais aware signifie conscient. Une application peut être consciente de son
contexte et réagir en conséquence. Les notions context-aware application et context-aware
computing se traduisent respectivement par application sensible au contexte et informatique
contextuelle. D’après [DA99], ce serait communément reconnu dans la littérature que le
premier travail de recherche en informatique sur le context-aware serait celui de Want et
al. [WHFaG92], en 1992. Ce travail porte sur un système de localisation des employés dans
les pièces d’un bâtiment, utilisant des badges actifs.
La première fois que l’on a parlé de context-aware computing est en 1994, dans le
travail de Schilit et Theimer [ST94]. Les auteurs considèrent l’informatique contextuelle
comme la capacité d’une application mobile à découvrir et à réagir à des changements
dans l’environnement. D’autres mots qui décrivent l’informatique contextuelle incluent réac-
tif [CTB+ 95] ou réceptif [EHC+ 93]. Nous reprenons de nouveau la définition donnée par Dey
et Abowd [DA99] :
« Un système est sensible au contexte s’il utilise le contexte pour fournir
des informations et/ou des services pertinents pour l’utilisateur, où la pertinence
dépend de la tâche de l’utilisateur. »
De nouveau, la définition est assez générale pour permettre d’inclure tous les aspects. La
sensibilité au contexte peut ensuite être divisée en fonction de son utilisation. D’un côté,
une application peut se concentrer sur la détection, la perception et l’interprétation des
éléments de l’environnement de l’utilisateur, comme par exemple dans les travaux de Pascoe
et al. [Pas98, PRM98]. D’un autre côté, les applications peuvent changer dynamiquement
1. Les travaux sur le contexte signés par Anind K. Dey et ses co-auteurs entre 1999 et 2001, [DA99, Dey01],
ont plus de 2000 citations sur Google Scholar.

16
 Chapitre 2. Tout le monde parle de « contexte »

leur comportement, en fonction du contexte de l’utilisateur et de l’application (par exemple

dans [BBC97, DMC+ 98]).
Les caractéristiques des applications sensibles au contexte seraient, d’après Dey [Dey01] :
présenter des informations et services à l’utilisateur ; exécuter automatiquement un service
pour l’utilisateur ; étiqueter l’information de contexte pour une récupération ultérieure.

2.1.3 Tout le monde parle de contexte

Dans les deux dernières décennies, les différents aspects du contexte ont été analysés par
la recherche. Quelques-uns des chercheurs ont fixé un ensemble d’éléments qu’ils considèrent
être le contexte pour le type d’application sur lequel ils travaillent. Par exemple, le travail
[CCT+ 03] représente le contexte pour des applications avec des interfaces utilisateur multi-
cibles. Dans [KPVOGM05] les auteurs proposent une modélisation du contexte pour des
utilisateurs nomades se servant d’un collecticiel sur le web.
D’autres auteurs préfèrent les couches plus abstraites, touchant à la sémantique. Mokhtar
et al. [MPG+ 08] proposent une spécification sémantique des propriétés pour une découverte
de services avec la prise en compte du contexte et de la qualité de service. Une autre piste à
explorer est représentée par les applications sensibles au contexte supportant des activités
cognitives. Prekop et Burnett [PB03] présentent un modèle de contexte dans le but de créer
des applications capables de déduire les besoins des utilisateurs en fonction de leur identité
et de l’environnement.
Henricksen et al. [HIR02] parlent du besoin d’une infrastructure pour la récupération, la
gestion et la dissémination du contexte aux applications omniprésentes. D’autres chercheurs
créent des modèles génériques, dans le but d’intégrer ultérieurement des sources de contexte
variées. Bacha et al. [BOA11] proposent un modèle générique du contexte pour la conception
des interfaces utilisateur. Ils lient les concepts du modèle à des ontologies spécifiques aux
différents domaines d’application. Rasch et al. [RLS+ 11] proposent un modèle formel où
le contexte est représenté en tant qu’espace multidimensionnel, évitant les ontologies. Ils
utilisent ce modèle pour la découverte personnalisée de services.
Parfois il arrive que certains articles ne parlent pas explicitement de contexte, mais le
travail présenté dans l’article utilise cette notion implicitement. Par exemple, Mukhtar et
al. [MBB08, MBB09b] font des compositions de services qui prennent en considération des
contraintes au moment de l’exécution. Les auteurs ne parlent pas de contexte, même s’ils
utilisent des informations que l’on peut considérer contextuelles, comme les ressources des
terminaux ou les préférences des utilisateurs.
Tout le monde parle de contexte parce que le contexte est la clef pour le développement
des nouveaux services dans la société informatisée qui émerge (Coutaz et al. [CCDG05], en
2005). Habituellement, le contexte est considéré comme la représentation d’un état (d’une
personne, d’un objet, etc.). Coutaz et al. attirent l’attention sur le caractère évolutif du
contexte. Les utilisateurs, les services et les ressources découvrent d’autres utilisateurs,
services et ressources qu’ils intègrent pour une meilleure expérience. Nous remarquons à
travers tous ces exemples que beaucoup de chercheurs parlent du contexte, mais de manière
différente. En effet, il existe un grand nombre d’aspects à traiter et il serait difficile de prendre
en considération tous les éléments de contexte pour toutes les applications. De plus, si l’on
arrivait à modéliser tout le contexte, les applications destinées aux smartphones seraient
probablement trop lourdes par rapport aux ressources limitées du terminal. Pour ces raisons,
la plupart des chercheurs présentés ci-dessus ont choisi de limiter leur interprétation du

17
2.2. Des modèles de contexte

contexte à une application ou à un type d’applications.

Même s’il est impossible de définir le contexte de manière exhaustive, on aurait besoin
d’une classification des types de contexte et des manières de réagir au contexte. Soylu et
al. [SCD09] attirent l’attention sur le fait que la recherche manque d’une vision d’ensemble et
d’une méthodologie concrète pour la réalisation des applications sensibles au contexte. Les
auteurs remarquent que, malgré un grand nombre de travaux dans le domaine, la relation
entre le contexte et les adaptations n’est pas bien définie, et le rôle de l’utilisateur n’est
pas toujours clair.
Notre but n’est pas de revoir toutes les définitions existantes, ni de proposer une définition
universelle. Nous retenons ici que le contexte doit être défini par rapport à une interaction ou
une activité et qu’un système est considéré sensible au contexte s’il l’utilise pour fournir des
informations et services pertinents par rapport à la tâche de l’utilisateur. Nous considérons le
contexte par rapport à un utilisateur mobile et ses interactions avec des applications dédiées
aux transports. Par la suite nous allons voir plus en détail d’autres préoccupations relatives
au contexte : la modélisation et l’utilisation du contexte afin d’améliorer les applications.

2.2 Des modèles de contexte

Pour pouvoir utiliser les informations de contexte, il faut d’abord les connaitre. Un
système informatique doit donc capter ces informations, éventuellement en utilisant des
capteurs, qui fournissent souvent des données brutes, difficiles à interpréter. Par exemple,
savoir que la température a la valeur 30 ne nous aide pas, car cela pourrait très bien être
une valeur en Fahrenheit ou en Celsius. Dans un cas il fait très froid, dans l’autre très chaud.
Il faut donc savoir interpréter les données brutes, pour ensuite les inférer afin d’obtenir des
informations utiles. Si l’on sait que la température est de 30˚C, on veut également savoir
où il fait aussi chaud. Le contexte constitue une très grande quantité d’information, qui
doit être acquise, interprétée et conservée. Dans cette section, nous nous intéressons aux
modèles de la littérature pour représenter le contexte.
Hoareau et Satoh font un état de l’art dans [HS09] sur les différents modèles de
contexte, touchant aussi au traitement de requêtes. Le principal aspect abordé dans ce
travail est la représentation des données contextuelles, qui permettent de décrire l’état
d’une entité. Les auteurs considèrent seulement l’aspect données du contexte, ne prenant
pas en considération les services qui peuvent être disponibles ou non à certains endroits.
Ils négligent aussi d’autres aspects comme l’utilisation des informations de contexte pour
modifier le comportement ou l’aspect des applications. Néanmoins, ils présentent une vue
d’ensemble sur une partie des problèmes liés au contexte, notamment la modélisation, en
se basant également sur le travail de Chen et Kotz [CK00]. D’après ces deux travaux, les
structures de données utilisées pour encoder et transmettre le contexte appartiennent le
plus souvent à l’une des six catégories suivantes :

Le modèle clef-valeur. Une clef représente un attribut de l’environnement, dont il faut

mesurer la valeur. Par exemple, <Température_bureau_4, 20> représente l’information
de température avec le modèle clef-valeur. Ce modèle est simple et facile à entretenir,
mais peut s’avérer peu flexible.
Le modèle à balises. Le modèle à balises 2 contient des données organisées dans des
structures hiérarchiques, grâce aux balises. L’une des plus importantes utilisations de

2. En anglais : Markup model

18
 Chapitre 2. Tout le monde parle de « contexte »

ce modèle dans l’informatique mobile sont les profils (utilisateur, terminal). Composite
Capabilities/ Preference Profiles est une telle spécification, basée sur RDF et encodée
en XML. Buchholz et al. [BHH04] et Indulska et al. [IRRH03] utilisent ce modèle pour
la prise en compte du contexte.
Le modèle orienté objet. Dans ce modèle, les informations de contexte sont capturées dans
les états des objets. De plus, les méthodes des objets permettent d’accéder aux
informations et de faire des traitements spécifiques.
Le modèle basé sur la logique. Dans le modèle basé sur la logique 3 , les données de con-
texte peuvent être exprimées comme des faits dans un système à base de règles. Des
méthodes de la logique de premier ordre peuvent être appliquées pour raisonner sur
le contexte.
Ontologie. Des ontologies et d’autres outils du Semantic Web (comme le langage OWL2
[OWL09]) peuvent être utilisés pour représenter et traiter le contexte, comme le font
par exemple Chen et al. [CFJ03]. Les ontologies permettent de créer des vocabulaires
partagés entre les systèmes et d’ajouter de la sémantique aux données de contexte.
Logique de situation. Dans les travaux de Loke [Lok04] ou Henricksen et Indulska [HI06],
une nouvelle abstraction est introduite, notamment la situation 4 , afin de modéliser les
informations de contexte en fonction des situations.

Chacun de ces modèles a ses avantages et ses désavantages en terme de rapidité,

de flexibilité ou encore d’extensibilité. En conséquence, chaque modèle est plus ou moins
efficace en fonction des besoins d’un certain type d’application. Des applications s’exécutant
sur un ordinateur de bureau ou un serveur peuvent utiliser des modèles basés sur la logique
ou sur des ontologies afin de déduire de nouvelles informations. Des applications pour les
téléphones mobiles (comme celles que nous visons) nécessitent des modèles plus légers,
leur permettant de réagir vite aux changements de contexte.

Les modèles de localisation

Depuis que l’informatique est devenue mobile, la localisation est l’un des aspects du
contexte le plus important et aussi l’un des plus utilisé. Nous pouvons mieux interagir
avec l’environnement en sachant où l’on est, qui est autour de nous et quels objets sont à
proximité. On peut faire deux types d’utilisations de la localisation : d’un côté, la localisation
du terminal et d’un autre côté, le suivi des entités environnantes. Les technologies permettant
la localisation varient du GNSS 5 au RFID ou encore à la localisation à base de systèmes
ultrasoniques de suivi 6 . A ces technologies s’ajoutent le Wi-Fi et les techniques de locali-
sation basées sur le réseau téléphonique UMTS 7 [BKH08]. Mises à part les technologies
pour acquérir des informations de localisation, nous nous intéressons ici à la modélisation
de cette information cruciale. Becker et Dürr [BD05] font un état de l’art sur les principaux
modèles de localisation utilisés pour des applications mobiles.
Le modèle géométrique. La position des entités est représentée par des coordonnées géo-
métriques, permettant de calculer des distances entre les entités. Le plus souvent, la
position est exprimée par rapport au World Geodetic System (WGS84), le système
géodésique mondial, en utilisant les satellites GNSS.
3. En anglais : Logic-based model
4. En anglais : Situation logic
5. La version des Etats Unis, le GPS, est disponible depuis 1995 (conforme à NAVSTAR GPS Operations).
6. En anglais : Ultrasonic-based tracking systems
7. Universal Mobile Telecommunications System (UMTS), l’une des technologies de téléphonie mobile de
troisième génération (3G)

19
2.2. Des modèles de contexte

Le modèle symbolique (sémantique). Les positions sont définies en donnant des noms
symboliques, plus proche de l’intuition humaine (par exemple, nom et numéro de rue,
étage et bureau dans un bâtiment, etc.).
Le modèle hybride. Les deux modèles antérieurs peuvent être combinés, comme le font
par exemple Jiang et Steenkiste [JS02], afin de profiter des avantages de chacun.
Delot et al. [DLT07] proposent un modèle de métadonnées ayant pour but d’assurer
l’interopérabilité entre les modèles géométriques et sémantiques de localisation.
Concernant la localisation à l’intérieur des bâtiments, Afyouni et al. [ARC12] font un
état de l’art sur les modèles spatiaux de représentation de la localisation, dans le cadre
des services géodépendants. Ils présentent les approches géométriques et symboliques de
division des espaces afin de construire des applications de navigation en intérieur, sensibles
au contexte. Ces modèles se basent sur des techniques radio (WLAN, RFID, Bluetooth) mais
aussi d’autres technologies telles que l’infrarouge ou les ultrasons.

Quels sont les besoins de l’informatique sensible au contexte ?

Dans le cadre de l’informatique ubiquitaire, les applications ne sont pas conçues de la

même manière que pour les ordinateurs de bureau. Strang et Linnhoff-Popien [SLP04] font
une synthèse des demandes que les systèmes doivent respecter pour la modélisation du
contexte. Les auteurs citent :
– La composition distribuée. Un système ubiquitaire doit prendre en considération le
manque d’une entité centrale pour gérer les données et les services.
– La validation partielle. Les informations contextuelles doivent pouvoir être validées
partiellement par rapport à un modèle.
– La richesse et la qualité des informations. En plus de l’information de contexte, un
modèle de contexte doit supporter aussi les notions de richesse et de qualité.
– L’ambiguité et l’incomplétude. Due au dynamisme des systèmes ubiquitaires et de
leurs environnements, un modèle de contexte doit pouvoir gérer des informations
incomplètes ou ambiguës.
– Le niveau de formalisme. Il est important de s’assurer que tous les participants à une
interaction comprennent bien le (même) sens des données échangées.
– L’applicabilité aux environnements existants. Un modèle de contexte doit être capable
d’interagir avec des infrastructures déjà existantes telles que les services web.
Dans le même travail, [SLP04], les auteurs font une évaluation des modèles de contexte, en
fonction des critères ci-dessus. Ils reprennent les mêmes six modèles que Chen et Kotz [CK00],
présentés au début de cette section, sauf celui de logique de situation. En contre-partie,
ils considèrent le modèle graphique (comme par exemple UML). Strang et Linnhoff-Popien
concluent que les ontologies sont les plus adaptées pour modéliser le contexte dans des
environnements ubiquitaires, tenant compte des critères qu’ils considèrent. En revanche,
Pils et al. [PRS06] résument les problèmes posés par ce type de modèle. Premièrement,
la lisibilité réduite de telles standardisations pour les personnes qui doivent interagir
directement avec ces informations. Deuxièmement, le coût élevé pour des petites entreprises
pour adopter des ontologies. Et troisièmement, le désordre causé par l’immense quantité
d’information et les erreurs introduites par les humains.
Dans [HS09], Hoareau et Satoh concluent que la complexité des données de contexte, leur
volatilité ainsi que la large gamme d’applications existantes, posent encore des problèmes
pour la modélisation du contexte. Les systèmes très génériques, incluant plusieurs modèles

20
 Chapitre 2. Tout le monde parle de « contexte »

de contexte et d’applications, sont souvent peu efficaces. D’après eux, les sous-problèmes
de contexte et les applications ont des exigences incompatibles, pour lesquelles il n’existe
pas de solution universelle. Pour cette raison les modèles de contexte sont souvent créés
pour une application en particulier.
Jusqu’à présent, nous avons vu ce qu’est le contexte en général, comment modéliser les
informations de contexte et quels sont les besoins de l’informatique ubiquitaire vis-à-vis
des modèles de contexte. L’étape suivante est d’étudier quand et comment utiliser ces
informations et quelle doit être la réaction des systèmes informatiques.

2.3 Quand et comment le contexte est-il utilisé ?

Le contexte doit être défini par rapport à une interaction (par exemple entre l’utilisateur
et son application [DA99]) pour qu’il ait une signification. Dans cette section nous nous
intéressons aux différentes situations où les informations de contexte sont nécessaires.
Bolchini et al., dans leur étude sur des modèles de contexte orientés données [BCQ+ 07],
évoquent quelques-unes des utilisations du contexte :
– L’adaptation des interfaces. Ce sujet appartient au domaine des interactions homme-
machine et touche à deux aspects : (i) l’adaptation des interfaces par rapport à
l’utilisateur actuel et ses préférences, comme présentée par exemple dans le travail de
synthèse de Simonin et Carbonell [SC07], et (ii) l’adaptation des interfaces en fonction
des terminaux disponibles et du contexte d’utilisation, comme décrite par Calvary et
al. [CCT+ 03], où l’application utilise non seulement le téléphone mais aussi d’autres
terminaux (écrans, claviers).
– Filtrer l’ensemble de données pertinentes pour une application. Bolchini et al. [BCST06]
fournissent un travail sur l’adaptation des données. Le but est de réduire la quantité
d’informations présentée à l’utilisateur en les filtrant par rapport au contexte et en
gardant seulement celles pertinentes dans la situation actuelle.
– Augmenter la précision de récupération d’information. Shen et al. [STZ05] proposent
des algorithmes sensibles au contexte pour la récupération des informations à travers
de requêtes, en se basant entre outre sur les historiques des requêtes.
– Découverte de services. Par exemple Raverdy et al. [RRdLC+ 06] proposent un intergiciel
multi-protocole de découverte et d’accès à des services. Leur but est d’assurer une
sélection correcte des services par rapport aux besoins actuels des utilisateurs dans
un milieu pervasif.
– Rendre les interactions de l’utilisateur implicites. Petrelli et al. [PNS+ 00] discutent
dans leur travail les interactions implicites pour une application de visite guidée de
musée. Ils considèrent des éléments tels que le temps passé devant une œuvre, le
parcours antérieur, etc. pour proposer des descriptions adaptées.
– Créer des environnements intelligents. Dey et al.[DSSK06] fournissent une étude sur
les besoins des utilisateurs pour des maisons intelligentes.

Une autre utilisation du contexte, moins évidente que dans les cas précédents, est pour
l’adaptation des services techniques tels que la sécurité ou les transactions. Les utilisateurs
ne remarquent pas le changement, mais cette adaptation peut être essentielle pour le bon
fonctionnement d’une application. Herault (et al.) [Her05, HLD06] proposent une solution
pour adapter les services techniques en utilisant une architecture à base de composants.
On peut constater que les utilisations des informations de contexte sont assez variées.
Dans certains cas, plusieurs terminaux participent à une même action, dans d’autres cas un

21
2.3. Quand et comment le contexte est-il utilisé ?

seul terminal interagit avec un serveur, etc. Il faut donc déterminer les acteurs qui parti-
cipent aux interactions avant de décrire l’utilisation du contexte. Ensuite, il faut considérer
l’ensemble des entités participant au système informatique.

2.3.1 Des systèmes sensibles au contexte et l’accès au contexte

Nous avons déjà constaté que les systèmes informatiques de nos jours sont devenus
assez complexes. Pour les rendre sensibles au contexte, nous avons vu que nous devons,
d’un côté réfléchir à comment le contexte doit être modélisé, et d’un autre côté, déterminer
quelle sera son utilisation. Mais quels sont les éléments d’une architecture sensible au
contexte ? Quels sont les différents traitements à faire ?
Baldauf et al. [BDR07] font un état de l’art sur les systèmes sensibles au contexte, où
ils extraient les traits communs de tels systèmes dans la pratique. Les auteurs discutent
d’une plateforme conceptuelle à différentes couches pour la séparation des préoccupations
dans les systèmes sensibles au contexte. Les couches que les auteurs considèrent sont
présentées dans la figure 2.1.

Capteurs −→ Données brutes −→ Pré-traitements −→ Stockage et gestion −→ Applications

Figure 2.1 – Les couches des systèmes sensibles au contexte.

Les données de contexte peuvent être divisées en deux dimensions : physique versus
logique (Hofer et al. [HSP+ 03]) ou bien, en utilisant des dénominations équivalentes, externe
versus interne (Prekop et Burnett [PB03] et Gustavsen [Gus02]). Les éléments externes sont
directement mesurables par des capteurs, comme par exemple la température, la luminosité,
la position, etc. Les éléments internes (ou logiques) sont plutôt liés à l’utilisateur et doivent
parfois être déduits : le but, la tâche actuelle, les émotions, etc. Ces données peuvent même
être de nature informatique, déduites de l’exécution d’une application.
Baldauf et al. évoquent trois types de capteurs pour l’acquisition du contexte, mentionnés
aussi par Indulska et Sutton [IS03] : des capteurs physiques (hardware) ; des capteurs virtuels
(software) ; des capteurs logiques (combinent les deux autres pour inférer des informations).
L’accès des applications au contexte peut se faire de trois manières, comme décrit par
Chen [Che04] :
– Accès direct aux capteurs. Dans ce cas, les applications intègrent les pilotes 8 des
capteurs, rendant cette solution peu adaptée pour des systèmes distribués. De plus,
elle manque de flexibilité à cause du fort couplage entre les applications et les pilotes.
– Infrastructure intergicielle. Cette technique est plus facilement extensible que la
précédente. Elle utilise l’encapsulation pour séparer le code métier des détails de bas
niveau concernant la capture du contexte.
– Serveurs de contexte. Cette méthode consiste à externaliser la gestion du contexte
en utilisant une architecture client-serveur. Un serveur possède plus de ressources
qu’un terminal mobile, et pourra donc mieux gérer une grande quantité d’information
de contexte, allégeant ainsi la tâche du client.
Baldauf et al. [BDR07] considèrent dans leur travail un système distribué avec un serveur
de contexte qui centralise les informations fournies pas les capteurs, et avec plusieurs clients
8. En anglais : Device drivers.

22
 Chapitre 2. Tout le monde parle de « contexte »

(applications) qui peuvent soit interroger l’état du contexte (par des sondages) soit s’abonner
auprès du serveur pour être notifiés au moment d’un changement de contexte.

2.3.2 Des exemples d’applications sensibles au contexte

Malgré une grande quantité de travail fourni par la recherche liée au contexte, et malgré
de nombreuses applications qui se disent sensibles au contexte, nous considérons qu’il reste
encore la place pour des améliorations. Un des problèmes concerne la classification des
types d’adaptation possibles. Nous considérons nécessaire d’étudier le niveau auquel le
contexte est utilisé et le but dans lequel il est utilisé. Nous essayons ici de donner quelques
exemples de manières très différentes de considérer le contexte.

L’adaptation du contenu et de la présentation en fonction du terminal

Il existe des applications telles que des sites web ou des services web qui proposent
du contenu pour leurs utilisateurs : des articles d’actualité, du commerce en ligne, des
informations sur les horaires de bus, train, etc. Pour ce type d’applications, plusieurs
adaptations sont possibles. Premièrement, la présentation de la page devrait s’adapter
en fonction de la taille de l’écran, car souvent les sites sont créés pour le grand écran
d’un ordinateur et sont totalement inadéquats pour un téléphone portable. Dans ce cas, la
présentation peut être réorganisée afin d’avoir une meilleure visibilité sur un petit écran.
Toujours dans le même but, le contenu lui aussi peut être adapté, en choisissant d’afficher
seulement la partie la plus importante. Cette adaptation peut servir aussi dans le cas où la
connexion n’est pas rapide, permettant d’envoyer moins de données. Il faut pouvoir exprimer
les données caractérisant le terminal, dans le but d’adapter la présentation. De même, il
faut pouvoir exprimer les préférences de l’utilisateur.
La spécification Composite Capability/Preference Profiles (CC/PP) est proposée par
le W3C [Kis07] pour décrire le contexte de distribution du terminal 9 . Cette spécification
étend le Resource Description Framework (RDF), un langage général de description de
métadonnées, proposé aussi par le W3C. La spécification CC/PP permet de construire un
profil, tenant compte des capacités du terminal mais aussi de l’utilisateur. Néanmoins, les
aspects modélisés sont, en grande partie, statiques, c’est-à-dire que leur valeur ne change
pas (ou change peu souvent). Pour cette raison, ce type de modélisation du contexte n’est
pas adapté pour des applications confrontées à un contexte qui change très souvent. Bettini
et al. [BBH+ 10] résument les critiques les plus importantes apportées aux modèles basés sur
CC/PP, touchant à leurs capacités limitées pour : (i) saisir une variété de types de contexte,
(ii) saisir des relations, dépendances, ponctualité, et qualité d’information de contexte, (iii)
permettre un contrôle de cohérence, et (iv) permettre un raisonnement sur le contexte.
Malgré les critiques apportées, la spécification W3C pour CC/PP reste très utile dans
certains cas, surtout quand il s’agit d’un profil qui change peu souvent. De notre point de
vue, l’utilisation la plus importante reste l’adaptation du contenu en fonction du terminal.
Mais d’autres utilisations restent possibles. Par exemple, Mukhtar et al. [MBB08, MBB09b]
étendent le modèle CC/PP et l’utilisent pour faire la composition des applications ou des
tâches multimédia. Ils présentent une approche dynamique pour la sélection des composants
(services), prenant en considération leur besoins de ressources et/ou les préférences de
l’utilisateur.

9. En anglais : the device’s delivery context

23
2.3. Quand et comment le contexte est-il utilisé ?

Un autre moyen d’adapter le contenu est à travers des services web qui répondent à des
requêtes, telles que « quel est le restaurant le plus proche ? » Dans ce cas, l’une des plus
importantes informations est celle de localisation de l’utilisateur. D’autres aspects tels que
les préférences de l’utilisateur peuvent aussi influencer la réponse. Pour aller plus loin, une
branche de la recherche se concentre sur la personnalisation des interfaces, pour fournir
les plus pertinentes informations par rapport à l’utilisateur, comme si l’application avait été
conçue pour lui. Bacha et al. [BOA11] proposent un modèle générique de contexte pour la
conception de n’importe quelle interface utilisateur. Les auteurs veulent guider la conception
de l’interface ainsi que l’information présentée en fonction de ce qui est important pour
l’utilisateur.
Une classe entière d’applications est dédiée aux guides mobiles. Ce sont des applications
destinées à améliorer l’expérience de l’utilisateur pendant une visite (musée, exposition,
ville, etc.). Emmanouilidis et al. [EKT12] font une étude des différents aspects d’un tel guide :
sensibilité au contexte, architectures client, interfaces utilisateur, fonctionnalités offertes.
Ils proposent une taxonomie en fonction de ces aspects. Emmanouilidis et al. classifient le
contexte en cinq catégories : (i) utilisateur ; (ii) environnement ; (iii) système ; (iv) social et
(v) service. Ils concluent que, dans la littérature, la plupart des travaux négligent toutes les
catégories de contexte sauf une : la localisation de l’utilisateur (une sous-catégorie de (i)
). La plupart des auteurs arrivent à détecter où l’utilisateur se trouve pour lui envoyer un
contenu adéquat.
Les exemples présentés ici touchent à l’adaptation du contenu et de la présentation
pour un terminal, principalement mobile et avec des ressources limitées. D’autres types
d’adaptations sont possibles dans l’informatique ubiquitaire. Dans le domaine des interactions
homme-machine (IHM), Ganneau et al. [GCD07] s’attaquent à la plasticité des interfaces,
pour rendre un terminal capable d’utiliser d’autres entités informatiques telles que des
écrans externes. Par rapport aux exemples antérieurs où le terminal est le seul à changer la
présentation, ici le terminal profite des autres entités autour. Les auteurs utilisent un modèle
Evenement – Condition – Action pour réagir aux changements qui ont lieu au moment de
l’exécution.

Les divers aspects de l’adaptation au contexte

Etant donnés la complexité du contexte et le grand nombre d’éléments qui pourraient

influencer les applications, cela devient clair qu’il y a un besoin de classifier les types
d’applications, les types de contexte et les façons de réagir au contexte. Nous essayons de
montrer la complexité du domaine au travers des exemples. Voici trois types d’applications
très différentes par rapport aux entités qui participent aux interactions : (i) une application
avec un seul utilisateur, qui se connecte aux services web ; (ii) une application de coopération
dans un réseau ad hoc (MANET ou VANET), où plusieurs utilisateurs interagissent dans un
but commun tel que éviter des accidents ; (iii) une application de type maison intelligente,
où plusieurs objets informatiques travaillent ensemble pour l’utilisateur. Nous observons
que le nombre et le type d’entités qui participent sont très différents d’un cas à l’autre.
Si l’on considère le contexte, on peut s’intéresser aux différents éléments : (i) des
informations personnelles telles que les préférences en matière de chaussures, le niveau
d’anglais, des rendez-vous dans l’agenda de l’utilisateur, etc. ; (ii) des informations externes :
lumière, température, localisation, etc. ; (iii) ses informations sur l’état du terminal : niveau
de la batterie, mémoire disponible, etc. En fonction du type d’application, il faut déterminer
l’importance de chaque élément pour les interactions de l’utilisateur avec d’autres entités.

24
 Chapitre 2. Tout le monde parle de « contexte »

Enfin, voici trois exemples de façons assez différentes de réagir au contexte, où l’entité
qui agit à cause du contexte est différente : (i) un service web peut donner des réponses
différentes aux clients en fonction de leur localisation – c’est donc le service qui adapte
le contenu d’une réponse ; (ii) une application peut prévoir un besoin de l’utilisateur en
fonction de ses préférences et du contexte ; (iii) une application peut réagir au changement
d’un élément de contexte et adapter son comportement. Les aspects que nous venons de
présenter et encore d’autres doivent être considérés dans la création de systèmes sensibles
au contexte.

2.4 Conclusions

Dans ce chapitre, nous avons passé en revue quelques-uns des aspects liés aux systèmes
sensibles au contexte. Nous sommes partis de la définition générale donnée par Dey, qui
permet de comprendre ce qu’est le contexte pour l’informatique. Nous avons retenu que le
contexte doit être défini par rapport à une interaction ou une activité de l’utilisateur. Ensuite,
nous avons passé en revue les modèles de contexte, les besoins des systèmes sensibles
au contexte ainsi que les différentes étapes à accomplir, de la captation à l’utilisation des
informations contextuelles. Le chapitre présente également quelques objectifs de l’utilisation
du contexte : adapter des interfaces, filtrer des informations, découvrir des services, etc.
Comme remarqué aussi par [SCD09], nous constatons le manque d’une vision globale
sur le contexte. Souvent, les travaux sont vagues et ne précisent pas exactement quel
contexte ils considèrent ([MBB08, MBB09b]), qui devra s’adapter ou qui est impliqué dans
les interactions. Le but de cette thèse n’est pas de fournir une classification globale et
exhaustive du contexte et des types d’adaptation. Nous essayons par contre de spécifier
clairement le cadre de nos travaux. Nous nous intéressons aux utilisateurs qui se déplacent
et à leurs applications sur des terminaux mobiles, destinées à les accompagner et à les
assister dans leurs déplacements. Pour nous, le contexte est surtout lié aux éléments de
l’environnement, qui changent souvent. Notre but est de fournir des applications robustes,
capables de fonctionner correctement dans toutes les conditions. Pour cela il faut pouvoir
adapter le comportement des applications.
Nous allons présenter notre proposition pour la modélisation du contexte dans le
chapitre 5 (page 49). Dans le chapitre qui suit, nous nous intéressons aux travaux existants
sur les architectures qui permettent à une application de s’adapter.

25
2.4. Conclusions

26
Chapitre 3

Réagir au contexte : applications et

architectures adaptables

Dans le chapitre précédent nous avons présenté différents aspects de la

recherche liée au contexte. De nos jours, il est devenu impératif que les
applications (surtout mobiles) réagissent en fonction de différents éléments
de contexte, en adaptant leur contenu, leur composition et même leur
comportement. Dans ce chapitre, nous analysons les aspects techniques
permettant de rendre les applications adaptables aux changements de
contexte.

3.1 Introduction

Dans le processus de création de systèmes sensibles au contexte il faut tout d’abord

définir ce qu’est le contexte pour les applications du système en question. Une fois que les
éléments influençant l’exécution des applications ont été déterminés, il faut comprendre la
manière dont le système doit les prendre en considération : est-ce qu’il doit calculer des
résultats personnalisés ? est-ce qu’il doit réagir aux changements de contexte et adapter
son comportement ? est-ce qu’il doit prévoir des actions ? etc.
Après ces questions, nous nous devons de considérer la suite du processus : quelle
architecture permettra au système de prendre en considération le contexte ? Dans certains
cas, il suffit pour une application d’envoyer les bonnes informations sur son contexte auprès
des entités externes pour récupérer des résultats pertinents. Par exemple si l’on veut
interroger un serveur sur le « restaurant le plus proche », il faut lui envoyer la position en
même temps que la requête. Le serveur s’occupe ensuite de rendre une réponse adéquate à
la situation. Dans d’autres cas, un changement dans l’application elle-même est nécessaire.
Par exemple, une application utilisant le GNSS est obligée de changer son moyen de
se localiser au moment où l’utilisateur entre dans un bâtiment. Donc des changements

27
3.2. Des modèles, standards, pratiques et architectures

importants doivent se produire sur le terminal de l’utilisateur. C’est plutôt ce deuxième cas
que nous considérons dans notre travail.
Nous constatons donc que les systèmes sensibles au contexte doivent fournir des
capacités d’adaptation. Le choix d’une bonne architecture logicielle dépend de multiples
critères : le type d’adaptation au contexte, le terminal ciblé pour l’exécution et ses contraintes
en terme de ressources, le type d’interaction avec d’autres entités (communication internet,
réseau ad hoc, utilisation des entrées/sorties connectées en Bluetooth, . . . ), etc. Dans cette
partie, nous passons en revue les différentes architectures que l’on peut trouver dans la
littérature concernant les systèmes sensibles au contexte.

3.2 Des modèles, standards, pratiques et architectures

Dans la recherche, mais aussi dans l’industrie, plusieurs principes, standards et pratiques
sont utilisés dans la conception de systèmes informatiques. De plus, de nos jours, la
modularité est devenue très importante, d’un côté pour simplifier le développement du code
et d’un autre côté pour la réutilisation du code. Cette pratique permet aussi de créer des
composants interchangeables, rendant les applications plus flexibles.

3.2.1 Les modèles à composants

Les systèmes informatiques ont besoin de flexibilité, modularité et séparation des

préoccupations. Pour atteindre ces objectifs, les systèmes peuvent être basés sur des
composants. L’idée de produire des composants logiciels en masse, de manière similaire à
l’industrie, a été énoncée pour la première fois en 1968, par McIlroy [McI68]. Le concept est
devenu populaire plus tard, à la fin des années ’90, dans l’industrie aussi bien que dans
le monde universitaire. Brown et Wallnau [BW98], ensuite Cai et al. [CLWK00] s’attaquent
à la programmation orientée composant (CBSE) 1 . Les auteurs de ces travaux décrivent
quelques-unes des caractéristiques des composants :
– Ce sont des parties indépendantes et remplaçables d’un système, qui remplissent une
fonction claire dans une architecture bien définie.
– Les composants peuvent être associés à l’exécution et sont identifiables à travers leurs
interfaces, qui spécifient un contrat.
Le but de la programmation orientée composant est la construction des systèmes logiciels
en utilisant des composants sur étagère du commerce 2 , et ainsi accélérer le processus de
création de logiciels.
Une critique que l’on apporte à ce type d’architecture est son caractère statique après
la composition du système. En effet, une fois les composants choisis et couplés, ils ne
sont que difficilement changés durant l’exécution. Liu et al. [LPH04] proposent en 2004
une plateforme pour la programmation à base de composants. Leur but est de créer des
applications capables d’auto-gestion, pour un environnement grid. Les auteurs utilisent des
règles de haut niveau pour les interactions et la coordination entre les composants. Les
règles servent également à l’adaptation au contexte.

1. En anglais : Component-based software engineering (CBSE)

2. En anglais : Commercial off-the-shelf components [CLWK00]

28
 Chapitre 3. Réagir au contexte : applications et architectures adaptables

3.2.2 L’architecture orientée service et la programmation orientée service

Papazoglou et al. [PTDL07] décrivent l’architecture orientée service 3 (SOA) comme

la manière logique de concevoir des systèmes logiciels qui fournissent des services. Un
service est mis à disposition par un fournisseur (ou producteur) au bénéfice d’un client (ou
consommateur). Srinivasan et Treadwell [ST05] attirent l’attention sur la signification du
terme SOA, qui se réfère à la conception d’un système et non pas à son implémentation.
Les auteurs présentent également une vue d’ensemble sur l’architecture orientée service et
discutent les caractéristiques des services :

– Les services peuvent être utilisés séparément ou intégrés dans un service composé.
Cette pratique promeut la réutilisation du code.
– Les services communiquent avec leurs clients à travers des messages et sont définis
par les messages qu’ils acceptent et par la réponse qu’ils fournissent.
– Les services peuvent être autonomes ou dépendants des autres services ou de res-
sources pour fournir leur résultat.
– Les services doivent décrire leurs interfaces, politiques et protocoles de communication.
Ils n’ont pas besoin de décrire les détails d’implémentation.

Une autre caractéristique importante de la SOA est le couplage lâche entre les ser-
vices [ST05]. Cela veut dire que les composants logiciels minimisent les connaissances qu’ils
ont les uns des autres. Les avantages de cette pratique incluent la flexibilité des clients, qui
ne sont pas limités à un seul fournisseur mais peuvent en découvrir et utiliser plusieurs.
Les applications conçues de cette manière sont extensibles à travers l’ajout de nouveaux
services. Les fournisseurs peuvent être remplacés facilement, permettant des mises à jour
rapides. Pour réussir à faire un couplage lâche, les services doivent être « sans état » 4 . Le
résultat fourni ne doit pas dépendre de l’état du fournisseur à un moment donné, car si c’est
le cas, le couplage entre les clients et les fournisseurs n’est plus lâche.
La programmation orientée service (service oriented computing – SOC) est un paradigme
qui utilise les services comme base pour la création des applications (voir aussi : Huhns et
Singh [HS05], Papazoglou et Georgakopoulos [PG03]). Le SOC représente une vision pour les
nouvelles plateformes informatiques, avec des nouveaux principes, architectures et technolo-
gies. SOA est l’un des éléments de base du SOC 5 . Papazoglou et Georgakopoulos [PG03]
considèrent les services comme des composants ouverts 6 , qui s’auto-décrivent, et qui sont
utilisés pour composer des applications distribuées, de manière rapide et peu coûteuse.
Les auteurs considèrent surtout un accès aux services via Internet. Dans la programmation
orientée service, il existent trois acteurs principaux : le fournisseur, le consommateur et le
courtier 7 . Un fournisseur publie ses services auprès du courtier, pendant qu’un consommateur
découvre les services connus par le courtier. Les caractéristiques qui font l’intérêt de ce
paradigme sont nombreuses. Premièrement, il permet un couplage lâche, où le consommateur
n’a pas besoin de connaître l’implémentation du service. Deuxièmement, le couplage peut se
faire à l’exécution, grâce au courtier. Troisièmement, le consommateur peut utiliser plusieurs
implémentations sans qu’il en soit conscient. Et finalement, les fournisseurs et consomma-
teurs n’ont pas besoin de considérer leur caractère local ou distant, ni l’infrastructure de
communication.

3. En anglais : Service Oriented Architecture (SOA)

4. En anglais : Stateless.
5. What is SOA, par Thomas Erl http ://www.whatissoa.com/
6. En anglais : Open components, i.e. avec des spécifications ouvertes
7. En anglais : Registry.

29
3.2. Des modèles, standards, pratiques et architectures

3.2.3 Composants versus services

Au cours du temps, des confusions sont apparues entre les composants et les services.
Janecek [Jan05] essaye de définir la différence entre ces deux termes. Il considère que la
programmation par composants est plus orientée vers le code, pendant que l’architecture
orientée services ignore d’une certaine façon le code. En effet, les services peuvent être
implémentés de différentes façons, même par des composants. Les deux architectures ont été
combinées pour la création d’une nouvelle : Service Component Architecture (SCA). OASIS
(Organization for the Advancement of Structured Information Standards) 8 , le consortium
en charge de spécifications libres, fournit les spécifications SCA, qui ont été annoncées en
2005 [sca05].
Chapell [Cha07] parle de SCA et des notions principales de ce type d’architecture. Le
composant représente l’unité de base des applications SCA. Même si en principe un compo-
sant est une abstraction, il est défini par rapport aux éléments suivants : des services, des
références, des propriétés et des liaisons. Un composant peut donc fournir plusieurs services,
illustrés en vert, à gauche dans la figure 3.1. Les références représentent les dépendances
des services fournis par d’autres composants (en mauve, à droite dans la figure). Les proprié-
tés permettent de configurer les composants. Enfin, les liaisons (bindings) représentent les
interactions entre les composants. Dans une architecture SCA, les composants peuvent être
associés pour former un composite. Dans un composite, les composants peuvent s’exécuter
sur la même machine ou sur des machines différentes, dans un ou plusieurs processus. De
plus, les composants d’un composite peuvent être écrits dans des langages de programmation
différents. Les interactions entre les composants sont modélisées par les services, ce qui
aide à la séparation entre le code et l’interface.

A P
Composant
B SCA Q

Service Propriété

Référence

Figure 3.1 – Un composant SCA [Cha07].

Escoffier et al. [EHL07] proposent de combiner les propriétés de la programmation orientée

service et celle orientée composant, en utilisant un modèle à composants orienté service. Ils
visent à combattre le caractère statique des configurations créées à base de composants,
qu’ils estiment un problème de ce type de systèmes. Le résultat de cette proposition est le
modèle à composants iPOJO, un outil puissant pour l’assemblage dynamique de services.
Escoffier et Hall [EH07] expliquent la création des applications adaptables dynamiquement
avec le modèle à composants iPOJO. Nous avons choisi ce modèle pour l’implantation de
notre prototype, nous allons donc y revenir avec plus de détails dans le chapitre 7 (page 85).

8. Specification de la version 1.1 de janvier 2011, http ://docs.oasis-open.org/

30
 Chapitre 3. Réagir au contexte : applications et architectures adaptables

En conclusion, le débat composant versus service n’a pas un gagnant et un perdant, mais
deux gagnants. Nous pouvons combiner ces deux modèles et profiter du développement
simplifié par les composants ainsi que du couplage lâche des services. Malgré la multitude
d’implémentations et modèles à base de composants, le consensus général est de définir un
composant en tant que boite noire avec des interfaces connues (Hnetynka et al. [HMM11]).
Nous nous intéressons à ces architectures car elles permettent des reconfigurations
dynamiques à l’exécution, nécessaires si l’on veut adapter les applications en fonction
du contexte. Des tels travaux existent déjà, comme par exemple celui de Ben Hamida et
al. [BHLMFBA11]. Les auteurs s’intéressent aux usagers mobiles qui sont confrontés à de
nouveaux services durant leurs déplacements. Ben Hamida et al. proposent une architecture
de déploiement d’applications orientées services, capables de changer leur composition en
fonction du contexte.

3.2.4 Autonomic computing

Dans le cadre des avancées technologiques en informatique, l’objectif de l’autonomic

computing 9 a été remis à la lumière en 2001, à l’initiative de IBM. Kephart et Chess
expliquent dans leur article [KC03] ce que l’autonomic computing a pour but : créer des
systèmes informatiques capables de s’auto-gérer en fonction d’objectifs de haut niveau,
donnés par les administrateurs. Ganek et Corbi [GC03] donnent des pistes pour la réalisation
de ce type de systèmes qui devraient respecter les principes fondamentaux de l’informatique
autonome :

1. Auto-configuration. Le système autonome doit être capable d’intégrer de nouveaux

logiciels et des nouvelles caractéristiques de façon dynamique.

2. Auto-réparation. Le système doit découvrir, diagnostiquer et traiter des perturbations

afin que l’expérience de l’utilisateur ne soit pas interrompue.

3. Auto-optimisation. Le système doit être capable de maximiser l’utilisation des res-

sources par lui-même.

4. Auto-protection. Le système doit utiliser les technologies existantes afin de prévoir,

détecter et se protéger des attaques.

Menascé et Kephart [MK07] décrivent un exemple de système autonome : un centre de

traitement de données. Si la vision était accomplie, ce centre pourrait être l’hôte de multiples
services pour plusieurs clients. Des nouveaux clients pourrait être accueillis, et le système
devrait configurer de manière autonome les ressources nécessaires. Bien que la vision
initiale était destinée aux systèmes à grande échelle, comme un centre de traitement de
données, le concept peut être appliqué aussi dans l’informatique ubiquitaire. Diaconescu et
al. [DBE08] proposent un intergiciel respectant les principes de l’informatique autonome pour
des applications destinées à des maisons intelligentes. Maurel et al. [MDL10] s’intéressent
à une solution pour l’intégration opportuniste des ressources de gestion autonome afin
d’obtenir un système complexe. Dans ce but, ils utilisent une approche orientée services
et conçoivent des tâches de gestion autonome en tant que services. En 2010, Dobson et
al. [DSNH10] concluent que, malgré les efforts et les avancées dans la recherche en ce
domaine, l’objectif de l’autonomic computing n’est pas encore entièrement accompli.

9. En français nommé aussi informatique autonome

31
3.2. Des modèles, standards, pratiques et architectures

3.2.5 Lignes de Produits (SPL)

La technique des lignes de produits 10 adresse les méthodes de génie logiciel, les outils
et les techniques pour dériver des produits différents dans une même famille. Ces produits
partagent des traits techniques communs, mais permettent de planifier des extensions et
versions pour des besoins spécifiques (Clements et Northrop [CN01]). Estublier et al. [EDL10]
soulignent les manques des lignes de produits, qui font que la technique n’est pas adoptée à
grande échelle. Ils identifient le manque d’évolution (de l’environnement, des architectures, du
champ d’action des produits) et le manque d’une hiérarchie de composants comme principaux
problèmes des SPL, qu’ils tentent de résoudre avec leur système Selecta.
La méthodologie SPL sert principalement à créer des versions différentes d’un même
produit, mais elle peut également servir à la création des systèmes sensibles au contexte.
Parra et al. [PBD09] proposent l’utilisation des techniques Dynamic Software Product
Line pour créer des applications qui prennent en considération le contexte. Ainsi, les
auteurs proposent des produits différents en fonction du contexte. Leur travail repose sur
une plateforme de gestion de contexte, COSMOS, proposée par Rouvoy et al. [RCS08].
Cette plateforme utilise une hiérarchie de composants, réalisant des cycles de collecte /
interprétation / identification de situations afin d’inférer des informations de plus haut niveau.
Parra et al. [PBD09] s’intéressent au cycle complet de développement des applications en
utilisant des SPL dynamiques et sensibles au contexte.
Dans une autre approche, Jaroucheh et al. [JLS10] proposent également d’utiliser les
techniques de SPL pour la création des applications sensibles au contexte pour des milieux
pervasifs. Leur but est de rendre les applications sensibles à l’activité de l’utilisateur et
surtout à son changement (changement de focus). Les auteurs proposent un meta-modèle
générique appelé CANDEL pour la gestion du contexte. Ils font une utilisation différente du
SPL par rapport à l’exemple précédent, car ils utilisent ces techniques pour le gestionnaire
de contexte et non pas pour les applications. De cette façon, Jaroucheh et al. proposent
une famille de produits pour le contexte, permettant des performances telles que plusieurs
représentations différentes d’un même élément de contexte. Par exemple, la localisation peut
être exprimée soit avec des coordonnées GNSS, soit en utilisant des blocs : bâtiment-étage-
bureau. Ce travail reste par contre au niveau théorique, les auteurs eux-mêmes précisant
comme perspective l’extension du modèle pour supporter des applications auto-adaptables
et sensibles au contexte. Un inconvénient que nous notons est le manque de clarté sur les
entités impliquées dans l’adaptation : des terminaux mobiles, des bâtiments intelligents, etc.

3.2.6 Utilisation d’un intergiciel

Un intergiciel 11 représente une couche intermédiaire qui n’appartient ni aux applications,

ni au système d’exploitation. C’est un logiciel qui fournit des services aux applications, comme
par exemple un réseau d’échange d’information. Dans le cadre des applications distribuées,
un intergiciel peut assurer la communication entre des applications différentes et gérer les
données. Etant donnée la complexité des systèmes informatiques de nos jours, la recherche
s’est orientée vers la séparation des préoccupations dans la conception du code. Cela a pour
but la réutilisation du code, mais, en même temps, la simplification du développement, en
permettant aux développeurs de se concentrer seulement sur l’application. De plus, dans le
cadre des applications sensibles au contexte, il est intéressant de gérer le contexte à part,
de le séparer du reste de code. Un intergiciel peut être la solution idéale dans ce cas.
10. En anglais : Software Product Line (SPL).
11. En anglais : middleware

32
 Chapitre 3. Réagir au contexte : applications et architectures adaptables

Déjà en 2004, Gu et al. [GPZ04] proposent un intergiciel orienté services et sensible

au contexte. Ils ont pour but d’augmenter les services mobiles à travers des informations
de contexte, d’une façon indépendante de l’application et du système d’exploitation. Ils
utilisent des ontologies pour modéliser le contexte et proposent une architecture avec des
fournisseurs, interpréteurs et bases de connaissances de contexte. Des règles de la logique
de premier ordre sont utilisées pour déclencher des actions en fonction du contexte et de
son changement. Malgré l’intention exprimée par les auteurs de supporter des terminaux
mobiles avec peu de ressources, la mise en œuvre n’est pas claire. De plus, les auteurs
disent utiliser des serveurs pour des raisonnements sur le contexte, afin d’alléger la tâche
des terminaux mobiles, ce qui implique le besoin d’être connecté en permanence à un
serveur. D’autres travaux viennent compléter l’adaptation au contexte avec une approche
intéressante : l’adaptation de l’intergiciel même. Herault (et al.) [HLD06, Her05] proposent
des services techniques avec plusieurs personnalités afin de rendre l’intergiciel flexible.
Kjær [Kja07] propose une vue d’ensemble et une taxonomie pour les intergiciels sensibles
au contexte. L’auteur souligne les différents caractères et méthodes de ces solutions et
note qu’aucune ne couvre tous les cas possibles. Kjær analyse les solutions utilisant des
intergiciels, principalement en fonction de critères suivants :
– L’environnement. Un intergiciel peut être destiné à un environnement disposant d’une
infrastructure ou bien il peut être indépendant des infrastructures, nécessitant seule-
ment un moyen de communication.
– Le stockage. Un intergiciel peut stocker soit des informations de contexte, soit des
données organisées en fonction du contexte actuel.
– La réflexion. Un système peut fournir des informations sur lui-même à travers des
métadonnées. Dans le cas des intergiciels, la réflexion peut être sur l’intergiciel même,
sur l’application ou sur des données de contexte.
– La qualité. On peut mesurer la qualité de service (la disponibilité des services) mais
aussi la qualité des informations de contexte.
– L’adaptation. L’adaptation est un critère plus complexe, touchant soit à l’application,
soit à l’intergiciel. En ce qui concerne l’intergiciel, il peut réagir au contexte de
manière transparente pour les applications, il peut fournir des services en fonction
d’un profil envoyé par l’application, ou il peut s’adapter en fonction de certaines règles.
L’application peut, elle aussi, s’auto-adapter en fonction du contexte ou s’adapter en
fonction de règles.
Kjær considère aussi la composition des composants en fonction du contexte et la migration
des entités. Les solutions utilisant des intergiciels analysées dans [Kja07] sont principalement
basées sur une infrastructure, elles stockent des données de contexte et elles permettent
la composition et laissent l’application s’auto-adapter. Il n’est pas nécessaire que chaque
solution réponde à tous les critères, car il ne peut exister une solution universelle. Les critères
proposés par Kjær peuvent néanmoins donner des pistes vers une meilleure compréhension
des intergiciels.

3.3 D’autres préoccupations de l’informatique récente

Pour montrer encore plus l’étendue du problème de l’informatique récente, nous citons
quelques-unes des autres préoccupations de la recherche, qui ne sont pas liées à notre sujet.
Le cloud-computing 12 commence à prendre de l’importance et à s’intégrer avec l’informatique
12. Les dénominations françaises incluent : informatique virtuelle, informatique en nuage, informatique
dématérialisée, stockage dans les nuages.

33
3.4. Conclusions

ubiquitaire. Ce nouveau sous-domaine de l’informatique consiste à délocaliser une importante

partie du code et du stockage sur internet afin d’alléger la tâche des terminaux contraints en
ressources. Par exemple, Corredor et al. [CMF11] s’intéressent à la liaison entre les réseaux
ubiquitaires, l’Internet of Things et le Cloud. Golchay et al. [GLMFP11] proposent d’utiliser
les smartphones comme passerelles entre les objets informatiques appartenant à l’IoT et les
capacités du Cloud.
D’autres travaux, comme Issarny et al. [IGH+ 11], s’intéressent aussi au futur de l’Internet
et étudient les besoins qui commencent à émerger. Parmi d’autres préoccupations, on trouve
le besoin d’intégrer la notion de mobilité, causée par le grand nombre de terminaux mobiles.
De plus, la sensibilité au contexte devrait, elle aussi, devenir une partie intégrante du Future
Internet tel qu’il est décrit par Issarny et al.

3.4 Conclusions

Ce chapitre présente les architectures logicielles actuelles. Nous nous sommes intéressés
surtout aux architectures flexibles, capables de s’adapter en fonction du contexte. Les
architectures à composants existent depuis des années et amènent l’avantage d’accélérer la
création des applications. Ultérieurement, les architectures à services sont apparues, rendant
les applications plus flexibles grâce au couplage lâche. Nous avons présenté l’autonomic
computing, un objectif visant à rendre les systèmes informatiques autonomes. D’autres
techniques qui permettent aux applications d’être adaptables au contexte incluent les lignes
de produits et l’utilisation des intergiciels.
Comme on peut le constater, plusieurs solutions existent pour l’adaptation des appli-
cations en fonction du contexte. Le choix d’une solution dépend de divers aspects, comme
le type d’application, sa taille, l’homogénéité d’implémentation des différentes parties de
l’application ou encore le dynamisme de l’adaptation. Dans la suite, nous nous penchons
sur la problématique que nous considérons dans ce manuscrit.

34
Chapitre 4

Problématique des applications dans le

domaine des transports

Dans les chapitres précédents, nous avons passé en revue plusieurs

aspects de l’informatique mobile récente. Le domaine est vaste, nous
devons donc bien positionner le travail fourni dans cette thèse par rapport
à tous les types d’applications existantes. Notre intérêt porte sur les
applications mobiles qui accompagnent les utilisateurs tout au long de
leurs voyages. Les problématiques de recherche abordées incluent la
sensibilité au contexte et le mécanisme d’adaptation au contexte. Nous
finirons le chapitre par un aperçu de notre proposition.

4.1 Les applications sensibles au contexte d’aujourd’hui

La notion de « contexte » apparait souvent dans les travaux de recherche, car c’est
devenu un sujet très important. Il existe beaucoup d’applications (mobiles ou non) qui
sont concernées par le contexte dans lequel elles sont utilisées. Nous en avons présentés
quelques exemples dans les chapitres précédents. Pour nous, les humains, la notion de
contexte est naturelle et instinctive [HS09]. Nous évaluons et utilisons des informations
qui semblent non essentielles pour nos actions, sans y prêter attention. Considérons une
personne qui rentre à pied du travail, tous les jours. Si un jour elle voit des nuages, cette
personne va accélérer son rythme afin d’éviter la pluie. Donc son comportement change
en fonction d’une situation externe qui n’a pas un lien direct ou évident avec l’activité de
marcher. En ce qui concerne nos programmes informatiques, le défi consiste à expliquer à
la machine ce qu’est le contexte, quels sont les éléments les plus importants et comment
réagir à leurs changements. Un grand nombre de travaux s’attaquent aux différents aspects
du contexte, comme nous l’avons présenté dans le chapitre 2 (page 15). Dans cette section
nous présentons une analyse des applications existantes et leurs relations au contexte.

35
4.1. Les applications sensibles au contexte d’aujourd’hui

4.1.1 Le contexte – manque d’une classification en informatique

L’un des problèmes liés au contexte est la multitude d’utilisations que l’on peut faire
des informations contextuelles. L’utilisation qui nous intéresse dans ce travail de thèse,
est l’adaptation du comportement des applications aux nouvelles situations. Une deuxième
consiste à adapter la présentation d’un contenu – soit en fonction de l’utilisateur, soit
en fonction des sorties disponibles à un moment donné. Encore une autre utilisation
du contexte serait l’inférence des informations, qui ensuite peuvent être utilisées pour
automatiser différentes actions. Nous pouvons également adapter une application en fonction
de l’utilisateur, par exemple une application de e-learning en fonction du niveau de l’étudiant.
Les éléments de contexte étant nombreux et très divers, nous constatons le manque
d’une classification stricte pour les domaines de l’informatique. En effet, nous avons montré
dans le chapitre 2 (page 15) qu’un grand nombre de travaux parlent du contexte sous
différents angles 1 . Souvent les chercheurs définissent les éléments auxquels ils veulent
prêter attention et négligent les autres, car ce serait impossible de tout considérer. Nous
considérons nécessaire une classification des domaines et sous-domaines sensibles au
contexte afin de permettre un bon positionnement des travaux. Néanmoins, la tâche de
proposer une vision globale du contexte est très complexe et ne représente pas l’objectif de
notre thèse. Dans ce travail nous précisons clairement quels éléments nous considérons et
nous donnons des pistes vers une classification des éléments que nous pourrons introduire
dans des travaux futurs.

4.1.2 Manque d’un cadre de conception et d’exécution

Le plus souvent, les chercheurs s’intéressent à une application ou à un type d’applications

pour y intégrer leur notion de contexte. L’une de premières préoccupations consiste à
déterminer les éléments de contexte qui peuvent influencer l’application en question. Nous
avons constaté qu’il existe souvent de multiples applications concernées par les mêmes
éléments de contexte. Un très bon exemple est la localisation GNSS, utilisée par de
nombreuses applications, parfois en même temps. Quand des conditions externes changent
(l’utilisateur entre dans un bâtiment par exemple), toutes les applications dépendant de
la localisation arrêtent de fonctionner correctement. Nous considérons alors important de
gérer ensemble ces applications qui ont des comportements similaires, qui partagent des
fonctionnalités ou qui dépendent des mêmes éléments de contexte.
Comme l’état actuel ne nous semble pas satisfaisant, nous allons proposer l’utilisation
d’un cadre commun d’exécution pour plusieurs applications. Cela permettra d’un côté de
réutiliser le code des fonctionnalités partagées et ainsi d’alléger l’ensemble des applications
qui s’exécutent simultanément. D’un autre côté, au moment où le contexte change, il est
fortement possible que plusieurs applications soient influencées. Une gestion commune du
contexte apportera un gain, car le problème sera traité une fois au bénéfice de toutes les
applications concernées.

1. Plus de 40 travaux que nous citons dans cette thèse contiennent context ou context-aware dans le titre !

36
 Chapitre 4. Problématique des applications dans le domaine des transports

4.2 Vers une solution pour des applications dédiées aux transports
sensibles au contexte

Nous voulons répondre aux manques soulignés dans le paragraphe 4.1 (page 35), en
proposant une technique de prise en compte du contexte pour les applications des transports.
Étant donné le nombre assez important d’applications sensibles au contexte, nous devons
préciser le problème considéré et le domaine d’application que nous visons, avant de
présenter nos propositions. Nous considérons des applications mobiles, s’exécutant sur
un terminal portable qui accompagne l’utilisateur dans son déplacement. Ces applications
ont pour but d’assister l’utilisateur au fur et à mesure de son avancement, elles doivent
donc s’adapter aux changements de contexte assez fréquemment. Nous nous attaquons
à un type général d’applications, et non pas seulement à une application. Notre but est
de fournir une solution pour plusieurs applications similaires ou qui utilisent les mêmes
fonctionnalités. Nous nous concentrons sur le domaine très dynamique des transports. Dans
la suite nous précisons ce que nous considérons comme transports et donnons un exemple
de cas d’utilisation que nous traitons dans cette thèse.

4.2.1 Le domaine des transports et l’informatique mobile

Le domaine des transports comprend tout ce qui concerne le déplacement de personnes

ou de marchandises d’un endroit à un autre, pour la plupart en utilisant des véhicules
et des routes. Nous nous intéressons donc à améliorer des applications de ce domaine à
travers la prise en compte du contexte. Quand l’informatique mobile rencontre le domaine
des transports, on parle de Systèmes de Transport Intelligents (ITS) 2 . Les ITS utilisent
une application concrète des réseaux mobiles ad hoc : la Communication Inter-Véhicules
(IVC) 3 [LH06]. Parmi les buts des ITS, tels que décrits dans [FJM+ 01], on peut compter
l’augmentation de la sécurité et de l’efficacité du trafic routier à travers les nouvelles
technologies. Les cibles concernées par l’ITS sont les utilisateurs, les véhicules et les routes,
qu’il faut rendre plus intelligents.
Dans [FJM+ 01], six catégories d’amélioration du transport sont décrites, concernant :
les systèmes de gestion du trafic, les systèmes d’information des voyageurs, l’opération
des véhicules commerciaux, les systèmes avancés de transport en commun, les systèmes
avancés de contrôle de véhicules, les systèmes avancés de transport rural. Les avancées de
l’industrie incluent aujourd’hui les voitures dites connectées, c’est-à-dire avec une connexion
Internet 3G embarquée dans la voiture 4 . Certaines voitures, comme la Volkswagen Golf VII
ou l’Audi A3, commencent à embarquer des modules Wi-Fi 5 . Des technologies comme R-Link
de Renault 6 permettent d’amener directement dans les voitures les applications que les
utilisateurs connaissent déjà sur leurs smartphones, à travers une tablette tactile intégrée
dans le véhicule. Cela ne rend pas les terminaux des utilisateurs inutiles, mais augmente
leurs capacités grâce à la connexion Internet.
Dans ce cadre, nous considérons des utilisateurs impliqués dans le transport de différentes
façons. Ils peuvent être à pied, en train de conduire ou dans un moyen de transport. Tout
au long de leur voyage, ils utilisent un terminal mobile tel qu’un téléphone, un ordinateur
portable où encore le terminal embarqué dans leurs véhicules. Les intérêts de ces utilisateurs
2. En anglais : Intelligent Transportation Systems (ITS)
3. En anglais : Inter-Vehicle Communication (IVC)
4. Conforme à un article Le Monde de mars 2012, http ://www.lemonde.fr/
5. Salon de l’Automobile 2012, http ://auto.nouvelobs.com/
6. R-LINK, http ://www.renault.com/

37
4.2. Vers une solution pour des applications dédiées aux transports sensibles au contexte

varient, mais la plupart ont besoin d’aide pour la navigation, des informations de sécurité
routière en conduisant et d’autres informations sur des entités à proximité (parking, boutique,
restaurant, etc.). Parmi les applications possibles, nous considérons le partage d’informations
en réseau ad hoc (MANET ou VANET) pour la coopération des utilisateurs impliqués dans
le transport ainsi que la communication avec des entités fixes (des serveurs appartenant aux
parkings, boutiques, gare, etc.). En principe, le terminal reste personnel (un seul utilisateur)
et les applications ne migrent pas sur d’autres terminaux (comme des écrans externes). Par
contre, chaque application doit évoluer en même temps que son utilisateur. Les changements
qui interviennent sont surtout dus au déplacement, car chaque nouvel endroit où l’utilisateur
arrive, présente de nombreuses différences. Nous illustrons dans le paragraphe suivant les
applications visées et comment nous souhaitons que le terminal s’adapte à une nouvelle
situation.

4.2.2 L’exemple : un conducteur, son téléphone et ses applications

Nous allons prendre un exemple pour mieux expliquer le type d’applications que nous
considérons, ainsi que le comportement que nous désirons atteindre. Considérons Jean,
qui vit dans une petite ville et qui possède un smartphone dont il se sert souvent. Jean
décide d’aller dans une ville V , pas très loin de chez lui, pour rencontrer un ami. Il devra
prendre sa voiture et parcourir plusieurs kilomètres pour s’y rendre. Comme il ne connait
pas suffisamment bien la ville où il doit aller, il utilise la navigation disponible sur son
téléphone. En plus, il a installé plusieurs autres applications qu’il trouve très utiles, parmi
lesquelles une pour la sécurité routière, qui l’avertit des événements tels que des accidents,
des freinages d’urgence ou encore des véhicules d’intervention. La deuxième application qu’il
aime bien sert pour la recherche de places de parking. Voyons comment tout cela fonctionne
au cours de son déplacement, quand son environnement change.

Situation normale – trafic en ville

Jean commence à utiliser son téléphone pour se rendre dans la ville V , dès qu’il monte
dans sa voiture. Il démarre les trois applications qu’il va utiliser sur la route :
1. La navigation, dépendante des éléments suivants : un réseau de téléphonie permettant
l’échange de données (technologie 3G ou plus) pour télécharger la carte en continu ;
le module GNSS pour connaître la position à tout moment ; un algorithme de calcul
de chemin pour fournir la route à emprunter.
2. L’application de sécurité routière, nécessitant : le module Wi-Fi pour la connexion au
réseau ad hoc formé par les participants au trafic ; le module GNSS pour connaître la
position de la voiture et pour pouvoir estimer les distances qui la séparent des événe-
ments dangereux ; un algorithme d’estimation de l’importance que chaque événement
peut avoir pour le conducteur.
3. Le gestionnaire de parking, qui dépend de mêmes fonctionnalités que l’application
de sécurité : les modules Wi-Fi et GNSS et un algorithme qui estime l’importance
de chaque place de parking dont il a reçu des informations à travers les voisins du
réseau ad hoc. Le gestionnaire de parking a également besoin d’un module d’interface
graphique s’occupant d’indiquer la position des places libres rencontrées sur la route.
Les deux dernières applications peuvent être combinées dans une seule, comme on le voit
dans le projet VESPA, Cenerario (et al.) [Cen10, CDI11]. Dans ce cas, les places de parking
peuvent être traitées comme les autres événements de trafic en disséminant l’information

38
 Chapitre 4. Problématique des applications dans le domaine des transports

à tous les véhicules intéressés. Cela fonctionne bien dans la petite ville de Jean, car le
trafic n’est pas souvent encombré. En revanche, utiliser une application qui informe tous les
conducteurs de toutes les places disponibles n’est pas envisageable si le trafic est dense,
comme dans la ville V .

Arrivée à destination – changement de contexte

Une fois arrivé à destination, Jean souhaitera sûrement se garer, pour ensuite se diriger à
pied vers l’endroit de rencontre. Quelques places sont disponibles sur les rues du centre-ville
de V , mais elles sont difficiles à trouver. De plus, à cet endroit il faut utiliser une autre
application de parking que celle de Jean, car les places doivent être réservées grâce à un
protocole ad hoc. La ville V possède également un parking couvert, Parking Centre, très bien
placé au centre-ville, dont Jean pourrait profiter. Jean se trouve donc devant un choix : se
garer à l’extérieur gratuitement, ou profiter des avantages d’un parking couvert. Cependant,
plusieurs changements ont lieu dans les deux cas :
1. Jean désire garer sa voiture sur les rues de la ville V . Bien que Jean ait déjà une
application pour trouver des places de parking dans le réseau ad hoc, ce n’est pas la
même version que celle utilisée dans V . Il devrait donc installer cette autre version.
2. Jean désire garer sa voiture dans Parking Centre. Plusieurs changements auront lieu
dès son entrée dans le bâtiment.
– Le signal GNSS ne sera plus accessible, rendant la localisation impossible.
– Le parking est intelligent et possède des capteurs pour les places ainsi qu’un
serveur qui gère leur allocation aux conducteurs. Il faut donc installer une troisième
version de l’application de parking.
La situation est illustrée par la figure 4.1 (page 40), qui montre Jean devant l’entrée du
parking. Dans cette situation, le terminal de Jean devrait s’adapter et acquérir des nouvelles
fonctionnalités. Arrivé devant le Parking Centre, nous remarquons que Jean est entouré
par des terminaux qui possèdent différents services. Le serveur du parking fournit le code
permettant aux utilisateurs d’interagir avec lui, notamment le service Parking PC. De plus,
il possède d’autres services utiles comme localisation Wi-Fi (utilisant des points d’accès
pour estimer le positionnement) ou encore un plan du parking pour aider les conducteurs à
trouver la place qui leur a été allouée. D’autres utilisateurs ayant garé leurs voitures dans
le Parking Centre pourraient également disposer des fonctionnalités spécifiques du parking.
Un conducteur à proximité dispose du service qui fonctionne dans les réseaux véhiculaires
avec un grand nombre de participants, Parking Res. Le choix est là, mais . . . comment faire
pour intégrer ces services sur le terminal de Jean ?

Le comportement désiré

Ce que l’on attend du smartphone de Jean serait de s’adapter au fil du temps. Quand

Jean arrive dans la ville V , son terminal devrait détecter que les véhicules autour utilisent
une autre version du service de parking, et l’installer à la place de l’ancienne. De cette façon,
Jean pourrait profiter d’une place qui se libère près de sa destination. S’il décide d’entrer
dans le parking couvert, plusieurs fonctionnalités de ses applications devrait s’adapter aux
nouvelles conditions. En effet, le service de localisation GNSS ne fonctionne plus, et Jean
aura besoin du plan du parking. Ce serait intéressant si tous ces changements pouvaient se
faire sans déranger Jean, le conducteur, qui n’a pas le temps de télécharger et installer une
application, tout en essayant de se garer. Ce n’est pas possible de prévoir à chaque fois ce

39
4.2. Vers une solution pour des applications dédiées aux transports sensibles au contexte

Figure 4.1 – La dépendance des applications de leur contexte d’exécution.

que l’on va faire, ni de savoir dans quel parking on va se garer. Ce n’est donc pas possible
de télécharger à l’avance les applications dont on aurait besoin, il faut pouvoir réagir et
s’adapter aux nouvelles situations quand elles se présentent.
Un autre aspect que l’on doit considérer est le parcours de Jean une fois qu’il quitte sa
voiture. Il aura peut-être encore besoin d’un service de navigation, mais les deux autres
applications ne seront plus utiles. Il peut donc les arrêter, mais ce serait mieux si son
téléphone le faisait pour lui. Le comportement que l’on désire donc pour les applications qui
assistent un utilisateur dans son déplacement consiste à s’adapter aux nouvelles situations
rencontrées, avec un minimum d’intervention de la part de l’utilisateur.

Les manques d’aujourd’hui

Si nous considérons les trois applications que Jean utilise pour son trajet, nous remar-
quons qu’aujourd’hui ce sont trois applications distinctes. Pourtant, les trois utilisent le
GNSS (ou un autre moyen de localisation), et les trois doivent indiquer à l’utilisateur où
se trouvent des événements importants, par rapport à sa position. De nos jours, avec la
multiplication des applications, nous retrouvons parfois les fonctionnalités intéressantes
dispersées dans différentes applications. Par exemple, Trapster 7 alerte les utilisateurs de
radars de police sur leur route et Primo Spot 8 trouve des places de parking. Il arrive que
7. Trapster, http ://www.trapster.com/
8. Primo Spot, http ://www.primospot.com/

40
 Chapitre 4. Problématique des applications dans le domaine des transports

des applications différentes regroupent les mêmes utilités, comme Waze 9 et Glob 10 , qui
se basent sur des communautés d’utilisateurs afin de fournir des informations sur le trafic
(bouchons, accidents, . . . ).
Toutes ces applications doivent être installées séparément, démarrées et arrêtées par
l’utilisateur. Il manque donc un cadre commun pour ce type d’applications. Il serait intéressant
d’avoir un affichage de la carte, et pouvoir ajouter les fonctionnalités souhaitées à cette
application : navigation, recherche de places de parking (à proximité de la destination),
sécurité du trafic avec affichage des événements sur la carte. De plus, si la fonctionnalité
de parking était liée avec la navigation, elle pourrait connaitre la destination et donc être
plus efficace. Parmi les manques des applications d’aujourd’hui nous évoquons également la
flexibilité. Les applications ne s’adaptent pas aux changements de contexte et sont difficiles
à mettre à jour.

Encore plus loin . . .

Nous avons présenté seulement une partie des applications qui nous concernent, no-
tamment celles que Jean utilise quand il conduit. Il ne faut pas oublier que Jean ne prend
pas toujours sa voiture, parfois il utilise les transports en commun. Les arrêts, gares, . . . ,
mais aussi les moyens de transport, peuvent disposer de différentes applications, indiquant
l’itinéraire, la fréquence de passage ou les points d’intérêt à proximité de chaque arrêt.
Jean devrait pouvoir profiter de toutes ces applications quand il se trouve à proximité d’un
arrêt ou dans un moyen de transport. Aujourd’hui l’utilisateur doit tout télécharger à partir
des marchés d’applications. De plus, ces applications peuvent encombrer son terminal, car
elle sont nombreuses. Les applications devraient plutôt être installées et utilisées tant que
nécessaire et ensuite être désinstallées automatiquement. Le terminal de Jean pourrait
apprendre quelles applications ou services il utilise souvent et lesquelles sont utilisées une
seule fois, afin de connaître quelles applications peuvent être désinstallées.

4.2.3 Les caractéristiques des applications considérées

Les applications que nous ciblons s’exécutent sur des terminaux mobiles et ont pour
but d’accompagner et d’assister l’utilisateur dans son déplacement. Notre objectif est de
rendre ces applications capables de fournir un résultat, qui soit le plus pertinent possible
par rapport à la situation dans la quelle l’utilisateur se trouve. Au fur et à mesure qu’une
personne se déplace, elle change l’environnement dans lequel ses applications s’exécutent.
Ce que l’on veut atteindre est :
– Un comportement adéquat de l’ensemble des applications en fonction du contexte
(adaptation aux changements de situation).
– Eviter les pannes (arrêts des fonctionnalités ou applications) à cause d’une condition
non satisfaite ou d’un événement imprévu.
– Rendre le terminal capable d’acquérir de nouvelles fonctionnalités, surtout quand une
entité spécifique (propre à un endroit) les fournit.
Pour déterminer si une fonctionnalité est nécessaire ou non, nous pouvons nous baser sur
ce dont l’utilisateur se sert déjà. Dans notre exemple, Jean avait installé une application de
gestion de places de parking, nous pouvons donc supposer qu’il voudra utiliser l’application
d’allocation de places du Parking Centre ou celle utilisée par les véhicules de la ville V ,
9. Waze, http ://world.waze.com/
10. Glob, http ://g-lob.com/

41
4.2. Vers une solution pour des applications dédiées aux transports sensibles au contexte

Parking Res. Afin d’arriver à notre but, nous devons étudier le contexte dans lequel Jean
utilise les applications et déterminer les éléments qui influent sur leur comportement.

Contraintes de fonctionnement

Tout d’abord nous devons proposer une solution réalisable pour le problème que nous
considérons. Nous voulons gérer ensemble les applications qui partagent des fonctionnalités
et les rendre sensibles au contexte, en changeant une partie de leur comportement. Les
contraintes que nous nous imposons sont :
– Le terminal doit effectuer des adaptations de manière autonome (autant que possible
sans l’intervention de l’utilisateur).
– Le terminal doit être capable de fonctionner dans les conditions imposées par le
domaine du transport : forte mobilité, changements fréquents d’environnement, perte
de connexion (GNSS, Wi-Fi), changement de type de transport (voiture, moyen de
transport en commun, marche).

4.2.4 Les problématiques abordées

Nous voulons proposer une solution simple et efficace pour permettre des adaptations
dans le domaine des transports, où la vitesse de réaction est importante. Nous nous attaquons
au mécanisme qui permet de modifier le comportement des applications en laissant les
questions de sécurité dans la perspective de nos travaux. Pour arriver à notre but, nous
nous intéressons à trois aspects principaux, que nous allons développer dans la suite de ce
manuscrit.

1. Le contexte.
Nous devons répondre aux questions telles que : Qu’est-ce que le contexte dans
le domaine des transports ? Quels éléments du contexte nous intéressent dans nos
travaux ? Quand et comment doit-on utiliser les informations de contexte ? Notre
but est de proposer une classification des éléments de contexte ainsi qu’un modèle
générique d’interaction avec le contexte.
2. Les applications modulaires, sensibles au contexte.
Nous nous attaquons aux questions suivantes : Comment modéliser et concevoir des
applications sensibles au contexte et capables de s’adapter ? Quand et comment les
applications doivent-elles changer leur comportement ? Comment intégrer la notion de
contexte dans l’architecture des applications ? Nous voulons proposer une architecture
capable de prendre en compte la notion de contexte et le besoin de flexibilité.
3. Les mécanismes d’adaptation.
Nous voulons permettre aux applications de réagir aux changements de contexte, nous
nous sommes donc interrogés : Comment faire le suivi du contexte ? Quand et comment
assurer les adaptations ? Notre objectif consiste à rendre les applications autonomes
par rapport au contexte, afin qu’elles adaptent leur comportement sans s’interrompre.

Nous utilisons l’exemple de Jean et ses applications pour évaluer notre proposition. Nous
allons démontrer qu’il est possible de télécharger de nouvelles fonctionnalités et d’adapter
des applications sans l’intervention de l’utilisateur et sans arrêter les applications. Nous
allons étudier la vitesse de réaction, dans le cas où tous les services nécessaires sont
présents sur le terminal et dans le cas où un service doit être téléchargé.

42
 Chapitre 4. Problématique des applications dans le domaine des transports

4.3 Conclusions

Dans les premiers chapitres de cette thèse, nous avons analysé l’état de l’art des
applications mobiles et nous avons formulé le problème auquel nous tentons de répondre :
l’amélioration de l’expérience d’un utilisateur mobile à travers la prise en compte du contexte
particulier et très dynamique du domaine des transports. Nous avons pu constater quelques
caractéristiques communes entre les applications qui nous intéressent :
– L’utilisateur a besoin de plusieurs applications. Souvent, de multiples applications
sont nécessaires pour répondre à tous les besoins de l’utilisateur : la navigation ; la
sécurité routière ; une application pour des requêtes telles que « quel est le restaurant
le plus proche ? » ; etc.
– Les applications partagent des fonctionnalités. Nous avons observé que plusieurs ap-
plications ont des caractéristiques similaires ou nécessitent les mêmes fonctionnalités,
comme par exemple le positionnement.
– Le contexte a une influence sur toutes les applications. Le contexte influence de
manière similaire les applications avec des fonctionnalités communes. De plus, il peut
également influencer certaines applications qui ne sont pas encore démarrées et
déclencher leur démarrage (ou à l’inverse, les arrêter).

Besoin d’une plateforme d’exécution

Nous considérons nécessaire l’utilisation d’une plateforme embarquée pour l’exécution

et la gestion des applications dédiées aux transports. Cette approche pourrait résoudre les
problèmes évoqués ci-dessus. Toutes les applications concernées s’exécuteraient dans le
même cadre, ce qui rendrait possible le partage de fonctionnalités et assurerait une meilleure
utilisation des ressources du terminal. De plus, la gestion des applications serait externalisée,
les rendant plus légères. La plateforme aurait une connaissance globale des applications et
pourrait gérer la prise en compte du contexte de manière uniforme. Nous présenterons plus
en détail les avantages de notre approche dans le paragraphe 6.2 (page 76).

43
4.3. Conclusions

44
Deuxième partie

Contributions

45
Propositions

L’informatique de nos jours est devenue très complexe, avec un grand

nombre d’aspects importants à considérer au moment de la conception des
applications. Nous avons vu dans les chapitres précédents que le contexte
est devenu un concept très important, ayant une grande influence sur
l’exécution des applications. Ces dernières doivent assurer des services
adéquats à la personne, à l’endroit où elle se trouve, aux conditions
externes, etc. Nous proposons un regard complet sur les applications
mobiles, de leur conception jusqu’à leur utilisation, incluant leur adaptation
en fonction du contexte. Pour réaliser cet exploit, il faut d’abord analyser
le contexte et son utilisation, la méthode de conception des applications
et les méthodes de gestion de l’adaptation au moment de l’exécution.

Un modèle de contexte

Le contexte peut être très complexe et il doit être défini par rapport à des interactions
entre différentes entités (utilisateurs, applications, objets informatisés). Le nombre et le type
d’applications mobiles est très grand, rendant difficile la tâche de prendre en considération
tous les aspects du contexte. Nous nous concentrons sur un utilisateur mobile et ses besoins
quand il se déplace.
Dans un premier temps, nous voulons modéliser le contexte en considérant les différents
aspects d’une application dédiée aux transports, qui s’exécute sur un téléphone ou un autre
terminal mobile. Nous divisons le contexte en fonction du terminal et ses caractéristiques,
des services disponibles, de l’environnement où l’utilisateur se trouve et de l’utilisateur
lui-même. Certains éléments du contexte ont une nature statique ou quasi-statique, comme
le profil du terminal ou de l’utilisateur, pendant que d’autres éléments changent fréquemment,
tel que l’environnement.
Nous accordons plus d’intérêt à l’aspect dynamique du contexte. Bien que nous trouvons
un véritable intérêt pour les applications se basant sur des préférences utilisateur pour
filtrer des informations, nous trouvons également intéressant l’aspect immédiat, la réaction
aux conditions qui changent dynamiquement. Nous nous concentrons sur la réaction aux
changements de contexte car nous la considérons comme étant le meilleur moyen d’être
utiles aux utilisateurs mobiles. Néanmoins, le fait de nous concentrer sur un aspect plutôt
que l’autre n’exclut pas une intégration future de ce dernier.

47
Une méthodologie pour la conception des applications

Dans un deuxième temps, nous allons analyser les applications, leur relation avec le
contexte ainsi que le comportement que l’on souhaite de leur part. Les applications se doivent
d’être sensibles au contexte et réagir à ses changements. Une adaptation au contexte peut
inclure l’arrêt ou le démarrage d’une application.
Pour pouvoir gérer le contexte, il n’y a pas de doute que cette notion doit être intégrée dès
la conception de l’application. Notre approche consiste à prévoir quels éléments pourraient
influencer l’exécution d’une application. L’intégration du contexte peut se faire en créant
des services spécialisés pour les différentes situations de contexte. Nous proposons une
architecture à composants orientée services, où les composants sont présents localement
sur le terminal. Cela rendra les applications flexibles et répondra à la contrainte liée aux
ressources limitées : en partageant des fonctionnalités entre les applications, celles-ci
deviennent plus légères.
Nous favorisons les applications qui s’exécutent sur le terminal mobile, éventuellement
en coopérant à travers des messages ou des services à distance avec d’autres entités. Nous
ne focalisons pas sur d’autres types d’applications, par exemple celles qui connectent des
périphériques dans la maison ou celles qui ne dépendent pas du contexte (comme les jeux).

48
Chapitre 5

Modélisation du contexte pour des

applications dédiées aux transports

Le comportement des applications est influencé par le contexte dans

lequel elles s’exécutent. Nous considérons le contexte non seulement au
moment des adaptations, mais également au moment de l’installation des
nouvelles fonctionnalités. Nous considérons plusieurs aspects des appli-
cations fortement mobiles, et nous nous concentrons plus particulièrement
sur l’aspect de l’adaptation dynamique.

5.1 Quel contexte est important ? Quand ? Pourquoi ?

Nous nous sommes intéressés à la façon dont le contexte est considéré dans les travaux
de recherche récents et nous avons pu observer deux tendances opposées. La première
consiste à limiter le contexte à une application ou un type d’application ([KPVOGM05],
[Boc08], [SCF+ 10], etc.), tandis que la deuxième focalise sur la modélisation de « tout » le
contexte, éventuellement à travers des ontologies ([CFJ03], [BOA11], [RLS+ 11], etc.). Étant
donné le caractère limité en ressources des terminaux mobiles, mais aussi la complexité
du contexte, la deuxième tendance nous semble peu pratique pour des utilisateurs mobiles.
Hoareau et al. [HS09] évoquent la complexité de la prise en compte du contexte et ils attirent
l’attention sur le besoin de traiter des sous-problèmes liés au contexte.
Le but de l’utilisation des informations de contexte est l’amélioration de l’expérience
utilisateur, à travers des services pertinents par rapport à sa tâche [DA99]. Nous considérons
intéressant et important de réagir aux changements de contexte qui se produisent de
manière inattendue pendant l’exécution d’une application. Pour cette raison, nous optons
pour la modélisation du contexte dans le cadre des applications dédiées aux transports.
Une application de ce type peut être très importante pour la sécurité du trafic, il est donc
nécessaire qu’elle soit adaptée à son contexte d’exécution. Quelques travaux ont déjà abordé

49
5.1. Quel contexte est important ? Quand ? Pourquoi ?

ce sujet en essayant d’identifier les éléments importants qui influencent l’exécution des
applications dédiées aux transports. Gransart et Lecomte [GL09] divisent le contexte en
deux catégories, en fonction de l’environnement et de l’application elle-même. Dans la
première catégorie, les auteurs considèrent la localisation, le temps et l’état du réseau de
communication. Dans la deuxième, ils considèrent d’un côté le dynamisme du réseau ad hoc,
où les nœuds se connectent et se déconnectent fréquemment, et d’un autre côté les services
proposés par ces nœuds.
Dans un autre travail sur les applications mobiles dédiées aux transports, Desertot et
al. [DLD09] identifient quelques-uns des éléments de contexte qui sont importants dans ce
domaine. Sans surprise, ils considèrent la position comme l’une des informations les plus
importantes. D’autres éléments que les auteurs mentionnent sont le temps (essentiel pour
situer les messages en fonction de leur moment d’émission), la communication et le réseau
de communication (ad hoc ou lié à une infrastructure), et finalement le profil de mobilité du
terminal de l’utilisateur.
Ces deux travaux commencent seulement à analyser l’influence du contexte dans le
domaine des transports. En partant de leurs propositions, nous offrons un modèle plus
complet du contexte, prenant en considération une grande partie des aspects auxquels
l’utilisateur pourrait être confronté pendant son trajet. Dans les sections suivantes, nous
analysons les différents éléments qui influencent les applications d’un utilisateur mobile.
Nous présentons les aspects que nous considérons importants pour des systèmes sensibles
au contexte et nous précisons comment les situations devraient être gérées.

5.1.1 L’influence de l’environnement

Un utilisateur se sert de ses applications pour explorer son environnement et interagir

avec des entités autour de lui. Ces interactions entre l’utilisateur et les autres entités sont
influencées par un très grand nombre d’éléments. Souvent, en fonction du déplacement de
l’utilisateur, le changement des conditions doit entraîner la modification du comportement des
applications. La figure 5.1 présente notre classification des éléments de contexte appartenant
à l’environnement (qui sont déterminés par le mouvement de l’utilisateur).

EnvironmentCtx

Position Network Status External Time Move

GPS/Wifi Infrastruct. Driver Noise LocalTime Speed
GPS Map Ad hoc Passenger Luminosity GPSTime Average
Itinerary Bandwidth Pedestrian

Figure 5.1 – Les caractéristiques de l’environnement

Le premier élément que l’on considère est le positionnement (Position dans la figure 5.1).
C’est l’information de contexte la plus étudiée dans le domaine de l’informatique ubiquitaire,
elle reste néanmoins assez complexe. D’un côté, on dispose de différentes technologies
de localisation : GNSS, Wi-Fi, infrarouge, etc. Il est intéressant de connaître la position
courante, mais aussi la précision de cette information ou la disponibilité du service de
localisation (le GNSS devient indisponible à l’intérieur des bâtiments). D’un autre côté, il
faut savoir interpréter les coordonnées, par exemple par rapport à une carte. Si aucune carte

50
 Chapitre 5. Modélisation du contexte pour des applications dédiées aux transports

n’est disponible, les coordonnées peuvent toujours servir pour calculer des distances en
ligne droite, sachant toutefois que la précision est diminuée. Enfin, un itinéraire calculé pour
l’utilisateur pourrait donner une indication sur ses positions futures, permettant d’optimiser
d’autres applications. Par exemple, s’il cherche une place de parking, il faudra lui indiquer
celles qui se trouvent à proximité de sa destination.
Les réseaux de communication représentent une deuxième catégorie d’éléments de
contexte très importante pour le domaine des transports (Network dans la figure 5.1). Les
applications destinées à l’informatique ubiquitaire se basent souvent sur une infrastructure.
Dans le cas des transports, on ne peut plus supposer qu’une infrastructure soit toujours
disponible, car il arrive souvent de perdre la connexion aux réseaux de communication. Le
Wi-Fi n’est présent que dans certains endroits, et la transmission de données par le réseau
téléphonique n’est pas toujours disponible. Parmi les informations importantes liées aux
réseaux de communication on retrouve : les réseaux disponibles (Wi-Fi, infrastructure/ad
hoc, 3G), le débit, le nombre de voisins, etc.
Un troisième élément de contexte que l’on considère important pour un utilisateur mobile
est son statut (Status dans la figure 5.1). Sans avoir besoin de connaître en détail le but
ou la tâche de l’utilisateur, on peut s’intéresser à son statut en tant que participant au
trafic. L’utilisateur peut être un piéton, un passager dans différents moyens de transport
(bus/tramway en ville, train à grande vitesse, avion, etc.) ou bien le conducteur d’une
automobile. Les trois cas ont chacun leurs particularités et contraintes.
– Un piéton se déplace à une vitesse limitée, d’environ 5 km/h. Les réseaux auxquels
il est connecté ne changent pas souvent et il se trouve probablement en ville, où il
y a une bonne couverture du réseau 3G (ou 4G). En revanche, sa zone d’intérêt est
probablement limitée aux endroits qu’il peut atteindre à pied.
– Un passager est lié à son moyen de transport, qui se déplace plus ou moins vite.
Pour les transports en commun, un avantage pourrait être la présence d’un terminal
spécifique au moyen de transport, offrant des services tels que la liste des arrêts.
– Un conducteur est beaucoup plus contraint que tout autre utilisateur : il ne peut pas
manipuler son terminal car son attention doit rester sur la route ; il peut se trouver
dans des endroits différents (en ville, à la campagne, sur autoroute, à la montagne,
etc.) avec ou sans accès à une infrastructure de communication.
Les applications doivent considérer ces trois statuts différents de l’utilisateur, ainsi que le
changement de statut.
Des éléments externes peuvent aussi influencer l’exécution de certaines applications
(External dans la figure 5.1). En se basant sur les différents capteurs d’un terminal portable
tel qu’un smartphone, on peut connaître la luminosité, le niveau de bruit ou même reconnaître
des objets à travers la caméra. Ces informations pourraient servir à améliorer l’interaction
de l’utilisateur avec ses applications. Par exemple, si le terminal détecte un niveau de bruit
élevé dans la voiture, il peut augmenter le son de la navigation, afin que le conducteur
entende correctement les instructions.
Le temps fait partie des éléments de contexte pour certaines applications (Time dans la
figure 5.1). En effet, il faut connaître le temps afin d’évaluer la pertinence des événements
ponctuels. Par exemple, si l’on reçoit une information sur un freinage d’urgence, il est
important de savoir si celui-ce vient de se produire ou si l’événement est plus ancien. Dans
le premier cas il faut probablement informer le conducteur ou même freiner à sa place. Pour
une bonne synchronisation entre toutes les entités (voitures), le temps GNSS peut être
utilisé. Néanmoins, celui-ci n’est plus disponible si le terminal ne peut accéder aux satellites
et doit être remplacé par un temps local.

51
5.1. Quel contexte est important ? Quand ? Pourquoi ?

Enfin, un dernier élément que nous considérons important pour les applications dédiées
aux transports est le profil de mobilité (Move dans la figure 5.1). En fonction de la vitesse
moyenne et instantanée, il est possible de déterminer d’autres informations, comme le statut
de l’utilisateur (piéton, passager, conducteur). Il est également possible de prévoir des
positions futures ou la configuration du réseau ad hoc, si par exemple d’autres entités ont
des profils de mobilité similaires.
Tous les éléments de contexte présentés ci-dessus changent au fil de l’utilisation des ap-
plications, car l’utilisateur se déplace. Les applications sont influencées par ces changements
et doivent le plus souvent réagir afin de fournir les meilleurs résultats.

5.1.2 Quelles fonctionnalités peut-on utiliser ?

Un utilisateur mobile se déplace souvent, changeant ainsi son environnement et parfois

ses propres besoins. D’un côté, il peut arriver que les applications doivent s’adapter à
l’environnement en utilisant les fonctionnalités qui sont à leur disposition. Ces dernières
peuvent se trouver sur le terminal même, ou peuvent être fournies par d’autres entités à
proximité, comme le serveur d’un parking, d’une gare, etc. D’un autre côté, nous n’utilisons
pas toutes les applications à tout moment. Un piéton n’aura probablement pas besoin des
informations sur le trafic. Les questions qui se posent sont : quelles sont les fonctionnalités
disponibles à chaque moment ? de quelles fonctionnalités a-t-on besoin ?
Nous considérons comme faisant partie du contexte l’ensemble des services disponibles à
un moment donné. Ces éléments sont liés à l’exécution des applications (ExecutionCtx dans
la figure 5.3), qui est déterminée par les fonctionnalités disponibles à chaque instant. De plus,
une application peut produire des données de contexte, qui, elles aussi, peuvent influencer
son exécution ou l’exécution des autres applications. Ainsi, le terminal peut par exemple
enregistrer combien de fois l’utilisateur s’est garé dans le Parking Centre de la ville V . Si
c’est moins d’une fois par mois, semaine, . . . , alors le terminal peut décider de désinstaller
le code correspondant afin qu’il n’encombre pas le terminal. Au contraire, les fonctionnalités
utilisées souvent ou à des moments précis peuvent être démarrées automatiquement.
Nous considérons ici les interactions entre les différentes parties des applications,
qu’elles soient déjà disponibles sur le terminal ou sur un terminal voisin, prêtes à être
téléchargées. Le contexte d’exécution est utile pour déterminer quelles fonctionnalités sont
disponibles et à quel moment.

5.1.3 Des applications adaptées au terminal

Dans l’exemple du paragraphe 4.2.2 (page 38), nous avons suivi Jean, qui possède un
smartphone et qui utilise plusieurs applications durant son trajet. Au moment où il arrive
dans un parking couvert, Jean rencontre un problème : il ne peut profiter des services du
parking que s’il installe le code spécifique sur son téléphone. Est-ce possible ?
Si l’on veut profiter d’une nouvelle fonctionnalité, on peut avoir besoin d’installer une
partie du code sur le terminal mobile dont on dispose. Dans ce cas, on doit s’assurer que le
code pourra fonctionner correctement. Supposons que le code en question soit écrit en Java
et qu’il utilise le Bluetooth. Il faut que notre terminal dispose d’une machine virtuelle Java
et du module matériel Bluetooth. Une partie du contexte est donc liée aux caractéristiques
matérielles et logicielles, telles que les états des différents modules (Wi-Fi, GNSS, Bluetooth),
la capacité de stockage, les caractéristiques du processeur ou les plateformes logicielles

52
 Chapitre 5. Modélisation du contexte pour des applications dédiées aux transports

disponibles.

DeviceCtx

Software Hardware
OS info Device type
Platforms

Platform Resources Network Input Output

Java Storage interfaces Captors External
OSGi Memory Wifi, GSM Keyboard Img./Video
C++ CPU Bluetooth Webcam Sound

Figure 5.2 – Les caractéristiques d’un terminal mobile

La figure 5.2 illustre notre proposition pour la description d’un terminal 1 mobile. Ces ca-
ractéristiques représentent le contexte pour l’interaction entre le matériel et une application.
D’un côté nous considérons le côté logiciel (Software), comprenant le système d’exploitation
et les différentes plateformes logicielles d’exécution. De l’autre côté nous divisons la partie
matérielle en quatre sous-catégories. La première, Resources, décrit les ressources qui ont un
degré plus ou moins important de disponibilité en fonction des applications qui s’exécutent à
chaque instant. La deuxième sous-catégorie décrit les interfaces de communication, Network
interfaces, qui sont disponibles ou non sur le terminal, actives ou inactives, connectées
ou non. Les deux dernières sous-catégories, Input et Output, décrivent les entrées et les
sorties du terminal, dont certaines applications pourraient avoir besoin pour fonctionner
correctement. Toute nouvelle application doit être adaptée au terminal sur lequel elle est
installée.

5.1.4 Des applications personnelles

Un utilisateur peut désirer des applications personnelles, adaptées à ses propres besoins.
Pour atteindre cet objectif, il faut considérer le profil et les préférences de l’utilisateur
(UserCtx dans la figure 5.3). Le profil est constitué par des caractéristiques générales de la
personne tels que l’âge, le sexe, la présence d’un handicap, etc. Par exemple, savoir que
la personne a un handicap ou connaître le type de permis qu’elle possède (moto, voiture,
etc.) pourrait constituer une information importante quand l’utilisateur est conducteur et
cherche une place de parking adaptée. L’âge et le sexe pourraient servir à personnaliser
des catalogues de e-shopping par exemple. Les caractéristiques de l’utilisateur influencent
l’interaction de l’application avec d’autres entités et les résultats fournis. Par exemple, si
l’utilisateur est conducteur de camion, un service de recherche des places de parking devra
lui indiquer des places spécifiques à son type de véhicule.
Les préférences ne sont pas universelles, mais doivent être définies en rapport avec
une tâche. Ainsi, les applications devraient aussi donner la possibilité de configurer des
paramètres pour personnaliser les résultats qu’elles fournissent. Par exemple, une personne
pourrait préférer les routes de campagne pendant qu’une autre préférerait plutôt rester sur
1. En anglais : device

53
5.1. Quel contexte est important ? Quand ? Pourquoi ?

l’autoroute aussi longtemps que possible. La même application de navigation aura donc
des comportements différents en fonction de l’utilisateur. Les préférences de l’utilisateur
influencent donc son interaction avec l’application.

5.1.5 Vue d’ensemble sur le contexte pour le domaine des transports

La figure 5.3 illustre une vue d’ensemble des éléments de contexte que nous considérons
importants pour les applications dédiées aux transports. Dey et Abowd [DAS01] avaient
divisé les entités impliquées dans les interactions des applications en trois catégories :
endroits, personnes et objets. Nous proposons de diviser les acteurs de l’informatique
ubiquitaire (et plus spécifiquement au transport) en quatre catégories : la personne, son
terminal mobile, les services informatiques qui l’entourent et les éléments (ou événements)
externes. Chacun de ces quatre éléments influence l’exécution des applications.

Context

DeviceCtx ExecutionCtx EnvironmentCtx UserCtx

Software Hardware Services Data Position Network Status External Time Profile Prefers

Figure 5.3 – Vue d’ensemble des éléments de contexte.

Nous avons classifié les éléments de contexte en plusieurs catégories et nous avons mis
l’accent sur quelques-uns des éléments que nous considérons importants par rapport aux
contraintes spécifiques du domaine des transports. La hiérarchie présentée ici n’est pas
exhaustive par rapport à toutes les informations qui peuvent être considérées contextuelles
pour une application, mais elle aide à avoir une vision d’ensemble.
Par rapport à d’autres travaux portant sur la sensibilité au contexte, nous ne considérons
pas le contexte d’une seule application. Nous nous intéressons à l’ensemble des éléments qui
changent au fil du déplacement de l’utilisateur, mais également aux éléments qui influencent
d’une autre manière les applications. Nous considérons par exemple le statut de conducteur
ou piéton, ce qui nous permettra de démarrer ou arrêter des fonctionnalités quand il change
de statut : en tant que conducteur, il doit bénéficier de la fonctionnalité sécurité routière,
mais en tant que piéton il n’en a pas besoin. De plus, en arrêtant une application, elle ne
consomme pas les ressources inutilement.
Nous avons présenté l’ensemble des éléments que nous considérons, en donnant une
idée de la relation entre le contexte, l’utilisateur, le terminal et les applications. Nous avons
vu que les préférences de l’utilisateur ou les caractéristiques du terminal représentent des
informations importantes pour la configuration des applications. Nous n’avons pas encore
expliqué à quel moment le contexte intervient effectivement pour modifier une action (de
l’utilisateur, du terminal, d’une application). Par la suite, nous nous intéressons au moment
où le contexte intervient et à la façon dont il change le comportement des applications.

54
 Chapitre 5. Modélisation du contexte pour des applications dédiées aux transports

5.2 L’utilisation du contexte pour améliorer les applications

Nous avons montré dans le paragraphe 5.1 les diverses interactions entre les entités qui
participent à l’utilisation d’une application mobile : l’utilisateur, le terminal, l’environnement
de l’utilisateur et les services disponibles. Premièrement, l’utilisateur interagit, à travers
ses applications, avec l’environnement, mais aussi avec d’autres utilisateurs. L’application
même utilise certaines fonctionnalités, soit du terminal (par exemple le module Wi-Fi), soit
de l’environnement (sous forme de services). Pour chacun de ces cas, différents éléments du
contexte influencent l’interaction. Dans cette section, nous nous intéressons à la façon dont
le contexte est utilisé et au moment où il intervient dans le cycle de vie d’une application.
Nous identifions deux types d’utilisation du contexte, qui sont très différents. Certaines
informations (liées au terminal par exemple) peuvent influencer l’installation de nouvelles
fonctionnalités, pendant que des événements externes peuvent nécessiter des adaptations.

5.2.1 Installation d’une nouvelle fonctionnalité

Un utilisateur mobile peut avoir besoin de nouvelles fonctionnalités, mais ne peut pas
toujours prêter attention à son terminal pour faire des manipulations compliquées. Ce que
nous visons est donc l’installation automatique de fonctionnalités, en se basant sur ce que
la personne utilise déjà. Dans l’exemple de Jean, nous avons observé qu’il possédait déjà
une application dédiée à la gestion de places de parking capable de communiquer en mode
ad hoc. Nous pouvons donc supposer qu’il aura besoin du même genre d’application, mais
une version qui soit conçue pour la nouvelle situation dans laquelle il se trouve (soit dans
un trafic dense, nécessitant une réservation de la place, soit dans un parking géré par son
serveur qui alloue les places).
Au moment de l’installation du nouveau code sur le terminal, il faut se poser deux
questions par rapport à cette action, surtout si elle n’est pas supervisée par l’utilisateur :
1. Est-ce que le code sera compatible avec le terminal ?
2. Comment personnaliser le code par rapport à l’utilisateur ?
La première question doit être posée avant même de récupérer le code (si ces informations
sont disponibles) : quels sont les besoins du code par rapport aux caractéristiques du
terminal ? L’hétérogénéité des terminaux mobiles sur le marché peut causer un problème
de ce point de vue. Si le code que nous voulons récupérer dépend d’un module matériel ou
logiciel que le terminal ne possède pas, son installation sera un gaspillage de temps et
de ressources. On pourrait penser que l’on est à un stade où tous les téléphones mobiles
possédent toutes les ressources : Wi-Fi, Bluetooth, caméra, accéléromètre, mémoire externe,
etc. Mais il existe encore des différences, par exemple des téléphones avec ou sans caméra
frontale. De plus, nous ne pouvons pas nous limiter aux smartphones. Les tablettes tactiles
sont devenues très populaires. Il est probable que les applications ne fonctionnent pas sur
tous les terminaux, ou au moins pas avec les mêmes performances.
Nous considérons donc les caractéristiques du terminal (illustrées dans la figure 5.2)
comme les informations de contexte à utiliser pour l’installation d’un nouveau code. La plupart
des travaux sur le contexte ne prennent pas en considération la récupération et l’installation
de code. En effet, cette action ne fait pas partie de l’exécution de l’application. Par contre,
si le terminal mobile arrive à gérer la récupération de nouveau code sans l’intervention
de l’utilisateur, l’expérience de ce dernier sera amplement améliorée. Premièrement, le
fait de connaître le contexte du terminal permet de récupérer uniquement les applications
qui pourront fonctionner sur le terminal, en fonction des modules logiciels et matériels.

55
5.2. L’utilisation du contexte pour améliorer les applications

Deuxièmement, des optimisations peuvent être faites en fonction des ressources. Supposons
que l’on peut télécharger deux versions d’une application : une avec une interface graphique
simple, et une autre, avec une interface graphique très élaborée. L’utilisateur préférera
sûrement la deuxième, qui est plus jolie. Mais si son téléphone n’a plus beaucoup de mémoire
disponible, il est préférable de télécharger la version simple.
La deuxième question, comment personnaliser l’application, se pose au moment du
déploiement du nouveau code. La nouvelle fonctionnalité pourrait être configurée par rapport
au terminal (en fonction de la taille de l’écran, des sorties, etc.) mais surtout par rapport
à l’utilisateur (en fonction de son profil et de ses préférences). La configuration d’une
application en fonction de l’utilisateur se fait une seule fois lors de son premier démarrage
et n’a pas besoin de modifications. En effet, nous pouvons supposer que les caractéristiques
et préférences de l’utilisateur ne changent pas souvent et les caractéristiques de son
terminal sont statiques. Nous rencontrons un cas plus dynamique d’adaptation en fonction
du profil dans [MBB08, MBB09b]. Ici, plusieurs services sont offerts aux utilisateurs, et leur
composition se fait de manière personnalisée, en fonction de chaque utilisateur et de son
terminal. Les profils restent donc statiques, mais le système entier est dynamique.
Dans cette section, nous montrons comment nous pouvons utiliser le contexte pour amé-
liorer deux aspects : l’installation de nouvelles applications pour qu’elles soient conformes
au terminal et la configuration des applications afin de proposer une meilleure expérience
utilisateur en fonction de ses préférences. Notre intérêt porte plus sur les aspects dyna-
miques du contexte, nécessitant l’adaptation des applications. Nous présentons par la suite
les aspects liés à l’adaptation.

5.2.2 Pendant l’exécution : réagir aux changements de contexte

Les applications mobiles s’exécutent dans des conditions assez particulières. D’un côté
elles ont besoin de connaître des informations sur leur environnement : où suis-je ? qui
est autour ? combien d’entités sont autour ? quel service est disponible actuellement ? Ces
informations changent souvent à cause du déplacement de l’utilisateur. D’un autre côté,
les applications mobiles utilisent des fonctionnalités qui dépendent de l’environnement ou
d’autres conditions externes. Par exemple, le terminal utilise le GNSS pour connaître sa
position, mais la disponibilité de ce dernier dépend du fait que l’utilisateur soit à l’intérieur
ou à l’extérieur d’un bâtiment.
Pendant l’exécution des applications, différents changements peuvent se produire : la
position du terminal change ; les entités autour s’éloignent ou se rapprochent ; de nouveaux
services deviennent disponibles et d’autres services deviennent indisponibles (comme le
GNSS). La question qui se pose est : comment réagir à ces changements ?
Nous considérons que certaines applications dédiées aux transports peuvent être indis-
pensables pour l’utilisateur, par exemple la navigation. Notre objectif est d’assurer l’exécution
continue et dans de bonnes conditions de ces applications indispensables, malgré des per-
turbations de contexte. Selon nous, l’une des plus importantes utilisations du contexte
se fait pendant l’exécution des applications. Il est essentiel d’adapter dynamiquement le
comportement des applications par rapport aux conditions de contexte qui changent autour
de l’utilisateur.
Les réactions possibles aux changements de contexte comprennent la reconfiguration
des paramètres des applications ou le changement d’un module de code. Par exemple,
une application pourrait avoir des comportements différents en fonction de la vitesse de

56
 Chapitre 5. Modélisation du contexte pour des applications dédiées aux transports

déplacement. Supposons que l’utilisateur soit intéressé par des boutiques qu’il peut atteindre
en 10 minutes. En fonction de son statut de piéton ou conducteur, le rayon de recherche doit
varier. Le rayon de recherche de boutiques dépend d’un paramètre, la vitesse de déplacement.
Dans le cas du positionnement, ce ne sont plus des paramètres qui changent, mais c’est un
module de code qui doit être remplacé pour passer du GNSS au Wi-Fi ou l’inverse.
Étant donnée l’omniprésence de l’informatique, un autre aspect du contexte qui évolue
en permanence est lié aux services disponibles à proximité. En effet, l’utilisateur peut
arriver dans différents endroits qui proposent des services spécifiques. Par exemple un
parking peut gérer l’allocation des places, un bus peut proposer des informations sur son
itinéraire, indiquer l’arrivée à l’arrêt qui intéresse l’utilisateur, etc. Si l’on veut profiter de
tous les services disponibles à chaque endroit, cela pourrait devenir trop encombrant pour
un terminal mobile. Une bonne façon de s’adapter au contexte peut inclure l’installation du
code à l’arrivée dans une certaine zone et la désinstallation quand l’utilisateur n’est plus à
proximité.

Remarques

Nous faisons la prochaine remarque sur les éléments de contexte : si une information
est essentielle pour l’exécution d’une application, elle peut être considérée comme partie
intégrante de cette application. Prenons comme exemple les applications pour des requêtes
telles que « quel est le restaurant le plus proche ? ». La plupart des travaux sur le contexte
considèrent la position comme un élément de contexte, servant à améliorer les résultats.
Mais si l’information de localisation n’est pas disponible, la requête ne peut être résolue.
Dans les cas habituels, les informations de contexte améliorent les résultats. Par exemple,
connaître la vitesse de déplacement peut servir à limiter les restaurants les plus proches
à ceux atteignables en moins de 10 minutes. Par contre, si l’information de localisation
manquait totalement, l’application serait dans l’incapacité de donner des résultats.
Nous considérons par la suite que la fonctionnalité localisation est une partie intégrante
des applications. Etant donnée que l’implémentation utilisant le GNSS est très répandue,
nous considérons comme élément de contexte l’accès aux satellites (le fait ce capter le
signal ou non). Ainsi, au moment où le GNSS devient indisponible, les applications doivent
réagir et trouver un autre moyen de se localiser.

5.3 Les caractéristiques des différents éléments de contexte

Nous avons présenté une vue d’ensemble sur les éléments de contexte qui influencent
les applications mobiles. Nous avons également discuté l’existence de différentes façons de
considérer le contexte afin d’améliorer le comportement du terminal et des applications :
décider si une application est compatible avec le terminal, la configurer et la personnaliser
et ensuite adapter son comportement pendant l’exécution.
Il existe d’autres aspects liés au contexte que l’on a énoncé dans l’état de l’art. Par
exemple, certains chercheurs comme Hofer et al. [HSP+ 03] font une distinction entre les
éléments physiques et logiques. Nous ne faisons pas une classification par rapport à ce
critère, mais nous considérons plutôt des éléments logiques, sans exclure ceux physiques.
Parmi les caractéristiques des éléments de contexte, une qui nous semble importante à
traiter est la fréquence de changement. En effet, avant de pouvoir mettre en œuvre des
applications sensibles au contexte, il faut savoir si le contexte risque de changer souvent.

57
5.3. Les caractéristiques des différents éléments de contexte

5.3.1 Des éléments de contexte avec une évolution dynamique

Dans les sections précédentes, nous avons pu observer que certains éléments du contexte
changent au cours de l’exécution des applications. Ces changements sont souvent dus à
la mobilité de l’utilisateur (mais aussi au déplacement des entités autour du terminal). La
vitesse de déplacement influence la fréquence de changement du contexte. Ainsi, quelqu’un
qui conduit sa voiture peut passer en quelques minutes d’une zone avec une grande densité
de trafic à un chemin peu utilisé, d’une zone bien desservie par le réseau téléphonique à
une zone sans couverture, etc. Les éléments de contexte qui nous intéressent, et que nous
avons présenté dans le paragraphe 5.2.2 (page 56), ont les caractéristiques suivantes :
– Ils changent de manière dynamique. De manière générale, on ne peut pas prévoir
l’instant où le contexte va évoluer, ni comment il évolue. Néanmoins, il existe des
cas où l’on pourrait prévoir les changements, par exemple si l’utilisateur indique une
destination. Ainsi, la fonction navigation pourrait détecter un tunnel ou une autre
situation qui engagerait la perte du signal GNSS et anticiper une réaction. Mais
souvent il est peu probable d’anticiper et il faut détecter les changements de contexte.
– Leur changement peut entraîner des adaptations. Au moment où le contexte change,
certaines applications ont besoin de modifier leur comportement pour fournir des
résultats adaptés aux nouvelles conditions d’exécution.

Les éléments de contexte qui changent pendant l’exécution des applications et qui
influencent leurs résultats appartiennent à deux catégories. La première est la plus évidente :
les éléments de l’environnement (externes), illustrés dans la figure 5.1. La deuxième catégorie
est représentée par les éléments du terminal qui évoluent (figure 5.2). Le niveau de batterie,
la capacité disponible de mémoire et la charge du processeur sont quelques exemples.
Ces éléments peuvent aussi déterminer des adaptations. Par exemple, une application très
consommatrice d’énergie pour faire une action périodique peut changer la fréquence de son
action ou même s’arrêter si le niveau de batterie devient trop faible. Le contexte dynamique
lié au terminal représente en général le degré de consommation des ressources. Il ne faut
pas confondre avec d’autres informations liées au terminal qui représentent les capacités
des ressources. Par exemple, nous distinguons la mémoire totale, information déterminée à
la création du terminal, de la mémoire libre, information qui change au fur et à mesure de
l’utilisation.
Il est clair que l’une de plus importantes contraintes des applications dédiées aux trans-
ports est la mobilité et le besoin d’adapter fréquemment le comportement des applications.
Les éléments dynamiques de contexte doivent être suivis et le défi d’un système informatique
performant est de s’adapter au plus vite aux changements qu’il détecte.

5.3.2 Des éléments de contexte sans évolution dynamique

Les éléments de contexte qui ne changent pas de valeur au cours de l’exécution ne sont
pas moins importants. Ils représentent des profils (du terminal, de l’utilisateur) et servent
à configurer et personnaliser les applications. Ces éléments ne changent pas de manière
indéterminée. Les caractéristiques du terminal ne devraient pas changer dans le temps. Le
profil et les préférences de l’utilisateur peuvent varier, mais ces changements ne sont pas
fréquents. De plus, c’est l’utilisateur lui-même qui effectue la mise à jour de son profil.
Nous rappelons que le terminal possède deux types d’informations sur ses ressources :
leur présence (et capacité maximale) et leur degré de disponibilité. Un exemple pour un tel
élément de contexte est représenté par les interfaces de communication Wi-Fi, Bluetooth

58
 Chapitre 5. Modélisation du contexte pour des applications dédiées aux transports

ou encore GNSS. Il existe des terminaux qui ne possèdent pas les modules matériels pour
un ou plusieurs de ces éléments. La présence ou pas du module est une information qui ne
change pas dans le temps, au contraire des informations telles que la qualité du signal ou
la bande passante.
Il faut créer des profils pour les informations sans évolution. Contrairement aux éléments
dynamiques, on n’a pas besoin de les suivre pour détecter des changements. Nous devons
plutôt soigner la structure des profils pour que les données soit accessibles aisément. Les
profils sont importants à l’installation et au déploiement des applications.

5.4 Modélisation du contexte

Dans ce chapitre nous avons analysé les aspects liés au contexte des applications
mobiles, en prenant en compte le cas particulier du domaine des transports. Le contexte
sert à adapter le comportement des applications en cours d’exécution, à télécharger des
fonctionnalités compatibles avec le terminal ou encore à personnaliser des applications. Nous
avons présenté une vision d’ensemble de tous les éléments de contexte que nous considérons
dans le paragraphe 5.1.5 (page 54). Initialement, nous avons proposé une modélisation à
balises afin de capturer l’état du contexte à un instant donné. En analysant le caractère
dynamique de certains éléments de contexte, nous avons préféré introduire un deuxième
modèle, orienté objet. Par la suite, nous présentons ces deux modèles.

5.4.1 Modélisation initiale

Notre modélisation initiale du contexte visait à comprendre tous les éléments que nous
avons identifiés au début de ce travail de thèse. Nous avons donc proposé un modèle
encodé en XML, qui englobe les éléments présentés dans les Figures 5.1, 5.2 et 5.3. Nous
avons également proposé un schéma XML afin de décrire la structure de notre modèle.
La figure 5.4 montre un aperçu du schéma (à gauche) et un détail de la description de
l’élément de contexte Position (en haut à droite). En bas, à droite de la figure, nous illustrons
un extrait du document XML qui capture l’état du contexte, représentant les coordonnées
géographiques de localisation.

Le but de notre modélisation initiale était de représenter tout le contexte qui influence
une application mobile, s’exécutant sur un terminal avec des ressources limitées. Notre
modèle permet de créer une image (un snapshot) de l’état du contexte à un moment donné.
Ces informations doivent être réévaluées à chaque fois que nous voulons nous en servir. Le
modèle XML s’est avéré difficile à utiliser, surtout pour les éléments dynamiques de contexte.
En effet, ce type d’élément change souvent et peut déterminer des adaptations, nous devons
donc suivre l’évolution de ses valeurs. Le modèle XML ne permet pas de lire facilement une
valeur spécifique, rendant cette approche peu pratique pour nous. Par conséquent, nous
nous sommes penchés sur un autre modèle pour les éléments dynamiques de contexte, un
modèle orienté objet.
Dans nos perspectives proches, nous voulons mettre à jour le schéma XML afin qu’il ne
comprenne plus que les éléments statiques de contexte (voir aussi page 126). Ainsi, nous
utiliserons deux modèles différents pour des objectifs différents : (i) choix et configuration
optimale des applications en fonction du contexte non-dynamique (profil de l’utilisateur et du
terminal) et (ii) adaptation au contexte en fonction de l’évolution des éléments dynamiques.
Par la suite nous présentons notre deuxième modélisation du contexte.

59
5.4. Modélisation du contexte

<xs:element name="Position">
<xs:complexType>
<xs:element name="Context"> <xs:sequence>
<xs:complexType> <xs:element name="coordinatex" type="xs:string" minOccurs="0" />
<xs:sequence> <xs:element name="coordinatey" type="xs:string" minOccurs="0" />
<xs:element ref="Software" /> <xs:element name="coordinatez" type="xs:string" minOccurs="0" />
<xs:element ref="Hardware" /> <xs:element name="precision " type="xs:integer" minOccurs="0" />
<xs:element ref="DeviceInput" /> </xs:sequence>
<xs:element name="Communication"> </xs:complexType>
</xs:element>
<xs:complexType>
<xs:sequence> <xs:element name="History">
<xs:element ref="Wifi" />
<xs:element ref="GSM" />
<xs:element ref="Bluetooth" />
1 @ pos.xml @ 2010-11-03 15:34 @ Dana Popovici
<xs:element ref="OtherProtocols" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> <Position>
</xs:complexType> <coordinatex>50.328916</coordinatex>
</xs:element> <coordinatey>3.514252</coordinatey>
<xs:element name="Location"> </Position>
<xs:complexType>
<xs:sequence>
<xs:element ref="GPS" />
<xs:element ref="Map" minOccurs="0" maxOccurs="unbounded" />
<xs:element ref
ref="Move"
"Move" minOccurs
minOccurs="0"
"0" />
<xs:element
<xs:el
<xs :eleme
ement
nt re
ref="Position"
reff="Po
"Posit
"Po sition
sit ion"
ion " mi
minOccurs="0"
minOc
nOccur
curss="0"
"0" />
</xs:sequence>

Figure 5.4 – XML schéma et un exemple d’instance du XML

5.4.2 Modélisation d’un élément de contexte (CE)

Après avoir étudié les éléments de contexte qui influencent les applications mobiles dans
les différentes étapes (installation, configuration, exécution), nous avons décidé de nous
concentrer sur les aspects dynamiques durant l’exécution. Notre première modélisation était
trop compliquée pour utiliser le contexte de manière efficace quand les valeurs changeaient
fréquemment. En conséquence, nous avons opté pour un modèle orienté objet, afin de
permettre des réactions plus rapides au moment où le contexte change. Nous présentons ce
modèle dans le tableau 5.1.

Elément de contexte (CE)

Nom – le nom unique de l’élément de contexte
Type – le type d’information qu’il contient
Valeur – la valeur de cet élément à un moment donné
(Unité) – (optionnel) l’unité de mesure
(Catégorie) – (optionnel) une catégorie par rapport à une classification

Table 5.1 – Représentation d’un élément de contexte (CE)

Nous appelons « élément de contexte » ou « CE » 2 une caractéristique spécifique

du contexte, qui peut être caractérisée par une valeur. Nous définissons un élément en
considérant les informations présentées dans le tableau 5.1. Un élément de contexte est
identifié par son nom, qui doit être unique, et il est caractérisé par sa valeur à un moment
donné. Nous identifions trois types d’information représentable par un CE :
Booléen Un élément de contexte booléen représente une ressource, et modélise sa disponi-
bilité. Le CE prend la valeur true (vrai) si la ressource est disponible.
Discret Nous considérons qu’un élément est de type discret s’il prend des valeurs qui ne
peuvent être représentées que par des chaines de caractères.

2. De l’anglais « Context Element ».

60
 Chapitre 5. Modélisation du contexte pour des applications dédiées aux transports

Continu Un CE, dont la valeur est exprimée par un nombre réel, est classifié comme élément
de contexte de type continu.
Nous considérons également l’unité de mesure pour les éléments avec une valeur continue.
Par exemple, une température peut être exprimée en degrés Celsius ou Fahrenheit ; une
longueur peut être exprimée en mm ou en m ; etc. L’unité de mesure aide à interpréter
l’information. Enfin, nous considérons la catégorie dont le CE fait partie, par rapport à une
classification donnée. Nous pouvons par exemple représenter la catégorie par rapport à celles
illustrées précédemment, dans la figure 5.3 (page 54). Pour le moment, nous considérons
ces deux dernières informations optionnelles, c’est pourquoi elles sont représentées entre
parenthèses. Afin de mieux comprendre la relation entre le type et la valeur d’un CE, le
tableau 5.2 illustre des exemples pour un élément de contexte de chaque type.

CE C E1 C E2 C E3
Nom Signal GNSS Type De Route Vitesse
Type boolean discrete continuous
Valeur true “route en ville” 97.3
Unité (none) (none) (km/h)
Catégorie (Environment/Position) (Environment) (Environment/Move)

Table 5.2 – Exemples des Éléments de Contexte (CE) de chaque type

Dans le tableau 5.2, C E 1 représente l’élément de contexte appelé Signal GNSS, de type
booléen. Le signal GNSS peut être disponible à un moment et indisponible à un autre, c’est
pourquoi sa valeur est représentée par true ou false (vrai ou faux). Toutes les applications
utilisant la localisation doivent détecter quand la valeur de l’élément Signal GNSS passe à
false, indiquant l’impossibilité de son utilisation. Les applications peuvent réagir en trouvant
un autre moyen de localisation.
L’élément C E 2 du tableau 5.2 représente le Type De Route sur laquelle l’utilisateur
voyage, parmi un nombre limité de variantes. Par exemple, la route pourrait prendre une des
valeurs suivantes : “en ville”, “autoroute”, “route de campagne/montagne”, ou “inconnue”.
Pour ce genre d’élément de contexte, il faut définir l’ensemble des valeurs possibles. Une
application peut changer de comportement quand elle détecte un changement de type de
route.
Dans le tableau 5.2, l’élément C E 3 représente la Vitesse instantanée à laquelle l’utilisa-
teur se déplace. Sa valeur est donc représentée par un nombre réel positif. Nous pouvons
imaginer des applications dont l’exécution dépend de la vitesse, par exemple pour calculer
le rayon d’intérêt de l’utilisateur afin qu’il puisse atteindre rapidement les points d’intérêt.
Pour ce type d’élément de contexte il est nécessaire de connaître l’unité de mesure afin de
comprendre l’information qu’il contient.
Nous nous concentrons sur un modèle simple du contexte, pour une meilleure efficacité.
D’autres travaux, comme par exemple celui de Conan et al. [CRS08], traitent les informations
de contexte de manière répétitive afin d’inférer de nouvelles connaissances à partir de
données brutes. Nous considérons que les applications dédiées aux transports se prêtent
à des éléments plus simples de contexte, tels que GNSS = disponible/indisponible. La
complexité du contexte pourrait ralentir le temps de réaction et d’adaptation, ce qui nuirait
à la qualité des applications. Un modèle plus simple est également plus efficace étant
donné les ressources limitées des terminaux mobiles. Nous considérons que les traitements

61
5.4. Modélisation du contexte

complexes des informations de contexte pourraient être effectués par des entités plus
riches en ressources, comme des serveurs dédiés. Pour les terminaux mobiles tels que des
smartphones, le contexte doit être simple pour assurer des réactions rapides.

5.4.3 Vers l’intégration du contexte dans les applications

Pour mettre en œuvre des applications sensibles au contexte, nous proposons l’utilisation
de deux modèles de contexte en fonction des caractéristiques des éléments. D’un côté,
nous avons vu que les éléments de contexte qui représentent les profils (du terminal ou de
l’utilisateur) ne changent pas fréquemment. D’un autre côté, nous avons souligné l’importance
des éléments fortement dynamiques qui influencent le comportement des applications et qui
nécessitent des adaptations. Nous considérons donc indispensable l’utilisation des deux
modèles différents.
Les informations statiques (ou très peu dynamiques) peuvent être encodées en utilisant
XML ou JSON 3 . Les deux formats sont interprétables par la machine et peuvent être partagés
entre plusieurs entités. En effet, les applications mobiles communiquent parfois avec d’autres
entités et ont besoin d’envoyer le profil de l’utilisateur ou du terminal. L’avantage de JSON
est d’être plus rapide à transmettre et à interpréter les informations. L’avantage de XML est
que ce modèle a été plus étudié dans la recherche et qu’il existe des vocabulaires tels que
CC/PP, permettant de décrire les profils des terminaux. De plus, un document XML peut
être vérifié par rapport à un XML schéma, la recommandation du W3C pour la définition des
structures, le contenu et la sémantique des documents. De son côté, JSON n’a pas encore
d’outil de validation officiel. Le JSON schéma est une ébauche IETF depuis 2010.
Les informations dynamiques doivent être gardées en mémoire au cours de l’exécution
des applications. Pour cette raison, un encodage XML ou JSON serait trop long à interpréter.
Un modèle orienté objet confère la rapidité nécessaire pour ce type d’information. De
plus, ce modèle permet la construction de méthodes spécifiques pour la manipulation des
informations de contexte.
Nous avons présenté les différents aspects liés à la prise en compte du contexte dans le
cadre des applications fortement mobiles. Parfois, en fonction des changements dans les
conditions externes, nous devons décider de démarrer ou arrêter une application. La gestion
du contexte doit donc se faire en dehors des applications. Nous allons présenter dans le
chapitre 6 (page 65) notre cadre d’exécution et de gestion des applications et du contexte.
Notre objectif n’est pas de permettre à une application ou à la plateforme de connaître tous
les éléments de contexte possibles. Il est plus judicieux de définir de manière générique le
contexte afin d’ajouter les éléments en fonction du besoin, à l’exécution.

Récupération des informations de contexte

Nous avons présenté les deux modèles de contexte que nous considérons nécessaires
pour améliorer les applications mobiles. Une fois que les modèles ont été définis, nous devons
considérer un autre aspect, la récupération des informations. Il existe plusieurs façons pour
récupérer les valeurs des éléments de contexte, comme remarqué par Chen [Che04] : l’accès
direct aux capteurs, à travers une infrastructure intergicielle ou à travers des serveurs de
contexte.
L’accès direct aux capteurs rend les applications peu flexibles, car elles intègrent le
3. JavaScript Object Notation, http ://www.json.org/

62
 Chapitre 5. Modélisation du contexte pour des applications dédiées aux transports

code non fonctionnel lié aux capteurs, ainsi que le traitement de l’information. A l’opposé,
les serveurs de contexte externalisent tous les traitements de l’information, séparant les
applications de cet aspect. Les applications deviennent clients du serveur de contexte et sont
donc obligées de se connecter pour récupérer la valeur du contexte [BDR07]. De notre point
de vue, il est important que le terminal reste indépendant par rapport aux entités externes,
tout en utilisant des applications modulaires et découplées du contexte. L’utilisation d’un
intergiciel nous semble une solution optimale.
Nous avons précisé dans le paragraphe 5.3 (page 57) que notre intérêt porte surtout
sur les CE logiques, qui peuvent être calulés. En plus des informations des capteurs, nous
considérons la disponibilité de services à proximité, mais aussi d’autres informations déduites
par voie programmatique, comme étant des éléments de contexte. En ce qui concerne les
capteurs et les caractéristiques du terminal, nous supposons qu’il est possible d’utiliser
des modules légers qui gèrent le matériel et retournent les informations à l’aide d’un de
nos modèles de contexte. De cette manière, le contexte est géré indépendamment des
applications.

5.5 Conclusions

Dans ce chapitre, nous proposons une étude de l’influence du contexte sur les applications
destinées aux transports. Nous analysons les différents aspects, tels que la classification des
éléments de contexte, leurs caractéristiques (dynamiques ou statiques) et les façons dont
les informations de contexte peuvent influencer ou améliorer les applications, au moment
de l’installation ou pendant l’exécution [Pop10, DLP+ 10]. Nous avons proposé un modèle
de contexte à balises pour les éléments peu évolutifs [PDLP11] et un modèle orienté objet
[PDL12b], afin de pouvoir respecter les contraintes des applications fortement mobiles, qui
ont besoin de réactions rapides aux changements de l’environnement pour adapter leur
comportement.
Nos modèles présentent l’état des éléments de contexte, sans prendre en compte la
relation sémantique entre ces éléments. En principe, on n’a pas besoin que le terminal ou
les applications connaissent les liaisons entre les différents aspects du contexte ou qu’ils
fassent des raisonnements. Les concepteurs des applications doivent gérer la cohérence
entre les différents éléments de contexte qui sont mis à la disposition des applications.
Dans la suite de notre travail nous considérons la création d’un serveur qui centralise les
définitions des éléments de contexte ainsi que leur relation, éventuellement en se basant
sur des ontologies.
Dans la suite de ce manuscrit nous nous intéressons à la modalité d’intégration des
informations de contexte dans les applications. Ces dernières doivent être conçues au
départ dans le but d’être sensibles au contexte et avec la capacité de s’adapter en fonction
des conditions externes. Dans le chapitre suivant nous présentons notre approche pour la
conception des applications ainsi que leur gestion à l’exécution.

63
5.5. Conclusions

64
Chapitre 6

Un cadre flexible pour des applications

sensibles au contexte

Apres avoir étudié les différents aspects liés au contexte dans le domaine
des transports, nous nous penchons sur l’architecture des applications.
Nous allons montrer dans ce chapitre les bénéfices des applications
modulaires, qui séparent les fonctionnalités et la gestion du contexte.
Nous allons ensuite présenter notre plateforme d’exécution et de gestion
pour les applications mobiles dédiées aux transports.

6.1 Des applications modulaires

De nos jours, les applications évoluent très rapidement, surtout celles pour les smart-
phones. Ce nouveau type de téléphone est apparu dans les années 2000 mais il est devenu
populaire depuis 2007 environ, avec le lancement de l’iPhone. Pour montrer à quel point
les marchés mobiles ont évolué ces dernières années, nous citons l’article de Holzer et
Ondrus [HO11], publié en 2011. Les auteurs évoquent les parts de marché mondiales des
systèmes d’exploitation mobiles et présentent des données de 2008 : 52.4% Symbian, 11.8%
Microsoft, 8.2% iOS. En trois ans, le paysage a totalement changé, avec 50.9% part de marché
pour Android, 23.8% iOS et seulement 11.7% Symbian 1 . L’émergence des nouveaux systèmes
d’exploitation entraine le développement des applications mobiles correspondantes.
Les contraintes des applications mobiles de nos jours incluent les ressources limitées
des terminaux et l’omniprésence des services. Bien que les smartphones deviennent de nos
jours de plus en plus puissants, il existe encore des limites, dont la taille de l’écran ou la
durée de la batterie. De plus, les applications deviennent de plus en plus complexes, car
elles peuvent profiter de nouvelles technologies (écran tactile, GNSS, Wi-Fi, accéléromètre,
etc.) ainsi que de services auxquels elles peuvent se connecter. De plus, une application
1. Ventes du 4ème quart de 2011, conforme à Gartner, http ://www.gartner.com/

65
6.1. Des applications modulaires

doit être facile à développer et adaptable pour répondre aux exigences des utilisateurs.
La croissance des applications mobiles peut être expliquée par l’utilisation que l’on a du
terminal. Nous pouvons utiliser un smartphone chez nous, dans les moyens de transport,
dans un restaurant, etc.
Nous avons passé en revue les pratiques actuelles de l’informatique dans le chapitre 3
(page 27), et nous avons observé une tendance vers la modularité des applications, qui
peuvent être à base de composants (CBSE), de services (SOA) ou des deux (SCA). La
conception des applications de manière modulaire comporte plusieurs avantages :
– La réutilisation du code. Le même module peut être réutilisé dans plusieurs applications.
Cette pratique accélère le processus de création des applications.
– Une mise à jour plus facile. Parfois seule une partie du code a besoin d’être modifiée.
Si le code est divisé en modules, il suffit de mettre à jour le module correspondant.
– La flexibilité. Le changement de comportement d’une application est facilité par sa
décomposition en modules indépendants.
L’utilisation d’une architecture à services apporte d’autres avantages, notamment le couplage
lâche et la possibilité de connecter les services à l’exécution. De plus, les fournisseurs
peuvent se trouver soit sur le même terminal, soit à distance.
Dans le chapitre 2 (page 15) nous avons présenté des travaux sur le contexte et son
influence sur les applications mobiles. Nous avons observé que, de nos jours, ce concept est
devenu très important pour l’informatique mobile. Parfois, les applications doivent réagir
à des événements externes et changer de comportement en fonction de la situation dans
laquelle elles se trouvent, afin de continuer à fournir des résultats de qualité. Donc, en
plus des contraintes mentionnées au début de ce paragraphe, les applications doivent être
flexibles et dynamiques. Nous trouvons la solution dans une architecture orientée service.
En effet, ce type d’architecture permet non seulement de créer des applications avec plus
de flexibilité à travers l’utilisation de plusieurs fournisseurs de services, mais elle permet
également la connexion à des services distants.

6.1.1 Des applications composées de services

Nous proposons de concevoir les applications à base de services afin de profiter de

tous les avantages de ce type de programmation. La plupart des travaux considèrent
l’aspect distribué des services et traite la découverte [RLS+ 11], l’accès [Boc08, SS09a] ou la
composition de services [MBB08, MBB09b] à travers un réseau. Nous partons des concepts
de la SOA pour analyser les besoins et contraintes spécifiques des applications sensibles
au contexte et dédiées aux transports. L’un des plus importants besoins dans ce domaine
consiste à réagir et à s’adapter aux nouvelles conditions qui se présentent pendant que
l’utilisateur se déplace. A cause du déplacement de l’utilisateur, il est important que les
applications soient indépendantes d’une infrastructure de communication, car la disponibilité
de cette dernière n’est pas garantie. Nous considérons donc des services présents sur la
même machine, capables de télécharger de nouvelles fonctionnalités (et de se connecter
aux services distants quand le contexte le permet).

Qu’est-ce qu’un service ?

Notre première préoccupation est de définir ce que nous comprenons par le mot service.
Nous reprenons la définition donnée par Hall et al. [HPMS10] : un service est une interface

66
 Chapitre 6. Un cadre flexible pour des applications sensibles au contexte

qui représente un contrat entre le fournisseur et les consommateurs. Considérons un service

S. Chaque fournisseur Fi implémente S à sa manière. Un consommateur Cj se sert seulement
du résultat de S tel qu’il a été spécifié dans l’interface. Au moment où Cj a besoin de S, il
fait appel à Fi et ce dernier exécute le code nécessaire pour retourner le bon résultat.
Pour un service S, il existe souvent plusieurs façons de calculer le résultat. Les fournis-
seurs peuvent employer des méthodes différentes pour arriver au résultat avec plus ou moins
de précision. Considérons la localisation comme exemple. Le résultat fourni est l’ensemble
des coordonnées représentant la position courante du terminal. Si l’on utilise des satellites
GNSS, le résultat a une précision de quelques dizaines de centimètres. Un autre moyen de
localiser le terminal peut être d’utiliser des points d’accès Wi-Fi. Le résultat est le même,
mais avec une moindre précision.
Les services présentent plusieurs caractéristiques intéressantes pour créer des applica-
tions dynamiques. Les services ont des couplages lâches et ils peuvent être sans état 2 . Dans
ce cas, l’arrêt et le remplacement d’un service n’a pas de répercussions sur l’exécution d’une
application qui le consomme. Nous pouvons envisager de considérer des services avec état,
mais cela implique une gestion particulière au démarrage et à l’arrêt afin de sauvegarder
ou restaurer l’état.

Une application à base de services

Nous proposons de concevoir les applications de façon modulaire dès le début. Une
application A peut être décomposée de manière logique par rapport à ses fonctionnalités.
Chaque fonctionnalité doit ensuite être représentée en tant que service. L’application A
devient un assemblage de plusieurs services, comme illustré dans la figure 6.1. De manière
générale, nous considérons plutôt des fournisseurs et consommateurs locaux (sur la même
machine), pour assurer un bon fonctionnement dans toutes les conditions (perte de connexion
à l’infrastructure). Par contre, nous n’excluons pas la possibilité de connecter des services
distants quand ceci est possible. Hall et al. [HPMS10] désignent ce type d’approche comme
« SOA dans une VM » pour la différencier des applications SOA qui se basent plutôt sur
l’utilisation de services web. Nous représentons une application dans la figure 6.1.

Application A
JKLMNAFOF
@ABCDEFGHHIJKFGLF
@ABCDEAFPF

@ABCDEAF@GHIF
@ABCDEAF@F @ABCDEAFQF

Figure 6.1 – Une application constituée par assemblage de services

Nous appelons module une unité de code qui peut être exécutée de manière indépendante.
Un module peut fournir ou consommer des services. Une application est composée de plusieurs
2. En anglais : Stateless service.

67
6.1. Des applications modulaires

modules, qui encapsulent les services. Chaque application doit comprendre un module
représentant son noyau 3 . C’est la partie qui centralise les traitements de l’application,
comme le module C dans la figure 6.1. Le noyau consomme plusieurs des services qui
constituent l’application. Les autres modules peuvent, eux aussi, consommer un ou plusieurs
services. Par contre, un module ne peut fournir qu’un seul service. Nous imposons cette
règle pour assurer le couplage faible entre les modules et pour pouvoir arrêter un module si
son service n’est plus utile. Nous illustrons dans la figure 6.1 deux modules fournisseurs,
ce sont les services S et U. Le dernier module est à la fois fournisseur du service T et
consommateur du service U.
Nous considérons de manière générale que les services sont synchrones et sans état.
Dans ce cas, un module client, qui a besoin d’un service, interroge le fournisseur et attend son
résultat. Entre deux appels, le fournisseur peut changer sans que cela affecte le client, car
la réponse ne dépend pas de l’état du fournisseur. Néanmoins, nous pouvons aussi envisager
des services avec un état ainsi que des services asynchrones. Dans le premier cas il existe
deux possibilités pour récupérer l’état. La première consiste à ajouter une fonctionnalité pour
gérer l’arrêt d’un service qui garde des informations sur son état. La deuxième possibilité
implique la séparation entre l’état et l’implémentation du service. Considérons par exemple
un service de localisation qui vérifie son résultat en comparant la nouvelle position avec un
historique. Il est possible de séparer (i) la fonctionnalité de récupération de la position, (ii) la
vérification du résultat, et (iii) l’historique. De cette façon, la partie enregistrant l’historique
reste toujours active car elle n’est pas influencée par les changements de contexte. Pour
l’utilisation de services asynchrones, une manière de faire est de permettre au client de
s’abonner aux notifications du fournisseur. Ainsi, ce dernier effectue les calculs nécessaires
et envoie le résultat de façon asynchrone.
Parmi les avantages des architectures orientées services, nous notons le partage de
services entre plusieurs applications. Nous illustrons dans la figure 6.2 des services qui
font partie de deux assemblages, ceux des applications A et B. Le meilleur exemple pour
démontrer l’utilité du partage des services est l’exemple de la localisation. En effet, un grand
nombre d’applications a besoin de cette fonctionnalité, et dans la pratique courante cela
implique des parties de code similaires qui se répètent dans chaque application. Notre
solution permet d’avoir un seul module responsable de la localisation au bénéfice de plusieurs
consommateurs.
Les applications modulaires (à base de composants) permettent un développement plus
rapide et ont l’avantage d’une architecture « propre » et explicite, comme le remarquent
Hnetynka et al. [HMM11]. Les services, quant à eux, apportent d’autres atouts grâce aux
couplages lâches et au fait qu’ils n’ont pas d’état. Nous pouvons envisager de remplacer
un service et modifier ainsi le comportement d’une application, pourvu que la plateforme
d’implémentation le permette. Le service de localisation GNSS par exemple peut être
remplacé par celui utilisant le Wi-Fi au moment où l’utilisateur entre dans un bâtiment. Étant
donné le caractère dynamique de l’environnement dans lequel les applications s’exécutent,
ces dernières doivent être flexibles et capables de créer des compositions dynamiques.
Notre but est de proposer des systèmes qui peuvent changer de comportement en cours
d’exécution. Dans la section suivante nous discutons de l’intégration de la notion de contexte
dans la conception des applications, afin de les rendre adaptables.

3. En anglais : Core.

68
 Chapitre 6. Un cadre flexible pour des applications sensibles au contexte

Application B
@ABCDEAFRF
@ABCDEFGHHIJKFMLF

Application A
JKLMNAFOF
@ABCDEFGHHIJKFGLF
@ABCDEAFPF

@ABCDEAF@GHIF
@ABCDEAF@F @ABCDEAFQF

Figure 6.2 – Partage des services entre les applications

6.1.2 Des services dépendants du contexte (CDS)

Nous avons constaté le besoin d’adaptation pour les applications mobiles. Quand le
contexte change, les applications doivent modifier leur comportement en conséquence. Dans
la section précédente, nous avons décrit notre approche pour la création des applications
légères et flexibles à base de services. Nous n’avons pas encore discuté l’intégration
du contexte dans la structure des applications. Comment peut-on faire pour changer le
comportement d’une application facilement ?
Nous proposons l’utilisation des services avec plusieurs versions d’implémentation,
en fonction du contexte. Notre idée se rapproche des services techniques à multiples
personnalités proposés par Herault [Her05] ou encore de l’idée de familles de produits
proposée par Parra et al. [PBD09].
Nous appelons les services dépendants du contexte (CDS) 4 si leur exécution dépend de
l’état du contexte. Nous décrivons les services à travers leurs interfaces, qui spécifient le
résultat à fournir. Une interface n’impose pas la manière dont le résultat final est calculé,
donc des fournisseurs différents ne fonctionnent pas de la même manière. Nous utilisons
cette caractéristique pour rendre possible l’adaptation au contexte. Nous employons le terme
services équivalents pour décrire des services qui fournissent le même résultat (implémentent
la même interface) mais qui le calculent de manière différente.

Conception d’une application sensible au contexte

Au moment de la conception d’une application, nous devons la décomposer par rapport à

ses fonctionnalités. Ensuite, nous devons analyser les différentes situations dans lesquelles
l’application pourrait utiliser chaque fonctionnalité. Nous nous intéressons donc à la relation
entre une fonctionnalité (un service) de l’application et le contexte de son exécution. Si un
4. En anglais : Contexte Dependent Service (CDS)

69
6.1. Des applications modulaires

service peut être influencé par un élément de contexte, nous devons concevoir plusieurs ver-
sions afin de couvrir toutes les situations possibles. La manière de concevoir les applications
que nous proposons se rapproche de SPL.
La figure 6.3 reprend l’exemple de la figure 6.1 pour montrer le Service S avec plusieurs
versions : S(1), S(2) et S(3). Nous supposons donc qu’il existe trois situations distinctes de
contexte, nécessitant chacune un comportement différent. Pendant l’exécution de l’application
A, le module C devra utiliser le service Si correspondant à la situation courante de contexte.
Au moment d’un changement de contexte, A pourra échanger la version de S qu’elle utilise,
afin de s’adapter.

Application A
IJKLMAFNF
@ABCDEFGHHIJKFGLF
@ABCDEAFGF

@ABCDEAFHF
@ABCDEAF@OSQF
@ABCDEAF@ORQF
@ABCDEAF@OPQF

Figure 6.3 – Service avec plusieurs versions équivalentes

Nous proposons donc d’utiliser des versions de services qui soient conçues chacune pour
une situation spécifique, déterminée par l’état du contexte. En conséquence, chaque service
doit décrire ses dépendances au contexte, en fonction d’un ou de plusieurs éléments. Nous
reprenons les exemples de CE décrits dans le tableau 5.2 (paragraphe 5.4.2, page 60) pour
illustrer des versions de services qui dépendent de chaque type d’élément de contexte. Le
tableau 6.1 montre comment chaque service spécifie la situation pour laquelle il a été conçu.
Dans cet exemple nous ne considérons que des services dépendant d’un seul CE.

Service Localisation Recherche Boutiques Détection Sommeil

CE Nom Signal GNSS Type De Route Vitesse
CE Type boolean discrete continuous
CE Plage De Valeurs true “route en ville” [80, 250[
CE Unité (none) (none) (km/h)
CE Catégorie (Environ./Position) (Environ.) (Environ./Move)

Table 6.1 – Exemples de services dépendants de différents éléments de contexte.

Exemple de service : Localisation. Le service a pour but de retourner les coordonnées

géographiques du terminal. La version présentée dans le tableau 6.1 est celle qui fonctionne
avec le GNSS. Elle dépend donc de l’élément de contexte nommé Signal GNSS de type
booléen, une ressource qui est disponible ou non. Pour tout service dépendant d’un élément
de contexte booléen, le service est évidement créé pour fonctionner si la valeur est true. Le

70
 Chapitre 6. Un cadre flexible pour des applications sensibles au contexte

cas de la localisation est particulier, car chaque version du service dépend d’un élément
différent lié à la disponibilité d’une ressource : GNSS, Wi-Fi, Infrarouge, etc.

Exemple de service : Recherche Boutiques. Nous considérons un service qui recherche

les boutiques atteignables en quelques minutes par l’utilisateur. Ce service a une version qui
ne fonctionne que si l’utilisateur se trouve en ville. Il dépend donc de l’élément de contexte
Type De Route, et est supposé fonctionner pour la valeur “route en ville”. Cela permet
d’arrêter le service quand l’utilisateur se trouve sur autoroute. Dans ce nouveau contexte
il pourrait y avoir une version qui fonctionne quand le Type De Route prend la valeur
“autoroute”. Cette deuxième version du service prend en considération des détails comme
la proximité des boutiques par rapport à la sortie d’autoroute ou le détour nécessaire.

Exemple de service : Détection Sommeil. Ce service a pour but de détecter si l’utilisateur

(qui est en train de conduire) est susceptible de s’endormir. Démarrer ce service n’est utile
que si le véhicule se déplace à une vitesse élevée. Le service dépend donc du CE Vitesse et
décrit la gamme des valeurs pour laquelle il a été créé. Dans l’exemple du tableau 6.1, le
service doit être démarré dès que la vitesse dépasse 80 km/h.

La description associée à un service précise les conditions dans lesquelles celui-ci devrait
fonctionner pour rendre les meilleurs résultats. Il existe deux manières d’utiliser des services
dépendants du contexte pour adapter les applications :
– Échange entre des services équivalents. La première utilisation des CDS consiste à
couvrir toutes les situations par rapport à un élément de contexte qui prend plusieurs
valeurs. Si le CE est de type discret, il faut concevoir une version du service pour
chaque valeur possible (et éventuellement une version par défaut). Si c’est un élément
de type continu, les versions du service doivent préciser l’intervalle pour lequel elles
sont conçues. En fonction de l’état du contexte, l’application doit changer entre les
services équivalents.
– Démarrage à des moments spécifiques. La deuxième manière d’utiliser les CDS consiste
à démarrer un service seulement dans certaines conditions. Il se peut qu’un service
n’ait pas besoin de couvrir toutes les situations de contexte, mais seulement une
situation spécifique. Par exemple le service Détection Sommeil doit surveiller l’état du
conducteur et envoyer des notifications en cas d’endormissement. Si l’utilisateur n’est
pas en train de se déplacer vite, ce service n’a pas d’utilité et devrait être arrêté. Il
n’y a pas besoin d’un service équivalent pour des vitesses basses.

6.1.3 Description des modules et des services

Notre but est de permettre l’assemblage dynamique et autonome des applications à

l’exécution. De cette manière, l’expérience de l’utilisateur est améliorée, car ses applications
s’adaptent sans son intervention. En laissant le terminal gérer seul le couplage des services,
nous nous rapprochons des objectifs de l’informatique autonome. Par contre, pour que
l’assemblage des applications se fasse correctement, il est impératif de décrire les services de
manière complète. Aujourd’hui, quand on parle de service ou de SOA, on pense généralement
aux services livrés via Internet [HPMS10]. Plusieurs langages ou standards existent pour
décrire les services ou l’accès aux services. Le registre UDDI (description, découverte
et intégration universelle) [UDD02] ou le WSDL (langage de description de services web)
[WSD07] décrivent les services et l’accès aux services via Internet, en spécifiant les protocoles

71
6.1. Des applications modulaires

de communication et d’autres informations importantes. Oberle et al. [OBKH13] considèrent

nécessaire l’ajout d’autres informations, telles que le prix ou la licence du service. Les
auteurs décrivent USDL, un langage universel de description des services. Dans cette thèse,
nous ne nous intéressons pas aux services distants, mais à ceux qui sont sur le terminal
de l’utilisateur. Notre intérêt porte sur leur composition sensible au contexte. Cela n’exclut
pas la connexion à des services distants, encapsulée dans un service qui implémente les
protocoles nécessaires.
Nous présentons ici les informations nécessaires pour assembler les services sur une
seule machine. Nous divisons les applications en plusieurs modules, qui peuvent fournir un
service et consommer un ou plusieurs services. Pour chaque module nous devons répondre
aux questions suivantes : Est-ce le noyau de l’application ? Est-ce qu’il fournit un service ?
Lequel ? Le service dépend-t-il du contexte ? Est-ce que le module consomme des services ?
En fonction de ces informations, les clients peuvent être connectés aux bons fournisseurs,
au bon moment. Premièrement, nous nous intéressons à la description d’un service : sa
fonctionnalité, ses dépendances au contexte et ses autres attributs.

Service S
Interface Description de l’interface implémentée (le contrat)
Attributs Nom de la version
Description de la version
Précision du résultat fourni
Dépendances Élément de contexte C E 1
◦ Identification du CE : Nom & Type (& Unité & Catégorie)
◦ Dépendance du CE : Plage De Valeurs (la gamme de
valeurs pour laquelle S a été créé)

Élément de contexte C E 2
···
Élément de contexte C E n

Table 6.2 – Description d’un module d’application.

Le tableau 6.2 illustre notre description d’un service (pour un fournisseur). Celle-ci
doit comprendre les informations relatives à l’Interface implémentée pour spécifier quelle
fonctionnalité est fournie. Le service doit ensuite préciser des Attributs comme le nom et une
description de la version qu’il implémente, ainsi que la précision du résultat fourni. Enfin, si
le service est conçu pour une certaine situation de contexte, il doit décrire ses Dépendances
par rapport à chaque élément qui l’influe, comme dans l’exemple donné dans le tableau 6.1
(page 70). Un service n’est pas forcement influencé par le contexte. Dans ce cas, la partie
Dépendances peut entièrement manquer.

Précision d’un service.

Nous avons mentionné, parmi les attributs d’un service, la précision. Elle sert comme
indication pour la qualité du résultat fourni et peut aider à faire un choix entre les versions
du même service. Il existe deux façons pour exprimer la précision : de manière absolue (en

72
 Chapitre 6. Un cadre flexible pour des applications sensibles au contexte

fonction d’une unité de mesure) ou de manière relative, en utilisant une échelle quelconque.
Par exemple, pour la localisation, nous considérons trois services, utilisant le GSM, le
Wi-Fi ou le GNSS. Chacune des versions a une précision différente. Nous montrons un
exemple avec des valeurs possibles pour chaque service, dans le tableau 6.3. Sans connaître
exactement les valeurs réelles de ces données, nous avons créé une échelle approximative
qui sert d’exemple. Nous avons estimé la précision de la localisation par satellite à ±1 mètre
et nous l’avons noté à 9 sur 10 sur cette échelle imaginée, où 10 représente la meilleure
précision. Nous avons estimé les autres précisions à ±10 mètres pour le Wi-Fi et ±100
mètres pour le GSM.

Service Localisation Précision absolue Précision relative

GSM ±100 m 2 sur 10
Wi-Fi ±10 m 6 sur 10
GNSS ±1 m 9 sur 10

Table 6.3 – Exemples fictifs de précisions absolues et relatives des services

La description des modules d’une application.

Il est essentiel de connaître la description d’un service, mais ce n’est pas suffisant pour
assembler des applications. En effet, nous avons vu que les services sont encapsulés dans
des modules avant d’être déployés sur le terminal. Le tableau 6.4 montre comment nous
décrivons les modules pour permettre au terminal de faire les bons couplages à l’exécution.
Un module M comporte des Attributs, par exemple pour préciser si c’est le noyau d’une
application. Un module peut être producteur (fournisseur) d’un seul service et consommer
un ou plusieurs services. Ces informations sont décrites dans les catégories Producteur et
Consommateur.

Si le module M est producteur d’un service T , il reprend les informations présentées

dans le tableau 6.2 pour décrire T : son Interface, ses Attributs et ses Dépendances. Si
M consomme des services il doit spécifier lesquels. En principe, le module ne précise que
l’Interface dont il a besoin, permettant de consommer n’importe quelle version du service.
Par contre, il peut ajouter des informations sur ses Préférences pour le fournisseur. Par
exemple, M peut préciser qu’il accepte seulement les versions de U offrant une précision
au-dessus d’un certain seuil precx . Le module pourrait aussi demander une version précise
U(i) du service.

6.1.4 Mécanisme d’adaptation

Nous proposons des applications créées par assemblage de services afin d’être flexibles.
Nous avons défini des services dépendants du contexte, dont certains ont plusieurs versions,
créées spécifiquement pour des situations différentes de contexte, que nous appelons
services équivalents. Le mécanisme que nous proposons pour adapter les applications au
contexte consiste à arrêter et démarrer les services en fonction de l’état du contexte. Pour
les services équivalents, cela signifie que l’on échange un service avec son équivalent
en fonction des conditions du contexte. Notre approche ressemble à celle proposée par
Herault [Her05] pour l’adaptation des services techniques en fonction de leur personnalité,

73
6.1. Des applications modulaires

Module M
Attributs Noyau de l’application A
Producteur Service T
◦ Interface
◦ Attributs
◦ Dépendances

Consommateur Service U
◦ Interface U
◦ Préférences (Précision de U ≥ precx ; version U(i) ;
...)

Service V
···

Table 6.4 – Description d’un module d’application.

ou encore à l’algorithme de décision proposé par Parra et al. [PBD09], qui changent entre
des architectures équivalentes d’une même famille de produits.
L’exécution des services dépendants du contexte que nous utilisons est liée à l’état du
contexte (voir le paragraphe 6.1.2). Pour qu’une implémentation Si d’un service S puisse
fonctionner correctement, tous les éléments de contexte dont Si dépend doivent avoir des
valeurs correspondantes à celles définies dans la description de l’implémentation. Si ce n’est
pas le cas, Si ne peut pas fonctionner. Pour qu’une application s’exécute correctement, dans
toutes les situations de contexte possibles, il est nécessaire d’avoir des services équivalents
adaptés à chaque situation. Par exemple, pour une application qui nécessite obligatoirement
la localisation, il faut mettre à disposition des services équivalents qui récupèrent cette
information à travers les satellites, le réseau GSM ou des points d’accès Wi-Fi. Il se peut que
le terminal n’ait accès à aucun de ces moyens de localisation. Il est envisageable de créer
des services « par défaut » pour un CE dont S dépend. Quand le CE prend une valeur pour
laquelle aucune version du service S n’est adaptée, l’application peut utiliser Sdéfaut . Dans
le meilleur des cas, un service dépend d’un seul élément de contexte, rendant la conception
des services équivalents plus simple. Si un service dépend de plusieurs éléments, il faut
créer des versions pour toutes les combinaisons possibles de valeurs de chaque élément.
Nous trouvons possible de limiter les dépendances avec une bonne division logique des
applications, pour que chaque fonctionnalité ne dépende pas de plus de deux éléments de
contexte.
L’adaptation que nous proposons ressemble à une architecture orientée événements 5
simplifiée. En effet, les événements sont les changements dans le contexte, qui font que
certains services ne sont plus adaptés à la situation courante. Les conditions ne sont pas
définies en tant que règles explicites, mais sont plutôt implicites. La description de chaque
implémentation de service exprime les conditions dans lesquelles le ce dernier fonctionne.
L’état du contexte au moment de l’exécution doit remplir les conditions exprimées par le
service. Les actions sont représentées par l’arrêt et le démarrage de services en fonction

5. En anglais : Event-Condition-Action (ECA).

74
 Chapitre 6. Un cadre flexible pour des applications sensibles au contexte

de la nouvelle valeur du contexte, du style si C E i == valeurj alors démarrer Service Sij

et arrêter Sik où k &= j . Autrement dit, quand un élément de contexte change de valeur,
toutes les versions des services qui dépendent de cet élément et qui sont adaptées à la
nouvelle valeur sont démarrées. Par adaptées à la valeurj nous comprenons que la version
du service en question déclare fonctionner pour la valeurj ou que cette valeur est incluse
dans la plage de valeurs déclarée par la version du service.
De nouveau, nous remarquons que ce ne doit pas être l’application elle-même qui gère
son adaptation, mais plutôt une entité externe, comme une plateforme d’exécution. En effet,
les applications seraient encombrées par la gestion des versions des services qu’elles
utilisent. Une plateforme qui s’occupe seulement de la gestion du contexte et de l’adaptation
peut faire les mêmes actions pour toutes les applications. De plus, elle peut également gérer
le cas particulier où aucune version d’un service n’est adaptée pour la situation courante,
en recherchant la version nécessaire sur les terminaux voisins ou sur des serveurs dédiés.

Perspectives de l’adaptation

Dans le travail que nous présentons ici, l’adaptation est faite par le remplacement des
services et par l’arrêt et le démarrage des fonctionnalités, par rapport au contexte. Cette
approche fonctionne bien dans certains cas, comme celui de la localisation. Nous observons
que dans d’autres cas, il peut être inutile de remplacer un service entier. Par exemple, un
service pour la recherche des boutiques à proximité pourrait définir la « proximité » comme
« un endroit atteignable en moins de 10 minutes ». Dans ce cas, la distance maximale de
recherche peut être calculée en fonction de la vitesse de déplacement. Au lieu de créer
plusieurs versions du service, il faudrait intégrer la relation entre le service et l’élément de
contexte Vitesse.
Nous envisageons l’utilisation de paramètres comme deuxième mécanisme d’adaptation.
Dans ce cas, un service ne devrait plus laisser la plateforme gérer son exécution en fonction
des valeurs du contexte et des conditions qu’il précise. En revanche, le service pourrait
exprimer sa dépendance vis-à-vis d’un ou plusieurs éléments de contexte et intégrer une
fonction qui calcule ses paramètres à partir des valeurs du contexte. Le service pourrait
s’abonner directement à l’élément de contexte qui l’intéresse afin d’être informé des change-
ments quand ceux-ci se produisent. Ses paramètres seraient donc (re-)calculés dès qu’un
changement serait détecté.

6.1.5 Conclusions

Nous avons discuté dans cette section de la conception des applications sensibles au
contexte à base de services. Notre approche se différencie des autres approches se basant
sur les normes SOA, car nous considérons des services sur la même machine et non pas
distants. Nous nous focalisons sur la composition et l’adaptation locale afin de rendre
adaptables les applications de l’utilisateur. Avec notre approche, nous pouvons ajouter de
nouvelles fonctionnalités à tout moment, sous la forme d’un service. Dans la suite, nous
nous penchons sur la plateforme d’exécution que nous proposons comme solution pour les
applications dédiées aux transports. Notre solution à base de services permet des réactions
rapides, telles que demandées par les changements dynamiques de contexte dans les milieux
évolutifs. Une plateforme avec des capacités de gestion apporte d’importants avantages à
l’ensemble des applications visées.

75
6.2. Une plateforme d’exécution

6.2 Une plateforme d’exécution avec des fonctionnalités de gestion

du contexte

Afin d’améliorer l’expérience d’une personne impliquée dans le trafic, nous avons analysé
les applications qu’elle utilise ainsi que leurs besoins. L’adaptation au contexte s’est avérée
l’une des principales caractéristiques d’une application de nos jours, surtout pour les
utilisateurs fortement mobiles. Nous avons analysé les éléments de contexte qui influent sur
les applications dédiées aux transports et nous avons proposé un moyen de concevoir des
applications adaptables. Dans les paragraphes précédents, nous avons souligné les avantages
que pourrait apporter un cadre d’exécution pour les applications que nous considérons.
Les avantages incluent le partage de services entre les applications, l’extériorisation de la
gestion du contexte et de la gestion de l’adaptation. Nous allons présenter dans la suite le
fonctionnement de la plateforme que nous proposons, ainsi que les modules de gestion que
nous considérons nécessaires.

6.2.1 Plateforme pour des Services de Transports Sensibles au Contexte

Nous proposons l’utilisation d’une plateforme pour des Services de Transports Sensibles
au Contexte, que nous appellons CATS (de l’anglais « Context-Aware Transportation Services
Framework »). Le nom reflète le domaine d’application aussi bien que l’approche que nous
considérons. La principale raison pour proposer une plateforme réside dans la factorisation
des tâches de gestion. Ainsi, les applications deviennent plus légères et moins compliquées,
bénéficiant des fonctionnalités de gestion de la plateforme. Nous présentons ici tous les
avantages apportés par l’utilisation de la plateforme CATS ainsi que par notre approche de
construire les applications à base de services :

– L’ensemble des applications est plus léger. Nous avons observé la présence de fonc-
tionnalités similaires dans plusieurs applications mobiles (comme la localisation).
Les applications assemblées par des services peuvent partager ces fonctionnalités
communes, mais seulement si elles s’exécutent dans le même cadre. Si le nombre de
services partagés est grand, l’ensemble des applications est allégé.
– Des applications flexibles, adaptables dynamiquement. L’utilisation de notre plateforme
permet la composition des applications et leur reconfiguration dynamique, grâce
aux services avec un couplage lâche. Ainsi, les applications peuvent changer leur
comportement pour s’adapter aux changements de contexte.
– Extériorisation de la gestion par rapport aux applications. Nous avons constaté que
certaines applications ou services ont besoin d’une gestion externe pour démarrer ou
s’arrêter dans des conditions spécifiques. Au lieu d’encombrer l’application avec la
gestion de son démarrage, la plateforme peut s’en charger.
– Une gestion commune du contexte. Le contexte influence plusieurs applications (qui
partagent des services ou non) de façon similaire. Au lieu d’implémenter du code dans
chaque application pour détecter le contexte et réagir aux changements, la plateforme
peut le faire à leur place.
• Si un service partagé est concerné par le contexte et doit être remplacé par
un service équivalent, toutes les applications l’utilisant sont adaptées en même
temps.
• Si plusieurs services dépendent d’un même élément de contexte, quand ce dernier
change de valeur tous les services sont traités simultanément.

76
 Chapitre 6. Un cadre flexible pour des applications sensibles au contexte

– Mise à jour facile des applications. Pour mettre à jour une application, il suffit de
remplacer un service par sa nouvelle version, en utilisant le même mécanisme que
pour l’adaptation des applications.

– Ajout de nouvelles fonctionnalités. La plateforme peut gérer l’ajout de nouvelles

fonctionnalités, comme des services spécifiques à un endroit ou à une entité (parking,
bus, etc.).

L’utilisation d’une plateforme d’exécution permet donc de se focaliser sur les aspects de
contexte critiques pour un utilisateur qui se déplace : l’adaptation aux nouveaux environne-
ments. À part les applications, nous proposons l’utilisation de trois modules de gestion :
(i) un gestionnaire de contexte, que nous appelons Context Manager, (ii) un gestionnaire
d’exécution, que nous appelons Execution Manager, (iii) un courtier, que nous appelons
Trader qui gère l’installation de nouveaux services sur le terminal.

CATS Framework
"Appli. F" core
… Context
Manager
"Appli. E" core
E
pli.

Execution
Ap

Service X
Manager

Service T(2)
Service V Position
Position (GPS) (Wifi)

Service T(1) Service Y Trader

Appli. F

Figure 6.4 – La plateforme CATS avec deux exemples d’applications.

La figure 6.4 illustre la plateforme CATS avec les modules de gestion (à droite de la
plateforme) ainsi que deux exemples d’application E et F , qui partagent le service Position.
Le Trader représente la liaison avec des ressources externes. Ici nous présentons un scénario
où le service T (1) est arrêté pour être remplacé avec une autre version, T (2), qui n’est pas
présente sur le terminal. Le Trader récupère alors T (2) à partir des terminaux à proximité.
Dans la suite, nous présentons le rôle de chaque module de gestion dans le fonctionnement
de la plateforme.

6.2.2 Le gestionnaire de contexte : Context Manager

Nous avons présenté l’intérêt de rendre les applications sensibles au contexte afin
d’adapter leur comportement durant l’exécution. Nous proposons d’utiliser un module pour
la gestion du contexte, que nous appelons Context Manager. Son but est de connaître le
contexte et de suivre ses changements, en prenant en considération les caractéristiques de
chaque élément. Quand un changement a lieu, le Context Manager le détecte et notifie la
plateforme afin de prendre les mesures nécessaires, c’est-à-dire adapter les applications
qui ne sont plus conformes au contexte.

77
6.2. Une plateforme d’exécution

Le contexte peu évolutif

Nous avons remarqué qu’il existe des éléments qui ne changent pas souvent (ou qui ne
changent jamais). Pour ce type d’élément, le Context Manager peut garder des informations
statiques encodées en XML, comme présenté dans le paragraphe 5.4.1 (page 59). Une partie
du Context Manager se charge donc des éléments de contexte statiques, notamment le
profil du terminal et celui de l’utilisateur. Cette partie est initialisée au démarrage de la
plateforme CATS et utilisée au moment du téléchargement de nouvelles fonctionnalités ou
au déploiement des applications qui peuvent être personnalisées.

Le contexte dynamique et les moniteurs de contexte : Context Monitors

Certains éléments de contexte évoluent rapidement et ce ne serait pas efficace d’utiliser

un encodage à balises pour garder leur état. Nous avons donc proposé un modèle orienté
objet dans le paragraphe 5.4.2 (page 60). Ce type d’élément de contexte doit être suivi en
permanence afin que le Context Manager puisse détecter les changements et déclencher
les adaptations. L’exécution des services est gérée par l’Execution Manager, donc les
changements de contexte doivent être notifiés auprès de ce dernier.
Nous proposons l’utilisation des modules appelés Context Monitor, pour assurer le suivi
de chaque élément de contexte passible de changer durant l’exécution des applications. Le
Context Monitor en charge d’un élément C E i , que nous allons appeler MonitorC Ei , doit
être capable d’évaluer le contexte pour ensuite transmettre la valeur au Context Manager.
Nous envisageons deux fonctionnements différents, qui peuvent être utilisés séparément
ou en même temps. Dans le premier type de fonctionnement, les Context Monitors sont
invoqués par le Context Manager pour déclencher une évaluation du contexte à un moment
choisi par le gestionnaire. Dans le deuxième fonctionnement, chaque Context Monitor évalue
de manière autonome son élément de contexte et met à jour la valeur auprès du Context
Manager. Dans ce deuxième cas, l’évaluation se fait à une fréquence donnée, qui peut être
différente d’un CE à un autre.

Profil terminal
Profil utilisateur
Monitor CE1

Monitor CE2
@ Context Manager : Execution
• état du contexte Manager
Monitor CEn

Figure 6.5 – Le Context Manager et les Context Monitors.

La figure 6.5 montre la représentation du Context Manager et les parties qui le composent.
Le gestionnaire connaît les profils du terminal et de l’utilisateur qui ont une structure statique.
Le Context Manager ne connaît les éléments dynamiques de contexte que s’ils sont suivis
par un Context Monitor. De cette façon, le gestionnaire de contexte reste flexible et peut
être configuré en fonction des besoins. Les moniteurs, quant à eux, ne connaissent que le
CE qu’ils évaluent. Ils fournissent à chaque fois la nouvelle valeur de contexte, sans savoir si
elle a changé ou non. C’est au Context Manager de détecter les changements et de prendre

78
 Chapitre 6. Un cadre flexible pour des applications sensibles au contexte

les décisions nécessaires par la suite, notamment de prévenir le gestionnaire d’exécution. Le

Context Manager est fournisseur d’un service, il permet aux autres modules de la plateforme
de s’abonner pour des notifications de changement de contexte. Tout module qui souhaite
être notifié, doit préciser l’élément de contexte qui l’intéresse.

6.2.3 Le gestionnaire d’exécution : Execution Manager

Nous avons remarqué que l’exécution des services doit être gérée par un module externe
aux applications. Nous proposons donc l’utilisation du module appelé Execution Manager
pour gérer les aspects liés au cycle de vie des services sur la plateforme CATS. Son but
est d’assurer un bon fonctionnement de l’ensemble des applications ainsi que de gérer
leur assemblage. Ce module peut intervenir dans le fonctionnement des services pour les
arrêter ou les démarrer si nécessaire. Pour pouvoir gérer de manière efficace les services, le
gestionnaire d’exécution doit connaître :

– Les applications et les services. L’Execution Manager doit connaître les assemblages
nécessaires pour construire chaque application. Il doit savoir quelles sont les dépen-
dances entre les producteurs et consommateurs de services afin de satisfaire tous les
consommateurs.
– Les dépendances de contexte. Étant donné qu’une partie des services peut être
sensibles au contexte, l’Execution Manager se doit de savoir quand il faut utiliser une
version ou une autre d’un service. Pour cela, il doit savoir quels sont les éléments de
contexte qui influent sur un service et s’abonner auprès du Context Manager pour le
suivi de ces CE.

Les attributions de l’Execution Manager incluent le suivi des états des services et la
gestion de leur exécution. Plus précisément, l’Execution Manager doit :
– Gérer l’adaptation au contexte. Au moment où le contexte change, c’est l’Execution
Manager qui opère l’adaptation. Il doit arrêter les services qui ne sont plus adéquats et
démarrer ceux qui fonctionnent correctement dans les nouvelles conditions de contexte.
– Détecter des incohérences de fonctionnement. Le gestionnaire doit veiller sur l’exécution
des services et détecter les anomalies. Par exemple, si un service s’arrête sans raison,
il doit être remplacé par un service équivalent. Une autre anomalie peut se produire
au moment de l’adaptation, si le service requis par la situation courante n’est pas
disponible sur le terminal. Dans ce cas, l’Execution Manager fait appel au Trader pour
récupérer le service ailleurs (à partir des entités à proximité ou d’un registre web).

Nous représentons l’Execution Manager dans la figure 6.6. Dans cet exemple nous
supposons que le gestionnaire vient d’être informé par le Context Manager du changement
de la valeur d’un élément de contexte. Deux services, S et T , dépendent du CE qui vient
de changer. L’Execution Manager démarre les bonnes versions, ici S(1) et T (2), qui ont été
conçues pour fonctionner dans la situation courante de contexte. Toutes les autres versions
sont arrêtées car elles ne sont pas utiles dans ce cas.
Afin d’accomplir ses tâches, le gestionnaire d’exécution accède aux descriptions des
services, que nous avons présentées dans le paragraphe 6.1.3 (page 71). L’Execution Manager
connaît ainsi les dépendances de contexte et gère les arrêts et démarrages des services en
fonction des notifications du gestionnaire de contexte.

79
6.2. Une plateforme d’exécution

Execution
Context Trader
Manager :
Manager
• état des services

Service S(1)
Service S(2) ServiceService
T(1) T(2)
Service S(3)

Figure 6.6 – L’Execution Manager

6.2.4 Le courtier : Trader

Le troisième module que nous proposons pour la plateforme CATS est appelé Trader.
Son rôle est de rechercher et récupérer des services à partir d’autres terminaux. Notre
objectif est de proposer une solution efficace pour des utilisateurs fortement mobiles. Ces
personnes se trouvent souvent dans de nouveaux endroits, qui leur proposent des services
spécifiques (parking, bus, etc.). Pour servir au mieux l’utilisateur, nous avons choisi d’utiliser
un courtier afin que la plateforme puisse intégrer de nouvelles fonctionnalités.
En plus des services spécifiques à certains lieux, les terminaux peuvent aussi s’échanger
des services entre eux. En effet, pour des véhicules impliqués dans le trafic, cela pourrait
s’avérer intéressant d’échanger entre eux des services plutôt qu’accéder à une infrastructure.
Le Trader de chaque terminal peut communiquer en mode ad hoc, permettant un accès
plus rapide aux services que la plateforme ne possède pas. L’utilisation des services et d’un
Trader capable de communiquer en mode ad hoc présentent de multiples avantages. Parmi
les plus importants nous notons :

– L’adaptation dans des situations imprévues à la conception de l’application. Toutes

les situations ne peuvent pas être traitées dès la conception d’une application. Par
exemple, une application qui inclut la recherche de places libres de parking ne peut
pas prendre en considération tous les parkings. En revanche, des versions du service
peuvent être développées ultérieurement et téléchargées grâce au Trader.

– Un ensemble d’applications plus léger. L’utilisation du Trader peut se faire de manière

à alléger l’ensemble des applications. Des services peuvent être téléchargés seulement
quand ils sont nécessaires et effacés du terminal quand ils ne sont plus utiles. Par
exemple, une personne, qui voyage à l’international et passe quelques heures dans
différents aéroports ou gares, peut profiter des services associés à ces endroits
uniquement durant la courte période où elle en a besoin.

Nous illustrons le Trader dans la figure 6.7. Dans cet exemple, le module est appelé par
l’Execution Manager pour retrouver un service dont une application a besoin pour adapter
son fonctionnement au contexte. Le Trader doit chercher le service en se basant sur son
interface (ici T ) mais aussi sur des contraintes imposées par le contexte. Par exemple, il
faut trouver le service T qui fonctionne pour la valeur vk de l’élément de contexte C E i .

80
 Chapitre 6. Un cadre flexible pour des applications sensibles au contexte

Execution
Trader Service T(2)
Manager

ServiceService
T(1) T(3)

Figure 6.7 – Le Trader

Fonctionnement du Trader

Le Trader comporte deux modes de fonctionnement, dépendant de la disponibilité d’une

infrastructure. Si le terminal a accès à une infrastructure, le courtier préférera cette connexion
car il y a plus de chances de trouver le meilleur service (supposant qu’il existe un dépôt 6
fiable). Nous nous concentrons sur la partie ad hoc du Trader, car nous la considérons
intéressante et pas assez étudiée par rapport au fonctionnement basé sur une infrastructure.
En effet, il existe beaucoup de situations dans lesquelles une infrastructure n’est pas
disponible. En général, une personne qui voyage à l’étranger (en voiture, avion, . . . ) ne
dispose plus de son forfait données, car l’itinérance est très chère. Par contre, les gares
et aéroports peuvent fournir un accès Wi-Fi et des services. De la même façon, d’autres
terminaux mobiles peuvent proposer des services. Le rôle du Trader consiste donc à récupérer
des services, mais en même temps à fournir les services du terminal aux autres entités à
proximité.
Concernant le fonctionnement du courtier avec un réseau ad hoc, nous envisageons deux
modes de fonctionnement. Le premier consiste à chercher des services manquants sur la
demande du gestionnaire d’exécution. Le Trader fournit un service permettant à l’Execution
Manager de l’appeler pour demander la recherche d’une version spécifique d’un service.
Le Trader doit formuler des requêtes en se basant sur la description du service dont il a
besoin. Il doit inclure des préférences ou des « interdictions » en fonction de l’état courant
du contexte. Les préférences peuvent indiquer une version précise du service demandé ou
bien un critère de performance. Ce que l’on a appelé des interdictions exprime en général la
cause d’arrêt d’un service en fonction du contexte. Par exemple, si le service de localisation
est arrêté quand l’utilisateur entre dans un bâtiment, la cause est que le signal GNSS n’est
plus accessible. Le courtier cherchera alors tout service de localisation sauf ceux dépendants
de GNSS. Etant donné que l’échange de services en ad hoc se base sur un partage entre
les terminaux, chaque Trader doit remplir les deux rôles : client et serveur. Ainsi, une partie
du courtier reste à l’écoute des demandes provenant des entités à proximité.
Le deuxième mode de fonctionnement du courtier en ad hoc consiste à écouter les
annonces des entités qui ont une autorité locale. Ces entités peuvent être les terminaux
embarqués dans les différents moyens de transports ou les serveurs spécifiques à un endroit
(aéroport, gare, parking, etc.). Ce fonctionnement n’est pas encore finalisé mais reste dans
nos perspectives. L’idée principale consiste à détecter la présence de l’utilisateur dans un
endroit spécifique et lui proposer de découvrir les services liés à cet endroit.

6. En anglais : Repository.

81
6.3. Conclusions

6.2.5 Fonctionnement de la plateforme CATS

La plateforme CATS est formée par les modules de gestion, Context Manager, Execution
Manager et Trader, par les Context Monitors et par l’ensemble des applications sensibles au
contexte créées pour notre plateforme. Nous notons que les modules de gestion sont conçus
à base de services, de la même façon que les applications. De cette façon, nos modules
de gestion sont facilement mis à jour et peuvent, eux aussi, être sensibles au contexte.
Le courtier peut ainsi passer du mode ad hoc au mode infrastructure en fonction de la
disponibilité d’une infrastructure.
Au démarrage de la plateforme CATS, les trois modules de gestion sont également
lancés. Par la suite, l’utilisateur choisit de démarrer les applications dont il veut se servir.
L’Execution Manager et le Context Manager veillent à ce que les bons services soient
connectés en fonction de l’état du contexte. Dans une évolution future de notre plateforme,
nous envisageons d’intégrer des préférences de l’utilisateur pour démarrer dès le début
certaines applications.

6.3 Conclusions

Nous avons présenté notre approche pour des applications sensibles au contexte et
dédiées aux transports, de la conception des applications jusqu’à leur exécution. Nous
proposons d’utiliser des services dépendants du contexte, c’est-à-dire qui sont créés pour
fonctionner dans des conditions spécifiques. Cela nous permet d’un côté d’adapter les
applications à travers des services équivalents et d’un autre côté de démarrer ou d’arrêter
certaines fonctionnalités en fonction de l’état du contexte.
Nous proposons l’utilisation d’une plateforme d’exécution et de gestion pour des ap-
plications à base de services. Cela comporte plusieurs avantages, dont le partage de
fonctionnalités entre les services et la gestion commune du contexte. Un service partagé
par plusieurs applications permet d’alléger l’ensemble des applications, et d’éviter que le
code ne soit répété dans chacune d’entre elles. Les applications sont également allégées
par la gestion externe du contexte. L’Execution Manager est le seul à gérer les arrêts et
démarrages des services pour que les applications ne soient pas encombrées avec cela.
Notre Trader permet d’enrichir les applications, en téléchargeant de nouveaux services ou
des versions de services nécessaires pour une adaptation.
Dans la suite de ce manuscrit, nous présentons la mise en œuvre de nos propositions
grâce aux technologies actuelles. Nous allons montrer qu’il est possible de changer le
comportement d’une application afin de l’adapter aux changements de contexte sans avoir
besoin de l’arrêter.

82
 Troisième partie

Prototypage et Evaluations

83
Chapitre 7

Mise en œuvre de la plateforme CATS

Dans les chapitres précédents, nous avons présenté nos contributions sans
nous soucier de la technologie à utiliser. Il est temps de présenter nos
choix techniques et le matériel utilisé pour la création du prototype. Nous
allons montrer que OSGi et iPOJO sont des technologies qui se prêtent
bien à la création d’applications modulaires et adaptables dynamiquement.
Le système d’exploitation Android est un bon hôte pour notre plateforme
d’exécution et de gestion, CATS.

7.1 Technologies et matériel

Lors de la création des applications sensibles au contexte, l’un des plus grands défis
consiste à adapter de manière dynamique le comportement des applications. La plupart des
systèmes ne permettent pas de modifier une application sans nécessiter son redémarrage,
un processus trop long pour des applications dédiées aux transports. En effet, un utilisateur
mobile change souvent de contexte et a besoin d’applications capables de réagir à leur
environnement. Nous avons proposé une solution qui consiste à créer des applications par
assemblage de services. Cela constitue un premier pas vers des applications flexibles grâce
au couplage lâche entre les fournisseurs et les consommateurs de services.
Dans ce chapitre, nous présentons d’abord les technologies que nous avons choisies pour
la mise en œuvre du prototype CATS. Le mécanisme d’adaptation que nous avons proposé
consiste à remplacer un service par un équivalent, afin de modifier le comportement de
l’application en concordance avec le contexte. Nous nous intéressons donc aux technologies
qui permettent la reconfiguration des applications pendant leur exécution, sans nécessiter
un redémarrage. La création du prototype comprend plusieurs objectifs. Un premier consiste
à tester la faisabilité de notre solution avec les technologies disponibles, telles que OSGi
et iPOJO. Un deuxième objectif consiste à évaluer les performances du prototype sur les
terminaux du marché. Un autre objectif consiste à tester plusieurs scénarios afin d’optimiser

85
7.1. Technologies et matériel

la solution proposée.

7.1.1 OSGi – une couche de modularité pour Java

Nous avons constaté durant ce travail de thèse que le concept de modularité est
essentiel pour des applications dynamiques et flexibles. Nous nous sommes donc intéressés
aux technologies qui facilitent ce type de développement. Nous avons choisi la plateforme
OSGi qui, d’après l’ouvrage « OSGi in Action » par Hall et al. [HPMS10], permet de créer une
couche de modularité pour la plateforme Java. Les auteurs considèrent que la division du code
en parties logiques simplifie le développement ainsi que la maintenance des applications.
OSGi propose une manière de concevoir les applications et offre des capacités de gestion
du cycle de vie des modules et des services.

Un peu d’histoire

L’Alliance OSGi 1 est une organisation à but non lucratif fondée en mars 1999, et compte
à présent plusieurs entreprises internationales parmi ses membres. L’alliance a pour but de
créer des spécifications open source pour l’assemblage modulaire des logiciels basés sur la
technologie Java. Elle se charge de maintenir et publier les spécifications de la plateforme,
ainsi que de certifier les implémentations qui en sont faites. En 2000, l’Alliance OSGi a
publié la première version de la spécification, R1. Depuis, quatre autres spécifications ont
été publiées, avec la plus récente, R5, en 2012. La quatrième version, Release 4 – Core
Specification, qui a été publiée en octobre 2005, a eu la plus longue durée de vie.
Le nom OSGi était au début un acronyme pour « Open Service Gateway Initiative »,
reflétant l’objectif de l’alliance : fournir une passerelle informatique pour des maisons
intelligentes, intégrant divers terminaux embarqués. Au cours du temps, les objectifs de
OSGi se sont étendus et multipliés, et depuis la troisième version de la spécification, le
nom OSGi n’est plus considéré comme acronyme. De nos jours, les domaines d’application
de cette technologie comprennent entre autres : les téléphones mobiles, les automobiles,
l’automatique industrielle, le grid computing et des serveurs d’applications.

OSGi Service Platform

« OSGi Service Platform » est un standard industriel défini par l’alliance OSGi pour
aborder le manque de modularité en Java. La plateforme de services OSGi introduit un
nouveau modèle de programmation orientée service, appelé parfois SOA dans une VM 2 .
L’alliance a promu la programmation orientée services, même avant que le concept SOA soit
populaire [HPMS10].
La plateforme de services est composée de deux parties : la plateforme OSGi et les services
standards. La plateforme OSGi représente l’environnement d’exécution des applications
et doit être conforme aux spécifications de l’alliance. L’implémentation est laissée aux
usagers, ce qui a conduit à l’existence de plusieurs versions certifiées pour chaque version de
spécification. Par exemple, pour R4 (V4.2) il existe plusieurs implémentations propriétaires
et open source : Makewave Knopflerfish Pro 3, ProSyst Software mBedded Server 7, Hitachi
Solutions SuperJ Engine Framework V4, Apache Felix Framework 3.0.0.
1. OSGi Alliance, http ://www.osgi.org
2. VM de l’anglais Virtual Machine

86
 Chapitre 7. Mise en œuvre de la plateforme CATS

Les services standards définissent une API réutilisable pour des tâches habituelles telles
que la journalisation ou les préférences. Les implémentations sont mises à disposition par
les mêmes acteurs qui fournissent la plateforme. Du point de vue conceptuel, la plateforme
OSGi se divise en trois niveaux : module, cycle de vie et service.
Module layer Cette couche définit les modules, qui sont appelés « bundle » et qui sont
représentés par des fichiers JAR. Un bundle contient les fichiers .class, les ressources
associées au code et des métadonnées. En principe, un bundle contient un module
logique et non pas une application entière. Par rapport à un JAR habituel, un bundle
spécifie les packages qui sont visibles à l’extérieur (exportés) ainsi que ceux dont il
dépend (qui sont importés).
Lifecycle layer Cette couche définit le cycle de vie des bundles, comprenant leur installation
sur la plateforme et leur gestion. En dehors de l’application, les actions gérées par la
plateforme sont : l’installation, la mise à jour, le démarrage, l’arrêt et la desinstallation
des bundles. Du point de vue d’un bundle, la couche cycle de vie gère sa relation
avec le contexte d’exécution. La figure 7.1 illustre les actions que la plateforme OSGi
réalise, ainsi que les états successifs des bundles.
Service layer La couche des services représente le support pour un modèle de program-
mation flexible, à base de services. Les plus importantes actions de cette couche
sont : la publication des services dans un registre ; la découverte de services par les
consommateurs ; le couplage entre les bundles fournisseurs et consommateurs. Le
développement se fait à base d’interface, assurant la séparation entre l’interface et
l’implémentation.

installation
mise à jour
INSTALLED
résolution

mise à

ge STARTING
jour

m arra
dé
désinstallation

RESOLVED ACTIVE
arrêt
STOPPING

UNINSTALLED

Figure 7.1 – Le cycle de vie d’un bundle OSGi.

La figure 7.1 représente le cycle de vie de bundles OSGi. Le premier état par lequel un
bundle passe est « installé » (nommé INSTALLED), quand le code vient d’être installé, mais
avant que les dépendances soit résolues. La plateforme vérifie ensuite les dépendances et
si tous les packages importés sont disponibles le bundle passe à l’état « résolu » (nommé
RESOLVED). Pour démarrer ou arrêter les applications il faut démarrer ou arrêter les
bundles qui les composent, grâce aux méthodes start() et stop(). Les bundles passent
alors par les états « en démarrage » (nommé STARTING), « actif » (nommé ACTIVE) et « en
arrêt » (nommé STOPPING). Enfin, le module peut être desinstallé de la plateforme. Dans
ce cas, il passe dans l’état « désinstallé » (nommé UNINSTALLED).
La conception d’une application modulaire avec OSGi doit suivre les étapes suivantes.
Premièrement, l’application doit être divisée en fonction de modules logiques et de services.

87
7.1. Technologies et matériel

La communication entre les modules se fait à travers les services, il faut donc spécifier
leurs interfaces. Les différents fournisseurs et consommateurs doivent être développés et
encapsulés dans des fichiers JAR différents, en ajoutant les métadonnées nécessaires pour
construire un bundle OSGi. Enfin, la plateforme peut être démarrée, les bundles installés et
démarrés. Si tous les bundles d’une application sont ACTIVE, les consommateurs de services
peuvent interroger le registre pour découvrir les fournisseurs dont ils ont besoin.

Les avantages et les inconvénients d’OSGi

Richard S. Hall résume les avantages mais aussi les inconvénients de la plateforme de
services OSGi lors d’une présentation 3 . OSGi est une plateforme orientée composants qui
permet le partage de packages, l’utilisation de versions et la gestion du cycle de vie. En
plus de la modularité, OSGi permet la création d’architectures orientées services, avec le
mécanisme de publication, découverte et couplage. La figure 7.2 illustre deux bundles, A et
B. Le premier expose un package et fournit un service, pendant que le deuxième demande
le package et consomme le service. La plateforme OSGi assure de manière automatique la
résolution des dépendances au niveau du package. Cela permet de vérifier la cohérence du
code avant de démarrer les applications.

fournit service consomme service

résolution manuelle des services

Bundle A

Bundle B

résolution automatique des packages

exportation package importation package

Figure 7.2 – Exemple de bundles OSGi et leurs dépendances.

Un des avantages de la plateforme OSGi est de permettre d’écrire du code bien structuré,
en respectant le principe de séparation entre l’interface et l’implémentation. De plus, un
code divisé en modules est plus facilement remplaçable, mis à jour, ou réutilisable. OSGi
permet aussi de créer du code dynamique, grâce aux couplages lâches et aux connexions
tardives 4 . Cela ouvre la possibilité de gérer les modules à l’exécution et de reconfigurer les
applications sans les redémarrer. Un autre avantage d’OSGi est la flexibilité des architectures
des applications. Une application est composée des bundles présents sur la plateforme et
peut être adaptée au différents terminaux en fonction des ressources disponibles. Ainsi, pour
les terminaux avec peu de ressources on peut omettre les services facultatifs pour alléger
les applications.
En revanche, la plateforme de services OSGi comporte quelques inconvénients. La
façon de penser les applications n’est pas habituelle. Les services peuvent apparaître et
disparaître à tout moment, ce qui pose des problèmes pour certaines applications quand
elles se retrouvent sans aucun fournisseur pour un service. Cette situation doit être prévue
3. Présentation chez Akquinet en 2007, téléchargeable sur le site http ://felix.apache.org/
4. En anglais : Late binding.

88
 Chapitre 7. Mise en œuvre de la plateforme CATS

à la conception de l’application. Malgré la résolution automatique des dépendances de

packages par la plateforme OSGi, le couplage de services se fait manuellement. Cette action
est généralement accomplie au démarrage du bundle, ou durant l’exécution si l’on utilise
des Trackers. Si l’on veut faire des configurations au démarrage du bundle, on doit inclure
le code dans une classe spécifique, qui implémente BundleActivator. Grace à cette classe,
le développeur peut contrôler les actions effectuées au démarrage (la méthode start())
et à l’arrêt du bundle (la méthode stop()) : des initialisations, la recherche de service, la
finalisation des actions, la sauvegarde de l’état, etc.
Un des plus grands désavantages d’OSGi est que l’on doit ajouter du code spécifique
en plus des fonctionnalités des applications. L’avantage d’ajouter des services pendant
l’exécution sans arrêter l’application engage aussi un désavantage : nous devons ajouter du
code pour suivre les apparitions et disparitions de services. Une partie des inconvénients
d’OSGi sont résolus grâce aux plateformes telles que iPOJO, Declarative Services ou encore
Spring-OSGi. Nous avons choisi iPOJO pour le prototype de notre plateforme.

7.1.2 iPOJO – un gestionnaire de composants orientés services

iPOJO 5 , un projet Apache Felix, fournit un modèle de composants orientés service.

L’objectif d’iPOJO est de simplifier le développement des applications OSGi en séparant les
préoccupations non-fonctionnelles du code. La première version de iPOJO, 1.0.0, est sortie
en octobre 2008 et la plus récente version à présent, 1.8.2, est sortie en mai 2012.
Le concept de ce modèle à composants se base sur les POJOs (Plain Old Java Object), des
classes Java simples, sans dépendance externe. Les dépendances sont injectées au moment
de l’exécution (d’où le i de iPOJO). Pour pouvoir utiliser les POJOs dans l’environnement
OSGi, le code est encapsulé dans un conteneur qui gère les interactions avec l’extérieur.
Toutes les actions sont réalisées à l’aide de modules appelés handlers, dont chacun gère un
aspect non fonctionnel de la composant (initialisation, recherche et connexion de services,
etc.). La figure 7.3 illustre un bundle iPOJO dans son conteneur et avec des handlers.

Handler
Conteneur
Handler

Handler

POJO

Handler

Figure 7.3 – Un bundle OSGi avec iPOJO.

Les principaux concepts d’iPOJO

Un important avantage d’iPOJO est de pouvoir développer les classes « normalement »,

c’est-à-dire sans se soucier de la gestion des fournisseurs et des consommateurs de services

5. Apache Felix iPOJO, http ://felix.apache.org/site/apache-felix-ipojo.html

89
7.1. Technologies et matériel

dans le code, ni des apparitions et des disparitions de services pendant l’exécution. Néan-
moins, les informations spécifiques à OSGi et iPOJO doivent être attachées au composant.
Un fichier .bnd contient les informations du bundle (les packages importés/exportés, etc.).
Des informations supplémentaires sont nécessaires pour que iPOJO automatise la résolution
des dépendances de services et l’injection de code. Les métadonnées iPOJO peuvent être
placées dans un fichier XML ou exprimées grâce à des annotations directement dans le
code.
Pour la création des applications à composants avec iPOJO il faut connaître les deux
concepts de base, le type de composant et l’instance de composant.
Le type de composant (Component type) Le type de composant définit les informations
générales telles que la classe d’implémentation, les services exposés, les services
requis, etc. pour un module. Le type de composant spécifie la politique de création et
la configuration du conteneur iPOJO (les handlers qui sont connectés).
L’instance de composant (Component instance) Une instance hérite des caractéristiques
du type de composant mais possède un nom unique et peut avoir une configuration
propre (ensemble <clef, valeur>). Pour un même type on peut créer plusieurs ins-
tances. Chaque instance possède un conteneur composé par l’InstanceManager qui
encapsule le POJO et par les instances des handlers connectés.

Les handlers

Le modèle à composants iPOJO utilise un handler pour gérer chaque aspect non-
fonctionnel lié à une application. Les handlers iPOJO sont des composants héritant de
la classe abstraite PrimitiveHandler. Ils peuvent interagir avec le POJO et le conteneur
auquel ils sont associés, mais aussi avec ce qui est à l’extérieur (d’autres composants,
services, bundles, le framework OSGi, etc.). iPOJO contient 6 handlers dans son noyau
et les utilise pour la gestion des fonctionnalités suivantes : service providing – fournir
des services, service dependencies – les dépendances de services, lifecycle callbacks –
les fonctions de rappel du cycle de vie, lifecycle controller – les controlleurs de cycle de
vie, instance dynamic reconfiguration – les reconfigurations dynamiques des instances,
component instance architecture – l’architecture des instances de composant. À l’exécution,
les instances des handlers sont connectées à chaque instance de composant. Grâce à ce
fonctionnement, les conteneurs sont flexibles et moins encombrés. En effet, seuls les handlers
nécessaires sont instanciés et attachés à un composant.

Tous les handlers sont valides

INVALID VALID

Un (ou plusieurs) handler(s) ne sont plus valides

Figure 7.4 – Le cycle de vie d’une instance de composant iPOJO.

Les instances de composants iPOJO ont un cycle de vie simple avec deux états, « valide »
(nommé VALID) et « invalide » (nommé INVALID), comme illustré par la figure 7.4. Une
instance est valide si toutes les conditions sont réunies pour qu’elle puisse fonctionner
correctement. Par exemple si l’instance consomme un service, ce dernier doit être disponible

90
 Chapitre 7. Mise en œuvre de la plateforme CATS

sur la plateforme pour que l’instance soit dans l’état VALID. L’état d’un composant dépend de
tous les handlers qui lui sont attachés : l’instance est valide seulement si tous les handlers
sont valides. Pour contrôler des aspects liés au cycle de vie, iPOJO met à disposition
des méthodes dites de callback. Ces méthodes sont liées aux transitions de validation
ou d’invalidation du composant et servent à exécuter du code spécifique quand l’instance
démarre, ou quand elle s’arrête.

iPOJO, un cadre extensible

iPOJO permet l’utilisation d’autres handlers que ceux définis dans le noyau. Ce sont
des handlers externes, identifiés par un espace de noms 6 propre. Les développeurs peuvent
définir des handlers et les déclarer dans la description du type de composant qui les
utilisera. Cela permet d’élargir iPOJO et de personnaliser son comportement. Les avantages
des handlers incluent :
– L’accès aux métadonnées du type de composant avant la création de l’instance. Un
handler peut ainsi faire des configurations ou des vérifications sur la cohérence du
code et même décider de ne pas créer l’instance du POJO dans certaines conditions.
– L’interception de champs du POJO pour connaître leur utilisation, grâce aux méthodes
onGet() et onSet(). Un handler peut ainsi réagir à la lecture ou écriture d’un attribut
et peut intervenir pour modifier la valeur.
– L’interception de méthodes du POJO (avant ou après l’exécution de la méthode, en cas
d’erreur), grâce aux méthodes onEntry(), onExit(), onError() et onFinally().
– Des notifications de changements d’état de l’instance. Les handlers peuvent suivre
l’état de l’instance et même intervenir pour le changer.

Le modèle iPOJO confère un cadre léger qui apporte plusieurs avantages pour les
applications dynamiques. L’injection de code non-fonctionnel à l’exécution et la gestion des
dépendances de services simplifient le développement considérablement. Nous estimons
que le fait de pouvoir ajouter les informations liées à OSGi et iPOJO en dehors du code
représente un important avantage. Cela facilite la réutilisation de modules déjà existants
sans les modifier. La création de handlers personnalisés ouvre des possibilités pour de
nouvelles préoccupations non-fonctionnelles.

7.1.3 Android et OSGi

Nous avons choisi la plateforme OSGi et le modèle à composants iPOJO car ces techno-
logies nous permettent de créer des applications dynamiques. Le fait d’utiliser Java rend
les applications indépendantes de la plateforme d’exécution, tant que la machine virtuelle
Java est disponible. Notre objectif est de créer des applications pour les téléphones mobiles,
donc la question qui se pose est : est-ce que la plateforme OSGi peut fonctionner sur un
terminal aussi limité ? Logiquement, la réponse devrait être oui, car l’objectif initial d’OSGi
visait des terminaux à ressources limitées. Nous avons testé nos propositions sur le système
d’exploitation Android, qui utilise Dalvik, une version de la machine virtuelle Java.
Android est l’un des plus importants systèmes d’exploitation pour téléphone mobile,
ayant plus de 50% de part de marché des smartphones dans le premier quart de 2012 7 . De
6. En anglais : Namespace.
7. Conforme à International Data Corporation (IDC), http ://www.idc.com/

91
7.1. Technologies et matériel

plus, c’est un système d’exploitation libre et open source, moins restrictif à l’installation
des applications que d’autres systèmes sur le marché. Un autre avantage de ce système
d’exploitation est sa pénétration récente dans les véhicules. Les tablettes R-Link que Renault
commence à intégrer dans ses voitures sont basées sur Android 8 .
La programmation sous Android commence par l’extension de la classe Activity, où l’on
peut gérer le cycle de vie de l’application. Dans cette classe il est possible de démarrer
un framework OSGi et les bundles qui s’exécutent dessus. Mise à part la modification des
fichiers JAR pour les rendre compatibles avec la machine virtuelle Dalvik, aucune autre
modification n’est nécessaire pour porter une implémentation de OSGi sur Android. Pour
nos expériences, nous avons choisi la plateforme Felix 3.2.2, une implémentation par Apache,
sortie en mai 2011. La plateforme est certifiée par l’alliance OSGi 9 et se conforme à la
spécification R4.2 de mai 2010. Nous utilisons la version 1.8.0 de iPOJO.

7.1.4 Matériel

En choisissant Android comme plateforme de test, nous couvrons une bonne partie des
terminaux mobiles, smartphones et tablettes compris. La contrepartie du succès d’Android,
mais aussi de sa politique de distribution, est l’hétérogénéité des terminaux. Les différences
varient de la taille et résolution de l’écran jusqu’au type de processeur. Les versions du
système d’exploitation posent aussi des problèmes de compatibilité. Parfois les mises à jour
ne sont pas disponibles pour tous les téléphones car les producteurs ne peuvent gérer tous
leurs modèles, surtout les plus anciens.
Pour toutes ces raisons, nous avons utilisé plusieurs modèles de téléphones et tablettes
dans nos expériences. Les terminaux datent de 2009 à 2011, avec le moins puissant le HTC
Hero (sorti en 2009) et le plus puissant la tablette HTC Flyer (sortie en 2011). Nos objectifs
de test incluent :
– Vérifier la faisabilité de la plateforme CATS en utilisant OSGi et iPOJO sur des
terminaux Android.
– Vérifier la cohérence de la plateforme proposée sur des modèles différents de terminaux.
– Evaluer les performances du mécanisme d’adaptation.
– Analyser les possibilités d’optimisation du temps d’adaptation.
Notre préoccupation n’est pas de réaliser une comparaison entre les terminaux car cela
serait impossible. Néanmoins, les applications pour Android doivent pouvoir s’exécuter sur
tous les terminaux de manière acceptable. Nous nous attendons à voir des améliorations
de performance dans les modèles plus récents, sans que le code ne soit optimisé dans ce
but. La cohérence des applications peut être testée en fonction de la tendance générale de
différentes expériences effectuées. Les caractéristiques de tous les terminaux utilisés sont
détaillées dans la Table 7.1.

7.1.5 Travaux connexes utilisant Android et OSGi

Plusieurs projets ont étudié la possibilité de mettre la plateforme OSGi sur des télé-
phones mobiles Android. Leur réussite certifie la faisabilité de cet exploit. Deux compagnies
internationales, Luminis BV et Akquinet AG, se sont réunies en 2009 pour le projet EZ-

8. Renault lance la tablette R-Link, http ://www.techradar.com/

9. OSGi Certified prooducts, http ://www.osgi.org/Specifications/Certified

92
 Chapitre 7. Mise en œuvre de la plateforme CATS

Terminal Date de sortie Processeur (MHz) RAM (MB) Version Android

HTC Hero juillet 2009 528 288 Android 2.2
Samsung Galaxy 551 aôut 2010 600 256 Android 2.2
(mise à jour) Android 2.3.6
HTC Wildfire S février 2011 600 512 Android 2.3
Sony Ericsson Xperia Ray septembre 2011 1000 512 Android 2.3.4
HTC Flyer (tablette) mai 2011 1500 1024 Android 3.2.1

Table 7.1 – Caractéristiques du matériel de test.

droid 10 . Leur objectif était de faire bénéficier les applications Android des avantages de la
programmation à base de composants et de la plateforme OSGi.
Des travaux de recherche s’intéressent également à la compatibilité d’OSGi avec Android
et aux avantages que ces deux plateformes peuvent apporter à l’informatique mobile. Chen
et al. [CCC11] proposent une plateforme OSGi/Android qui serait intégrée dans les véhicules
afin de les faire profiter de services de la télématique. Kuna et al. [KKB+ 11] présentent
une plateforme basée sur OSGi et Android dont le but est d’acquérir des informations de
contexte à partir de multiples capteurs. Le système proposé peut servir pour surveiller
l’état des applications industrielles et pour des réactions aux événements qui se produisent.
Ces deux travaux trouvent que l’un des avantages de la plateforme OSGi/Android est une
consommation plus basse de mémoire que les applications natives.
La plateforme OSGi comporte plusieurs avantages, parmi lesquelles nous notons la
création de code dynamique. Les spécifications de la plateforme n’incluent pas tous les
services dont les développeurs ont besoin, mais elle permet d’ajouter des extensions. Par
exemple, Frénot et al. [FLMPS11] proposent des extensions de la plateforme OSGi concernant
le management, l’environnement d’exécution (runtime) et la sécurité des bundles.

7.2 CATS – le prototype

Nous avons montré dans les sections précédentes les technologies utilisées pour la
mise en œuvre de notre prototype de recherche pour la plateforme CATS. Dans la suite,
nous nous penchons sur le prototype lui-même. Notre objectif consiste à implémenter la
plateforme CATS ainsi que des applications de test, afin d’évaluer le comportement et les
performances de la solution que nous proposons. Initialement, l’application Android qui sert
d’hôte pour notre plateforme a été créée pour la version 2.2 du système d’exploitation (API
level 8), la plus récente version disponible à ce moment. Ultérieurement la plateforme a été
mise à jour pour utiliser Android 2.3 (API level 10) pour tous les terminaux disposant de la
version 2.3 ou plus.
Nous nous référons à l’application Android pour désigner les classes formant l’application
hôte pour notre plateforme. La plus importante est la classe étendant Activity, qui gère le
cycle de vie de l’application Android et démarre la plateforme OSGi. Nous l’appelons dans
ce manuscrit simplement Activity (par abus de langage). Les objectifs de notre application
Android incluent : démarrer la plateforme OSGi et iPOJO ; démarrer les modules de gestion
CATS ; démarrer les applications qui s’exécutent sur CATS ; fournir un accès en ligne de
commande à la plateforme OSGi ; offrir des capacités de contrôle pour l’exécution des
10. EZdroid open source project, http ://www.ezdroid.com/

93
7.2. CATS – le prototype

expériences.
La plateforme CATS prend donc la forme d’une application Android qui doit être installée
à partir du marché d’applications. La différence par rapport aux applications habituelles
est la simplification de l’ajout de nouvelles fonctionnalités. Grâce au Trader, des nouveaux
services peuvent être téléchargés à partir de terminaux voisins ou de dépôts sur internet.
Avant de pouvoir mettre en pratique notre solution, l’aspect sécurité doit être approfondi.
Dans ce travail de thèse, nous nous sommes focalisés sur la prise en compte et la gestion
du contexte. Par la suite, nous présentons la réalisation de la plateforme CATS et de ses
modules avec OSGi et iPOJO.

7.2.1 Plateforme, applications, services, modules, bundles . . .

Comme nous l’avons expliqué dans le paragraphe 6.1 (page 65), nous proposons la
division des applications par rapport aux fonctionnalités. Les fonctionnalités sont ensuite
exprimées par des services (à travers des interfaces). Pour créer une application comme
assemblage de services, nous devons encapsuler les différentes parties de code dans des
modules. La plateforme d’exécution et de gestion que nous proposons, CATS, est implémentée
au-dessus de Felix, en OSGi. Les modules de gestion qui composent CATS peuvent, eux
aussi, profiter des avantages de la technologie OSGi pour être plus flexibles et dynamiques.
Nous résumons ici les termes utilisés et leurs relations :
– La plateforme CATS = Felix + iPOJO + Modules de gestion (Context Manager,
Execution Manager, Trader)
– Une application = Σ services
– Un service est défini par son interface.
– Un module est une unité logique qui remplit une fonctionnalité. Un module peut être
constitué de l’implémentation d’un service ou bien de code qui utilise un ou plusieurs
services.
– Un bundle est un module dans la plateforme OSGi.

La spécification OSGi nous permet de réaliser les applications de la manière dont

nous les avons définie dans la proposition (paragraphe 6, page 65). Les modules logiques
deviennent des modules logiciels encapsulés dans les bundles. Grâce à iPOJO, nous avons
développé les modules en considérant seulement la structure logique de l’application. Nous
avons décidé de mettre les métadonnées dans des fichiers XML afin de garder le code
libre de toute information iPOJO. OSGi (et donc iPOJO également) permet de spécifier les
fournisseurs et consommateurs de services. Dans notre cas, nous avons utilisé des tags :
<provides/> pour les fournisseurs et <requires field=“...”/> pour les consommateurs, en
mentionnant le champ (le service) dont ils ont besoin.
Nous avons enrichi les métadonnées avec les informations liées à la plateforme CATS,
pour la gestion du contexte. Pour un fournisseur dépendant du contexte, les informations
sont celles décrites dans la Table 6.2 (page 72), Dépendances : l’élément de contexte qui
influe sur l’exécution du service et la valeur pour laquelle cette implémentation est conçue.
La figure 7.5 présente quelques captures d’écran de notre prototype pour la plateforme
CATS et un exemple d’application, VESPA. La figure 7.5(a) illustre notre vue pour le
déboggage, qui permet également d’accéder au terminal OSGi. Le deuxième onglet, présenté
dans la figure 7.5(b), contient une liste de services et d’applications. Nous observons l’icône
carrée rouge à côté de VESPA, indiquant que l’application est démarrée et qu’elle peut être

94
 Chapitre 7. Mise en œuvre de la plateforme CATS

(a) Vue de déboggage (b) Applications et services (c) Exemple d’application : VESPA

Figure 7.5 – La plateforme CATS – prototype

arrêtée. Nous pouvons aussi observer le menu de l’application hôte. La figure 7.5(c) illustre
notre adaptation de l’interface graphique de l’application.
VESPA, présenté dans le travail de Cenerario et al. [Cen10, CDI11], est un système
conçu pour le partage d’informations entre véhicules en exploitant les réseaux ad hoc. Les
informations partagées concernent des événements du trafic tels que des accidents, des
embouteillages, des véhicules d’urgence, des places disponibles de parking, etc. Pour une
partie de ces informations, les événements qui concernent tous les participants au trafic,
VESPA emploie la dissémination. Le service de parking par contre doit être considéré
différemment, car il dépend du contexte. En effet, nous avons vu au début de ce manuscrit
que les places libres de parking peuvent être disséminées à tous les véhicules, ou allouées
à un véhicule spécifique à travers un algorithme de réservation. Nous avons implémenté une
version de VESPA à base de services, permettant ainsi d’interchanger plusieurs services
de parking. Les différentes versions du service, que nous avons vu dans l’exemple de Jean
(paragraphe 4.2.2, page 38), peuvent être ajoutées dans cette implémentation. L’utilisateur
ne voit que la partie de l’application lui permettant d’annoncer la libération de sa place de
parking ou d’en chercher une. La gestion de la version du service utilisée est faite par la
plateforme en fonction du nombre de participants au trafic et de la détection du serveur du
parking.

7.2.2 Implémentation des modules de la plateforme CATS

Comme nous l’avons déjà mentionné, les modules de gestion de la plateforme CATS
sont implémentés à l’aide de bundles OSGi, pour profiter de la même flexibilité que les
applications. En effet, cette façon de faire nous permet d’ajouter ou retirer des Context
Monitors en fonction du besoin, ou encore de faire un Trader dépendant du contexte, avec
un comportement différent quand l’accès à une infrastructure n’est pas disponible. Dans la

95
7.2. CATS – le prototype

suite nous allons présenter les détails de l’implémentation de notre plateforme.

Le Context Manager

La mise en œuvre du Context Manager correspond au schéma illustré dans la figure 6.5
(page 78) : un module principal (intitulé Context Manager dans la figure), des Context
Monitors et un module dédié aux profils du terminal et de l’utilisateur. D’un point de
vue logique, tout l’ensemble représente le Context Manager, et non seulement le module
principal. Le module principal est le seul à devoir s’exécuter en permanence, les autres étant
optionnels, démarrés uniquement s’ils sont nécessaires. Néanmoins, le Context Manager ne
sera pas utile si aucun élément de contexte n’est suivi par des Monitors.
Un Context Monitor dans CATS fait des évaluations périodiques de l’élément de contexte
qu’il suit, avec une fréquence donnée. Il ne vérifie pas le changement de valeur dans
l’implémentation actuelle, mais pourrait le faire sans problème si nous le jugeons nécessaire.
Les évolutions possibles incluent l’évaluation à la demande, déclenchée donc par la Context
Manager ainsi que la configuration du paramètre fréquence d’évaluation. Le Context Monitor
pourrait ainsi s’adapter lui aussi au contexte, notamment en fonction de la fréquence de
changement de l’élément suivi.
Pour relier le Context Manager au Execution Manager, nous avons mis en place un service
de type publish/subscribe. Ainsi, tout module intéressé par un élément de contexte peut
s’abonner au Context Manager, en spécifiant le nom (et le type) de l’élément. En l’occurrence,
dans le prototype de CATS, c’est l’Execution Manager qui s’abonne pour connaître l’évolution
de plusieurs CE, en fonction des services qui sont en train de s’exécuter sur la plateforme. Le
Context Manager se charge de détecter tous les changements et de les notifier aux modules
intéressés. Par la suite, d’autres applications pourraient s’abonner directement pour être
notifiées des changements des éléments de contexte qui les intéressent.

Liste CE −→ Liste de services abonnés

Figure 7.6 – Structures de données du Context Manager.

Le Context Manager contient une liste de tous les éléments de contexte suivis par les
Context Monitors, comme illustré dans la figure 7.6. Pour chaque C E i dans la liste, un ou
plusieurs modules peuvent s’abonner afin d’être notifiés des changements. À son tour, le
Context Manager est notifié par chaque Context Monitor, quand ce dernier met à jour la
valeur de l’élément suivi. Le Context Manager vérifie si la valeur vient de changer, afin de
notifier les abonnés.

L’Execution Manager

L’Execution Manager, responsable de l’exécution de services, connait toutes les infor-

mations nécessaires pour leur gestion. L’Execution Manager se charge de deux missions :
l’adaptation à travers les services dépendant du contexte (CDS) et la détection de dé-
faillances. Il est nécessaire d’organiser les informations de manière à réagir vite en cas
de changement de contexte. Nous illustrons dans la figure 7.7 les structures de données
utilisées pour l’adaptation au contexte.
Nous regroupons les services en fonction des éléments de contexte dont ils dépendent,

96
 Chapitre 7. Mise en œuvre de la plateforme CATS

Liste CE −→ Liste services CDS −→ Liste versions CDS

Figure 7.7 – Structures de données de l’Execution Manager.

pour réagir au plus vite aux changements. Pour chaque élément C E i , nous gardons une
référence à la liste de services dépendants C DS ij associés. Pour chaque service C DS ij
nous considérons la liste de versions spécifiques aux valeurs possibles de C E i . De cette
façon, au moment où l’élément i change de valeur, l’Execution Manager peut gérer l’arrêt et
le démarrage des versions C DS ij .
Pour pouvoir être notifié de changements, l’Execution Manager implémente l’interface
CIService (Context Interested Service), fournissant la méthode de notification. Le gestionnaire
d’exécution s’enregistre auprès du gestionnaire de contexte, pour chaque élément de contexte
qui l’intéresse. Au moment d’une notification, l’Execution Manager traite tous les services
dépendant de l’élément qui vient de changer, en démarrant ceux qui sont conçus pour la
nouvelle situation et en arrêtant ceux qui sont devenus inadaptés.
Parmi ses attributions, l’Execution Manager doit suivre l’exécution des services et des
applications. Il est donc capable de détecter les situations quand une dépendance n’est
pas satisfaite, car aucune implémentation ne correspond au contexte. Si une telle situation
arrive, l’Execution Manager appelle le Trader, avec une description du service à chercher et
les contraintes courantes du contexte.

Le Trader

Le Trader fournit le service Trader pour la recherche de services qui manquent à la

plateforme CATS. En principe, le module devrait se connecter à un réseau ad hoc afin de
partager des services avec les autres terminaux à proximité. Du aux versions d’Android qui
ne supportent pas les réseaux ad hoc, nous avons utilisé un point d’accès.
Le Trader démarre un Thread qui écoute en permanence les requêtes de services des
autres terminaux. Le Thread utilise un server socket qui écoute sur un certain port. Si le
Trader doit chercher un service, il exécute la requête en utilisant le broadcast et attend des
réponses. Le Trader doit choisir le « meilleur » terminal à partir duquel il va télécharger,
en fonction des paramètres tels que la distance ou la qualité de la connexion. Une fois le
fournisseur du service choisi, le reste de la communication est effectuée en unicast.

7.2.3 Des handlers iPOJO pour la plateforme CATS

Les handlers iPOJO permettent d’isoler le code fonctionnel du code non fonctionnel.
Pour attacher un handler à un composant, il suffit d’ajouter simplement l’information dans le
fichier metadata.xml du composant, sans modifier son code. Les applications destinées au
framework CATS ont une architecture à base de services, avec un noyau qui utilise un ou
plusieurs services. Dans le cadre d’OSGi, les services sont encapsulés dans des bundles.
Pour une bonne gestion de l’ensemble des applications, il faut connaître le rôle de chaque
bundle, détecter les pannes et les situations de contexte.

97
7.2. CATS – le prototype

Pour les applications : Application Handler

Ce handler est associé aux noyaux des applications, comme le nom l’indique. Son but est
de gérer les situations spécifiques aux applications. Premièrement, l’utilisateur doit connaître
les applications disponibles dans le framework CATS. Deuxièmement, les changements d’état
des applications doivent être connus et gérés : mise en marche (par l’utilisateur), changement
d’affichage (premier ou arrière plan), ainsi que les situations d’invalidation par manque d’un
service. Un Application Handler est instancié pour chaque noyau d’application. Le handler
relie les informations du module avec l’Execution Manager.

Pour les descriptions des services : Service Description Handler

Ce handler permet de récupérer les informations sur le composant auquel il est attaché
afin de les relayer aux composants de gestion de CATS (notamment au Trader et Execution
Manager). Les services doivent donc compléter leurs métadonnées avec les informations
nécessaires pour leur description. Le Service Description Handler enregistre chaque service
auprès de l’Execution Manager. La figure 7.8 illustre un exemple de métadonnées d’un
service.

<ipojo xmlns:sdh="service.description">
<component classname="componentClassname">
<provides/>
<!-- "serviceName" = name of the implemented interface!! -->
<sdh:servicedescription servicename="serviceName" OS="OSname">
<sdh:context element="name" type="type" min="min" max="max"/>
</sdh:servicedescription>
</component>
</ipojo>

Figure 7.8 – Métadonnées d’un bundle exposant un service.

Le type de composant « componentClassname » est déclaré dans le fichier XML dans

le tag <component>. Le tag <provides/> indique que le composant fournit un service. Le
tag <sdh:servicedescription> est associé au namespace de notre handler et contient la
description du service. Les éléments de cette description sont les suivants :
– Servicename et OS. Les attributs du tag <servicedescription> qui permettent d’iden-
tifier le service et sa plateforme cible.
– <context>. 0, 1 ou plusieurs éléments de contexte qui influencent le fonctionnement
du service. Le service est adapté pour des valeurs de contexte situées entre « min » et
« max ».
Un exemple : <sdh:context element="speed" type="continuous" min="0" max="50">

Pour détecter des anomalies : Service Down Handler

Un handler est nécessaire pour vérifier le bon fonctionnement de chaque service. Ce

handler doit suivre l’état de l’instance pour notifier une éventuelle panne. Un autre rôle
de ce handler est de vérifier le fonctionnement correct des méthodes du composant. La
figure 7.9 présente les métadonnées pour attacher le Service Down Handler, qui doivent

98
 Chapitre 7. Mise en œuvre de la plateforme CATS

être ajoutées à l’intérieur du tag <component> (de la même manière que pour le Service
Description Handler, avec le tag <sdh:servicedescription> dans la figure 7.8).

</sdh:servicedescription>
<down:handler>
<down:method methodName="name" badValue="value"/>
</down:handler>
</component>
</ipojo>
Figure 7.9 – Métadonnées pour déclarer l’utilisation d’un handler.

Le type de composant déclare dans ses métadonnées l’utilisation du Service Down

Handler, en indiquant la méthode qui pourrait mal fonctionner ainsi que la valeur du code
d’erreur. En plus du suivi de l’état de l’instance, le composant peut configurer une ou plusieurs
méthodes à suivre par le handler en indiquant le nom de la méthode ainsi qu’une valeur
considérée fausse (badValue). Ceci nous permet de détecter des situations où le service ne
fonctionne pas correctement, sans pour autant passer à l’état INVALID. Un exemple est le
cas du GNSS qui parfois envoie des réponses avec une très mauvaise précision.

Pour les statistiques : Statistic Handler

Pour les évaluations de l’exécution de notre plateforme, nous avons mis en place un
handler qui gère les statistiques. Le Statistic Handler intercepte l’état du composant auquel
il est attaché, permettant ainsi de mesurer le temps pendant lequel le composant a été
invalide. Ce handler s’avère utile pour évaluer la durée d’adaptation d’une application, en
mesurant l’impact sur un consommateur qui attend que l’échange d’un fournisseur à un autre
soit fini.

7.3 Conclusions

Dans ce chapitre, nous avons présenté les technologies que nous avons employées afin
de mettre en œuvre nos propositions. La plateforme OSGi, combinée au modèle à composants
iPOJO, permet de créer des applications à base de services qui sont reconfigurables pendant
leur exécution. Cela nous permet de réaliser des adaptations dynamiques afin d’assurer un
comportement toujours adéquat aux conditions du contexte.
Grâce au modèle extensible iPOJO, nous pouvons réaliser des modules simples avec une
programmation orientée objets et réutiliser des modules existants. iPOJO injecte le bytecode
non-fonctionnel au moment de l’exécution à travers les handlers. Le système d’exploitation
Android, l’un de plus répandus sur les téléphones, mais également sur les tablettes, est
compatible avec la plateforme OSGi.
Par la suite, nous nous intéressons à l’évaluation de notre plateforme CATS. Nous allons
montrer l’efficacité des adaptations à travers différents scénarios de test.

99
7.3. Conclusions

100
Chapitre 8

Evaluation du prototype CATS

Au fur et à mesure de l’avancement de ce travail, nous avons mis en œuvre

et évalué notre prototype. Premièrement, nous nous sommes intéressés
au portage d’OSGi sur les smartphones Android, aux temps de démarrage
de la plateforme et des bundles, mais aussi aux interactions entre les
bundles et les éléments du smartphone. Par la suite nous nous sommes
intéressés aux adaptations dynamiques en utilisant les avantages d’OSGi
et iPOJO. Nous présentons dans ce chapitre nos différentes évaluations,
qui nous ont permis de valider nos propositions. Les expériences que nous
avons effectuées nous servent également pour guider le développement
futur ainsi que les optimisations de notre plateforme CATS.

8.1 Une plateforme pour des applications modulaires

Le but de notre travail est de fournir une plateforme à embarquer sur des terminaux
mobiles, avec des applications flexibles et modulaires. Nous avons essayé de montrer au long
de ce manuscrit les avantages des applications modulaires. Elles sont mieux configurables en
choisissant les meilleurs modules en fonction de la situation ou des ressources du terminal.
Une application modulaire est également plus facile à mettre à jour en remplaçant seuls les
modules qui changent.
L’objectif de nos premières évaluations a été de tester la mise en œuvre de la solution
que l’on propose, notamment d’exécuter des applications créées par assemblage de services
sur des téléphones mobiles. Nous avons créé la première version de la plateforme CATS sur
Android et les premières versions des bundles qui interagissent avec les modules matériels
du terminal (Wi-Fi, GNSS, les capteurs, etc.). Nous avons mesuré le temps de démarrage de
la plateforme CATS ainsi que le temps de lancement de chaque bundle, sur le téléphone et
l’émulateur.

101
8.1. Une plateforme pour des applications modulaires

8.1.1 Matériel de test et scénario pour les évaluations initiales

Nous avons commencé à effectuer des expérimentations en 2010. Nous avons utilisé des
smartphones disponibles à ce moment, notamment des HTC Hero, dont les caractéristiques
sont décrites dans la Table 7.1 (page 93). Au fil du temps, nous avons profité de nouveaux
matériels disponibles sur le marché pour tester nos propositions.
Pour nos premiers essais, nous avons également utilisé un émulateur configuré pour
Android 2.2, sur un ordinateur Mac Book avec 4GB de mémoire DDR3 et un processeur
Intel core 2 duo à 2,4 GHz. L’émulateur mis à disposition par le SDK d’Android simule les
caractéristiques logicielles et matérielles des téléphones, sans pouvoir passer de vrais appels.
Il permet par contre d’interagir avec les applications à travers une interface graphique avec
des boutons ou même à travers le clavier de l’ordinateur.

Déroulement de l’expérience

Nous avons mis en place neuf bundles qui interagissent avec les différentes fonctionnalités
du terminal. Les fichiers JAR qui les encapsulent varient en taille de 8 à 25 kB et aucune
dépendance envers d’autres bundles n’existe. Les bundles de test sont les suivants (dans
l’ordre croissante de leur taille) :
– Bluetooth. Ce module assure le contrôle du module physique Bluetooth, permettant
de connaître l’état du réseau et les voisins auxquels le terminal peut se connecter.
– Locate. Un module de positionnement utilisant le réseau de téléphonie. Ce bundle
peut fournir une information peu exacte sur l’endroit où le terminal se trouve.
– ShellAO. Ce bundle fait partie du code de débogage. Il met à disposition sur le
téléphone une interface en ligne de commande pour accéder au framework OSGi.
– SoftwareInfo. Ce bundle a pour but de récupérer les caractéristiques des plateformes
logicielles qui sont installées sur le terminal et utilisables par notre plateforme.
– Wi-Fi. Le bundle Wi-Fi assure l’accès au module physique afin de détecter des réseaux
(infrastructure ou ad hoc), se connecter et envoyer des messages.
– CpuInfo. Ce module a pour but de lire les informations liées au processeur.
– Localization. Ce module de positionnement est une version plus complète que Locate,
exploitant le réseau téléphonique ainsi que le GNSS, en fonction de leurs disponibilités.
– Sensors. Le bundle permet l’accès à plusieurs capteurs du terminal, tels que l’accélé-
romètre, les capteurs de luminosité ou de température, etc.
– MemoryInfo. Ce bundle accède aux informations liées à la mémoire du terminal.

Pour tester notre prototype, nous avons lancé la plateforme CATS et les 9 bundles
de test plusieurs fois sur le téléphone et l’émulateur. Nous avons enregistré le temps au
moment du lancement de l’application hôte. L’application hôte démarre la plateforme Felix
embarquée, ensuite elle installe et démarre les bundles un par un. Nous avons enregistré
le temps avant chaque appel à la méthode Bundle.install() (qui permet de manipuler de
manière programmatique les bundles). Grâce à l’interception des événements des bundles,
nous avons pu également enregistrer les moments où les bundles sont passés dans l’état
ACTIVE. Nous considérons la plateforme CATS comme définitivement démarrée au moment
où le dernier bundle devient actif.

102
 Chapitre 8. Evaluation du prototype CATS

8.1.2 Résultats numériques du lancement de CATS et ses modules

Nous avons mesuré le temps total de démarrage de la plateforme CATS, entre le moment
où elle est lancée et le moment où elle est prête pour l’utilisation. Nous avons trouvé
qu’il faut en moyenne 15 secondes pour le démarrage sur le téléphone et 16 secondes sur
l’émulateur. Ces premiers résultats nous ont montré qu’il était envisageable de créer une
plateforme utilisant les technologies OSGi et iPOJO sur des téléphones Android. Par la suite
nous avons amélioré le prototype. D’un côté nous avons optimisé les services standards
embarqués avec Felix en gardant le minimum nécessaire. D’un autre côté, le code a évolué
pour inclure de nouvelles fonctionnalités. De plus les tests ont été effectués sur différents
terminaux. Vue l’hétérogénéité des terminaux et des versions du système d’exploitation,
nous ne pouvons pas donner de résultats génériques pour le démarrage de notre plateforme.
Nous pouvons par contre conclure qu’elle est réalisable sur des téléphones Android.

Temps d'installation & démarrage des bundles

1000
900
800
700
temps (ms)

600
500
400 Téléphone
300
Emulateur
200
100
0
h

te

ifi

fo

fo
or
ot

nf

io
W
lA
ca

In

In
at
to

eI

ns
el

pu

y
Lo

liz

or
ue

ar
Sh

Se
C

em
ftw

ca
Bl

Lo
So

Figure 8.1 – Temps moyen d’installation et démarrage des bundles sur HTC Hero.

Nous présentons dans la figure 8.1 les résultats d’installation et démarrage des bundles
sur le prototype de CATS (en tant que valeur moyenne sur 10 essais). Nous avons observé
que, de manière générale, le téléphone est plus rapide que l’émulateur, sauf pour le bundle
utilisant le Wi-Fi. Nous imputons cette incohérence au fait que le module matériel réagit
plus lentement que dans la simulation, probablement à cause du chargement du pilote. Le
temps de lancement d’un bundle prend entre 0.30 et 0.74 secondes sur le téléphone et entre
0.46 et 0.84 secondes sur l’émulateur. En réalisant ce test, nous avons préparé la suite,
notamment les futures adaptations que la plateforme devra accomplir. Cette évaluation nous
a permis d’estimer le coût de remplacement d’un service par un équivalent, afin d’adapter le
comportement d’une application. Les bundles utilisés ici font partie de la première version
du Context Manager, qui capturait l’état du contexte à un moment donné.

8.1.3 Conclusions des évaluations initiales

Nous avons trouvé ces évaluations initiales satisfaisantes. Elles nous ont montré que la
plateforme Felix est suffisamment légère pour les smartphones existants sur le marché. Nous
avons donc pris confiance dans notre approche consistant à créer des applications à base
de modules, avec une architecture orientée services. Le fait que les modules peuvent être
installés et démarrés en moins d’une seconde nous a encouragé à penser que les adaptations

103
8.2. Des applications capables d’acquérir des nouvelles fonctionnalités

que l’on proposait pouvait se faire suffisamment vite pour ne pas déranger l’utilisateur. Les
résultats de ces évaluations ont été publiés dans Popovici et al. [PDLP11].
Cette première expérience nous a permis aussi d’évaluer l’émulateur, qui ne nous a
pas convaincu. Les performances de l’émulateur sont légèrement inférieures à celles du
téléphone, sans que ce soit très gênant : il est un peu plus long pour démarrer la plateforme
CATS et de manière générale un peu plus long pour chaque bundle comparé. Les vrais
inconvénients sont le temps de lancement de l’émulateur et le fait qu’il soit encombrant
pour l’ordinateur sur lequel il s’exécute. Nous n’avons pas vu un intérêt à continuer d’utiliser
l’émulateur dans les expériences qui ont suivi.
Par la suite, nous nous sommes intéressés au téléchargement de nouvelles fonctionnalités
(nouveaux services), une partie importante de notre solution pour une meilleure expérience
des utilisateurs impliqués dans le transport. Enfin, nous nous sommes préoccupés à étudier
en détails les différentes possibilités que nos technologies nous offrent pour effectuer des
adaptations rapides.

8.2 Des applications capables d’acquérir des nouvelles fonction-

nalités

Une fois ces premiers tests réalisés, nous avons commencé à examiner la possibilité
d’acquérir de nouvelles fonctionnalités grâce à notre plateforme. Nous envisageons deux
situations dans lesquelles l’expérience de l’utilisateur serait considérablement améliorée
par le téléchargement de nouvelles fonctionnalités. La première est quand le contexte
change, rendant un ou plusieurs services inadéquats aux nouvelles conditions d’exécution.
Si aucun module du terminal ne peut remplacer l’ancien, il faut essayer de télécharger un
service compatible avec le nouveau contexte, afin que les applications puissent continuer
à fonctionner. La deuxième situation est quand l’utilisateur arrive dans un nouvel endroit
qui met à disposition des services. L’utilisateur pourrait vouloir profiter de fonctionnalités
spécifiques à l’endroit où il se trouve.

8.2.1 Matériel de test et scénario pour le téléchargement de services

Pour ce deuxième ensemble de tests nous avons gardé le smartphone HTC Hero. Nous
avons renoncé à l’émulateur et nous avons ajouté le téléphone Samsung Galaxy 551 (avec la
version Android 2.2) comme matériel de test. Les objectifs de ces évaluations sont multiples.
Tout d’abord, nous avons voulu nous assurer de la faisabilité du téléchargement de modules
à travers notre plateforme. Comme nous l’avons mentionné ci-dessus, le terminal a besoin
de télécharger un service si le contexte a changé, causant l’arrêt d’une application. La
plateforme CATS doit alors télécharger le service adéquat pour rendre l’application de
nouveau fonctionnelle. Ils est donc impératif que le module soit récupéré, installé et démarré
le plus vite possible.
Étant donné le caractère fortement mobile des utilisateurs, le téléchargement doit se
faire suffisamment vite afin d’éviter la perte de la connexion. Nous avons donc mesuré le
temps nécessaire pour télécharger des bundles, en variant des paramètres : la distance entre
les terminaux et la taille des modules. Nous avons effectué des tests pour le téléchargement
seul, puis des évaluations du temps total d’adaptation, de la récupération du service jusqu’à
son démarrage.

104
 Chapitre 8. Evaluation du prototype CATS

Déroulement de l’expérience

Nous avons implémenté le Trader, capable de communiquer avec les terminaux à proximité.
Nous avons effectué les tests en intérieur (mais sans murs interposés entre les téléphones).
Les terminaux ont été placés à des distances de 1.5 à 15 mètres. Le Trader reçoit des
demandes internes de téléchargement d’un service et émet une requête sur le réseau. Il
attend ensuite 5 secondes pour une réponse et renonce (pour réessayer plus tard). Pour
chaque résultat que nous présentons par la suite, nous avons effectué 100 essais. Nous
avons exclu les faux résultats, quand le Trader arrêtait la requête par manque de réponse
dans le temps imposé. Les résultats que nous présentons sont calculés comme moyenne sur
80 valeurs. En tout, nous avons effectué 18 tests de téléchargement, sur lesquel nous avons
observé une moyenne de 3.66% d’erreur (pas de connexion entre les Traders).

8.2.2 Résultats numériques du téléchargement et des adaptations

Cette section présente les résultats que nous avons obtenus pour les différents scénarios.
La plupart des tests ont été effectués de manière statique, c’est-à-dire sans que les terminaux
communicants bougent. Comme nous l’avons mentionné précédemment, le but n’est pas de
comparer les différents téléphones. Néanmoins, on remarque une amélioration des résultats
avec les terminaux plus récents.

Téléchargement des services à 1.5 m

EB@@A
Temps de téléchargement (ms)

E@@@A

DB@@A

D@@@A
Samsung
CB@@A HTC Hero
C@@@A

B@@A

@A
FA D@A F@@A
Taille du fichier (kB)

Figure 8.2 – Comparaison du temps de téléchargement en fonction de la taille du module

sur Samsung 551 et HTC Hero, à petite distance.

La figure 8.2 illustre les résultats du temps de téléchargement sur les deux appareils de
test, en changeant la taille du service partagé. L’expérience a été effectuée une fois entre
deux terminaux HTC et une deuxième fois entre deux terminaux Samsung. A chaque fois,
les deux smartphones participant à l’expérience ont été placés à environ 1.5 m distance. La
taille du module à télécharger prend trois valeurs : 4 kB, 20 kB et 400 kB.
Nous observons peu de différence entre le temps nécessaire pour télécharger un fichier
de 4 et de 20 kB. Nous imputons ce comportement au fait que la connexion au socket du
fournisseur prend sensiblement plus de temps que l’envoi des paquets contenant le service.
Ainsi, les valeurs moyennes de téléchargement pour des services de petite taille varient
entre 1200 ms et 1450 ms sur les deux terminaux. Sur le HTC nous observons une anomalie,
une moyenne plus basse pour le téléchargement du module de 20 kB que pour celui de

105
8.2. Des applications capables d’acquérir des nouvelles fonctionnalités

4 kB. Ce comportement peut être imputé au temps nécessaire pour établir la connexion
entre les terminaux. En effet, pour le téléchargement de modules de petite taille le temps
de connexion est plus important que le temps de transfert.
Nous avons remarqué une importante différence quand la taille du module devient plus
importante, 400 kB. Pour le téléphone Samsung, le temps passe de 1371 à 1908 ms, alors
que pour le HTC il augmente de 1421 à 2800 ms. Nous attribuons le plus grand écart
de HTC à une écriture plus longue (qui augmente donc considérablement avec la taille
du fichier). Nous envisageons d’utiliser des services avec une taille entre 20 et 200 kB
pour les applications qui s’exécuteront sur la plateforme CATS. Grâce à la modularité des
applications, cette solution est largement envisageable. Des services de plus grande taille
peuvent également être utilisés, mais ils seront moins efficaces s’ils doivent être téléchargés
pour une adaptation urgente.

Echange complet des services de taille 20 kB

EB@@A

E@@@A

DB@@A

D@@@A
Temps (ms)

Samsung
CB@@A
HTC Hero
C@@@A

B@@A

@A
CFBA GFBA CBA
Distance entre les téléphones (m)

Figure 8.3 – Comparaison du temps d’échange complet pour des smartphones Samsung et
HTC, avec un service de 20 kB, en variant la distance entre les téléphones.

La figure 8.3 illustre ce que l’on appelle temps d’échange complet dans ce manuscrit.
Nous considérons comme échange complet le pire cas qui arrive pendant une adaptation : le
service équivalent n’est pas présent sur le terminal et doit être téléchargé. Nous mesurons
le temps nécessaire pour arrêter le service à échanger, télécharger le service équivalent,
l’installer et le démarrer. L’échange complet inclut donc toutes les étapes jusqu’à ce que le
service équivalent soit prêt à être utilisé. Nous avons utilisé un service de 20 kB pour ce
test, car la plupart de nos services ont entre 8 et 20 kB. Nous avons placé les téléphones à
différentes distances afin d’évaluer l’influence de ce paramètre : très proche, à moins de 1.5
m ; proche, à environ 4 – 5 m ; éloigné, à environ 15 m.
Nous observons une légère croissance du temps avec la distance entre les téléphones.
Ceci est dû au temps de téléchargement qui augmente avec la distance. Nous observons
aussi un important écart entre les deux types de smartphones. Le HTC est considérablement
plus long à toutes les distances. Ce comportement indique que le HTC est non seulement
plus long à télécharger, mais aussi plus long à installer et démarrer les bundles.
Nous souhaitons montrer la différence entre le temps de téléchargement et le temps
complet d’échange. Nous présentons les résultats que nous avons obtenu sur le téléphone
Samsung dans la figure 8.4. Les caractéristiques restent les mêmes que pour les résultats
de la figure 8.3 : un service de 20 kB et les téléphones placés à trois distances différentes.
Nous observons une légère augmentation du temps, de quelques centaines de milisecondes

106
 Chapitre 8. Evaluation du prototype CATS

Samsung - 20 kB service
EB@@A

E@@@A

DB@@A

D@@@A Télécharge

Temps (ms)
ment
CB@@A

C@@@A Echange
B@@A complet

@A
CFBA GFBA CBA
Distance entre les téléphones (m)

Figure 8.4 – Comparaison du temps d’échange complet versus le temps de téléchargement

pour des smartphones Samsung, avec un service de 20 kB, en variant la distance.

– 350 ms au plus pour l’échange complet. Cette différence représente le temps d’installation
et démarrage du bundle. Nous présentons plus de détails sur le temps d’installation et de
démarrage, avec des tests dédiés dans le paragraphe 8.3 (page 108).

Samsung - téléchargement des services

EB@@A
Temps de téléchargement (ms)

E@@@A

DB@@A

D@@@A 4kB

CB@@A 20kB
400kB
C@@@A

B@@A

@A
CFBA GFBA CBA
Distance entre les téléphones (m)

Figure 8.5 – Comparaison du temps de téléchargement en fonction de la taille du module et

la distance, pour des smartphones Samsung.

Nous montrons dans la figure 8.5 les influences des deux paramètres, distance et taille du
module à télécharger. Les résultats suivent nos attentes, c’est-à-dire le temps augmente avec
la taille et avec la distance. Pour les modules de petite taille, le temps de téléchargement
varie entre 1200 et 1600 ms (à 15 m distance, pour un module de 20 kB). Pour les service
encapsulés dans des bundles de 400 kB, le temps est sensiblement plus grand, variant entre
1910 et 2100 ms. Néanmoins, cela prouve que même un service de grande taille peut être
échangé dans un temps acceptable.

107
8.3. Des applications réactives aux changements du contexte

Autres expérimentations et résultats

Nous avons effectué plusieurs expérimentations en plus de celles que nous venons de
présenter. Nous avons testé le Trader avec plusieurs terminaux qui participent à l’échange
de services, ou encore avec un terminal en mouvement. Tous ces autres tests ont été effectués
avec un service de 20 kB.
Deux HTC et un Samsung. Nous avons effectué des essais avec un téléphone HTC
Hero détenant le service désiré par les deux autres terminaux. Le deuxième HTC et le
Samsung font des requêtes successivement pour obtenir le service. Les trois appareils se
trouvent à environ 1 m les uns des autres. Nous avons trouvé que le téléchargement dure en
moyenne 1619 ms pour le Samsung et 2157 ms pour le HTC. Nous concluons que l’un des
problèmes du smartphone HTC est qu’il écrit moins vite le fichier téléchargé. Nous observons
aussi l’influence du fait que plusieurs téléphones demandent le service, car le temps de
téléchargement est sensiblement plus élevé que dans le cas où seuls deux téléphones
interagissent.
Test en mobilité. Nous avons expliqué que la plupart des tests ont été effectués sans que
les terminaux bougent. En effet, il s’avère plutôt difficile d’effectuer des expérimentations
en mouvement, car cela nécessite une personne qui se déplace durant toute la période
de test. Ce test a été effectué avec deux téléphones HTC, dont un restant dans la même
position (le fournisseur) et le deuxième se déplaçant entre 0 et 10 m distance du premier.
Nous avons trouvé une moyenne de 3700 ms pour le téléchargement dans ces conditions.
Les performances sont donc inférieures à celles obtenues lorsque les smartphones sont
fixes. Nous notons que nous avons utilisé le Wi-Fi classique. De nos jours, de nouvelles
technologies sont proposées par la recherche et par l’industrie, permettant de meilleures
performances pour les communications sans-fils mobiles.

8.2.3 Conclusions

Les objectifs de ces expériences ont été d’évaluer les paramètres qui peuvent influencer
le temps de téléchargement des nouveaux services. Au delà de l’adaptation, nous nous
intéressons au temps de téléchargement, car il est nécessaire de minimiser le risque de
perdre la connexion avant la récupération du service. Nos résultats montrent que les services
peuvent être téléchargés dans des délais de 2 à 3 secondes. Cela permet à des utilisateurs
peu mobiles de récupérer des nouvelles fonctionnalités, en utilisant la technologie Wi-Fi.
Nous remarquons qu’une fois le service équivalent téléchargé, il reste sur le terminal.
Les adaptations suivantes seront donc plus rapides, car elles ne nécessiterons plus un
téléchargement. Dans la suite de nos expérimentations, nous nous sommes concentrés sur la
réactivité de la plateforme, pour que l’utilisateur puisse profiter au plus vite d’une application
adaptée.

8.3 Des applications réactives aux changements du contexte

Nous voulons proposer une plateforme réactive aux changements de contexte. Pour cela,
nous nous intéressons aux moyens d’effectuer l’adaptation afin que les applications soient
fonctionnelles au plus vite. Nous étudions donc les différents aspects liés à l’échange de
services. Nous avons présenté dans le paragraphe 7.1.1 (page 86) les caractéristiques de la
plateforme OSGi ainsi que les états dans lesquels peuvent être les bundles. En fonction

108
 Chapitre 8. Evaluation du prototype CATS

de ces états, nous pouvons garder des services en mémoire (prêts pour l’utilisation) ou les
garder sans les installer, nécessitant plus de temps pour un échange. Nous appelons test 1
l’ensemble des expériences destinées à étudier les différents mécanismes d’adaptation que
nous pouvons mettre en place grâce aux technologies que nous utilisons.
Nous nous intéressons ensuite à d’autres aspects qui peuvent influencer la rapidité de
l’adaptation. Par exemple, un grand nombre de services équivalents peut nuire à la réactivité
de la plateforme CATS. Nous appelons test 2 l’ensemble des expériences destinées à étudier
la réactivité de notre plateforme.

8.3.1 Test 1 : Matériel de test et scénarios d’échange de service

Pour ces expérimentations nous avons utilisé trois téléphones, le HTC Hero, le Samsung
551 et le HTC Wildfire S. Pour les tests antérieurs nous avons mesuré le temps en fonction des
notifications des bundles qui passent à l’état ACTIVE. Nous avons estimé le temps d’échange
de services en fonction du moment de déclenchement de l’adaptation et de l’événement
généré par le bundle activé. Dans les tests suivants, nous avons utilisé une version évoluée
du prototype, capable de profiter de handlers iPOJO pour capter les changements d’état
des bundles. Grâce aux handlers, nous interceptons plus précisément les moments clefs de
l’adaptation. Nous pouvons connaître le moment où le client passe dans l’état INVALID car
son fournisseur est devenu indisponible et le moment où le client passe dans l’état VALID,
quand le service équivalent est prêt à être utilisé.

CA
BA DA
S(1)
C @A
@
Ctx.Dep.Handler
Statistic Handler
S(2)
Ctx.Dep.Handler
Statistics

Figure 8.6 – Configuration de test pour la mesure du temps d’indisponibilité.

La figure 8.6 présente la configuration de test que nous avons utilisée. Un module client
C dépend d’un service S. Deux implémentations dépendantes du contexte sont disponibles,
S(1) et S(2). Le Statistic Handler est connecté au module client, afin de mesurer le temps
durant lequel C a été dans l’état INVALID. Supposons que C consomme S(1) au moment où
le contexte change, causant l’arrêt de S(1). Une adaptation est nécessaire pour démarrer
S(2) et le connecter au client. Il est donc possible que le fonctionnement du module C soit
perturbé par cette adaptation. Nous mesurons l’impact entier de l’échange de services en
nous concentrant sur le client plutôt que sur les implémentations de S.

Les différents mécanismes d’adaptation

Nous trouvons plusieurs situations possibles pour les applications modulaires conçues
avec OSGi et iPOJO. Nous avons vu que les services sont encapsulés dans des modules,
notamment les bundles OSGi. Un bundle peut se trouver dans plusieurs états sur un terminal :

109
8.3. Des applications réactives aux changements du contexte

en forme de fichier JAR dans un dossier quelconque du terminal ; en tant que bundle installé,
dans l’état RESOLVED ; en tant que bundle démarré, dans l’état ACTIVE. De plus, si le
module contient un service, il peut l’enregistrer auprès du registre de services. Étant donné
que nous utilisons iPOJO, il n’est plus nécessaire d’enregistrer explicitement les services,
car iPOJO s’occupe des liaisons dynamiques entre les fournisseurs et les consommateurs.
Nous avons tout de même voulu garder la possibilité d’enregistrer un service. Pour mettre
en place cette propriété, nous avons utilisé des controllers iPOJO pour rendre un service
disponible ou non pour les autres modules. Dans la suite nous nous référons à l’action
de rendre disponible un service comme « enregistrement ». Les différents cas d’adaptation
sont résumés par la suite, par ordre croissant des actions nécessaires pour effectuer une
adaptation.
Cas #1 : Plusieurs implémentations du service S sont disponibles sur le terminal et prêts
pour l’utilisation (dans l’état ACTIVE, avec le service enregistré). Dans ce cas, si
l’implémentation qui est consommée par le client s’arrête, elle est automatiquement
remplacée par son équivalent.
Cas #2 : Une seule implémentation de S est disponible à la fois. D’autres implémentations
sont dans l’état ACTIVE, sans avoir enregistré leur service. De cette façon, nous impo-
sons la version du service qui est consommé par C à tout instant. En cas d’adaptation,
il suffit de rendre un autre service disponible pour satisfaire le besoin du client. Cette
opération devrait être plus longue que dans le Cas #1.
Cas #3 : De façon similaire au Cas #2, une seule version du service est disponible à la
fois. Les autres versions sont installées sur le terminal, dans l’état RESOLVED. De
cette manière, les objets du module ne sont pas instanciés et n’occupent donc pas la
mémoire. Pour échanger le service, le bundle de la nouvelle version doit être démarré
et son service doit être enregistré. De nouveau, les actions nécessaires sont plus
longues que dans le cas précédent.
Cas #4 : Une seule version de S est disponible sur la plateforme. D’autres implémentations
sont stockées sur le terminal, mais leurs bundles ne sont pas installés sur CATS. C’est
une manière de faire encore plus économique en terme de mémoire. Pour résoudre la
dépendance de C dans le cas d’une adaptation, le module de remplacement doit être
installé, démarré et son service doit être enregistré.
Cas #5 : Le pire cas pour une application mobile qui doit s’adapter à un changement de
contexte : le service nécessaire pour les nouvelles conditions n’est pas disponible sur
le terminal. Pour que les applications continuent à fonctionner correctement, le service
adéquat doit être téléchargé à partir des terminaux à proximité (ou d’un serveur). Les
actions nécessaires dans ce cas introduisent un nouveau surcoût en terme de temps.

Déroulement de l’expérience

Nous avons créé nos scénarios de test à partir des cas présentés ci-dessus. Le Cas #5 a
été étudié précédemment, bien que cela ne soit pas dans les conditions exactes présentées
ici. Des mesures sur le temps nécessaire pour télécharger un service et le rendre disponible
(ACTIVE) ont été présentées dans le paragraphe 8.2 (page 104). Les expériences n’ont
pas été répétées dans les nouvelles conditions, car nous avons considéré qu’elles étaient
suffisamment éloquentes.
Les expériences pour le Cas #1 sont différentes que dans les autres cas, nous les
présentons donc séparément. Nous avons effectué ce test avec le module C et les deux
implémentations de S, S(1) et S(2) dans l’état ACTIVE et avec les services enregistrés. Par
défaut, C est connecté à S(1). Nous forçons l’arrêt du service connecté pour mesurer l’impact

110
 Chapitre 8. Evaluation du prototype CATS

sur C . Nous avons observé sur plus de 10 essais que le client ne passe à aucun moment
dans l’état INVALID et qu’il commence tout de suite à utiliser S(2). Le résultat est conforme
à nos attentes car ce comportement est dû aux caractéristiques d’iPOJO. Les outils de ce
modèle à composants résolvent les dépendances des services automatiquement. Comme le
client reste valide tout le temps, nous ne pouvons pas mesurer la durée d’adaptation quand
plusieurs services équivalents sont prêts pour l’utilisation. Bien que cette configuration soit
très rapide, il n’est pas raisonnable de garder un grand nombre de services démarrés à tout
moment sur un terminal limité en ressources tel qu’un smartphone. Cette solution devrait
être réservée pour des cas spécifiques où les changements arrivent souvent et de manière
inattendue, forçant la plateforme CATS à réagir très vite.
Dans la suite nous allons traiter les Cas #2, Cas #3 et Cas #4, pour lesquels nous
comparons les résultats sur trois téléphones, HTC Hero, Samsung Galaxy 551 et HTC Wildfire
S. Nous appelons les trois tests 1A, 1B et 1C pour les différents cas d’adaptation que nous
avons identifiés. Nous allons effectuer des tests pour trois des situations d’adaptation :
– Test 1A (« register »). Ce test correspond au Cas #2, où plusieurs services équivalents
sont dans l’état ACTIVE, mais un seul est enregistré. Pour réaliser l’adaptation il suffit
d’enregistrer le services adéquat sur la plateforme.
– Test 1B (« start »). Ce test effectue l’adaptation comme décrit par le Cas #3 : pour
remplacer un service il faut démarrer le bundle qui contient le service équivalent et
enregistrer son service.
– Test 1C (« install »). Le dernier test consiste à mesurer le temps nécessaire pour
adapter un service dans la situation du Cas #4. Le module contenant le remplacement
se trouve sur le terminal et doit être installé avant de connecter le nouveau service.

Les résultats que nous présentons par la suite sont obtenus sur la base de 102 essais
pour chaque test et pour chaque terminal. Les valeurs extrêmes ont été supprimées pour
garder 100 valeurs. Les conditions d’exécution sont celles disponibles sur les téléphones, nous
n’avons pas explicitement arrêté des applications pour libérer la mémoire ou le processeur.
Le service utilisé pour les expériences est encapsulé dans un module de 13 087 octets. Nous
présentons les résultats moyens, mais aussi les distributions de valeurs et les écarts types
sur les 100 essais. Les tests sont effectués dans des boucles for, mais le fil d’exécution
s’arrête pendant 2 secondes (sleep()) entre chaque essai, pour que les résultats n’interfèrent
pas entre eux. Apres chaque type de test, la plateforme CATS est redémarrée. Nous avons
réalisé une comparaison entre des tests effectués dans une boucle et des tests effectués en
laçant manuellement chaque adaptation. Les résultats obtenus ont été très similaires en
terme de valeur moyenne et répartition des valeurs. Pour cette raison, nous avons choisi
d’utiliser une boucle for.

8.3.2 Test 1 : Résultats numériques

Nous illustrons dans la figure 8.7 le temps moyen nécessaire pour chaque type de tests
sur les trois téléphones. La tendance des résultats est conforme à nos attentes : le temps
d’adaptation augmente de test 1A (simple enregistrement du service) à test 1C (installation,
démarrage et enregistrement). Le temps augmente aussi avec l’ancienneté du téléphone.
Pour le test 1A la moyenne du temps d’adaptation varie entre 140 et 260 ms, des valeurs
encourageantes. Pour le deuxième test, la moyenne varie entre 330 et 605 ms, pendant que
pour le troisième elle se situe entre 490 et 995 ms.
Le pire résultat est une adaptation qui dure environ 1 seconde en moyenne sur le
téléphone HTC Hero. Ce temps reste acceptable, malgré qu’il devrait être amélioré. Nous

111
8.3. Des applications réactives aux changements du contexte

Temps moyen d'échange

1200
1100
1000
900
800
700
Temps (ms)

600 HTC Wildfire

500 Samsung 551
400
HTC Hero
300
200
100
0
register start install

Figure 8.7 – Temps moyens d’adaptation pour test 1A, 1B et 1C

attirons l’attention sur les réalités du marché de nos jours : les smartphones ont une durée
de vie courte, car les compagnies téléphoniques incitent leurs clients à changer souvent
leurs terminaux. En moyenne les utilisateurs changent de téléphone tous les 2 ans. Nous
pouvons donc être satisfaits que notre plateforme fonctionne de manière satisfaisante sur
un téléphone qui date de 3 ans. Le prochain pire temps d’échange de services après le HTC
Hero est sur le téléphone Samsung 551, 700 ms. Cela représente une amélioration de 30%
par rapport au HTC Hero.
Nous remarquons l’intérêt d’avoir des services équivalents prêts sur la plateforme :
une adaptation en moins de 300 ms, même sur un ancien téléphone. Mais comme nous
l’avons mentionné au-dessus, garder plusieurs services actifs a un coût important en terme
de mémoire. Pour cette raison, nous avons mesuré la mémoire disponible entre chaque
essai, pour évaluer l’impact de chaque type d’adaptation que nous proposons. La figure 8.8
(page 114) présente une vue d’ensemble des tests 1A, 1B et 1C. Nous illustrons la distribution
de valeurs du temps d’adaptation sur chaque téléphone ainsi que la mémoire consommée. La
mémoire consommée est calculée comme la différence entre la valeur de mémoire disponible
avant le début du test et la mémoire disponible après chaque essai. Nous commençons en
présentant les distributions de valeurs des tests 1A, 1B et 1C.
Pour le test 1A, le module client C est perturbé par le service S qui disparaît (n’est plus
enregistré) et réapparaît de nouveau. Le temps mesuré à chaque essai ne varie pas beaucoup
par rapport à la moyenne. Cela nous montre que l’action d’enregistrer un service n’est pas
influencée par les autres activités du processeur. Dans notre implémentation avec iPOJO,
l’action à faire pour rendre disponible un service est de changer la valeur d’un attribut à
true.

Dans les tests 1B et 1C le module qui encapsule S doit être démarré, respectivement
installé et démarré, afin de remplacer l’ancienne version. Dans ces cas, plusieurs objets sont
créés, ce qui demande plus de temps. Nous observons plus de variation des valeurs et une
période d’échauffement au début. Après quelques essais, les valeurs se stabilisent. Pour
mieux comprendre le comportement des différents téléphones, nous avons calculé les écarts
types que nous présentons dans la Table 8.3.
Nous observons que le téléphone Samsung varie plus que les deux téléphones HTC.
Les écarts type le montrent aussi, le temps d’adaptation varie de 10, 10.5 et 13 % sur le

112
 Chapitre 8. Evaluation du prototype CATS

test 1A test 1B test 1C

HTC Hero 7,91 ms (3,1%) 33,05 ms (5,5%) 81,96 ms (8,2%)
Samsung 551 23,14 ms (10%) 47,24 ms (10,5%) 86,47 ms (13%)
Wildfire S 3,44 ms (2,5%) 27,42 ms (8,3%) 51,42 ms (10%)

Table 8.1 – Les écarts types des tests d’adaptation 1A, 1B et 1C en valeur absolue (ms) et
pourcentage (%) par rapport à la moyenne.

Samsung pour les trois types de test. Pour les terminaux HTC, l’écart type est de seulement
2.5 et 3.1 %, montrant que pour les adaptations avec « register » (test 1A) il y a une forte
probabilité que le résultat soit cohérent. Pour le deuxième test, l’écart type augmente sur
tous les téléphones. Sur le HTC Hero il arrive à 5.5 % et sur le HTC Wildfire à 8.3 %. Enfin,
pour le troisième test l’écart type arrive à 8.2 et 10 % sur le Hero et Wildfire respectivement.
La dispersion des valeurs du temps d’adaptation reste dans des limites acceptables. Nous
attribuons les différences de comportement au matériel et surtout au couches logicielles
ajoutées par les constructeurs de téléphones.
En ce qui concerne la consommation de mémoire, nous présentons l’évolution sur les
trois téléphones également dans la figure 8.8. Nous notons que la machine virtuelle Dalvik
n’arrive pas à libérer la mémoire durant un test, donc pendant les 100 essais la mémoire
est occupée par les objets du même module, récréés à chaque essai. Ce comportement ne
devrait pas se reproduire dans l’utilisation normale de la plateforme CATS. Néanmoins, il
faut prendre en considération le fait que parfois la machine virtuelle n’ait pas le temps de
libérer la mémoire entre deux changements de service. Il faudra donc prêter attention à cet
aspect : les adaptations ne doivent pas se suivre à des intervalles trop courts.
Les résultats des téléphones HTC Hero et le Samsung 551 sont ceux que nous attendions.
Il n’y a pas de consommation de mémoire pour le test 1A, car aucun objet n’est instancié dans
ce cas. Comme nous l’avons déjà précisé, dans ce cas seule la valeur d’un attribut change.
Les 232 kB, respectivement 472 kB « consommés » par le Hero et le Samsung peuvent être
attribués à des fluctuations aléatoires de la mémoire (causées pas d’autres applications). Les
tests suivants, 1B et 1C, demandent la mémoire nécessaire pour la création des instances.
Dans le cas du test « start », le service est instancié. Comme le bundle était déjà installé,
cette action prend moins de mémoire que celle du test 1C.
Les valeurs que nous observons doivent être interprétées à l’inverse : le test 1A n’est pas
le meilleur des trois tests parce qu’il ne consomme pas de mémoire. En réalité, pour le 1A, la
mémoire a déjà été occupée par le service installé et démarré. Donc si nous gardons toutes
les versions des services prêts pour l’utilisation, la mémoire sera encombrée tout au long de
l’exécution de l’application. Les deux autres tests permettent de calculer l’espace mémoire
nécessaire pour les bundles RESOLVED et ACTIVE. Nous observons un comportement
bizarre pour le HTC Wildfire S, qui semble consommer la mémoire même pour le test 1A.
Pour les deux autres tests, la consommation de mémoire augmente à chaque fois, là où les
terminaux HTC Hero et Samsung ont des courbes très rapprochées. Nous considérons que
ce comportement est dû à un problème de conception du téléphone ou des logiciels installés.
Malgré aucune information officielle de la part de HTC, des nombreuses plaintes peuvent
être trouvées sur les forums dédiés.
Nous résumons les données sur la consommation de la mémoire dans la Table 8.2.
Nous avons observé que le téléphone HTC Wildfire consomme une quantité très grande

113
8.3. Des applications réactives aux changements du contexte

Temps d'échange pour "register" Mémoire utilisée pour "register"

1200 24000
HTC Wildfire HTC Wildfire
1100 22000
1000 Samsung 551 20000 Samsung 551
900 HTC Hero 18000 HTC Hero
800 16000
700 14000

Mémoire utilisée (kB)

Temps (ms)

600 12000
500 10000
400 8000
300 6000
200 4000
100 2000
0 0
1 11 21 31 41 51 61 71 81 91 1 11 21 31 41 51 61 71 81 91

Temps d'échange pour "start" Mémoire utilisée pour "start"

1200 24000
1100 22000
1000 20000
900 18000
800 16000
700 14000
Mémoire utilisée (kB)
Temps (ms)

600 12000
500 10000
400 8000
300 6000
200 4000
100 2000
0 0
1 11 21 31 41 51 61 71 81 91 1 11 21 31 41 51 61 71 81 91

Temps d'échange pour "install" Mémoire utilisée pour "install"

1200 24000
1100 22000
1000 20000
900 18000
800 16000
700 14000
Mémoire utilisée (kB)
Temps (ms)

600 12000
500 10000
400 8000
300 6000
200 4000
100 2000
0 0
1 11 21 31 41 51 61 71 81 91 1 11 21 31 41 51 61 71 81 91

Figure 8.8 – Tests 1A, 1B et 1C (« register », « start » et « install ») – distribution des valeurs
pour le temps d’échange sur chaque terminal de test et consommation de mémoire.

de mémoire, même quand il ne devrait pas en consommer. Pour le premier test 11 150 kB
sont consommés pendant que les deux autres terminaux n’en consomment presque pas.
En moyenne, le HTC Wildfire utilise 111 kB de mémoire à chaque essai, là où les autres
terminaux en utilisent 2.3 et 4.7 kB. Pour le test 1C, qui est le plus consommateur en terme
de mémoire, les téléphones HTC Hero et Samsung utilisent environ 8000 kB de mémoire
pour les 100 essais, donc en moyenne 80 KB à chaque essai. Nous concluons donc que la

114
 Chapitre 8. Evaluation du prototype CATS

place occupée en mémoire pour un bundle dont le JAR a une taille de 12.8 kB est environ
40 kB dans l’état RESOLVED et 80 kB dans l’état ACTIVE.

test 1A test 1B test 1C

HTC Hero 232 kB 4200 kB 8120 kB
Samsung 551 472 kB 4460 kB 8810 kB
HTC Wildfire S 11150 kB 18220 kB 23500 kB

Table 8.2 – Consommation de mémoire (kB) après 100 répétitions.

Nous avons également étudié le comportement des téléphones dans un cadre « normal »,
où les adaptations ne se succèdent pas toutes les 2 secondes. Nous avons donc effectué
des tests où les adaptations sont initiées à la main, avec un intervalle aléatoire de 1 à 60
secondes entre deux essais consécutifs. Cela permet à la machine virtuelle de libérer la
mémoire à certains instants. Nous présentons les résultats grâce à la figure 8.9. Cette fois,
75 essais ont été effectués, avec un mélange des trois tests, 1A, 1B et 1C, qui se succèdent
dans cet ordre.

Mémoire utilisée - test mixte

HBBBC
IBBBC
Mémoire utilisée (kB)

BC
@IBBBC
@HBBBC HTC Wildfire
@GBBBC Samsung 551
@FBBBC HTC Hero
@EBBBC
@DBBBC
@ABBBC
1 11 21 31 41 51 61 71

Figure 8.9 – Tests mixtes de consommation de la mémoire.

La valeur de la mémoire libre est mesurée, comme dans le cas précédent, la première
fois avant le début de chaque test (ensemble de 75 essais) et ensuite après chacun des
essai. Cette expérience nous montre l’évolution de la consommation de mémoire sur une
durée d’environ une heure. Nous observons des baisses de consommation significatives, ainsi
que des petites variations. Les baisses plus importantes sont probablement liées aux autres
processus des téléphones et non pas à la plateforme CATS. Néanmoins, il est également
possible que la machine virtuelle n’arrive pas à libérer la mémoire suffisamment vite. Dans
ce cas, il faut essayer de limiter le nombre d’adaptations que notre plateforme effectue.

8.3.3 Test 1 : Conclusions

Nous avons essayé plusieurs configurations pour les adaptations de services en fonction
du contexte. Nous concluons que même la plus longue adaptation, qui inclut l’installation
du module contentant le nouveau service sur la plateforme CATS, est suffisamment rapide
pour être acceptable du point de vue de l’utilisateur. De plus, notre solution est convenable

115
8.3. Des applications réactives aux changements du contexte

sur une grande partie des terminaux, bien qu’ils soient déjà vieillissants, comme le HTC
Hero qui est sorti en 2009, il y a 3 ans déjà.
Le problème que nous devons analyser par la suite est lié à la consommation de mémoire
pendant les adaptations. Nous avons vu que l’adaptation la plus rapide implique de garder
en mémoire plusieurs versions du même service. À l’autre extrémité, nous pouvons garder
les versions d’échange des services sur le terminal, et les installer seulement au moment
d’une adaptation. Nous avons par contre remarqué que la machine virtuelle ne libère pas
suffisamment vite la mémoire. Il faut donc éviter d’installer et désinstaller des bundles très
souvent. Il faut trouver le bon équilibre entre les services qui sont échangés très souvent,
qui doivent rester dans l’état ACTIVE pour des adaptations rapides, et ceux qui changent
moins souvent, que l’on peut installer seulement en cas de besoin.

8.3.4 Test 2 : Matériel de test et scénarios d’évaluation

Nous nous intéressons à fournir des applications réactives au contexte, afin que l’uti-
lisateur ait une meilleure expérience. Nous avons discuté dans les sections précédentes
des différentes configurations possibles pour effectuer des adaptations. Les évaluations du
test 2 concernent les aspects qui peuvent améliorer le temps d’adaptation ou, au contraire,
lui nuire. Pour ces expériences nous avons utilisé deux téléphones et une tablette Android :
Sony Ericsson Xperia ray, Samsung Galaxy 551 (avec la mise à jour Android 2.3.6) et la
tablette HTC Flyer. Leurs caractéristiques ont été présentées dans la Table 7.1 (page 93).
Pour cet ensemble de tests nous avons utilisé l’application VESPA, adaptée pour la
plateforme CATS. Nous avons créé une configuration complète, avec tous les modules
de gestion, des Monitors de contexte, tous les handlers et une application complète avec
interface graphique (simple). Nous avons présenté brièvement l’application dans le para-
graphe 7.2.1 (page 94). Pour cet ensemble d’expériences, nous considérons les éléments
suivants (en plus des modules de gestion de la plateforme CATS).
– Context Element {Name = NeighborCount ; Type = Continuous (codé par le nombre
entier 3) ; [Unit = Entities ; Category = Environment ;]}.
L’élément de contexte que nous considérons est le nombre de voisins, qui est représenté
par un nombre entier supérieur ou égal à 0. En effet, le service de parking se comporte
différemment en fonction des terminaux qui participent au trafic.
– Context Monitor pourt le CE « NeighborCount ». Ce module évalue le nombre de
voisins (à un saut) toutes les 15 secondes et met à jour l’information dans le Context
Manager. Bien que le module fonctionne bien en Wi-Fi, il a été modifié, pour des
raisons de test, afin qu’il retourne une série de valeurs bien définie.
– Vespa. L’application utilise la communication inter-véhicules pour partager des infor-
mations de trafic. Elle dépend du service appelé Parking Service.
– Parking Service. Ce service est dépendant du contexte et a plusieurs implémentations,
en fonction des valeurs du CE « NeighborCount ».
• DPS (Dissemination Parking Service). Cette version du service informe tous les
véhicules quand une place de parking est libérée, en utilisant le broadcast. Le
DPS est à utiliser quand il y a peu de participants : NeighborCount ∈ {0, 1}.
• RPS (Reservation Parking Service). Dans cette version, le véhicule qui libère
la place l’annonce aux voisins et réserve ensuite la place pour un seul véhicule.
Cette version fonctionne pour NeighborCount = 2.
• DPSvi et RPSvj (versions des deux services au-dessus). Chacune de ces ver-
sions fonctionne de manière similaire à DPS ou RPS, mais pour des valeurs de
NeighborCount ∈ {3, 4, 5, 6, 7}.

116
 Chapitre 8. Evaluation du prototype CATS

Nous notons que les valeurs du CE utilisées dans nos expériences sont choisies seulement
pour le test. En réalité, les valeurs pour lesquelles on utilise DPS ou RPS seront différentes.
Nous estimons que jusqu’à 5 voisins nous pouvons diffuser l’information à tous les participants,
et au-dessus de cette valeur il faudrait réserver la place.
Les modules contenant les services de parking ont des caractéristiques différentes. Le
DPS est encapsulé dans un bundle d’environ 5 kB. Cette version du service ne fait qu’envoyer
un message sur le port d’écoute de VESPA. La version RPS par contre est encapsulée dans
un bundle d’environ 15 kB qui lance un fil d’exécution pour la communication Wi-Fi. Pour
cette raison, nous disons que DPS est une version légère du Parking Service, pendant que
RPS est une version plus lourde. Les évaluations ont été effectuées avec deux ou six versions
du Parking Service sur la plateforme. Les mêmes tests ont été effectués avec DPS et DPSvi
pour évaluer les réactions de CATS avec des services légers, et ensuite avec RPS et RPSvj
pour estimer l’influence d’une version de service plus lourde.

Déroulement de l’expérience

Les objectifs de nos expérimentations sont de mesurer le temps total de réaction d’une
application quand le contexte change ainsi que l’influence de la présence de multiples
versions sur la plateforme. Par rapport aux évaluations précédentes, nous mesurons le temps
dès la détection du changement de contexte et jusqu’à la fin de l’adaptation. Pour ces tests
nous avons utilisé le prototype complet. Au lieu d’imposer les échanges de services, nous
avons laissé le Context Manager détecter les changements et l’Execution Manager gérer
les arrêts et les démarrages des différentes versions du service. Les versions du Parking
Service ont été démarrées dans un ordre précis, ce qui a conduit à leur enregistrement
dans ce même ordre dans l’Execution Manager. Le module de gestion traite les services
dans l’ordre pour chaque événement. Par conséquent, l’ordre dans lequel sont effectuées
les actions d’arrêt et de démarrage est important. Pour une courte période, nous avons soit
deux versions actives du service, soit aucune. Dans le deuxième cas, l’application VESPA
sera arrêtée à cause de la dépendance manquante.

Contexte service service Vespa OK

changé "inadéquat" OFF "adéquat" ON (adapté) Deuxième possibilité:

tC tOFF tON tV tC tON tOFF tV

(B) (A) (B)

(A)
(C) (C)

Figure 8.10 – Mesures expérimentales.

La figure 8.10 illustre les événements qui ont lieu pendant l’exécution de VESPA, quand
le contexte change. Nous considérons le moment tC , où le changement est détecté, tOF F
où le service courant est arrêté, tON quand le service adéquat est démarré (et prêt pour
l’utilisation) et tV , quand Vespa est adaptée par la connexion du nouveau service. En
fonction de l’ordre dans lequel l’Execution Manager fait les actions, tOF F et tON peuvent
être dans n’importe quel ordre. Dans les expériences, nous avons mesuré les périodes de
temps suivantes : Temps (A) – de la détection du changement de contexte jusqu’à ce que le
service adéquat soit prêt pour l’utilisation ; Temps (B) – la période dans laquelle VESPA
est indisponible à cause de la dépendance manquante ; Temps (C) – de la détection du

117
8.3. Des applications réactives aux changements du contexte

changement de contexte jusqu’à ce que VESPA soit adaptée et opérationnelle. Dans la partie
gauche de la figure 8.10 nous illustrons le cas où l’application devient indisponible. Dans le
deuxième cas, où tON est avant tOF F , l’application ne devient pas indisponible et nous ne
pouvons plus mesurer Temps (B) et Temps (C). Ce comportement est dû à iPOJO, qui gère la
connexion des fournisseurs et consommateurs de manière automatique. Nous pouvons donc
utiliser cela à notre avantage et réaliser les adaptations sans perturber l’application. Dans
cette situation il devient plus compliqué de mesurer le temps exact entre la détection du
changement et le moment précis où VESPA commence à utiliser le service adapté.

8.3.5 Test 2 : Résultats numériques

Dans un premier temps, nous avons réalisé des tests avec deux versions du service RPS
qui sont enregistrées et dés-enregistrées sur la plateforme CATS en fonction de la valeur
du contexte. Nous présentons dans la figure 8.11 la distribution de valeurs pour les trois
temps, (A), (B) et (C), pour 30 essais sur le téléphone Sony Ericcson.

Sony - essais avec le service RPS

140

120

100
Temps (ms)

80 Temps (A)
Temps (B)
60
Temps (C)
40

20

0
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29

Figure 8.11 – Temps (A), (B) et (C) pour un échange entre deux versions du service RPS.

Dans les tests que nous avons effectués, le service courant est arrêté avant de démarrer
le nouveau, rendant VESPA indisponible. Nous observons que tV > tON : le temps nécessaire
pour que iPOJO détecte le nouveau service jusqu’à ce qu’il soit connecté avec le client est
toujours supérieur à 0. Nous pouvons donc affirmer que Temps (C) est supérieur au deux
autres, comme nous pouvons l’observer aussi dans la figure 8.11. Il n’y a pas une règle pour
la relation entre les temps (A) et (B), mais nous avons souvent remarqué (B) comme étant
plus grand. Nous observons que Temps (C) suit la même forme que Temps (B), ce que nous
pouvons expliquer par la signification de ces deux temps :
T emps(C ) = tV − tC ; T emps(B) = tV − tOF F ; T emps(C ) − T emps(B) = tOF F − tC
La différence tOF F −tC représente le temps nécessaire entre le moment où le changement
de contexte a été détecté et le moment où le service devenu inadéquat est arrêté. Le fait
qu’il ne varie pas beaucoup signifie que la plateforme réagit de manière cohérente à chaque
fois.
Dans la Table 8.3, nous présentons les valeurs moyennes de trois temps que nous avons
mesurées sur le téléphone Sony Ericcson. Nous observons donc qu’il faut environ 107 ms
en moyenne pour l’adaptation de l’application depuis que le changement de contexte est

118
 Chapitre 8. Evaluation du prototype CATS

détecté. L’application devient indisponible durant 90 ms en attendant le changement des

services. Les écarts type, quant à eux, varient entre 7.8% et 15.6%, montrant la fiabilité de
nos résultats.

Temps (A) Temps (B) Temps (C)

Moyenne 68,16 ms 90 ms 106,26 ms
Écart type 5,34 ms (7,83%) 14,09 ms (15,65%) 14,17 ms (13,33%)

Table 8.3 – Moyenne et écart type pour les temps (A), (B) et (C), avec le service RPS.

La figure 8.12 présente une vue d’ensemble sur les trois temps, (A), (B) et (C), et sur
les trois terminaux que nous avons utilisés. Comme nous l’avons déjà mentionné, il n’y a
pas de règle pour déterminer l’ordre des temps (A) et (B). Nous pouvons seulement dire
que le temps (C) est supérieur aux deux autres temps. Nous observons de nouveau que les
performances s’améliorent sur les terminaux qui sont plus récents. Le temps (C), le plus
important du point de vue de l’utilisateur, reste dans des limites acceptables, avec le pire
résultat qui est environ de 144 ms en moyenne sur le téléphone Samsung.

Temps d'adaptation (service RPS)

160

140

120

100
Temps (ms)

HTC Flyer
80
Sony
60 Samsung
40

20

0
Temps (A) Temps (B) Temps (C)

Figure 8.12 – Temps d’adaptation à partir du changement de contexte.

Nous observons que le temps nécessaire pour l’adaptation sur le Samsung 551 diffère
de celui d’un test équivalent, le test 1A. En effet, ici l’adaptation dure 144 ms en moyenne,
par rapport aux 230 ms nécessaires dans les résultats de la figure 8.7 (page 112). Cette
différence est causée par la mise à jour du système d’exploitation. Nous pouvons donc
observer l’influence des avancées technologiques et logicielles sur le comportement de notre
plateforme.

Les autres expériences que nous avons effectuées concernent le nombre de services
équivalents qui se trouvent en même temps sur la plateforme, mais également l’influence
de leur complexité. Dans ce but, nous avons utilisé d’abord six versions légères (DSP) et
ensuite six versions plus complexes (RPS) du service de parking. Dans les résultats que
nous présentons les services sont appelés S1, S2, . . . , S6 et représentent soit les versions
de DPS soit celles de RPS. Les indexes indiquent la position de chaque service dans la liste
du Execution Manager, nous permettant ainsi de déduire le surcoût introduit par le nombre

119
8.3. Des applications réactives aux changements du contexte

de services équivalents. Nous avons imposé les conditions de contexte afin que les services
soit échangés de S1 à S6 ou à l’inverse. Nous avons étudié deux cas d’échange de services :
– Un échange indiqué comme Si+1 → Si implique que Si est démarré pour remplacer
Si+1 (qui est arrêté juste ensuite). Dans ce cas, VESPA continue à fonctionner sans
être influencé par l’échange. Les résultats de ce cas sont présentés dans la Figure
8.13(a).
– Un échange indiqué comme Si → Si+1 implique que Si est arrêté avant de démarrer
Si+1 , causant l’iterruption du fonctionnement de VESPA le temps que la dépendance
n’est pas satisfaite. Les résultats de ce cas sont illustrés dans la figure 8.13(b).
Nous faisons la remarque suivante : les transitions S1 → S6 et S6 → S1 sont différentes
du reste, car elles entraînent le comportement opposé par rapport à leur cas respectif. Pour
une meilleure vue des résultats nous n’avons pas inclus ces valeurs dans les figures. Les
résultats de ces transitions sont cohérents avec ceux du reste des expérimentations. Dans le
premier cas, S1 est arrêté et S6 démarre en environ 68,4 ms et 71,63 ms pour DPS et RPS
respectivement. Dans le deuxième cas, S1 démarre en 4,3 ms et 4,46 ms respectivement par
rapport au moment où le contexte change.

Temps (A) sur Sony - avec l'arrêt de l'application

- sans arrêt de l'application 80

70
DPS (5kB) RPS (15kB)
60
8
7 50
time (ms)

6 40
time (ms)

5
4 30

3 20
2
10
1
0 0
S2 -> S1 S3 -> S2 S4 -> S3 S5 -> S4 S6 -> S5 S1 -> S2 S2 -> S3 S3 -> S4 S4 -> S5 S5 -> S6

(a) Cas tON < tOF F (b) Cas tOF F < tON

Figure 8.13 – Temps (A) sur le téléphone Sony avec des services légers et lourds.

Dans la figure 8.13 nous présentons les résultas du temps nécessaire pour démarrer le
service adéquat après un changement de contexte, le Temps (A). Les résultats présentés
sont ceux obtenus avec le téléphone Sony Ericsson. Nous observons dans la figure 8.13(a)
que l’Execution Manager a besoin de très peu de temps pour enregistrer le service adéquat,
moins de 10 ms. Nous observons également une influence claire de la position du service
dans la liste. Le temps varie de 3.1 ms pour la première version de service DPS à 5.9 pour la
cinquième, et de 3.8 à 7.5 ms pour les versions de RPS. Comme nous l’attendons, les versions
plus complexes prennent plus de temps avant d’être validées. Ces tests ont également été
effectués sur la tablette HTC et le téléphone Samsung, avec des résultats similaires en ce
qui concerne la tendance croissante du temps d’enregistrement et la différence entre les
deux types d’implémentation.
Dans la figure 8.13(b) nous présentons le cas où le service inadéquat est invalidé avant
de valider le nouveau. Étant donné que c’est le même fil d’exécution qui fait les actions, un
surcoût important est introduit, d’environ 70 ms. L’ordre des services dans la liste n’est plus
évident. Néanmoins, les transitions sont assez uniformes, avec des moyennes qui varient

120
 Chapitre 8. Evaluation du prototype CATS

entre 68,5 et 70,7 ms pour le DPS et entre 69,3 et 76,2 ms pour le RPS.

8.3.6 Test 2 : Conclusions

Ce deuxième test de réactivité nous a permis d’étudier l’influence de la taille et du

nombre des services sur le temps d’adaptation. Nous avons utilisé six versions légères du
service de parking et six versions plus encombrantes, qui créent des fils d’exécution. Nous
avons considéré les quatre moments clefs dans l’adaptation, c’est-à-dire la détection du
changement de contexte, l’arrêt du service devenu inadapté, le démarrage du nouveau service
et, finalement, le moment où l’application est adaptée.
Les résultats, que nous avons obtenus, nous permettent de conclure que le nombre et
la complexité des services influencent le temps d’adaptation dans des limites raisonnables.
Nous avons également observé que l’on peut fixer l’ordre des actions pour que le service de
remplacement soit démarré avant d’arrêter le service courant. Dans ce cas, l’application qui
en dépend n’est pas perturbée par la disparition du service et l’adaptation est plus rapide.

8.4 Conclusions

Nous avons créé un prototype de la plateforme CATS sur Android et nous avons montré
qu’il est possible de mettre en œuvre des applications flexibles et sensibles au contexte
grâce à une architecture orientée services. Nous sommes partis de l’exemple d’un utilisateur,
Jean, qui est assisté dans son voyage par les applications mobiles de son téléphone :
navigation, gestion de places de parking, sécurité routière, etc. (paragraphe 4.2.2, page 38).
Notre utilisateur a besoin que ses applications changent et s’adaptent à l’environnement
qui évolue constamment, sans que cela soit perturbant pour l’utilisation des applications.
Notre première évaluation s’est focalisée sur la création des applications modulables afin
de permettre le partage des services entre plusieurs applications. Nous avons ensuite testé
différents scénarios d’adaptation en inter-changeant des services équivalents en fonction
du contexte. Nous avons considéré plusieurs cas où le service à démarrer se trouvait sur
le terminal, mais également le cas où la plateforme devait télécharger un service afin de
pouvoir s’adapter au contexte. Nos résultats nous ont permis de valider notre approche sur
plusieurs terminaux différents, montrant que l’utilisateur n’est pas perturbé par l’adaptation,
même sur des anciens terminaux qui sont moins puissants.

121
8.4. Conclusions

122
Conclusions et perspectives

Au long de cette thèse, nous nous sommes intéressés aux applications

mobiles dédiées aux transports. Notre but a été de les rendre sensibles au
contexte afin d’améliorer l’expérience de l’utilisateur. Nous avons proposés
deux modélisations de contexte pour les éléments statiques et dynamiques.
Ensuite nous avons proposé une architecture orientée services pour des
applications flexibles et réactives aux changements de contexte. Nous
avons validé nos solutions grâce à un prototype. Ce chapitre présente les
conclusions du travail effectué ainsi que les pistes à poursuivre dans des
travaux futurs.

Conclusions

Dans ce document, nous nous sommes intéressés à la problématique de l’adaptation des

applications mobiles dédiées aux transports. Nous avons remarqué l’importance d’une bonne
modélisation du contexte, qui doit être pris en compte par les applications, car il influence
leur comportement. Nous avons analysé les situations dans lesquelles les utilisateurs
se servent des applications, les situations dans lesquelles ils se trouvent ainsi que le
comportement et les réactions que l’on attend de la part de terminaux mobiles quand le
contexte change. Nous avons proposé une solution pour rendre les applications sensibles à
leur environnement et nous avons testé nos propositions grâce à un prototype de recherche.

Le contexte, élément clef des applications mobiles !

Dans un premier temps, nous nous sommes intéressés au contexte. Cette notion cache
beaucoup de significations, car il existe plusieurs éléments différents de contexte, et chacun
d’entre eux influence les applications de sa façon propre. Nous avons étudié les applications
dédiées aux transports afin de comprendre quels sont les éléments auxquels nous devons
prêter attention, et comment les applications doivent réagir au contexte.
Nos contributions à ce niveau portent sur une classification des éléments de contexte
dans le domaine des applications mobiles dédiées au transport et sur un modèle générique
d’un élément, utilisé pour le suivi du contexte à l’exécution. Dans une première phase, nous
avons regroupé les éléments de contexte qui nous semblent importants dans le cycle de
vie d’une application. Nous ne prétendons pas les avoir tous identifiés, mais nous avons
décrit plusieurs éléments importants pour le domaine des transports. Nous avons classifié
le contexte en quatre catégories, en fonction de sa source : le terminal, les éléments liés

123
à l’exécution des applications, l’environnement et l’utilisateur. Nous avons présenté notre
classification du contexte dans le paragraphe 5.1 (page 49).
Dans une deuxième phase, nous avons analysé les caractéristiques des différents éléments
de contexte, en fonction du moment de leur utilisation, de leur fréquence de changement et
de la façon dont ils influencent les applications. Nous avons identifié un important besoin
de réagir à des changements de contexte. En effet, les applications mobiles doivent être
dynamiques, connaître leur contexte d’exécution et réagir à son changement. Nous avons
mis en place un modèle simple et efficace pour les éléments qui évoluent durant l’exécution
d’une application. Nous considérons que pour les applications dédiées aux transports il est
plus important d’utiliser des modèles simples, afin de réagir vite, plutôt que créer un modèle
plus riche mais qui nécessite du temps et des ressources.
Nous avons proposé d’utiliser deux modèles de contexte, dans des buts différents.
Le premier modèle, basé sur un encodage XML, sert à décrire le profil du terminal et
celui de l’utilisateur. Ces informations sont importantes au moment de l’installation des
nouvelles fonctionnalités, qui doivent être compatibles avec le terminal et personnalisées
pour l’utilisateur. Ce modèle a été présenté dans le paragraphe 5.4.1 (page 59). Notre
deuxième modèle est orienté objets et vise les éléments dynamiques de contexte. L’objectif
de ce modèle est de suivre le contexte et détecter les changements. Nous avons illustré ce
deuxième modèle dans le paragraphe 5.4.2 (page 60).
Nos propositions, pour la classification des éléments de contexte qui influencent les
applications dédiées au transports et pour les modélisations de ces éléments, ont été validées
à travers des articles dans des conférences internationales [Pop10, DLP+ 10, PDL12b].

La plateforme d’exécution et de gestion pour les applications mobiles

En étudiant l’influence du contexte, nous avons réussi à évaluer le comportement des

applications mobiles et surtout la façon dont elles doivent réagir dans un environnement
dynamique. Dans la deuxième partie de cette thèse, nous nous sommes penchés sur l’archi-
tecture des applications afin de les rendre adaptables quand de nouvelles conditions de
fonctionnement se présentent. En effet, la façon de concevoir et d’utiliser les applications a
beaucoup évolué avec l’émergence du mobile. Le besoin de modularité des applications se
fait de plus en plus sentir de nos jours. Pour nos applications, nous nous sommes inspirés
du modèle à composants orienté services, proposé par Escoffier et al. [EHL07]. De cette
façon, nous assurons la modularité et la flexibilité des applications, grâce au couplage lâche
des services.
Nous avons intégré la notion de contexte dans les applications grâce aux services
dépendant du contexte, qui fonctionnent seulement dans certaines conditions. Nous essayons
d’identifier les influences du contexte au niveau d’un service afin d’en créer différentes
versions, une pour chaque situation identifiée. Nous avons appelé services équivalents les
diverses implémentations du même service. Notre approche consiste à former les applications
par assemblage de services, en choisissant les versions des services qui sont adéquates
aux conditions de contexte. De cette manière, si le contexte change, il suffit de changer les
fournisseurs des services dépendants du contexte qui sont affectés. Étant donné que les
couplages des services sont lâches, cela n’affecte pas les applications et peut se faire sans
les interrompre. Nous avons présenté notre proposition dans le paragraphe 6.1 (page 65).
Le mécanisme d’adaptation que nous avons proposé est simple et efficace, et c’est pour
cela qu’il est adéquat dans un milieu fortement mobile. En effet, l’utilisateur a besoin de

124
réactions rapides de la part de ses applications de transport. Une autre caractéristique des
applications mobiles que nous avons observée en analysant leur comportement est le fait
qu’elles partagent des fonctionnalités. Ainsi, nous nous sommes dirigés vers une plateforme
d’exécution permettant le partage de services entre les applications. Notre plateforme,
appelée CATS, permet la composition des applications à base de services et assure la
prise en compte et la gestion du contexte. Nous avons présenté notre plateforme dans le
paragraphe 6.2 (page 76).
Nous avons pu valider notre architecture à base de services, l’adaptation à travers des
services équivalents, ainsi que la plateforme CATS dans plusieurs articles publiés dans des
conférences et revues internationales [PDLP11, PDLD11, PDLD12].

Un prototype

Nous estimons que la solution que nous proposons apporte plusieurs avantages, res-
pectant en même temps les contraintes d’un utilisateur fortement mobile. Mais il ne suffit
pas de croire qu’une solution est bonne . . . il faut toujours tester ! Durant les deux dernières
années de thèse, nous avons mis en place et perfectionné un prototype pour notre plateforme
d’exécution et de gestion pour des services de transports sensibles au contexte, CATS. À
ce jour, le prototype contient tous les services de gestion, Context Manager, Execution
Manager et Trader, une application utilisant des services dépendants du contexte, des
implémentations équivalentes d’un même service et des modules en charge de suivre le
contexte, des Context Monitors. Nous avons présenté le prototype de la plateforme CATS
dans le paragraphe 7.2 (page 93).
Au départ, nous avons démontré la faisabilité de notre solution, en particulier la recon-
figuration dynamique des applications. Nous avons trouvé que les technologies actuelles,
telles que la plateforme OSGi et le modèle à composants iPOJO, permettent de réaliser
des applications adaptables dynamiquement. De plus, la plateforme OSGi est suffisamment
légère pour les smartphones, permettant ainsi de mettre en œuvre notre solution d’adaptation
à travers l’échange de services équivalents.
Nous avons montré dans le chapitre 8 (page 101) les scénarios de test que nous
avons réalisés grâce à notre prototype. Nos expériences ont démontré que la plateforme
proposée fonctionne de manière cohérente et avec de bons résultats sur plusieurs terminaux
Android. Cela est important car les terminaux du marché sont très hétérogènes. Nous
avons présenté des résultats qui montrent que des nouvelles fonctionnalités et de nouveaux
services peuvent être téléchargés et installés à la volée, augmentant considérablement la
qualité de l’utilisation des applications dynamiques. Cela signifie qu’une application peut
être adaptée même dans une situation qui n’avait pas été prévue au départ. Nous avons
également utilisé nos expériences pour analyser et améliorer notre mécanisme d’adaptation.
Nous avons testé la réactivité de la plateforme dans différents cas et nous avons analysé
l’impact sur la consommation de mémoire.
Les résultats obtenus grâce au prototype de la plateforme CATS ont été présentés dans
nos articles [PDLP11, PDLD11, PDLD12, PDL12b]

Bilan

Ce travail de thèse a eu pour but de proposer une solution pour la création des applica-
tions sensibles au contexte et dédiées aux transports. Nous considérons le domaine des

125
transports comme une très importante niche d’applications mobiles. En effet, les utilisateurs
mobiles, et surtout ceux participant au trafic, peuvent bénéficier de l’aide apportée par
ce type d’application. Elles peuvent même sauver des vies, en évitant des accidents (par
exemple ceux causés par des carambolages) à travers la notification des conducteurs en
cas de danger. Étant donné le contexte très dynamique dans lequel ce type d’applications
s’exécutent, il est impératif de s’adapter rapidement. Nous considérons notre solution adaptée
au problème auquel elle veut répondre : assister l’utilisateur par tout où il va et dans toutes
les circonstances. La plateforme CATS répond parfaitement à ce besoin grâce aux modules
de gestion de l’exécution et du contexte.

Perspectives

À travers cette thèse, nous offrons une solution pertinente pour un domaine d’actualité,
mais notre travail est loin d’être fini. D’un côté il reste des améliorations à faire (comme
toujours dans un travail de recherche). D’un autre côte, il faut intégrer notre solution dans
la réalité du marché des applications. Les différents acteurs du monde informatique, du
transport et de la téléphonie doivent coopérer pour donner vie aux nouvelles idées et
solutions et les intégrer de manière cohérente avec les technologies existantes. Dans cette
section, nous présentons les perspectives de notre travail ainsi que les évolutions que nous
estimons nécessaires dans les deux mondes, qui sont la recherche et l’industrie.

Nouvelles fonctionnalités pour la plateforme CATS

À court terme, nous pouvons améliorer notre travail avec des contributions au niveau de la
recherche mais aussi au niveau de l’implémentation. Nous considérons qu’il est très important
de prêter attention à la découverte de services. Durant ce travail nous avons montré que des
services peuvent être ajoutés à la volée et nous nous sommes concentrés sur ceux provenant
des pairs. Par la suite, nous voulons faire évoluer notre courtier, le Trader, afin qu’il puisse
découvrir de manière autonome les services des entités avec ce que l’on appelle une autorité
locale. Dans la version courante, le courtier réagit aux demandes de services de la part du
gestionnaire d’exécution, l’Execution Manager. Prochainement, le courtier devra détecter la
présence de l’utilisateur dans un endroit avec des services potentiellement intéressants, et
lui proposer leur installation. Par exemple, si l’utilisateur monte dans un bus, nous pouvons
estimer qu’il sera intéressé par les services liés à son moyen de transport : indication
des arrêts, calcul de la durée du trajet, zones de transit, etc. De même, un conducteur qui
a l’habitude d’utiliser un service de parking devrait être automatiquement connecté aux
services des parkings dans lesquels il entre. Nous considérons important d’avancer sur le
côté ad hoc, avec la connexion de services à proximité sans passer par une infrastructure.
Cela permet d’étendre la disponibilité des services sans encombrer le réseau téléphonique
lorsque ce n’est pas nécessaire. Parmi les travaux en cours, nous effectuons de essais liés
au téléchargement de services, incluant le temps de connexion et la quantité de données
récupérées dans une période de quelques secondes.
Les autres améliorations que nous envisageons concernent des aspects de l’adaptation
que nous n’avons pas assez approfondis. Nous nous sommes focalisés sur l’aspect dynamique
du contexte, qui nécessite une modélisation simple et efficace afin d’aboutir à des réactions
rapides. Notre modèle orienté objets a prouvé son efficacité. Par la suite, nous souhaitons
revenir sur la modélisation XML afin de la perfectionner pour la prise en compte des
préférences des utilisateurs. Un deuxième point à faire évoluer concerne l’adaptation à

126
travers des paramètres. Nous l’avons mentionné dans le paragraphe 5.2.2 (page 56) comme
alternative à l’échange des services. Nous avons préparé cette amélioration, en permettant à
n’importe quel service de s’abonner auprès du gestionnaire de contexte, le Context Manager,
afin d’être notifié des changements de contexte. Toujours dans le cadre du contexte, nous
notons l’apparition de nouveaux capteurs, capables de fournir des informations contextuelles.
Les capteurs, comme par exemple ceux mis à disposition par Arduino 1 , peuvent être intégrés
dans les systèmes informatiques afin de créer de nouvelles interactions.

Vers une application universelle dédiée aux transports

L’évolution que nous voyons à moyen terme consiste à créer une application universelle
pour le transport, qui propose une interface graphique commune pour plusieurs services.
Nous avons vu au long de ce manuscrit qu’une partie des fonctionnalités des applications sont
communes, dont le plus important exemple est la localisation. La plupart des applications
ont également besoin d’une carte, afin d’indiquer l’emplacement des points d’intérêt (place
de parking, boutique, arrêt de bus, etc.). Cette application universelle serait le compagnon
parfait d’un utilisateur qui se déplace. En fonction de l’endroit où il est, de son activité et
de ses préférences, plusieurs services pourraient s’ajouter dynamiquement à son application
et s’adapter de la même manière que nous l’avons expliqué dans ce manuscrit. Ainsi, pour
un piéton, des services de shopping ou touristiques pourraient se lancer en fonction de
l’endroit où il se trouve. Pour un conducteur, les services de sécurité routière et de parking
pourraient démarrer au moment où il commence à conduire. Finalement, pour une personne
dans un moyen de transport, l’itinéraire et les horaires aux arrêts pourraient s’afficher.
Un aspect capital de la solution que nous proposons touche à la sécurité des applications.
Rouse [Rou12] évoque ce problème : les terminaux mobiles ne seraient-ils pas le pire
environnement du point de vue de la sécurité ? De nos jours, nous possédons une multitude
d’applications sensibles aux attaques sur nos terminaux mobiles : paiements, banques,
informations médicales, ou simplement informations personnelles sur les réseaux sociaux.
Notre solution pour profiter de nouvelles fonctionnalités via le Trader pose, elle aussi, des
problèmes de sécurité. En effet, c’est un sujet à part entière qui devra être traité dans le
futur : une solution de partage de services dans des réseaux ad hoc, tout en assurant un
bon niveau de sécurité.
Un dernier aspect à prendre en considération pour aboutir à une application universelle
pour le domaine des transports concerne l’hétérogénéité des terminaux existants. L’un des
plus grands défis est posé par les systèmes d’exploitation qui sont fermés d’un point de vue
développement. Les grands acteurs dans le monde de smartphones et tablettes tactiles ont
chacun leur propre API, demandant une création d’applications spécifiques. Des travaux de
recherche s’intéressent au développement cross-plateforme, afin de simplifier la mise en
œuvre des applications pour tous les systèmes d’opération. Un exemple de travail en cours
sur ce sujet est celui de Perchat et al. [PDL12a].

Une vision du futur des applications mobiles !

Le marché des terminaux mobiles est en pleine expansion. Les smartphones et tablettes
évoluent à grands pas et envahissent nos vies (car nous sommes fascinés par ces nouvelles
technologies). Un smartphone réunit plusieurs fonctionnalités, en plus de celle de téléphone,

1. Arduino, http ://www.arduino.cc/

127
devenue pratiquement secondaire : appareil photo, baladeur mp3, galerie multimédia, naviga-
teur internet et console de jeux. De plus, de nombreuses applications sont disponibles pour
des fonctionnalités comme le shopping, la météo, le trafic, etc., ou simplement pour profiter
d’un site web en court-circuitant le navigateur et en adaptant le contenu au terminal. Les
tablettes ont des capacités similaires, et proposent en principe les mêmes applications que
les smartphones. Il y a deux importantes différences entre des deux types de terminaux : d’un
côté, la tablette ne sert pas pour téléphoner (même si quelques-unes acceptent des cartes
SIM) ; d’un autre côté, une tablette est plus puissante et offre un écran considérablement plus
grand que le smartphone. Du point de vue de l’utilisation, la tablette est plus confortable à
utiliser dans un endroit statique : à la maison, au bureau, etc. Par contre quand on est en
mouvement, elle est trop grande pour être utile. Le smartphone restera toujours le terminal
dont on ne pourra se passer et qui nous apportera de l’aide, surtout dans le cas que nous
considérons dans cette thèse, le domaine des transports.
De notre point de vue, dans le futur proche le rôle de chaque type de terminal sera
mieux défini : quand et comment est-ce qu’il sert aux utilisateurs ? Nous considérons que le
smartphone aura toujours le rôle d’accompagner les utilisateurs dans leurs déplacements. Il
faudra donc toujours concevoir les applications en conséquence : adaptées aux ressources
limitées du terminal et à l’écran de petite taille. Nous estimons qu’il ne faut pas oublier le
rôle primordial, celui de téléphone ! Une préoccupation importante devrait être d’assurer
un minimum de batterie pour téléphoner en cas d’urgence. Les applications peuvent fournir
des versions plus ou moins efficaces en termes de consommation d’énergie. Le niveau de
batterie peut, lui aussi, être considéré comme élément de contexte pour passer aux versions
plus légères des services ou des applications. Le système d’exploitation pourrait également
assurer une fonctionnalité de secours, où aucune autre application que le téléphone ne
fonctionne.
De nos jours, un grand nombre d’utilisateurs possèdent plusieurs terminaux informatiques :
smartphone, tablette tactile, ordinateur portable et/ou fixe 2 . De plus, de nombreux autres
objets sont devenus informatisés, de la télévision jusqu’au réfrigérateur ! Nous considérons
absolument nécessaire de mettre en ordre les concepts autour du contexte. Une étude
approfondie des types d’applications, appareils et situations d’utilisation devrait être faite afin
de proposer une classification complète des éléments de contexte et types d’adaptation. Un
cadre conceptuel permettrait aux différents acteurs du monde de la recherche et de l’industrie
de mieux positionner leurs contributions par rapport au type de contexte considéré. De nos
jours, de nombreux travaux expriment de manière vague leurs approches et n’identifient
pas bien les éléments de contexte utilisés. En ce qui nous concerne, nous avons commencé
ce travail de classification pour les applications mobiles dédiées au transport. Il serait
intéressant d’avoir une classification globale, qui permettrait de bien définir chaque domaine,
mais aussi de coopérer entre les domaines plus facilement.

2. En moyenne, les foyers français disposent de plus de 5 écrans – télévision, smartphone, tablette tactile,
etc. Conforme à une enquête de Médiamétrie en 2012 http ://www.lefigaro.fr/

128
Bibliographie

[ARC12] Imad Afyouni, Cyril Ray, and Christophe Claramunt, Spatial models for
context-aware indoor navigation systems : A survey, Journal of Spatial
Information Science (2012), no. 4, 85–123.
[BBC97] P.J. Brown, J.D. Bovey, and Xian Chen, Context-aware applications : from
the laboratory to the marketplace, Personal Communications, IEEE [see also
IEEE Wireless Communications] 4 (1997), no. 5, 58–64.
[BBH+ 10] Claudio Bettini, Oliver Brdiczka, Karen Henricksen, Jadwiga Indulska, Da-
niela Nicklas, Anand Ranganathan, and Daniele Riboni, A survey of context
modelling and reasoning techniques, Pervasive and Mobile Computing 6
(2010), no. 2, 161 – 180, Context Modelling, Reasoning and Management.
[BCQ+ 07] Cristiana Bolchini, Carlo A. Curino, Elisa Quintarelli, Fabio A. Schreiber, and
Letizia Tanca, A data-oriented survey of context models, SIGMOD Rec. 36
(2007), no. 4, 19–26.
[BCST06] C. Bolchini, C. Curino, F.A. Schreiber, and L. Tanca, Context integration for
mobile data tailoring, Proceedings of the Fourteenth Italian Symposium
on Advanced Database Systems, SEBD 2006, Portonovo (Ancona), 2006,
pp. 48–55.
[BD05] Christian Becker and Frank Dürr, On location models for ubiquitous compu-
ting, Personal and Ubiquitous Computing 9 (2005), 20–31, 10.1007/s00779-
004-0270-2.
[BDR07] Matthias Baldauf, Schahram Dustdar, and Florian Rosenberg, A survey on
context-aware systems, Int. J. Ad Hoc Ubiquitous Comput. 2 (2007), no. 4,
263–277.
[BHH04] Sven Buchholz, Thomas Hamann, and Gerald Hübsch, Comprehensive struc-
tured context profiles (cscp) : Design and experiences, Pervasive Computing
and Communications Workshops, IEEE Computer Society, 2004, pp. 43–47.
[BHLMFBA11] Amira Ben Hamida, Frédéric Le Mouël, Stéphane Frénot, and Mohamed
Ben Ahmed, Déploiement adaptatif d’applications orientées services sur
environnements contraints, Technique et Science Informatiques 30 (2011),
no. 1, 59–91 (Français).
[BKH08] Paolo Bellavista, Axel Kupper, and Sumi Helal, Location-based services :
Back to the future, IEEE Pervasive Computing 7 (2008), 85–89.
[BOA11] Firas Bacha, Káthia Oliveira, and Mourad Abed, Using context modeling and
domain ontology in the design of personalized user interface, International
Journal on Computer Science and Information Systems (IJCSIS) 6 (2011),
69–94.
[Boc08] Aurelien Bocquet, Infrastructure logicielle multi-modeles pour l’acces a des
services en mobilite, These de doctorat en informatique, Universite des
Sciences et Technnologies de Lille, 2008.

129
Bibliographie

[BW98] Alan W. Brown and Kurt C. Wallnau, The current state of cbse, Software,
IEEE 15 (1998), 37–46.
[CCC11] Ming-Chiao Chen, Jiann-Liang Chen, and Teng-Wen Chang, Android/osgi-
based vehicular network management system, Computer Communications 34
(2011), no. 2, 169 – 183, Special Issue : Open network service technologies
and applications.
[CCDG05] Joëlle Coutaz, James L. Crowley, Simon Dobson, and David Garlan, Context
is key, Commun. ACM 48 (2005), no. 3, 49–53.
[CCT+ 03] Gaëlle Calvary, Joëlle Coutaz, David Thevenin, Quentin Limbourg, Laurent
Bouillon, and Jean Vanderdonckt, A unifying reference framework for multi-
target user interfaces, Interacting with Computers 15 (2003), no. 3, 289 – 308,
Computer-Aided Design of User Interface.
[CDI11] Nicolas Cenerario, Thierry Delot, and Sergio Ilarri, A content-based disse-
mination protocol for vanets : Exploiting the encounter probability, IEEE
Transactions on Intelligent Transportation Systems 12 (2011), no. 3, 771–782.
[CDM11] Gabriele Costa, Pierpaolo Degano, and Fabio Martinelli, Secure service
orchestration in open networks, Journal of Systems Architecture 57 (2011),
no. 3, 231 – 239.
[Cen10] Nicolas Cenerario, Partage d’information dans les réseaux de communication
inter-véhicules, Ph.D. thesis, Universite de Valenciennes et du Hainaut
Cambresis, 2010.
[CFJ03] Harry Chen, Tim Finin, and Anupam Joshi, An ontology for context-aware
pervasive computing environments, Knowl. Eng. Rev. 18 (2003), no. 3, 197–207.
[Cha07] David chapell, introducing sca
http: // www. davidchappell. com/ articles/ Introducing_ SCA. pdf ,
juillet 2007.
[Che04] Harry Chen, An intelligent broker architecture for pervasive context-aware
systems, Ph.D. thesis, University of Maryland, Baltimore County, 2004.
[CK00] Guanling Chen and David Kotz, A survey of context-aware mobile computing
research, Tech. report, Department of Computer Science Dartmouth College,
Hanover, NH, USA, 2000.
[CLV12] Shudong Chen, Johan Lukkien, and Richard Verhoeven, A generic service ar-
chitecture for secure ubiquitous computing systems, Int’l J. of Communications,
Network and System Sciences 5 (2012), no. 1, 50–65.
[CLWK00] Xia Cai, Michael R. Lyu, Kam-Fai Wong, and Roy Ko, Component-based
software engineering : technologies, development frameworks, and quality
assurance schemes, Proceedings of the Seventh Asia-Pacific Software En-
gineering Conference (Washington, DC, USA), APSEC ’00, IEEE Computer
Society, 2000, pp. 372–380.
[CMF11] Ivan Corredor, Jose F. Martinez, and Miguel S. Familiar, Bringing pervasive
embedded networks to the service cloud : A lightweight middleware approach,
Journal of Systems Architecture 57 (2011), no. 10, 916 – 933.
[CN01] Paul Clements and Linda Northrop, Software product lines : practices and
patterns, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA,
2001.
[CRS08] Denis Conan, Romain Rouvoy, and Lionel Seinturier, COSMOS : composition
de noeuds de contexte, Technique et Science Informatiques (TSI) 27 (2008),
1189–1224.

130
 Bibliographie

[CTB+ 95] Jeremy R. Cooperstock, Koichiro Tanikoshi, Garry Beirne, Tracy Narine, and
William A. S. Buxton, Evolution of a reactive environment, Proceedings of the
SIGCHI conference on Human factors in computing systems (New York, NY,
USA), CHI ’95, ACM Press/Addison-Wesley Publishing Co., 1995, pp. 170–177.
[DA99] Anind K. Dey and Gregory D. Abowd, Towards a better understanding
of context and context-awareness, In HUC ’99 : Proceedings of the 1st
international symposium on Handheld and Ubiquitous Computing, Springer-
Verlag, 1999, pp. 304–307.
[DAS01] Anind K. Dey, Gregory D. Abowd, and Daniel Salber, A conceptual frame-
work and a toolkit for supporting the rapid prototyping of context-aware
applications, Special issue on context-aware computing ; Human-Computer
Interaction (HCI) Journal 16 (2001), no. 2, 97–166.
[DBE08] Ada Diaconescu, Johann Bourcier, and Clement Escoffier, Autonomic ipojo :
Towards self-managing middleware for ubiquitous systems, Wireless and
Mobile Computing, Networking and Communication, IEEE International
Conference on (2008), 472–477.
[Dey01] Anind K. Dey, Understanding and using context, Personal and Ubiquitous
Computing 5 (2001), no. 1, 4–7.
[DLD09] Mikael Desertot, Sylvain Lecomte, and Thierry Delot, A dynamic service-
oriented framework for the transportation domain, Intelligent Transport
Systems Telecommunications (Lille, France), 2009.
[DLP+ 10] Mikael Desertot, Sylvain Lecomte, Dana Popovici, Marie Thilliez, and Thierry
Delot, A context aware framework for services management in the transporta-
tion domain, 2010 10th Annual International Conference on New Technologies
of Distributed Systems (Tozeur, Tunisia), juin 2010, pp. 157–164.
[DLT07] Thierry Delot, Sylvain Lecomte, and Marie Thilliez, Vers l’interopérabilité des
modèles de localisation géométrique et sémantique au travers de l’utilisation
de métadonnées., Ingénierie des Systèmes d’Information 12 (2007), no. 2,
75–95.
[DMC+ 98] Nigel Davies, Keith Mitchell, Keith Cheverst, Gordon Blair, Keith Cheverst,
and Gordon Blair, Developing a context sensitive tourist guide, 1st Workshop
on Human Computer Interaction with Mobile Devices - GIST Technical Report
G98-1 (Distributed Multimedia Research Group, Department of Computing,
Lancaster University), 1998.
[DSNH10] Simon Dobson, Roy Sterritt, Paddy Nixon, and Mike Hinchey, Fulfilling the
vision of autonomic computing, Computer 43 (2010), 35–41.
[DSSK06] Anind Dey, Timothy Sohn, Sara Streng, and Justin Kodama, icap : Interactive
prototyping of context-aware applications, Pervasive Computing (Kenneth
Fishkin, Bernt Schiele, Paddy Nixon, and Aaron Quigley, eds.), Lecture
Notes in Computer Science, vol. 3968, Springer Berlin / Heidelberg, 2006,
10.1007/11748625_16, pp. 254–271.
[EDL10] Jacky Estublier, Idrissa A. Dieng, and Thomas Leveque, Software product
line evolution : the Selecta system, Proceedings of the 2010 ICSE Workshop
on Product Line Approaches in Software Engineering (New York, NY, USA),
PLEASE ’10, ACM, 2010, pp. 32–39.
[EH07] Clement Escoffier and Richard Hall, Dynamically adaptable applications with
ipojo service components, Software Composition (Markus Lumpe and Wim
Vanderperren, eds.), Lecture Notes in Computer Science, vol. 4829, Springer
Berlin / Heidelberg, 2007, pp. 113–128.

131
Bibliographie

[EHC+ 93] Scott Elrod, Gene Hall, Rick Costanza, Michael Dixon, and Jim Des Rivières,
Responsive office environments, Commun. ACM 36 (1993), no. 7, 84–85.
[EHL07] Clement Escoffier, Richard S. Hall, and Philippe Lalanda, ipojo an extensible
service-oriented component framework, IEEE International Conference on
Service Computing (SCC’07) (Salt Lake City, USA), 2007, pp. 474 – 481.
[EKT12] Christos Emmanouilidis, Remous-Aris Koutsiamanis, and Aimilia Tasidou,
Mobile guides : Taxonomy of architectures, context awareness, technologies
and applications, Journal of Network and Computer Applications (2012), no. 0,
–.
[FJM+ 01] L. Figueirdo, I. Jesus, J.A.T. Machado, J.R. Ferreira, and J.L. Martins de Carvalho,
Towards the development of intelligent transportation systems, Intelligent
Transportation Systems, 2001. Proceedings. 2001 IEEE (2001), 1206–1211.
[FLMPS11] Stéphane Frénot, Frédéric Le Mouël, Julien Ponge, and Guillaume Salagnac,
Various Extensions for the Ambient OSGi Framework, International Journal
of Adaptive, Resilient and Autonomic Systems (IJARAS) 2 (2011), no. 3, 1–12
(Anglais).
[FR11] Michael Friedewald and Oliver Raabe, Ubiquitous computing : An overview
of technology impacts, Telematics and Informatics 28 (2011), no. 2, 55 – 65.
[GC03] A. G. Ganek and T. A. Corbi, The dawning of the autonomic computing era,
IBM Syst. J. 42 (2003), no. 1, 5–18.
[GCD07] Vincent Ganneau, Gaëlle Calvary, and Rachel Demumieux, Métamodèle de
règles d’adaptation pour la plasticité des interfaces homme-machine, IHM
’07 : Proceedings of the 19th International Conference of the Association
Francophone d’Interaction Homme-Machine (New York, NY, USA), ACM, 2007,
pp. 91–98.
[GL09] Christophe Gransart and Sylvain Lecomte, Utilisation du contexte dans
l’adaptation d’applications dediees aux transports, Atelier d’Inforsid 2009
(2009).
[GLMFP11] Roya Golchay, Frédéric Le Mouël, Stéphane Frénot, and Julien Ponge, To-
wards Bridging IoT and Cloud Services : Proposing Smartphones as Mobile
and Autonomic Service Gateways, Actes des 7ème Journées Francophones de
la Mobilité et Ubiquité (UbiMob’2011) (Toulouse, France), June 2011, Position
Paper, pp. 45–48.
[GPZ04] Tao Gu, Hung Keng Pung, and Da Qing Zhang, A middleware for building
context-aware mobile services, In Proceedings of IEEE Vehicular Technology
Conference (VTC 2004), 2004.
[Gus02] RM Gustavsen, Condor–an application framework for mobility-based context-
aware applications, Concepts and Models for Ubiquitous Computing UBI-
COMP02, 2002.
[Her05] Colombe Herault, Adaptabilite des services techniques dans le modele a
composants, These de doctorat, Universite de Valenciennes et du Hainaut
Cambresis, 2005.
[HI06] Karen Henricksen and Jadwiga Indulska, Developing context-aware perva-
sive computing applications : Models and approach, Pervasive and Mobile
Computing 2 (2006), no. 1, 37 – 64.
[HIR02] Karen Henricksen, Jadwiga Indulska, and Andry Rakotonirainy, Modeling
context information in pervasive computing systems, First International Confe-
rence on Pervasive Computing, vol. 2414, 2002, pp. 167–180.

132
 Bibliographie

[HLD06] Colombe Herault, Sylvain Lecomte, and Thierry Delot, New technical services
using the component model for applications in heterogeneous environment,
Innovative Internet Community Systems (Thomas Böhme, Victor Larios Rosillo,
Helena Unger, and Herwig Unger, eds.), Lecture Notes in Computer Science,
vol. 3473, Springer Berlin / Heidelberg, 2006, pp. 99–110.
[HMM11] Petr Hnetynka, Liam Murphy, and John Murphy, Comparing the service
component architecture and fractal component model, The Computer Journal
54 (2011), 1026–1037.
[HO11] Adrian Holzer and Jan Ondrus, Mobile application market : A developer’s
perspective, Telematics and Informatics 28 (2011), no. 1, 22 – 31, Mobile
Service Architecture and Middleware.
[HPMS10] Richard S. Hall, Karl Pauls, Stuart McCulloch, and David Savage, Osgi in
action : Creating modular applications in java, Manning Publications, 2010.
[HS05] Michael N. Huhns and Munindar P. Singh, Service-oriented computing : Key
concepts and principles, Internet Computing, IEEE 9 (2005), 75–81.
[HS09] Christian Hoareau and Ichiro Satoh, Modeling and processing information for
context-aware computing : A survey, New Generation Computing 27 (2009),
no. 3, 177–196.
[HSP+ 03] T. Hofer, W. Schwinger, M. Pichler, G. Leonhartsberger, J. Altmann, and
W. Retschitzegger, Context-awareness on mobile devices - the hydrogen
approach, System Sciences. Proceedings of the 36th Annual Hawaii Interna-
tional Conference on, 2003.
[HTC11] Choonha Hwang, Elmurod Talipov, and Hojung Cha, Distributed geographic
service discovery for mobile sensor networks, Computer Networks 55 (2011),
no. 5, 1069 – 1082.
[IGH+ 11] Valérie Issarny, Nikolaos Georgantas, Sara Hachem, Apostolos Zarras, Panos
Vassiliadist, Marco Autili, Marco Gerosa, and Amira Hamida, Service-oriented
middleware for the future internet : state of the art and research directions,
Journal of Internet Services and Applications 2 (2011), 23–45, 10.1007/s13174-
011-0021-3.
[IRRH03] Jadwiga Indulska, Ricky Robinson, Andry Rakotonirainy, and Karen Henrick-
sen, Experiences in using cc/pp in context-aware systems, In Proc. of the Intl.
Conf. on Mobile Data Management (MDM, Springer, 2003, pp. 247–261.
[IS03] Jadwiga Indulska and Peter Sutton, Location management in pervasive
systems, Proceedings of the Australasian information security workshop
conference on ACSW frontiers 2003, ACSW Frontiers ’03, vol. 21, 2003,
pp. 143–151.
[Jan05] Radovan janecek, why services are not components, and vice versa
http: // www. webservices. org/ weblog/ radovan_ janecek/ why_
services_ are_ not_ components_ and_ vice_ versa
http: // radovanjanecek. net/ blog/ archives/ 296. html , 2005.
[JAS10] Martin Junghans, Sudhir Agarwal, and Rudi Studer, Towards practical seman-
tic web service discovery, The Semantic Web : Research and Applications
(Lora Aroyo, Grigoris Antoniou, Eero Hyvönen, Annette ten Teije, Heiner
Stuckenschmidt, Liliana Cabral, and Tania Tudorache, eds.), Lecture Notes in
Computer Science, vol. 6089, Springer Berlin / Heidelberg, 2010, pp. 15–29.
[JH11] Micah Jones and Kevin W. Hamlen, A service-oriented approach to mobile
code security, Procedia Computer Science 5 (2011), no. 0, 531 – 538, The 2nd

133
Bibliographie

International Conference on Ambient Systems, Networks and Technologies

(ANT-2011) / The 8th International Conference on Mobile Web Information
Systems (MobiWIS 2011).
[JHB+ 10] Shanshan Jiang, Svein Hallsteinsen, Paolo Barone, Alessandro Mamelli,
Stephan Mehlhase, Ulrich Scholz, Frank Eliassen, and Rüdiger Kapitza,
Hosting and using services with qos guarantee in self-adaptive service
systems, vol. 6115, pp. 15–28, Springer Berlin / Heidelberg, 2010.
[JHF09] Ivan Jureta, Caroline Herssens, and Stéphane Faulkner, A comprehensive
quality model for service-oriented systems, Software Quality Journal 17
(2009), 65–98, 10.1007/s11219-008-9059-2.
[JLS10] Zakwan Jaroucheh, Xiaodong Liu, and Sally Smith, Candel : Product line
based dynamic context management for pervasive applications, Proceedings
of the 2010 International Conference on Complex, Intelligent and Software
Intensive Systems (Washington, DC, USA), CISIS ’10, IEEE Computer Society,
2010, pp. 209–216.
[JS02] Changhao Jiang and Peter Steenkiste, A hybrid location model with a compu-
table location identifier for ubiquitous computing, UbiComp 2002 : Ubiquitous
Computing (Gaetano Borriello and Lars Holmquist, eds.), Lecture Notes in
Computer Science, vol. 2498, Springer Berlin / Heidelberg, 2002, pp. 307–313.
[KC03] Jeffrey O. Kephart and David M. Chess, The vision of autonomic computing,
Computer 36 (2003), no. 1, 41–50.
[Kis07] Cédric Kiss, Composite capability/preference profiles (cc/pp) : Structure and
vocabularies 2.0.
http: // www. w3. org/ TR/ CCPP-struct-vocab2/ , 2007.
[Kja07] Kristian Ellebaek Kjaer, A survey of context-aware middleware, Proceedings
of the 25th conference on IASTED International Multi-Conference : Software
Engineering (Anaheim, CA, USA), SE’07, ACTA Press, 2007, pp. 148–155.
[KKB+ 11] Matko Kuna, Hrvoje Kolarić, Iva Bojić, Mario Kušek, and Gordan Ježić,
Android/osgi-based machine-to-machine context-aware system, Proceedings
of the 11th International Conference on Telecommunications ConTEL 2011 /
Plank, Thomas, 2011.
[KPP10] Konstantinos Kakousis, Nearchos Paspallis, and George Angelos Papado-
poulos, A survey of software adaptation in mobile and ubiquitous computing,
Enterprise Information Systems 4 (2010), no. 4, 355–389.
[KPVOGM05] Manuele Kirsch-Pinheiro, Marlene Villanova-Oliver, Jerome Gensel, and
Herve Martin, Une formalisation du contexte dans les environnements co-
operatifs nomades, UbiMob ’05 : Proceedings of the 2nd French-speaking
conference on Mobility and ubiquity computing (New York, NY, USA), ACM,
2005, pp. 1–8.
[LH06] Jun Luo and Jean-Pierre Hubaux, A survey of research in inter-vehicle com-
munications, Embedded Security in Cars, Springer Berlin Heidelberg, 2006,
10.1007/3-540-28428-1_7, pp. 111–122.
[LKZ+ 01] Haiyun Luo, Jiejun Kong, Petros Zerfos, Songwu Lu, and Lixia Zhang, Pro-
viding robust and ubiquitous security support for mobile ad hoc networks,
ICNP, 2001, pp. 251–260.
[LMP05] Vincent Lenders, Martin May, and Bernhard Plattner, Service discovery in
mobile ad hoc networks : A field theoretic approach, Pervasive and Mobile
Computing 1 (2005), no. 3, 343 – 370.

134
 Bibliographie

[Lok04] Seng W. Loke, Representing and reasoning with situations for context-aware
pervasive computing : a logic programming perspective, Knowl. Eng. Rev. 19
(2004), no. 3, 213–233.
[LPH04] Hua Liu, Manish Parashar, and Salim Hariri, A component-based program-
ming model for autonomic applications, 1st International Conference on
Autonomic Computing (ICAC 2004), 2004, pp. 10–17.
[MBB08] Hamid Mukhtar, Djamel Belaid, and Guy Bernard, A policy-based approach
for resource specfication in small devices, UBICOMM ’08 : Proceedings of the
2008 The Second International Conference on Mobile Ubiquitous Computing,
Systems, Services and Technologies (Washington, DC, USA), IEEE Computer
Society, 2008, pp. 239–244.
[MBB09a] Adnan Noor Mian, Roberto Baldoni, and Roberto Beraldi, A survey of service
discovery protocols in multihop mobile ad hoc networks, IEEE Pervasive
Computing 8 (2009), no. 1, 66–74.
[MBB09b] Hamid Mukhtar, Djamel Belaid, and Guy Bernard, User preferences-based au-
tomatic device selection for multimedia user tasks in pervasive environments,
Proceedings of the 2009 Fifth International Conference on Networking and
Services (Washington, DC, USA), IEEE Computer Society, 2009, pp. 43–48.
[McI68] M. D. McIlroy, Mass-produced software components, Proceeding of NATO
Conf. on Software Engineering, Garmisch, Germany, Springer-Verlag, 1968.
[MDL10] Yoann Maurel, Ada Diaconescu, and Philippe Lalanda, Ceylon : A service-
oriented framework for building autonomic managers, Engineering of Auto-
nomic and Autonomous Systems, IEEE International Workshop on 0 (2010),
3–11.
[MK07] Daniel A. Menasce and Jeffrey O. Kephart, Guest editors’ introduction :
Autonomic computing, IEEE Internet Computing 11 (2007), no. 1, 18–21.
[MPG+ 08] Sonia Ben Mokhtar, Davy Preuveneers, Nikolaos Georgantas, Valérie Issarny,
and Yolande Berbers, Easy : Efficient semantic service discovery in pervasive
computing environments with qos and context support, Journal of Systems
and Software 81 (2008), no. 5, 785 – 808, Software Process and Product
Measurement.
[OBKH13] Daniel Oberle, Alistair Barros, Uwe Kylau, and Steffen Heinzl, A unified
description language for human to automated services, Information Systems
38 (2013), no. 1, 155 – 181.
[OWL09] Owl 2 web ontology language, w3c recommendation 27 october 2009
http: // www. w3. org/ TR/ owl-overview/ , octobre 2009.
[Pas98] J. Pascoe, Adding generic contextual capabilities to wearable computers,
ISWC, 1998, pp. 92–99.
[PB03] Paul Prekop and Mark Burnett, Activities, context and ubiquitous compu-
ting, Computer Communications 26 (2003), no. 11, 1168 – 1176, Ubiquitous
Computing.
[PBD09] Carlos Parra, Xavier Blanc, and Laurence Duchien, Context awareness for
dynamic service-oriented product lines, 13th International Software Product
Line Conference SPLC 2009 (John McGregor and Dirk Muthig, eds.), vol. 1,
08 2009, pp. 131–140.
[PDL12a] J. Perchat, M. Desertot, and S. Lecomte, Cross-platform : le nouveau challenge
dans le domaine du mobile, Ubimob’12 (Cépaduès, ed.), 2012.

135
Bibliographie

[PDL12b] Dana Popovici, Mikael Desertot, and Sylvain Lecomte, Seamless context
adaptation on a service-oriented framework, MOBILWARE (5th International
Conference on MOBILe Wireless MiddleWARE, Operating Systems, and
Applications), novembre 2012, pp. 207–220.
[PDLD11] Dana Popovici, Mikael Desertot, Sylvain Lecomte, and Thierry Delot, When
the context changes, so does my transportation application : Vespa, Procedia
Computer Science 5 (2011), no. 0, 401 – 408, The 2nd International Conference
on Ambient Systems, Networks and Technologies (ANT-2011) / The 8th
International Conference on Mobile Web Information Systems (MobiWIS
2011).
[PDLD12] Dana Popovici, Mikael Desertot, Sylvain Lecomte, and Thierry Delot, A fra-
mework for mobile and context-aware applications applied to vehicular social
networks, Social Network Analysis and Mining (2012), 1–12, 10.1007/s13278-
012-0073-9.
[PDLP11] Dana Popovici, Mikael Desertot, Sylvain Lecomte, and Nicolas Peon, Context-
aware transportation services (cats) framework for mobile environments,
International Journal of Next-Generation Computing, vol. 2, March 2011.
[PG03] Michael P. Papazoglou and D. Georgakopoulos, Service-oriented computing,
Communications of the ACM 46 (2003), 25–28.
[PH12] Juho Pesonen and Eric Horster, Near field communication technology in
tourism, Tourism Management Perspectives 4 (2012), no. 0, 11 – 18.
[PNS+ 00] D. Petrelli, E. Not, C. Strapparava, O. Stock, and M. Zancanaro, Modeling
context i s like taking pictures, Conference on Human Factors in Compu-
ters, Workshop "The What, Who, Where, When, Why and How of Context-
Awareness", 2000.
[Pop10] Dana Popovici, Context elements for transportation services, IEEE Interna-
tional Conference on Mobile Data Management, PhD Forum (2010), 287–288.
[PRM98] J. Pascoe, N. S. Ryan, and D. R. Morse, Human Computer Giraffe Interaction :
HCI in the Field, Workshop on Human Computer Interaction with Mobile
Devices (C. Johnson, ed.), GIST Technical Report G98-1, University of Glasgow,
May 1998.
[PRS06] Carsten Pils, Ioanna Roussaki, and Maria Strimpakou, Location-based context
retrieval and filtering, Location- and Context-Awareness, Lecture Notes in
Computer Science, vol. 3987, Springer Berlin / Heidelberg, 2006, pp. 256–273.
[PTDL07] Michael P. Papazoglou, Paolo Traverso, Schahram Dustdar, and Frank Ley-
mann, Service-oriented computing : State of the art and research challenges,
Computer 40 (2007), 38–45.
[RCS08] Romain Rouvoy, Denis Conan, and Lionel Seinturier, Software architecture
patterns for a context-processing middleware framework, IEEE Distributed
Systems Online 9 (2008), no. 6.
[RLS+ 11] Katharina Rasch, Fei Li, Sanjin Sehic, Rassul Ayani, and Schahram Dustdar,
Context-driven personalized service discovery in pervasive environments,
World Wide Web 14 (2011), 295–319, 10.1007/s11280-011-0112-x.
[Rou12] Jason Rouse, Mobile devices – the most hostile environment for security ?,
Network Security 2012 (2012), no. 3, 11 – 13.
[RPM98] N. S. Ryan, J. Pascoe, and D. R. Morse, Enhanced reality fieldwork : the
context-aware archaeological assistant, Computer Applications in Archaeo-
logy 1997 (Oxford) (V. Gaffney, M. van Leusen, and S. Exxon, eds.), British
Archaeological Reports, Tempus Reparatum, October 1998.

136
 Bibliographie

[RRdLC+ 06] Pierre-Guillaume Raverdy, Oriana Riva, Agnes de La Chapelle, Rafik Chi-
bout, and Valerie Issarny, Efficient context-aware service discovery in multi-
protocol pervasive environments, Proceedings of the 7th International Confe-
rence on Mobile Data Management, MDM ’06, 2006.
[SAM+ 09] F. Sailhan, I. Astic, F. Michel, C. Pitrey, M. Uy, E. Gressier-Soudan, P. Gerbaud,
and H. Forgeot, Sauvegarde du patrimoine en cas de sinistre : conception
d’une solution de localisation et de surveillance a base de RFIDs actifs,
défis et perspectives. 2ème Atelier sur la Gestion des Données dans les
Systèmes d’Information Pervasifs, Atelier sur la GEstion des Données dans
les Systèmes d’Information Pervasifs (GEDSIP) au sein de la conférence
INFormatique des ORganisations et Systèmes d’Information et de Décision
(INFORSID), January 2009, pp. 1–15.
[Sat01] M. Satyanarayanan, Pervasive computing : Vision and challenges, Personal
Communications, IEEE 8 (2001), 10–17.
[SC07] Jérôme Simonin and Noelle Carbonell, Interfaces adaptatives adaptation
dynamique à l’utilisateur courant, CoRR abs/0708.3742 (2007).
[sca05] Service component architecture (sca)
http: // xml. coverpages. org/ SCA-Announce200512. html , novembre
2005.
[SCD09] Ahmet Soylu, Patrick De Causmaecker, and Piet Desmet, Context and adap-
tivity in pervasive computing environments : Links with software engineering
and ontological engineering, Journal of Software (2009), 992–1013.
[SCF+ 10] Andre C. Santos, Joao M.P. Cardoso, Diogo R. Ferreira, Pedro C. Diniz, and
Paulo Chainho, Providing user context for mobile and social networking
applications, Pervasive and Mobile Computing 6 (2010), no. 3, 324 – 341.
[SK08] Mihail L. Sichitiu and Maria Kihl, Inter-vehicle communication systems :
A survey, IEEE Communications Surveys and Tutorials 10 (2008), no. 1-4,
88–105.
[SLP04] Thomas Strang and Claudia Linnhoff-Popien, A context modeling survey,
Workshop on Advanced Context Modelling, Reasoning and Management,
UbiComp 2004 - The Sixth International Conference on Ubiquitous Computing,
September 2004.
[SO10] Patrick Sondi-Obwang, Le routage à qualité de service dans les réseaux
mobiles ad hoc, Ph.D. thesis, Université de Valenciennes et du Hainaut-
Cambrésis, 2010.
[SS09a] Salma Ben Sassi and Nicolas Le Sommer, Towards an opportunistic and
location-aware service provision in disconnected mobile ad hoc networks,
MobileWireless Middleware, Operating Systems, and Applications, Lecture
Notes of the Institute for Computer Sciences, Social Informatics and Te-
lecommunications Engineering, vol. 7, Springer Berlin Heidelberg, 2009,
pp. 393–406.
[SS09b] , Une plate-forme intergicielle pour la découverte et l’invocation de
services géolocalisés dans les réseaux ad hoc discontinus, 9e Conférence
Internationale sur les NOuvelles TEchnologies de la REpartition (Notere
2009) (Montréal, Canada), Université de Québec à Montréal, July 2009,
pp. 28–37.
[ST94] Bill Schilit and M. Theimer, Disseminating active map information to mobile
hosts, IEEE Network 8 (1994), no. 5, 22–32.

137
Bibliographie

[ST05] L. Srinivasan and J. Treadwell, An overview of service-oriented architecture,

web services and grid computing, HP Software Global Business Unit (2005).
[STZ05] Xuehua Shen, Bin Tan, and ChengXiang Zhai, Context-sensitive information
retrieval using implicit feedback, Proceedings of the 28th annual international
ACM SIGIR conference on Research and development in information retrieval
(New York, NY, USA), SIGIR ’05, ACM, 2005, pp. 43–50.
[Toh01] Chai K Toh, Ad hoc mobile wireless networks : Protocols and systems,
Prentice Hall, 2001.
[UDD02] Universal description discovery and integration
https: // www. oasis-open. org/ committees/ uddi-spec/ doc/ tcspecs.
htm , 2002.
[VP08] Christopher N. Ververidis and George C. Polyzos, Service discovery for mobile
ad hoc networks : a survey of issues and techniques, Communications Surveys
& Tutorials, IEEE 10 (2008), no. 3, 30–45.
[VRdL05] Alex Varshavsky, Bradley Reid, and Eyal de Lara, A cross-layer approach to
service discovery and selection in manets, IEEE International Conference on
Mobile Adhoc and Sensor Systems Conference (2005), 466.
[VSS+ 11] Tim Verbelen, Tim Stevens, Pieter Simoens, Filip De Turck, and Bart Dhoedt,
Dynamic deployment and quality adaptation for mobile augmented reality
applications, Journal of Systems and Software 84 (2011), no. 11, 1871 – 1882,
Mobile Applications : Status and Trends.
[Wei91] M. Weiser, The computer for the 21st century, Scientific American (1991).
[WHFaG92] Roy Want, Andy Hopper, Veronica Falcão, and Jonathan Gibbons, The active
badge location system, ACM Trans. Inf. Syst. 10 (1992), no. 1, 91–102.
[WSD07] Web services description language (wsdl) version 2.0
http: // www. w3. org/ TR/ wsdl20/ , juin 2007.
[WTM09] T. L. Willke, P. Tientrakool, and N. F. Maxemchuk, A survey of inter-vehicle
communication protocols and their applications, Communications Surveys &
Tutorials 11 (2009), no. 2, 3–20.
[ZMN05] Feng Zhu, Matt W. Mutka, and Lionel M. Ni, Service discovery in pervasive
computing environments, IEEE Pervasive Computing 4 (2005), no. 4, 81–90.

138
Résumé

De nos jours, la façon d’utiliser les applications mobiles dans le domaine des transports
offre de nouveaux défis liés aux spécificités de l’environnement, comme la forte mobilité des
terminaux, leur répartition, ou encore le réseau instable de communication. La plupart des
applications existantes ont des contraintes de fonctionnement qui les rendent inadaptées si
les conditions d’exécution évoluent rapidement. Cela rend intéressant l’utilisation d’un cadre
unifié de conception et d’exécution, capable de gérer ces applications.
Nos travaux portent, dans un premier temps, sur une étude des applications mobiles et
de leur comportement, en fonction du contexte d’exécution. Nous considérons le cas des
applications dédiées aux transports, conçues pour accompagner et assister un usager dans
son déplacement (navigation, sécurité routière, applications des moyens de transports, etc.).
Nous identifions les éléments du contexte propres aux applications fortement mobiles et les
modélisons.
Dans un second temps, nous proposons un cadre dynamique et sensible au contexte,
permettant le déploiement de nouveaux services « à la volée » ainsi que leur adaptation pour
une meilleure utilisation des ressources dans des milieux très évolutifs. Nous nous focalisons
sur le côté réactif, permettant d’adapter le comportement des applications à leurs nouvelles
conditions d’utilisation. Les applications sont décomposées en services de base avec un
couplage lâche pour une plus grande flexibilité. Nous utilisons une architecture orientée
service, qui permet la réutilisation des services communs à plusieurs applications mais aussi
la gestion du contexte au travers de services équivalents mais capables de fonctionner dans
des conditions différentes.
Nous montrons, grâce au prototype de notre plateforme CATS (Context-Aware Transporta-
tion Services), d’abord la faisabilité d’une plateforme à services sur des terminaux portables.
Nous testons ensuite plusieurs scénarios afin de démontrer la réactivité des adaptations
aux changements de contexte. Dans cette thèse nous proposons une vue d’ensemble sur la
création et la gestion des applications sensibles au contexte pour le domaine des transports.
Le but de notre démarche est d’assurer le bon fonctionnement de l’ensemble des applications
d’un utilisateur, malgré les changements dynamiques du contexte.

Mots clefs :
Contexte ; Application sensible au contexte ; Architecture orientée service ; Mobilité.
Abstract

The use of mobile applications in the transportation domain raises a multitude of

challenges, related to the specific execution environment: highly mobile and distributed
devices, unstable communication networks, etc. Most of the existing applications are not
flexible enough to cope with the rapidly changing environment. It would be interesting to
provide a unified frame for the design and execution of such applications, offering management
capabilities as well.
We propose a study of the mobile applications and their behavior in relation with the
context. We consider a certain type of applications, designed to accompany and assist users
on the move (navigation, traffic security, applications related to a means of transport, etc.).
We identify the context elements which are characteristic to highly mobile applications and
we propose a context model for the transportation domain.
In order to handle multiple applications at a time, we propose a dynamic and context-
aware framework, capable of deploying services “on the fly”. We consider applications built
through the assembly of services, allowing them to adapt to the execution environment and
make the best use of the available resources. We focus on the reaction of the applications
to the changes in the environment. Applications are built of services and thus benefit from
loose coupling, allowing them to be flexible. A service oriented architecture brings further
advantages, notably that services can be shared between applications and that a service
can have multiple implementations. We manage the adaptation to new conditions of use
through equivalent services built for different context situations.
The framework that we have proposed, called CATS (Context-Aware Transportation
Services), has been tested thanks to a prototype. We were able to prove the feasibility of
the framework as well as evaluate several testing scenarios, showing the reactivity of the
applications to context changes. This work proposes a complete view of the design and
management of context-aware applications for the transport domain. Our goal is to enhance
user experience by ensuring the well functioning of his/her applications despite the ever
changing context.

Keywords:
Context; Context-aware applications; Service Oriented Architecture; Mobility.