système d’accès personnalisé à l’information :...

N° d’ordre 2008-ISAL-0092 Année 2008

Thèse

Système d’Accès Personnalisé à l’Information :

Application au Domaine Médical

Présentée devant L’Institut National des Sciences Appliquées de Lyon

Pour obtenir

Le grade de docteur

École doctorale : Informatique et Information pour la Société (EDIIS) Spécialité : Informatique

Par

Karine Al Makssoud épouse ABBAS

Soutenue le 9 décembre 2008 devant la Commission d’examen

Jury MM.

Président P. RUBEL Professeur (INSA de Lyon) Rapporteur D. RIEU Professeur (Université de Grenoble) Rapporteur J-L CAVARERO Professeur (Université Nice-Sophia Antipolis) Examinateur M. GOURGAND Professeur (Université de Clermont-Ferrand) Directeur A.Flory Professeur (INSA de Lyon) Co-directrice C. VERDIER Professeur (Université de Grenoble)

Karine ABBAS / Thèse en informatique / 2008 / Institut national des sciences appliquées de Lyon

Système d’Accès Personnalisé à l’information : Application au domaine médical

Résumé

Le travail mené dans le cadre de cette thèse repose sur une problématique centrale : la personnalisation de l’accès à l’information. En effet, face à la croissance considérable des données, à l’hétérogénéité des rôles et des besoins et au rapide développement des systèmes mobiles, il devient important de proposer un système personnalisé capable de fournir à l’utilisateur une information pertienente et adaptée à ses besoins et son utilisation quotidienne. Ce système doit prendre en considération les différentes caractéristiques de l’utilisateur ainsi que l’ensemble des situations contextuelles qui influence son comportement lors de son interaction avec le système d’information.

Le système d’accès personnalisé à l’information que nous proposons est basé sur le principe de la gestion des profils. Un modèle générique du profil est proposé afin de couvrir l’ensemble des facettes de la personnalisation. Ce modèle est capable de collecter des informations sur l’utilisateur et son contexte d’utilisation et de représenter tout besoin de personnalisation une fois modélisé.

Le système de personnalisation est fondé principalement sur trois éléments : les profils, le contexte et les services. Les profils sont des conteneurs des connaissances sur l’utilisateur. Le contexte définit un ensemble de paramètres qui caractérisent l’environnement d’utilisation du système. Les services sont des programmes autonomes capables d’exécuter les tâches de la personnalisation. Le processus de la personnalisation est déclenché lorsque l’utilisateur envoie une requête et appliqué sur des données structurées extraites des différentes sources de données en réponse à cette requête. Mots-Clés: accès personnalisé – système d’information – modèle générique des profils – contexte – services – interface adaptative – personnalisation des données – gestion de la personnalisation – schéma XML – utilisateur


Personalised Access System to information: Application to the medical domain

Abstract

The thesis work relays on a central problematic : the personalisation access to information. Indeed, with the considerable growth of data, the heterogeneity of roles and needs and the spread development of mobile systems, it becomes important to propose a personalised system to get relevent information. This system allows to user to provide relevent and adapted information. This system takes into account the different user characteristics as well as the different contextual situations which influence his behavior during the information access process.

The personalised access system we propose is based on the profiles management. A generic profile model is defined to cover all personalisation facets. The model is able to collect information on user and his context of use and to represent all personalisation needs. The personalised system is mainly founded on three elements : the profiles, the context and the services. The profiles are containers of knowledge on users. The context defines a set of parameters characterising the user environment when the system is used. The services are autonomous programs able to execut the personalisation tasks. The personalisation process starts when the user sends a request that produces the extraction of data useful for it. Keywords: personalised access – information system– generic profile model – context – services – adaptive interface – data personalisation – management of personalisation needs– XML Schema – user


Remerciements

Tout d’abord, je voudrais remercier, mes deux directeurs de thèse, Monsieur André Flory et Madame Christine Verdier, pour leur encadrement et pour leurs précieux conseils tout au long de la thèse. Je leur remercie pour leurs encouragements, leur soutien et leur patience qui m’a beaucoup aidé pour mener à bien ce travail de thèse. Je suis particulièrement reconnaissant aux Professeurs Dominique Rieu et Jean Louis Cavarero qui ont honoré mon travail de thèse en acceptant de le rapporter. Je les remercie de l’intérêt qu’ils y ont porté. Je remercie également Le Professeur Paul Rubel d’avoir bien voulu présider le jury lors de ma soutenance de thèse ainsi que Le Professeur Michel Gourgand d’avoir accepté d’être examinateur. Je tiens également à remercier Monsieur Robert Laurini de la sympathie qu’il m’a toujours manifestée. Je souhaiterais remercier les membres du laboratoire LIRIS du bâtiment Blaise Pascal ainsi que mes collègues du bureau de leur collaboration et de leur sympathie pendant toute la durée que j’ai passée avec eux. Enfin, un grand merci à mon mari qui n’a pas arrêté de m’encourager durant toute la durée et les étapes de ma thèse. Un grand bisous à mes trois enfants qui m’ont apporté du soutien moral durant mon travail de thèse.

Table des matières


Chapitre 1 Introduction générale

1 Introduction générale ............................................................ 1

1.1 Problématique...................................................................................... 2

1.2 Contribution ........................................................................................ 4

1.3 Plan du mémoire .................................................................................. 5

Chapitre 2 Etat de l’art

2 Etat de l’art ........................................................................... 8

2.1 Introduction ......................................................................................... 8

2.2 L’adaptation et la personnalisation des systèmes d’informations.......... 9 2.2.1 Les dimensions de l’adaptation ............................................................ 9

2.2.1.1 Adaptation du contenu ............................................................. 9 2.2.1.2 Adaptation de la présentation ..................................................10 2.2.1.3 Adaptation de la navigation.....................................................10 2.2.1.4 Adaptation de la structure .......................................................11 2.2.1.5 Adaptation des fonctionnalités ................................................11 2.2.1.6 Adaptation des services web....................................................12

2.2.2 Processus de la personnalisation .........................................................13 2.2.3 Les services de personnalisation .........................................................17

2.2.3.1 La recommandation.................................................................17 2.2.3.2 L’enrichissement des requêtes .................................................18 2.2.3.4 Le filtrage des résultats des requêtes .......................................20

2.2.4 Conclusion..........................................................................................22

2.3 Modélisation de l’utilisateur ...............................................................22 2.3.1 Classification des modèles de l’utilisateur ..........................................23

2.3.1.1 Buts ........................................................................................24 2.3.1.2 Préférences .............................................................................24 2.3.1.3 Expériences, connaissances et compétences ............................24


2.3.1.4 Autres caractéristiques ............................................................24 2.3.2 Représentation du profil de l’utilisateur ..............................................25 2.3.3 Techniques de construction et mise à jour des profils..........................27

2.3.3.1 Techniques d’apprentissage.....................................................28 2.3.3.1.1 Raisonnement à partir de cas...................................29 2.3.3.1.2 Les classificateurs / réseaux bayésiens ....................31 2.3.3.1.3 Les méthodes de clustering .....................................32 2.3.3.1.4 Les règles d’association ..........................................33 2.3.3.1.5 Les agents intelligents.............................................34

2.3.3.2 Algorithmes de filtrage social .................................................35 2.3.4 Conclusion..........................................................................................36

2.4 Système sensible au contexte et système pervasif ...............................37 2.4.1 Système pervasif.................................................................................37 2.4.2 Sensibilité au contexte ........................................................................37 2.4.3 Notion du contexte..............................................................................39 2.4.4 Architecture d’un système sensible au contexte ..................................40

2.4.4.1 Couche d’acquisition du contexte ............................................40 2.4.4.2. Couche d’Interprétation et d’agrégation du contexte ..............41 2.4.4.3. Couche de stockage et historique du contexte.........................41 2.4.4.4. La couche dissémination du contexte .....................................42 2.5.4.5. La couche application ............................................................42

2.6 Conclusion..........................................................................................42

Chapitre 3 Proposition : objectif, architecture et approche

3 Architecture générale de l’approche de la personnalisation . 45

3.1 Introduction ........................................................................................45

3.2 Présentation de l’approche de personnalisation ...................................45 3.2.1 Cadre général de l’approche de la personnalisation .............................45 3.2.2 Objectif de l’approche de la personnalisation......................................48

3.3 Modèle sous-jacents au processus de personnalisation ......................48 3.3.1 Modèle du profil .................................................................................48


3.3.1.1 Modélisation du profil ...........................................................48 3.3.1.2 Méta-description du modèle ....................................................50 3.3.1.3 Description du profil ...............................................................56 3.3.1.4 Instanciation du profil .............................................................58

3.3.2 Modèle du Contexte d’utilisation ........................................................59 1.3.2.1 Formalisation du contexte d’utilisation ...................................59 3.3.2.2 Situation contextuelle ............................................................61

3.3.2.3 Relation d’héritage entre les profils ....................................................61 3.3.3 Modèle des services ............................................................................63

3.3.3.1 Notion du service ..................................................................64 3.3.3.2 Modélisation des services ......................................................64

3.4 Conclusion ..........................................................................................67

Chapitre 4 Exploitation des modèles de profils dans le processus de la personnalisation

4 Exploitation des modèles de profils dans le processus de personnalisation .................................................................. 70

4.1 Introduction ........................................................................................70

4.2 Architecture générale de l’approche de la personnalisation .................70

4.3 Gestion des profils ..............................................................................72 4.3.1 Création des profils.............................................................................73

4.3.1.1 Création de la structure d’un profil..........................................74 4.3.1.2 Modélisation du besoin ...........................................................75 4.3.1.5 Règles de traduction d’un modèle UML en schéma XML........78 4.3.1.6 Intégration du schéma XML dans la structure du profil relative à

un sujet donné .......................................................................85 4.3.1.7 Insertion des données dans les profils......................................88 4.3.1.8 Acteurs du module de gestion des profils ................................92

4.3.2 Gestion des droits d’accès aux profils .................................................93 4.3.2.1 Modèles de contrôle d’accès..................................................93


4.3.2.2 Modèles de contrôle d’accès discrétionnaire ..........................94 4.3.2.3 Modèles de contrôle d’accès obligatoires...............................94 4.3.2.4 Modèles de contrôle d’accès basé sur les rôles ......................95 4.3.2.5 Modélisation des droits d’accès dans notre module de gestion

des profils .............................................................................97 4.3.2.6 Hiérarchie d’accès entre les rôles ..........................................99 4.3.2.7 Hiérarchie d’accès entre les objets.........................................99 4.3.2.8 Contraintes ..........................................................................100 4.3.2.9 Mise en œuvre du système d’accès ......................................101 4.3.2.10 Conclusion ..........................................................................105

4.4 Gestion du contexte ..........................................................................105 4.4.1 Fournisseur du contexte (Context provider) ......................................106 2.4.2 Registre de contexte..........................................................................107 4.4.3 Conclusion........................................................................................107

4.5 Gestion des services..........................................................................108 4.5.1 Association d’un service à une entité du profil..................................110 4.5.2 Ordre d’exécution des services .........................................................113

4.6 Exploitation des profils et des services dans la mise en œuvre de la personnalisation................................................................................115

4.6.2 Utilisation des profils dans le processus de la personnalisation .........116 4.6.3 Sélection des services pour personnaliser l’information ....................123 4.7 Conclusion........................................................................................124

Chapitre 5 Mise en œuvre de la personnalisation

5 Mise en œuvre de la personnalisation................................ 127

5.1 Introduction ......................................................................................127

5.2 Personnalisation du contenu..............................................................127

5.3 Personnalisation de la présentation ...................................................140


5.4 Conclusion........................................................................................147

Chapitre 6 Implémentation de l’approche de la personnalisation

6 Implémentation de l’approche de la personnalisation ........ 149

6.1 Introduction ......................................................................................149

6.2 Architecture logicielle de l’approche de la personnalisation..............149

6.3 Scénario générique d’utilisation du système de personnalisation .......172

6.4 Application au projet SGI2 ...............................................................173

6.5 Conclusion........................................................................................174

Chapitre 7 Conclusion

7 Conclusion ........................................................................ 176

7.1 Bilan du travail réalisé ......................................................................176

7.2 Perspectives......................................................................................177


Table des figures


Figure 2.1 Différents types de processus d’adaptation : de l’adaptabilité à l’adaptativité. ..................................................................................................16 Figure 2.2 Représentation graphique d’un profil utilisateur.............................19 Figure 2.3 Modèle général pour le filtrage d’information ................................21 Figure 2.4 utilisateur et modèle utilisateur .....................................................23 Figure 2.5 Utilisation du raisonnement à partir de cas dans Cosydor ..............30 Figure 2.6 Filtrage collaboratif .......................................................................36 Figure 2.7 Architecture générale d’un système sensible au contexte................40


Figure 3.1 Cadre général de l’approche de la personnalisation .......................46 Figure 3.2 Principe de l’approche de la personnalisation ................................47 Figure 3.3 Classe sujet vue comme une super-classe des objets décrits par des profils ..............................................................................................................51 Figure 3.4 Modélisation générale du profil ......................................................53 Figure 3.5 Association EstDecrit .....................................................................54 Figure 3.6 Exemple d’une relation de décomposition entre la classe profil et la classe dimension ..............................................................................................54 Figure 3.7 Exemple de l’association estAssocie ...............................................55 Figure 3.8 Exemple de l’association depend ....................................................56 Figure 3.9 Exemple de description d’un profil .................................................57 Figure 3.10 Exemple d’instanciation d’un profil ..............................................58 Figure 3.11 Facettes du contexte......................................................................60 Figure 3.12 Description du contexte ................................................................60 Figure 3.13 Représentation conceptuelle des paramètres du contexte ..............61 Figure 3.14 Exemple d’une situation contextuelle ............................................61 Figure 3.15 Exemple d’héritage entre les profils ..............................................62 Figure 3.16 Représentation de la relation de dépendance en XML ...................63 Figure 3.17 Modélisation des paramètres d’entrée et des sorties d’un service..65 Figure 3.18 Principe de fonctionnement des services .......................................65 Figure 3.19 Diagramme de classes de la modélisation des services..................66 Figure 3.20 Représentation des services en XML .............................................67



Figure 4.1 Architecture générale de l’approche de la personnalisation..........72 Figure 4.2 Ensemble des tâches du module de gestion des profils ....................73 Figure 4.3 Diagramme d’activités de la création d’une structure d’un profil ...75 Figure 4.4 Exemple d’un modèle de besoin ......................................................76 Figure 4.5 Principe de traduction entre UML et schéma XML..........................77 Figure 4.4.6 Traduction des classes et attributs ...............................................79 Figure 4.7 Choix de la racine...........................................................................79 Figure 4.8 Traitement des associations ............................................................80 Figure 4.9 Relation de décomposition/d’agrégation .........................................81 Figure 4.10 Relation d’héritage .......................................................................82 Figure 4.11 Traduction de la classe Concept ...................................................83 Figure 4.12 Traduction d’un modèle de besoin en schéma XML .......................84 Figure 4.13 Algorithme général de l’intégration du schéma xml du besoin dans la structure du profil ........................................................................................87 Figure 4.14 Principe de représentation de la structure et du contenu en schéma XML.................................................................................................................88 Figure 4.15 Correspondance entre les éléments de profil en UML et XML .......89 Figure 4.16 Algorithme général d’insertion des données dans les profils .........91 Figure 4.17 Modèle RBAC ...............................................................................96 Figure 4.18 Classe Objet .................................................................................97 Figure 4.19 Relation Autorise .........................................................................98 Figure 4.20 Relation Joue ................................................................................98 Figure 4.21 Relation Generaliser .....................................................................99 Figure 4.4.22 Hiérarchie des rôles...................................................................99 Figure 4.23 Profil des droits d’accès .............................................................102 Figure 4.24 Principe de fonctionnement des droits d’accès ............................102 Figure 4.25 Gestion du contexte.....................................................................106 Figure 4.26 Modélisation d’un fournisseur de contexte ..................................106 Figure 4.27 Modélisation d’un registre de contexte........................................107 Figure 4.28 Modélisation d’un courtier de contexte .......................................107 Figure 4.29 Principe d’association entre les services et les profils ................108 Figure 4.30 Services dans les deux phases de la personnalisation ..................109 Figure 4.31 Modélisation de l’association d’un service à une entité du profil......................................................................................................................110 Figure 4.32 Extrait de la représentation XML de l’association entre les services et les entités d’un profil .................................................................................111 Figure 4.33 Exemple d’association entre les éléments d’un profil et les services......................................................................................................................112 Figure 4.34 Algorithme de calcul de l’ordre d’exécution des services ............114


Figure 4.35 Ordre d’exécution des services ...................................................115 Figure 4.36 Principe de mise en œuvre de la personnalisation .......................116 Figure 4.37 la situation contextuelle exprimée dans une structure XML .........117 Figure 4.38 Exemple d’un profil ....................................................................118 Figure 4.39 Extrait d’un profil correspondant à la structure définie dans la figure 4.38 .....................................................................................................120 Figure 4.40 Algorithme générale d’utilisation des profils dans le processus de la personnalisation ............................................................................................122 Figure 4.41 Exemple d’un profil valide ..........................................................123 Figure 4.42 Algorithme général de sélection des services ..............................124


Figure 5.1 principe de la personnalisation du contenu ...................................128 Figure 5.2 Relation de correspondance entre un élément du document XML et un élément objet du profil ...................................................................................129 Figure 5.3 Fonctionnement d’un service ........................................................129 Figure 5.4 Principe de la personnalisation du contenu...................................130 Figure 5.5 Algorithme de la fonction accessProfile ........................................131 Figure 5.6 Exemple du contenu du document mapping.xml.............................131 Figure 5.7 Algorithme de la fonction mapping ...............................................132 Figure 5.8 Exemple d’une opération de mapping ...........................................133 Figure 5.9 Principe de suppression des données ............................................134 Figure 5.10 Principe de masquage partiel des données ..................................136 Figure 5.11 principe du masquage total .........................................................137 Figure 5.12 Principe de l’ajout des données ..................................................138 Figure 5.13 Principe de la modification des données .....................................139 Figure 5.14 Principe de l’exécution d’une action sur une donnée...................140 Figure 5.15 Principe de la personnalisation de présentation..........................141 Figure 5.16 Description abstraire d’une fenêtre.............................................142 Figure 5.17 Modélisation des composants d’une fenêtre ................................142 Figure 5.18 Relation d’association entre le service et la zone d’affichage......143 Figure 5.19 Fonctionnement d’un service de présentation..............................144 Figure 5.20 Algorithme pour affichage du résultat dans une nouvelle zone ....145 Figure 5.21 Principe de génération d’une nouvelle fenêtre contenant une nouvelle zone .................................................................................................146



Figure 6.1Architecture logicielle en trois couches d’un module .....................150 Figure 6.2 Diagramme des paquetages de l’approche de la personnalisation.151 Figure 6.3 Diagramme des cas d’utilisation ....................................................153 Figure 6.4 Paquetage regroupant les classes de gestion des profils.....................154 Figure 6.5 Architecture de l’interface de gestion des profils ..............................156 Figure 6.6 Diagramme de collaboration décrivant la création d’un profil......158 Figure 6.7 Ecran utilisé pour créer un profil..................................................158 Figure 6.8 Diagramme de collaboration d’insertion automatique du schéma.......159 Figure 6.9 Ecran d’insertion du schéma xml dans le profil .................................160 Figure 6.10 Diagramme de collaboration d’instanciation des profils ..................161 Figure 6.11 Ecran illustrant l’instanciation des profils ......................................162 Figure 6.12 Stockage des profils ......................................................................163 Figure 6.13 Diagramme de classes du paquetage contextManagement................164 Figure 6.14 Diagramme des cas d’utilisation....................................................165 Figure 6.15 Digramme de paquetage des services ............................................166 Figure 6.16 Architecture d’écrans du module de gestion des services..................167 Figure 6.17 Stockage des services dans la base de connaissances.......................167 Figure 6.18 Diagramme des cas d’utilisation....................................................167 Figure 6.19 Diagramme de collaboration décrivant la sélection des profils .........169 Figure 6.20 Diagramme de collaboration décrivant le scénario d’invocation des services...........................................................................................................170 Figure 6.21 Diagramme de classes du paquetage personnalisationManagement ..171 Figure 6.22 Diagramme des classes de paquetage stockageManagement ............172

igure 6.23 Architecture du Middleware sémantique: SGI2 ...............................174 F


Chapitre 1 Introduction générale

Karine ABBAS / Thèse en informatique / 2008 / Institut national des sciences appliquées de Lyon 1

1 Introduction générale

1.1 Problématique

La personnalisation de l’information est vue comme un processus qui change la fonctionnalité, l’interface, la teneur en information ou l’aspect d’un système pour augmenter sa pertinence en fonction des caractéristiques de l’utilisateur. Ce processus peut être décrit en trois étapes : collecte des informations sur les utilisateurs, utilisation de ces informations dans l’initialisation et la construction du modèle utilisateur et exploitation de ces données dans la personnalisation des réponses. Il a pour objectif, d’une part, de faciliter l’expression du besoin de l’utilisateur et de rechercher des informations sur un sujet donné en écartant l’information non-pertinente et donc réduire considérablement l’espace de recherche, d’autre part, de rendre cette information sélectionnée intelligible à l’usager et exploitable.

Personnaliser une information ou une application à un utilisateur particulier nécessite donc de disposer d’informations sur ce dernier permettant d’aider le système à faire des choix. Ces données persistantes caractérisant un utilisateur ou un groupe d’utilisateurs sont souvent organisées et structurées sous forme d’un modèle, appelé souvent, le modèle utilisateur (ou le profil utilisateur). Ce modèle est défini comme une source de connaissances, une base de données sur l’utilisateur telles que les préférences, les centres d’intérêts, les compétences, les droits d’accès, la qualité de l’information désirée, les modes de production, les préférences d’affichage ou d’ordonnancement.

La personnalisation ne cesse de préoccuper jusqu’à aujourd’hui les chercheurs dans divers domaines de recherche: économique, scientifique, éducatif, commercial, etc. En effet, L’accès à une information pertinente, adaptée aux besoins et au contexte de l’utilisateur constitue des facteurs clés du succès de ces systèmes. Ce réel besoin de personnalisation est particulièrement caractérisé par un ensemble de défis :

- un accroissement d’informations hétérogènes (données textuelles, documents textuels, images, composants logiciels, services, etc.) conduisant à des volumes considérables. Au fur et à mesure que le volume des données s’accroît et que les données se diversifient, il devient de plus en plus difficile à l’utilisateur de retrouver l’information qu’il recherche dans les résultats massifs que délivrent les systèmes d’information pour répondre à sa requête.

- les utilisateurs ont des rôles et des compétences de plus en plus diversifiés. Devant cet état de fait, il devient difficile pour les systèmes d’information classiques de satisfaire les besoins de ces utilisateurs sans prise en compte de leurs centres


d’intérêts récurrents, ni de leurs préférences, ni du contexte de recherche. En effet, ces systèmes estiment que l’utilisateur est complètement représenté par sa requête : les résultats retournés pour une même requête sont identiques même si elle est exprimée par des utilisateurs différents. En conséquence, toutes les informations retournées ne sont pas forcément pertinentes pour un même utilisateur et tous les utilisateurs ne sont pas intéressés par les mêmes informations.

- des nouveaux défis sont apparus avec l’avancée technologique dans le domaine pervasifs. Ces systèmes permettent à l’utilisateur d’être de plus en plus mobile et ainsi d’accéder aux informations quelque soient le lieu, le support et les contraintes. Donc il devient une nécessité que les systèmes de recherche actuels tiennent en compte du contexte de l’utilisateur qui a certainement de l’influence sur le comportement de l’utilisateur pendant sa recherche de l’information.

- la construction du modèle utilisateur est l’étape la plus importante dans le processus de la personnalisation. Donc il est important de proposer une vision globale ou un modèle global qui couvre tous les besoins en terme de personnalisation. Comme nous le verrons, la majorité des solutions existantes dans la littérature sont conçues à des besoins de personnalisation prédéfinis (préférences, centre d’intérêt, etc.) pour des domaines spécifiques (e-lerning, commerce électronique, bibliothèque digitale, etc.). Ils se focalisent sur des aspects parcellaires de l’utilisateur qui sont exploités, selon leur nature, dans une ou plusieurs phases du processus. Donc aucun modèle n’est proposé pour traduire une connaissance globale de l’utilisateur. Ces systèmes souffrent de la complexité lors d’un besoin de la mise à jour ou d’ajout des nouvelles fonctionnalités ce qui nécessiterait dans certains cas la reprise totale du cycle de vie de l’application afin de fournir une nouvelle version qui supporte les nouveaux besoins en terme de personnalisation. En plus, il n’existe pas dans la littérature de manière claire et détaillée une technique qui décrit les différents étapes de modélisation du profil (construction d’un modèle générique, collection et initialisation du profil).

- les utilisateurs demandent de plus en plus d’être aidés dans leurs recherches pour faire face à la surcharge informationnelle dans laquelle il est souvent difficile de distinguer l’information pertinente d’une information secondaire ou sans intérêt. Ce besoin d’assistance est de plus en plus demandé par les professionnels qui ont des contraintes au niveau de leurs emplois de temps. Par exemple, un médecin qui exerce au sein de son cabinet a un emploi de temps bien chargé (15 à 20 minutes pour chaque patient). Lorsqu’il consulte des données spécifiques sur un patient donné, il souhaite accéder rapidement à cette information.

- le système de personnalisation peut être exploiter dans des systèmes d’information utilisés dans un réseau de communication où les informations peuvent être demandées et partagées par des utilisateurs appartenant à des divers systèmes pour atteindre un objectif commun. Nous citons l’exemple d’un réseau de soins dans lequel les professionnels de santé soignant un patient sont amenés à coordonner leurs


tâches et à se partager les informations afin d’apporter les meilleurs soins au patient. Donc il est important que le système tienne en compte de cette hétérogénéité pour faciliter l’implémentation du processus de la personnalisation et offrir aux utilisateurs un accès transparent et homogène aux données.

En réponse à ce constat, il existe un réel besoin, pour les systèmes d’informations, de proposer un système de personnalisation capable de délivrer, d’une manière transparente, l’information désirée parmi la masse de données disponibles. Ce système doit intégrer les besoins de l’utilisateur ainsi que son contexte d’utilisation dans le processus de recherche d’information et ce dans le but de lui délivrer une information pertinente, adaptée à son contexte, à ses besoins et à ses préférences.

La définition et l’exploitation de profils sont donc les principaux facteurs clés pour fournir un modèle personnalisé d’accès à l’information. Cette définition passe par une bonne compréhension de l’utilisateur et de ses besoins en terme de personnalisation. Donc le système de personnalisation se base principalement sur la modélisation des profils.

Un deuxième facteur clé pour la réussite de ces systèmes est la définition et l’exploitation de l’ensemble des situations contextuelles des utilisateurs lors de l’ouverture des sessions.

Dans ce cadre, nous nous intéressons à cette problématique et nous proposons un système de personnalisation qui tient en compte à la fois des besoins de l’utilisateur et de son contexte d’utilisation afin de couvrir l’ensemble des besoins en terme de personnalisation. Ce système est pour objectif principal de fournir à l’utilisateur finale une information pertinente et personnalisé en écartant les données inutiles.

1.2 Contribution

Notre contribution consiste donc à proposer une stratégie de personnalisation complète et générique afin de couvrir toutes les facettes de la personnalisation. La stratégie que nous proposons se base sur trois piliers : (i) les profils qui sont des conteneurs de connaissances sur les utilisateurs, (ii) le contexte qui définit et interprète la situation contextuelle de l’utilisateur et (iii) les services qui sont des programmes autonomes capables de mettre en œuvre la personnalisation. La définition et l’exploitation de ces trois piliers présentent le principe général de notre approche de la personnalisation.

L’architecture générale ce cette approche est composée de cinq modules : 1) gestion des profils, 2) gestion du contexte, 3) gestion des services, 4) exploitation des services dans le processus de la personnalisation, 5) mise en œuvre de la personnalisation. Le premier module permet de modéliser, de définir et de gérer les


profils (structure et instances). Le second module permet de définir les paramètres du contexte qui seront considérés par les profils. Le troisième module définit et développe les services qui mettront en œuvre de la personnalisation. Ces trois modules constituent la première étape à développer du système de la personnalisation. Le quatrième module a pour objectif d’exploiter les profils dans le processus de la personnalisation. Ce module permet principalement d’extraire les profils qui correspondent à la situation contextuelle de l’utilisateur. Ensuite à partir de ces profils, les services sont sélectionnés et préparés pour exécution. Le dernier module est chargé d’exécuter les services qui personnaliseront le contenu et la présentation des données.

Le système de personnalisation doit être valable aussi bien pour des nouvelles applications que pour des applications existantes. Il peut être développé de manière indépendante du domaine de l’application et implémenter sous forme d’une surcouche logicielle sans avoir besoin de toucher au code de l’application existante.

Pour tester le fonctionnement de notre système de la personnalisation, il sera implémenté dans le projet SGI2 en cours d’élaboration. Ce projet a pour objectif principal de proposer un médiateur sémantique entre les producteurs des données et les consommateurs des données. Ce médiateur aura pour rôle d’homogénéiser entre les données extraites des différentes sources de données distribuées. Une fois les données homogénéisées, elles seront affichées dans une interface graphique sous forme des icônes. Notre système de personnalisation s’implémentera entre la phase de médiation et la phase d’affichage. La phase de médiation fournira les données dans un document XML. La personnalisation s’appliquera donc aux données contenues dans ce document pour effectuer un ensemble d’opérations de personnalisation sur ces données : suppression des données inutiles, masquage des données, enrichissement des données ou ajout des données. Ces opérations pourront générer des données additionnelles présentées dans des documents XML. Une fois les données personnalisées, la deuxième étape consiste à adapter l’interface pour qu’il prenne en considération les modifications apportées au contenu du document XML.

1.3 Plan du mémoire

Ce mémoire est organisé comme suit : - Dans le deuxième chapitre nous présentons l’état de l’art des travaux de

recherche qui s’apparentent à notre problématique. Ce chapitre est composé de trois parties : une partie sur le principe de l’adaptation et de la personnalisation et les travaux qui ont été proposés dans la littérature, une deuxième partie sur la modélisation de l’utilisateur, une troisième partie sur le formalisme du contexte.


- Dans le troisième chapitre, nous présentons le principe de l’approche de la personnalisation ainsi que le niveau conceptuel des différents modèles que le système de personnalisation propose. Ces modèles sont le modèle du profil, le modèle du contexte et le modèle des services.

- Dans le quatrième chapitre, nous présentons l’architecture générale de l’approche de la personnalisation. Cette architecture est organisée en quatre modules : la gestion des profils, la gestion du contexte, la gestion des services et l’exploitation des profils dans le processus de la personnalisation.

- Dans le cinquième chapitre, nous présentons le principe de mise en œuvre de la personnalisation. Cette personnalisation concerne deux phases : la personnalisation du contenu (données extraites afin de répondre à une requête utilisateur) et la personnalisation de la présentation.

- Dans le sixième chapitre, nous validons notre approche par l’implémentation d’un prototype du système de personnalisation. Ce prototype devra être testé sur le projet SGI2 qui permet de proposer un médiateur pour homogénéiser les données extraites des différentes sources de données et de les afficher dans une interface sous forme des icônes.

- Nous terminons ce mémoire par une conclusion sur les travaux réalisés et ceux qui restent en perspective.


2 Etat de l’art

2.1 Introduction Les systèmes d’information actuels ont permis jusqu’à aujourd’hui d’améliorer la qualité des services d’accès à l’information et de faciliter l’échange d’information et la communication entre les usagers. Les services fournis par ces systèmes proposent une organisation, un contenu d’information, un mode d’interaction et une présentation unique pour tous, quels que soient les domaines concernés. Les informations délivrées par ces systèmes sont de tous types et peuvent provenir de sources variées. Elles sont souvent hétérogènes, et de granularité très variable. Toutes les informations ne sont certainement pas pertinentes pour tous les utilisateurs qui ne sont pas eux-mêmes intéressés par les mêmes informations. La qualité d’accès est conditionnée donc par « l’accès à la bonne information, au bon moment, à l’endroit et sur le support choisi ». Dans cette optique, il est important de tenir compte des besoins et des connaissances des utilisateurs lors de l’accès à l’information ainsi que de la situation contextuelle afin de lui fournir une information pertinente, adaptée à ses besoins et son contexte d’utilisation.

Ce besoin d’adaptation a été accentué par le large développement web qui met à disposition d’un volume considérable des données de toute nature (images, texte, son, vidéo, etc.). Il devient donc primordial de proposer une aide aux utilisateurs afin de les guider dans leurs recherches mais aussi pour faire savoir qu’une ressource existe et comment y accéder.

Afin de mieux comprendre le problème et avant de proposer une solution permettant de fournir aux utilisateurs un environnement du travail personnalisé et permettant d’accéder efficacement aux informations la plus pertinentes, nous établissons dans ce chapitre un état de l’art sur les différents aspects et axes de recherche qui s’apparentent à cette problématique.

La première partie sera consacrée à la description du processus d’adaptation et de personnalisation. Les différentes dimensions de l’adaptation seront présentées dans la première section de cette partie. Le processus de personnalisation est décrit dans la deuxième section comme un sous processus de l’adaptation. Dans la troisième section de la première partie, les services de personnalisation tels que la recommandation, le filtrage, l’enrichissement des requêtes et le reordonnancement seront détaillés.

La deuxième partie sera dédiée à la présentation de la modélisation de l’utilisateur et à la description des différentes techniques utilisées dans l’acquisition et la construction du modèle utilisateur. Dans cette partie, les


différentes classifications du modèle seront décrites ainsi que les différentes caractéristiques composant un modèle utilisateur.

La troisième partie présente le système sensible au contexte dans le cadre d’un système pervasif. Cette partie débute par une description du système pervasif. Ensuite une description de la sensibilité au contexte est donnée ainsi qu’une définition de la notion du contexte. La dernière section de cette partie présente une architecture du système sensible au contexte.

2.2 L’adaptation et la personnalisation des systèmes d’informations

Le processus d’adaptation est devenu aujourd’hui un enjeu majeur pour l’informatique industrielle [FRA 02] [VIL 02]. En effet, la prolifération des ressources hétérogènes (données structurées, documents, images, etc.) conduisant à des volumes de données considérables qui ne cessent pas de s’accroître rendent l’accès à une information pertinente laborieuse. Lorsqu’un utilisateur demande une information, il est vite submergé par un grand nombre de données, ce qui génère souvent une surcharge informationnelle dans laquelle il est souvent difficile de distinguer l’information pertinente d’une information secondaire ou même sans intérêt. L’adaptation des systèmes d’information et la personnalisation de l’information constituent une solution adéquate pour résoudre la problématique évoquée ci-dessus. Que ce soit dans le contexte des systèmes d’information d’entreprise, du commerce électronique, de l’accès au savoir et aux connaissances ou même des loisirs, la pertinence de l’information délivrée, son intelligibilité et son adaptation aux usages constituent des facteurs clés du succès ou du rejet de ces systèmes.

Dans la section suivante nous allons présenter les différentes dimensions de l’adaptation déjà utilisées. Cette présentation s’appuie essentiellement sur les travaux de la communauté hypermédias adaptatifs.

2.2.1 Les dimensions de l’adaptation

D’après [BRU 98], différents axes qui peuvent faire l’objet d’adaptation dans les systèmes d’information ont été proposés [CHE 03][CAB 06]. Nous en présentons quelques-uns :

2.2.1.1 Adaptation du contenu Il s’agit de modifier le contenu sémantique du site en fonction des connaissances de l’utilisateur ou de ses préférences [VIR 05a].


Cette modification consiste principalement à : - ajouter un supplément d’information par rapport au contenu de base

défini pour l’ensemble des utilisateurs ; - supprimer (ou cacher) une partie des données jugée non pertinente

pour un utilisateur donné. Cette méthode peut être vue comme l’inverse de la précédente ;

- choisir parmi plusieurs alternatives prédéfinies pour proposer une information, celle qui est la plus adéquate pour un utilisateur donné. Plusieurs techniques existent pour mettre en oeuvre de telles adaptations de contenu. Cette technique porte majoritairement sur des documents de type texte, mais peuvent être transposées à des données multimédias [KOC 00] [BRU 98].

2.2.1.2 Adaptation de la présentation L’adaptation porte dans cette dimension sur les caractéristiques visuelles [FRA 02] [KAY 00]. Il s’agit ici d’intervenir sur les choix de couleurs et formes des composants (qu’ils soient interactifs tels que les boutons de commandes, ou non tels que les bordures, les puces, etc.), de tailles, types et couleurs de police, d’arrière-plans, etc. On rencontre également souvent dans la littérature des adaptations de la présentation à travers le choix de la langue utilisée pour diffuser l’information [KOC 00][FRA 02] [MAR 00].

Des méthodes portant sur l’adaptation de l’organisation du document sont aussi décrites. Celle-ci peut être spatiale ou temporelle. Dans ce cas, la page est décomposée en différentes régions qui peuvent être positionnées différemment dans la page et être activées selon des ordonnancements temporels variés. A un niveau de granularité plus fin, les caractéristiques spatiales et temporelles peuvent être affectées à des éléments d’affichage correspondant à des concepts du domaine d’application [FRA 01].

Diverses techniques sont employées pour implémenter ces méthodes. Une première possibilité est de créer autant de versions de pages ou de régions de pages que nécessaire. Une autre technique est proposée en utilisant des feuilles de styles. Tout d’abord avec les CSS (Cascading Style Sheets [W3C 98]) associées à HTML (HyperText Markup Language [W3C 99]), puis avec XSL (eXtensible Stylesheet Language [W3C 01]) et les langages associés, proposés autour de XML (eXtensible Markup Language [W3C 04]).

2.2.1.3 Adaptation de la navigation Elle permet d’éviter à l’utilisateur de suivre le chemin le menant à des informations non pertinentes. Parmi les méthodes associées à cette technique, nos citons [BRU 98][RAA 02] :


- le guidage global permet d’indiquer à l’utilisateur le chemin le plus court pour accéder à l’information voulue. L’information est contenue dans un ou plusieurs noeuds de l’hyperespace et ne peut être accessible que par navigation. Deux méthodes sont envisagées. L’une, appelée guidage direct, est de suggérer étape par étape (i.e. après chaque suivi de lien) le lien suivant à actionner. L’autre suppose de trier les liens potentiels par ordre décroissant de pertinence (adaptive sorting). La seconde méthode est équivalente à la première dès lors que l’utilisateur choisit le lien en tête de liste, mais lui laisse par ailleurs la liberté de suivre d’autres chemins.

- le guidage local vise à assister l’utilisateur dans le choix du lien à suivre à partir du nœud courant. Alors que le guidage global construit un chemin complet de navigation vers un but, le guidage local se résume à une suggestion élaborée à partir des préférences, connaissances, etc. de l’utilisateur ;

- l’orientation globale qui consiste à aider l’utilisateur à comprendre la structure complète de l’hyperespace et à situer sa position absolue actuelle dans cette structure. Des méthodes basées sur l’insertion de repères visuels ou d’affichage de la cartographie de l’hypermédia sont utilisées [KOC 00];

- l’orientation locale porte sur l’introduction d’informations permettant à l’utilisateur de mieux percevoir sa position relative et surtout d’avoir une meilleure représentation de ce qu’il peut atteindre à partir de celle-ci. Les méthodes d’annotations de liens sont utilisées, ainsi que des méthodes qui cachent les informations non pertinentes ;

- les vues personnalisées qui ont comme objectif de réduire l’hyperespace à la partie que les utilisateurs exploitent réellement dans leur tâche quotidienne. La création de telles vues est présentée comme relevant d’une méthode définissant la liste des liens vers les hyperdocuments qu’est amenée à manipuler l’utilisateur. Il s’agit globalement de créer des structures de type favoris (ou bookmarks) qui permettent un accès rapide à un espace restreint, mais n’offrent pas un véritable support à la réalisation des activités.

2.2.1.4 Adaptation de la structure Il s’agit de modifier les liens qui relient différentes pages d’un site web comme ajouter des liens à une page, cacher des liens existants, trier les liens en fonction de leur pertinence ou annoter des liens afin d’indiquer les liens les plus intéressants à suivre.

2.2.1.5 Adaptation des fonctionnalités Elle consiste à identifier les besoins fonctionnels de l’utilisateur et donner des réponses en adéquation avec ses besoins. Pour cet objectif, une démarche s’appuyant sur UML par l’identification des cas d’utilisation a été proposée pour offrir à l’utilisateur des moyens de remplir les tâches qui lui incombent.


Néanmoins, le simple fait de rendre possible l’accomplissement d’une tâche ne suffit pas à rendre fonctionnellement adapté un SI selon nous. Cette adaptation comporte deux dimensions :

- La définition d’un espace de travail adéquat qui consiste par exemple à ne pas mettre à disposition de l’utilisateur toutes les fonctionnalités supportés par le système s’il en pas l’usage. Les travaux relatés dans [TUR 01][TUR 02] sur les hyperclasses peuvent être analysés dans ce sens. Une hyperclasse est formée d’un ensemble de classes conceptuelles issues du schéma global d’une base de données (sous-jacente au SI). Il s’agit une unité ayant une sémantique précise qui est généralement associée à une fonction du SI. Une hyperclasse délimite le sous-domaine d’information (données et méthodes) nécessaire à la réalisation de la fonction associée. Un espace de travail déterminé à partir de la ou des hyperclasses qui ont un sens pour l’utilisateur, permet d’atteindre un degré d’adaptation intéressant.

- Un suivi personnalisé des processus que doivent exécuter les utilisateurs est proposé. Les travaux de Villanova [VIL 02] proposent un modèle pour le contrôle et la coordination des activités conduites dans les SI. Cette approche permet à tout instant d’informer l’utilisateur sur l’état des activités (activité terminée, en cours, à engager, etc.) et de le guider dans la réalisation des activités : celles à entreprendre sont automatiquement présentées à l’utilisateur, des mécanismes de rappel permettent de relancer un utilisateur ayant « oublié » une activité, etc.

2.2.1.6 Adaptation des services web L’adaptabilité des services web [PAS 03] se concentre à ce jour autour de quatre axes : le comportement du service, la composition des services, le contenu et la présentation du résultat. Rappelons que les services web [CHI 04] permettent l’utilisation, à travers le web, d’applications distantes par d’autres applications ; L’architecture sous-jacente aux services web repose sur trois standards : WSDL –Web Service Description Language qui permet de décrire un service, UDDI –Universal Discovery Description Integration- qui permet de référencer ce service, et SOAP –Simple Object Access Protocol- qui décrit la communication avec ce service. Une fois publiés, ces services Web sont potentiellement utilisables à partir de différents dispositifs d’accès (station du travail, PDA, téléphone portable, etc.).

L’adaptation du comportement du service permet de proposer à l’utilisateur les moyens de répondre à ses besoins fonctionnels, c'est-à-dire ses objectifs. Les travaux de Paques ([PAQ 03] proposent trois moyens d’adapter le comportement : appeler un service qui répond au même objectif, modifier le programme du service appelé afin qu’il réponde aux attentes de l’utilisateur, puis renouveler la connexion.


La composition des services permet aux plusieurs services d’interagir à la fois de manière intelligente en étant capables de se découvrir automatiquement, de négocier entre eux et de se composer en services plus complexes. Cette dimension peut s’adapter selon deux aspects : le modèle utilisateur et la tâche à effectuer. Le premier type choisit le service en fonction des caractéristiques d’un utilisateur donné [CON 03] tandis que le second choisit les services dont le comportement permet de mieux réaliser la tâche demandée [AMO 03].

Les services web peuvent adapter leurs fonctions selon le contexte de l’utilisateur, plus particulièrement les terminaux utilisés [CHA 04]. L’adaptation des services se fait en fonction des paramètres de sortie, donc du contenu. Le service connaissant le dispositif utilisé par l’utilisateur donne en résultat seulement les données en fonction des caractéristiques du dispositif (taille d’une image, réduire le nombre de couleur d’une image, etc.)

L’adaptation de la présentation devient incontournable du fait de l’augmentation des dispositifs mobiles aux possibilités réduites en termes logiciels et matériels. La présentation doit être adaptée afin de pourvoir être visualisée sur ces types de terminaux [KEI 04][PAS 03].

Nous avons décrit les différentes dimensions qui peuvent faire l’objet d’adaptations dans un système d’information – contenu, navigation, présentation, fonctionnalités, conditions d’exploitation, services –. Nous abordons dans section suivante l’adaptation dans différents domaines.

2.2.2 Processus de la personnalisation

La personnalisation est définie comme un processus qui change la fonctionnalité, l’interface, la teneur en information, ou l’aspect d’un système pour augmenter sa pertinence personnelle en fonction des caractéristiques sociodémographiques déclarées de l’utilisateur (sexe, âge, lieu de résidence, etc.) et/ou de son comportement observé [TUR 04]. Elle est considérée comme une des portées du processus de l’adaptation [KIM 02] [ANL 05b]. Elle vise à répondre de façon adaptée aux besoins et aux caractéristiques de chaque utilisateur. Ce processus s’appuie essentiellement ces dernières années sur l’apprentissage par la machine qui est basée sur l’observation du comportement de l’utilisateur au cours des sessions de navigation. Il s’agit de gérer la connaissance relative à l’utilisateur et exploite cette connaissance pour décider ce qui doit être présent à l’utilisateur.

Ce processus a tout particulièrement intéressé différents domaines tels que :


- la recherche d’information : l’utilisateur dans les systèmes de recherche d’information est complètement représenté par sa requête ce qui génère un ensemble de problèmes : (i) l’ambiguïté du sens des mots, (ii) l’impossibilité de sélectionner des sources opportunes, (iii) l’inintelligibilité des résultats [DEA 99]. Des nombreuses solutions, qui s’apparentent à la personnalisation, ont été proposées : 1) la reformulation des requêtes par injection de pertinence [NIC 01] [HAR 92] qui utilise la requête initiale pour amorcer la recherche puis modifier celle-ci à partir des jugements de pertinence et/ou de non pertinence de l’utilisateur, 2) l’utilisation de la notion des profils à long terme (profil construit sur une période relativement important) des besoins de l’utilisateur et l’utilisation des profils à court terme de ses besoins pour aider à l’interprétation de requêtes afin de réévaluer et de réordonner les résultats d’une recherche, 3) l’utilisation de la notion de contextualisation et d’individualisation (caractéristiques propres à l’utilisateur quel que soit le contexte), 4) l’utilisation de la recherche collaborative qui exploite la notion du groupe pour répondre aux besoins d’un utilisateur, 5) la technique d’expansion de requêtes en utilisant des techniques de désambiguïsation.

- les hypermédias adaptatifs : la personnalisation dans ce domaine consiste à proposer aux utilisateurs des pages différentes en fonction de leurs acquis, leurs antécédents, leurs objectifs et leurs connaissances par rapport à un sujet traité par l’hypermédia [BRU 02][BAR 00] [ROL 00] [BRU 01]. Ainsi uniquement les pages et les liens intéressants seront affichés à l’utilisateur.

- l’apprentissage assisté par ordinateur (e-learning) : la personnalisation dans ce domaine permet de définir les objectifs d’une formation sur mesure (selon les connaissances, le style d’apprentissage préféré, etc.) et de suivre l’apprenant au cours de sa formation afin d’adapter la réaction du système d’apprentissage à son état d’avancement et à son comportement [CON 02] [KIN 03][LMW 00]

- le commerce électronique : l’objectif principal de la personnalisation dans ce domaine est de fidéliser les clients et de garantir leur satisfaction [FIN 00] [RIC 99]. Cette technique de personnalisation permet (i) d’épargner à l’utilisateur la re-saisie dune information qu’il a déjà fournie au système (gestion du panier), (ii) de garantir que l’utilisateur ne passe pas à côté dune information intéressante ( envoi des emails), (iii) de recommander à l’utilisateur des produits qui ont déjà intéressé des utilisateurs ayant un profil similaire, (iv)


de maintenir l’historique des achats dans un profil utilisateur afin de suggérer ultérieurement des produits similaires.

- l’accès aux bibliothèques électroniques (digital librairies) : cette technique de personnalisation permet (i) de limiter l’accès aux seuls documents auxquels l’abonné a souscrit, (ii) de guider la navigation de l’utilisateur au sein de ces documents selon sa requête du moment et (iii) de recommander les nouveautés selon son profil [AMA 99].

- la dissémination sélective d’informations : ce domaine concerne plus particulièrement la diffusion d’information culturelles ou d’actualités. La personnalisation dans ce domaine consiste à filtrer le flux d’informations en tenant compte d’un profil traduisant non seulement les centres d’intérêts, mais aussi sa langue, sa position géographique et son itinéraire s’il s’agit dune visite guidée.

- les systèmes d’information mobiles : ces systèmes utilisent des dispositifs divers (PDA, téléphone mobile, etc.) pour accéder à l’information n’importe où. La situation contextuelle de l’utilisateur (localisation, activité, etc.) est prise en considération dans ce genre du système. Ce type de personnalisation est détaillé dans la partie 2.4 de l’état de l’art.

Selon les domaines, la personnalisation consistera en l’une ou plusieurs

des tâches suivantes : filtrer un flux d’informations entrant pour éliminer le bruit, guider la navigation dans un espace d’informations trop vaste, recommander un ensemble d’informations à l’utilisateur, ajuster le résultat d’une requête selon une interface, adapter l’interaction à la situation contextuelle de l’utilisateur.

Certains auteurs considèrent que la personnalisation et l’adaptation peuvent être synonymes [WEI 03], d’autres emploient une terminologie différente. Celle-ci oppose généralement les capacités d’adaptabilité et d’adaptativité (équivalent par lequel nous traduisons le terme anglais ‘adaptivity’) des systèmes, qui sont respectivement qualifiés d’adaptables et d’adaptatifs. Les sens attribués à ces termes diffèrent selon les auteurs :

Pour [STE 98a][STE 98b], l’adaptabilité fait référence à un processus d’adaptation basé sur des connaissances (à propos de l’utilisateur, de l’environnement, etc.) disponibles ou acquises par le système avant que ne soient engagées les interactions utilisateur/système. Les adaptations sont donc réalisées lors de l’initialisation du système qui se présente dans une version adaptée à l’utilisateur. Les connaissances utilisées par le système sont, de plus, supposées rester inchangées au cours de la session d’utilisation. Inversement, l’adaptativité traduit une vision plus dynamique du processus d’adaptation. Les


connaissances sont ici acquises ou modifiées par le système au cours des interactions, via des techniques de suivi de session. Le système procède à des adaptations pendant que l’utilisateur interagit avec lui. Cette vision est également partagée par [FRA 02] et par Kappel & al. [KAP 00], mais ces derniers appellent l’adaptabilité ‘adaptation statique’ et l’adaptativité ‘adaptation dynamique’.

Selon une autre approche, l’opposition des termes est basée sur le degré de contrôle que possède l’utilisateur dans le processus d’adaptation. Nous citons un extrait de [KOB 01] qui introduit les différents niveaux – initiation, proposition, sélection et exécution – auxquels peut s’exercer le contrôle de l’utilisateur, et définit sur cette base ce qui distingue l’adaptabilité de l’adaptativité :

« Systems where the user is in control of initiation, proposal, selection and production of adaptation (“in control” thereby meaning that the user can perform these functions, but can also opt to let the system perform some of them) are called adaptable. For instance, a user of a Website may see a need to introduce a shortcut for a Web page that is frequently visited by him or her but deeply buried in the site hierarchy (adaptation initiation). The user then “proposes” to himself or herself to introduce a new link on the lateral navigation bar of the site pages (assume this is possible) or to define a bookmark in the browser, selects the shortcut link and performs the necessary steps to produce this adaptation. In contrast, systems that perform all steps autonomously are called adaptive. For instance, the AVANTI system automatically inserts such personalised shortcut links for pages that a user frequently visits. »

Figure 2.1 Différents types de processus d’adaptation : de l’adaptabilité à l’adaptativité.


Pour les auteurs, un processus d’adaptation peut également relever de configurations qui combinent les caractéristiques de l’adaptabilité (i.e. contrôle émanant de l’utilisateur) et de l’adaptativité (i.e. contrôle émanant du système). La Figure 2.1 montre différentes possibilités de processus d’adaptation :

iée par lui (respectivement user-controlled adaptivity et user-initiated adaptivity [KOB 01]) sont des exemples de

nnalisation

l’adaptativité contrôlée par l’utilisateur et init

configurations mixtes. Les graphiques insérés dans la Figure 2.1 représentent l’implication de l’utilisateur et du système dans les différentes actions qui constituent le processus d’adaptation.

Dans la section suivante, nous allons présenter les différents services de personnalisation utilisés dans les domaines de recherche cités dans cette section.

2.2.3 Les services de perso

Le premier pas vers la construction d’un système capable de traiter les données en fonction des besoins et des préférences d’un utilisateur est le choix du service de personnalisation que le système va fournir. Les services de personnalisation les plus couramment proposés sont la recommandation, le filtrage des résultats,

s présente

2.2.3.1a techn lisation qui

consiste

approche basée sur la notion de profil utilisateur : elle consiste à proposer

ou les techniques d’apprentissage automatique;

et l’enrichissement des requêtes. Dans les sections suivantes, nous allonr ces services.

La recommandation L ique de recommandation est un des processus de la personna

à proposer à l’utilisateur une aide personnalisée à la recherche d’informations dans un domaine où il dispose de peu d’informations en se servant de l’expérience des autres utilisateurs [MIL 04] [BUR 02] [BRA 00] [ZHU 05]. Un système de recommandation peut être décomposé en trois entités de base :

- le groupe d’agents producteurs de recommandations ; - le module de calcul de recommandations ; - le groupe de consommateurs des recommandations.

Deux grandes approches sont proposées dans la littérature : - l’ aux utilisateurs ce qui a satisfait d’autres utilisateurs ayant un profil

similaire. Parmi les techniques les plus utilisées, nous citons le filtrage collaboratif

- l’approche basée sur la technique de fouilles des données : elle consiste à proposer des recommandations en s’appuyant sur l’observation et l’analyse du comportement d’un utilisateur ou d’autres utilisateurs lors de la navigation sur le web. Des techniques ont été utilisées pour ce genre d’approche


comme le raisonnement à partir des cas, les techniques de statistiques ou le clustering.

Une approche hybride peut être proposée en reposant sur l’utilisation des techniques de fouilles de données pour la construction d’un profil utilisateur [HWA 0

critères qui différencient ces système

partir d’un groupe d’utilisateur comme Brodway [TRO 99], FootPrin

t ne peuvent pas s’enrichir à partir des expériences des utilisate

- produire des recommandations personnalisées et de haute qualité part des producteurs et des

des requêtes utilisateur par un ensemble de

contenus dans son profil. L’enrichissement des requêtes exploite donc utilisateur pour reformuler sa requête en y intégrant des éléments

définis dans son profil (préférences, centre d’intérêt, etc.). La méthode la plus aboutie est celle de Koutrika [KOI 04]. Dans cette méthode, le profil de l’utilisateur est composé d’un ensemble des prédicats pondérés. Le poids du prédicat exprime son intérêt relatif pour l’utilisateur. Il est spécifié par un réel compris entre 0 et 1. Les poids relatifs des prédicats sont représentés sur les arcs correspondants (Figure 2.2).

2]. La stratégie d’apprentissage est un des

s. Nous distinguons des systèmes qui utilisent l’apprentissage à partir d’un seul utilisateur comme Letizia [LIE 95] et des systèmes centrés sur l’apprentissage à

t. [WEX 97] D’autres systèmes n’utilisent pas des techniques d’apprentissage e

urs puisqu’ils utilisent uniquement un ensemble de cas prédéfinis construits par des experts comme le système Hypercase.

Ces systèmes rencontrent un défi majeur lors de la conception de systèmes de recommandations qui est le suivant :

tout en minimisant l’effort requis de laconsommateurs ;

- définir des méthodes pour mesurer la similarité entre les comportements ;

- fournir des techniques d’identification et d’extraction de comportements pertinents à partir des données brutes des historiques ;

- définir des techniques d’inférence de recommandations personnalisées à partir des comportements pertinents passés identifiés.

2.2.3.2 L’enrichissementCe service consiste à enrichir la requête de l’prédicats le profil de l’


Figure 2.2 Représentation graphique d’un profil utilisateur

Dans l’exemple 1 ci-dessous, le profil décrit un utilisateur qui aime voyager en avion pour des séjours de plus de 7 jours, préfère les vols directs dont le niveau de confort est supérieur à 3, descend dans les hôtels de plus de 3 étoiles et n’aime pas les circuits touristiques. A chaque prédicat décrivant un élément du centre d’intérêt est associé un poids qui exprime son importance relative par rapport aux autres éléments de ce centre d’intérêt.

Exemple 1 : Profil utilisateur P1 = { VOYAGE.idT=TRANSPORT.idT 1.0 (a) VOYAGE.idH=HOTEL.idH 1.0 (b) VOYAGE.nbre_jours>7 1.0 (c) TRANSPORT.moyen='avion' 0.7 (d) TRANSPORT.type_trajet='direct' 0.6 (e) HOTEL.nbre_etoiles>3 0.5 (f) VOYAGE.type_formule<>'circuit' 0.4 (g) TRANSPORT.comfort>2 0.4 (h)}

L’enrichissement d’une requête à l’aide d’un profil se fait en deux étapes: (i) recherche des prédicats pertinents, et (ii) intégration de ces prédicats à la requête.

D’autres techniques d’enrichissement sont proposées dans le domaine des bases de données. Ces techniques consistent principalement à proposer des langages de requêtes avancés dont certains concepts sont très appropriés à la prise en compte des informations des profils. Pour illustrer les concepts mis en avant par ces langages, nous prenons deux exemples :


- Introduction d’opérateurs dépendant du contexte [LIE 02]: Dans certaines requêtes, il est souvent intéressant d’exprimer des critères approximatifs du type ‘environ 20 m2, pas trop cher, bonne exposition ‘. Ce type de requête est particulièrement adapté à l’usage de profils dans la mesure où la sémantique des termes utilisés dépend de chaque utilisateur. Disposant de profils décrivant la sémantique de ces termes, en fixant par exemple des distances ou des intervalles, les systèmes offrant ces langages peuvent permettre une grande flexibilité dans l’accès aux données. La même requête émise par deux utilisateurs aux profils différents aura des réponses différentes.

- Introduction de préférences dans les critères de sélection : Tous les résultats d’une requête n’ont pas la même importance pour l’utilisateur. La recherche des meilleurs résultats selon les valeurs des attributs sélectionnés , peut être réalisée en utilisant des formules de préférences (opérateur Winnow (Best) [CHO 02], opérateur Skyline [BOR 01]) ou par un ordonnancement des valeurs préférées (préférences : BETWEEN, LOWEST, HIGHEST, POS, NEG, POS/NEG, POS/POS, EXPLICIT [KIE 02]).

L’enrichissement progressif des langages de requêtes permet à l’avenir d’en faire aussi des langages de définition de profils. Néanmoins l’utilisateur est contraint d’écrire à chaque fois la requête complète qui définit son besoin d’information ce qui est un inconvénient non négligeable. Comme nous l’avons dit précédemment, l’objectif de la personnalisation est d’éviter à l’utilisateur d’écrire à chaque fois la partie commune à ses requêtes.

2.2.3.4 Le filtrage des résultats des requêtes Le principe de base de ce service est de filtrer les informations demandées par un utilisateur donné afin d’éliminer les données non pertinentes sur un flux entrant [GAR 00][MON 03]. Cette étape se réalise en post traitement après que l’utilisateur a envoyé sa requête. Elle implique typiquement des flux entrants, données émises par une source distante ou envoyées directement par d’autres sources. Le filtrage est basé sur des profils représentant généralement un ensemble de thèmes d’intérêts à long terme.

Dans la Figure 2.3, le filtrage d’informations commence avec des personnes (les utilisateurs du système de filtrage d’information) qui ont des objectifs ou des désirs (exemple : tâche professionnelle, passe-temps, etc.) relativement stables et à long termes. De tels intérêts engagent les utilisateurs dans un processus relativement passif de recherche d’information. Ce processus est réalisé à travers la représentation des besoins en information par des profils ou des requêtes destinés au système de filtrage d’information.


Figure 2.3 Modèle général pour le filtrage d’information

Pour réaliser le filtrage, on associe aux documents une représentation de leur contenu, qui est ensuite comparée aux profils. Les documents sont utilisés et évalués en termes de réponse aux besoins exprimés. Cette évaluation peut mener à la modification des profils et des domaines d’intérêt.

Le filtrage d’information se décline selon plusieurs grandes familles : - le filtrage basé sur le contenu (aussi appelé filtrage cognitif) [BRA

00][MON 03] [KAS 05] [FER 01] consiste à comparer les nouvelles informations au profil de chaque utilisateur (représenté par un ensemble des termes) afin de recommander celles qui sont les plus proches de ses besoins. Deux fonctionnalités centrales ressortent, pour un système de filtrage :

a) la sélection des documents pertinents vis-à-vis du profil ; b) la mise à jour du profil en fonction du retour de pertinence

fourni par l’utilisateur sur les documents qu’il a reçus ; la mise à jour se fait par intégration des thèmes abordés dans les documents jugés pertinents. - le filtrage collaboratif [POO 03] [MIL 97] se base sur l’hypothèse que les utilisateurs à la recherche d’informations devraient pouvoir se servir de ce que d’autres ont déjà trouvé et évalué. Si une information ou un document a été jugé intéressant par un utilisateur, il sera diffusé automatiquement aux utilisateurs qui ont eu des opinions similaires par le passé [SHA 03]. - le filtrage hybride : combine les approches de ces deux familles [BUR 02] [BEI 03]. En général, le système hybride gère des profils


d’utilisateurs orientés continu et la comparaison entre ces profils donne lieu à la formation de communautés d’utilisateurs permettant le filtrage collaboratif.

2.2.4 Conclusion

Dans la deuxième partie de l’adaptation et la personnalisation des systèmes d’information, nous avons fait le tour d’horizon des processus d’adaptation adoptés pour personnaliser les informations. La deuxième section a présenté le principe de la personnalisation. Dans la troisième section, quelques domaines d’adaptation ont été décrits. La quatrième section était consacrée à la présentation des principaux services de personnalisation.

Pour résumer, dans l’avenir l’adaptation et la personnalisation seront des points clé pour l’utilisation, la vente et l’accès aux informations et aux services par les entreprises et les particuliers. Mais nous remarquons que les différents processus d’adaptation que nous avons décrits ont en commun, à des degrés divers, le fait d’exploiter une représentation de l’utilisateur comme source d’informations. La prise en considération de l’utilisateur par les systèmes de personnalisation devient un facteur clé. Il est donc important d’aborder dans cet état de l’art les principales étapes de la modélisation des utilisateurs et les techniques adoptés pour la construction et la représentation des modèles utilisateurs. La section suivante fournit une description détaillée de la modélisation des utilisateurs.

2.3 Modélisation de l’utilisateur La modélisation de l’utilisateur est une discipline de recherche datant des années 70 et évoquant en premier lieu les travaux d’Allen, Cohen et Perrault [ALL 79] [CP 79]. La préoccupation majeure de cette discipline est d’améliorer la qualité des interactions homme-machine par inférence et prédiction des buts, préférences et contexte [VIR 05b] [YUD 05]. Ainsi adapter, personnaliser un document ou une application pour un utilisateur particulier nécessite de disposer d’informations sur ce dernier, désigné souvent par le profil utilisateur.

Le modèle utilisateur est une source de connaissances, une base de données sur un utilisateur [KOS 01]. Plus précisément il représente un ensemble de données persistantes qui caractérisent un utilisateur ou un groupe d’utilisateurs particuliers en contenant des caractéristiques sur les préférences, les connaissances, les objectifs, les centres d’intérêts, etc. de l’utilisateur.


Figure 2.4 utilisateur et modèle utilisateur

2.3.1 Classification des modèles de l’utilisateur

Daniels [DAN 86] oppose deux classes de modèle de l’utilisateur (ou modèle utilisateur).

- les modèles quantitatifs et empiriques : leur objectif est de modéliser le comportement externe de l’utilisateur. Ces modèles se basent sur l’observation de ce que fait l’utilisateur et permettent d’étudier ses interactions avec le système.

- les modèles analytiques et cognitifs : s’intéressent à la modélisation du comportement interne de celui-ci. Ils favorisent l’identification des connaissances et processus cognitifs de l’utilisateur.

Ces deux aspects doivent, selon Daniels, être combinés pour mieux représenter, construire et faire évoluer les profils. Il existe différents types de modèles utilisateur qui peuvent être combinés. Nous citons :

- le modèle individuel : il regroupe les caractéristiques propres à un individu. Il s’agit d’informations pouvant être renseignées par l’utilisateur, soit déduites par le système, soit acquises lors de l’utilisation de l’application ;

- le stéréotype : il correspond à un condensé des caractéristiques les plus représentatives d’un groupe (classe) d’individus que nous pouvons qualifier de valeurs par défaut. Le stéréotype peut être utilisé tel quel, ou dans une optique d’individualisation de modèle ;

- le modèle de recouvrement : il associe pour un utilisateur particulier une valeur à chaque concept du modèle de domaine. Chaque valeur correspond à une estimation du niveau de connaissance de l’utilisateur pour le concept. Ce modèle est facile à mettre à jour mais souvent difficile à initialiser. Les actions de l’utilisateur sont analysées pour augmenter ou réduire le niveau de connaissance des concepts du domaine ;

- le modèle partagé : il s’agit d’un modèle réutilisable dans plusieurs applications. En effet, de nombreuses caractéristiques d’un utilisateur sont utilisées systématiquement par toutes les applications adaptatives. Ce modèle dispose d’une partie commune et de parties spécifiques à chacune des applications ou tâches à réaliser.


L’utilisateur peut être donc modélisé en un ensemble de caractéristiques dont nous citons : buts, expériences, connaissances, préférences et autres caractéristiques.

2.3.1.1 Buts Il s’agit d’un état que l’utilisateur désire atteindre. Le but est une caractéristique qui est liée au contexte du travail. Selon le type de système, il peut s’agir d’un travail (dans les systèmes applicatifs), d’une recherche (dans les systèmes de recherche d’information) ou de résolution d’un problème (dans les systèmes éducatifs). Dans tous les cas, le but est la réponse aux questions : pourquoi l’utilisateur utilise-t-il le système ? que veut-il réaliser actuellement ?

2.3.1.2 Préférences Cette caractéristique s’utilise de façon répandue dans les interfaces adaptables et paramétrables par l’utilisateur, grâce à un ensemble d’options de menus de type « personnaliser » [OZT 04]. Donc elles ne peuvent pas être déduites par le système, l’utilisateur doit informer celui-ci directement ou indirectement (par simple rétroaction) sur ses préférences (comme par exemple le choix d’une vision textuelle d’un cours sans animations sonores). On parle, alors, plutôt d’adaptabilité que d’adaptativité, bien que parfois les systèmes adaptatifs puissent généraliser les préférences de l’utilisateur et les appliquer dans de nouveaux contextes.

2.3.1.3 Expériences, connaissances et compétences Par expérience de l’utilisateur, nous entendons toute information liée à l’expérience passée de celui-ci sans lien avec le domaine abordé par l’application. Elle représente le savoir faire de l’utilisateur, la familiarité et l’aisance qu’il possède avec le type de système qui lui est présenté. Ceci inclut la profession de l’utilisateur, sa formation, son point de vue ainsi que ses objectifs. Ceci comprend, également, la familiarité de l’utilisateur avec la structure et le fonctionnement de l’outil et sa faculté d’exploiter les fonctionnalité offertes.

La connaissance de l’utilisateur apparaît comme la caractéristique la plus importante dans les systèmes adaptatifs existants. La façon la plus simple de gérer les connaissances est de mémoriser ce que l’utilisateur connaît ou ne connaît pas. La connaissance est une variable propre à chaque utilisateur, ceci veut dire qu’un système adaptatif qui utilise les connaissances de l’utilisateur doit gérer les changements d’état de celles-ci et mettre à jour le modèle utilisateur en permanence.


Les compétences possédées par l’utilisateur correspondent aux connaissances qui ne relèvent ni du domaine, ni de l’expérience mais qui sont néanmoins considérées comme pertinentes dans le fonctionnement du système.

2.3.1.4 Autres caractéristiques D’autres caractéristiques peuvent composer le modèle utilisateur:

- Données personnelles : elles représentent les informations sur l’identité d’un utilisateur. Ils sont relativement stables.

- Ontologies du domaine : elles permettent d’expliquer la sémantique de certains termes ou de certaines opérations liées au domaine d’activité de l’utilisateur

- Qualité attendue des résultats délivrés : elle permet d’exprimer des préférences extrinsèques comme l’origine de l’information, sa précision, sa fraîcheur, sa durée de validité.

- Customisation : elle concerne les informations liées à la nature et au volume des données comme la présentation des résultats, les préférences visuelles.

- Sécurité : elle représente les droits d’accès aux données. Elle peut concerner les droits de visualisation ou de modification des données. Elle peut représenter également le droit de visualisation des données du profil.

- Retour de préférences (feedback) : Elle représente l’ensemble des informations collectées sur le comportement de l’utilisateur par exemple le nombre de clicks qu’il a effectué sur le lien d’une page.

- Informations diverses : cette caractéristique regroupe différents attributs non classables dans les caractéristiques précédentes, mais pouvant aussi caractériser un profil.

2.3.2 Représentation du profil de l’utilisateur

Selon Bouzeghoub et al. [BOU 05], le profil de l’utilisateur peut être vu comme un modèle personnalisé d’accès à l’information qui régit la manière de présenter les résultats du système. Il n’a pas forcément de structure explicite qui le représente. Il peut être constitué d’unités d’informations qui traduisent une connaissance éparse de l’utilisateur. Il n’y a pas à notre connaissance de modèle spécifique dédié à la représentation du profil de l’utilisateur. Plusieurs modèles de représentation du profil de l’utilisateur ont été proposés dans la littérature. Parmi ces modèles, les plus utilisés sont :

- Approche vectorielle : cette approche s’appuie généralement sur le modèle vectoriel [Sal 1971]. Le profil est formalisé sous forme de vecteurs de termes pondérés ou de classes de vecteurs [GOW 03]. Le contenu est constitué d’un ou de plusieurs vecteurs définis dans un espace de termes obtenus


implicitement ou explicitement à partir de plusieurs sources d’information. Les coordonnées des vecteurs correspondent aux poids des termes dans le profil. L’utilisation de plusieurs vecteurs permet de prendre en compte la diversité des domaines d’intérêts et gérer leur évolution dans le temps. Cette approche offre l’avantage de la simplicité de mise en œuvre. Cependant les modèles proposés ne mettent pas en évidence ni la dimension liée au temps marquant l’évolution des profils, ni à l’organisation des informations pour hiérarchiser les centres d’intérêts. Cette représentation manque de structuration et ne facilite ni l’interprétation ni la prise en compte des différents niveaux de généralités caractérisant l’utilisateur. En effet, ces derniers sont très variés et n’ont pas le même degré d’importance pour chaque utilisateur.

- Approche sémantique : La représentation sémantique met en relief les relations de sens entre les contenus de l’information représentant le profil en apportant des solutions aux problèmes de dissémination et synonymie. Ce type de représentation utilise généralement des ontologies ou de réseaux sémantiques probabilistes. Cette approche se base sur la construction hiérarchique de concepts à partir d’informations issues des fichiers logs. Chaque catégorie de la hiérarchie représente la connaissance d’un domaine d’intérêt de l’utilisateur.

- Approche booléenne et booléenne étendue : Cette approche est basée sur la présence ou l’absence des termes de la requête dans les représentations des documents (termes d’indexation associés). Il permet d’effectuer une recherche stricte réalisée à partir d’une comparaison exacte entre le besoin en information, décrit dans la requête à l’aide d’opérateurs logiques (ET, OU, NON ou SAUF) et les termes représentant les documents d’une collection. Ce modèle a pour inconvénient de ne pas pouvoir ordonner les documents restitués. De plus, l’écriture de la requête peut être complexe et une mauvaise formulation peut engendrer des résultats erronés. Une extension du modèle booléen a été proposée pour essayer de palier le premier inconvénient (ordonnancement des résultats) en s’appuyant sur la théorie des ensembles flous. Le modèle étendu prend en compte en plus de l’absence ou de la présence des termes de la requête dans le document, les poids sémantiques de chacun de ces termes. L’inconvénient majeur de cette méthode de recherche est que l’évaluation peut proposer des valeurs différentes pour des expressions équivalentes.

- Approche multidimensionnelle : C’est un type de représentation qui se veut global dans le sens où il permet de capturer puis catégoriser l’ensemble des informations caractérisant le profil de l’utilisateur [AMA 99] [KOS 03][BOU 04] [TAM 06]. Parmi les dimensions, on trouve les données personnelles, les données professionnelles, les centres d’intérêts, les préférences, les buts, les statistiques de comportement, etc. Les données du profil peuvent être utilisées pour enrichir (ou réécrire) les requêtes des utilisateurs, filtrer les résultats délivrés, guider le système dans l’évaluation de ces requêtes, inférer des


procédures d’adaptation du système à l’environnement de l’utilisateur ou à son niveau d’expertise. Plusieurs travaux ont abordé cet aspect sans le couvrir dans son ensemble. Ainsi les propositions de standards P3P [W3C 04] pour la sécurisation des profils ont défini des classes distinguant les attributs démographiques des utilisateurs (identité, données personnelles), les attributs professionnels (employeur, adresse, type) et les attributs de comportement (trace de navigation). Une autre proposition faite par Amato [AMA 99] consiste à représenter le contenu du profil utilisateur par un modèle structuré de dimensions (ou catégories) prédéfinies. L’auteur a proposé ce modèle dans le cadre du développement d’un service avancé de librairie digitale : le système EUROgatherer. [BOU 05] propose un ensemble de dimensions ouvertes, capables d’accueillir la plupart des informations caractérisant un profil. Il distingue principalement huit dimensions : les données personnelles, le centre d’intérêt, l’ontologie du domaine, la qualité attendue des résultats délivrés, la customisation, la sécurité et la confidentialité, le retour de préférences (feedback) et les informations diverses.

2.3.3 Techniques de construction et mise à jour des profils

Avant d’exploiter le modèle utilisateur dans le processus de personnalisation, il faut le construire. Cette étape est la plus difficile dans le processus de modélisation de l’utilisateur [GOW 03]. Elle se base généralement sur la collecte des informations nécessaires pour générer le modèle utilisateur. Deux méthodes ont été proposées pour collecter des informations et construire les profils. Elles sont classifiées en méthode explicite et en méthode implicite.

La première méthode est la plus simple pour initialiser le profil [POINT] [INF 04][POO 03]. Elle consiste à demander à l’utilisateur de saisir manuellement des paramètres de son profil en considérant que l’utilisateur connaît mieux ses préférences, ses besoins. Dans ce cadre, l’utilisateur dispose d’une interface lui permettant de saisir les paramètres dont a besoin le système ou éventuellement des formulaires. L’inconvénient de cette méthode, malgré la simplicité, est que l’utilisateur est parfois incapable d’exprimer ses besoins et ses préférences et de les définir de façon formelle. En plus, le processus de saisie de tous les paramètres du profil est souvent long et ennuyant.

Pour pallier ces ennuis liés à l’acquisition explicite des informations, la méthode implicite utilisée consiste à acquérir des informations sur l’utilisateur de façon automatique en évitant de faire intervenir l’utilisateur dans l’initialisation de son profil. Cette méthode est basée essentiellement sur l’apprentissage automatique et utilisée généralement dans les modèles utilisateur à long terme [GOW 03]. Cependant lors de l’utilisation de cette méthode, rien ne


garantit que le comportement soit ponctuel et récurrent pour pouvoir y extraire les informations représentatives du profil de l’utilisateur.

Avant de commencer de décrire les techniques de la modélisation de l’utilisateur. Il est important de signaler que lors de ce travail, nous utiliserons le terme profil utilisateur pour désigner les informations décrivant un utilisateur donné et le modèle utilisateur pour décrire l’ensemble du système qui modélise et gère les profils.

En général, dans la littérature, les termes « modèle utilisateur » ou « profil utilisateur » sont utilisés comme synonyme où signifient la même appellation. Mais d’après Koch [KOC 00], une différence existe entre le profil utilisateur et le modèle. Il définit le profil utilisateur comme une version simple du modèle utilisateur. Le profil utilisateur peut être vu comme une collection d’informations personnelles caractérisant un utilisateur telles que les buts, besoins, compétences, préférences, contexte d’utilisation, etc. Ces informations sont stockées sans aucune interprétation ou description. Ces informations sont généralement représentées par des couples (attribut, valeur). Ces valeurs sont soit stables soit évolutives. Le profil utilisateur est utilisé pour construire le modèle utilisateur. Donc ce dernier est vu comme une représentation des croyances du système sur un utilisateur donné.

Donc le modèle utilisateur et le profil utilisateur sont nécessaires dans le processus de personnalisation. Si nous ne disposons pas d’informations sur les utilisateurs, le même résultat est fourni à tous les utilisateurs. [KOC 00] définit l’application du modèle utilisateur comme suit:

« Users are different: they have different background, different knowledge about a subject, different preferences, goals and interests. To individualise, personalise or customise actions a user model is needed that allows for selection of individualised responses to the user.” Il existe plusieurs techniques qui permettent de construire

automatiquement un profil utilisateur et de le mettre à jour quand c’est nécessaire. Parmi ces techniques qui font partie des méthodes de fouilles de données, nous citons les techniques de classification, les algorithmes de clustering [JAI 99]. Le mécanisme de profilage automatique peut être classifié en trois paradigmes principaux : Analyse statistique des termes [ZUG 01], techniques de filtrage social, techniques d’apprentissage [WEB 01].

2.3.3.1 Techniques d’apprentissage Le principe de base de ces techniques est l’étude du comportement de l’utilisateur et la classification de ses caractéristiques ou celles des objets recherchés.


Ces techniques permettent de modifier de façon adaptative des interfaces pour aider l’utilisateur à rechercher des informations pertinentes qui répondent à leurs besoins. Parmi ces techniques, nous citons le raisonnement à partir de cas, les classifieurs bayésiens, les réseaux de neurones, des algorithmes à base des règles ou des règles d’association.

L’avantage de ces techniques est la fraîcheur et l’exactitude es données dérivées. Grâce au suivi de l’utilisateur, cette approche permet la mise à jour de son profil. L’inconvénient se trouve dans la complexité des algorithmes utilisés.

2.3.3.1.1 Raisonnement à partir de cas

Le raisonnement à partir de cas est une approche de résolution de problèmes basée sur la réutilisation par analogie d’expériences passées appelées cas au cours d’un cycle de raisonnement pour résoudre des nouveaux problèmes [BRA 00][TRO 99]. L’ensemble des expériences constitue la base de cas. Un cas est composé de deux parties : une description d’une situation représentant un problème et la solution qui lui a été appliquée pour remédier à cette situation. Parfois, le cas décrit les conséquences résultant de l’application de la solution (succès ou échec).

Le raisonnement à partir de cas est un processus incrémental qui nécessite au début des exemples servant comme base des prochaines classifications. Cette approche est adéquate pour les domaines où la similarité entre les descriptions de problèmes nous donne une indication de l’utilité des solutions antécédentes.

Le raisonnement à partir de cas se décompose habituellement en quatre phases principales :

- Une phase de recherche de cas ayant des similarités (i.e. des indices similaires) avec le problème courant ;

- Une phase de réutilisation, permettant de construire une solution au problème courant en se basant sur les cas identifiés dans la phase précédente ;

- Une phase de révision de la solution qui permet d’affiner cette dernière grâce à un processus d’évaluation ;

- Une phase d’apprentissage dont le but est de mettre à jour les éléments du raisonnement en prenant en compte l’expérience qui vient d’être realisée et qui pourra ainsi être utilisée pour les raisonnements futurs.

Parmi les systèmes qui utilisent la technique de raisonnement à partir de cas, nous citons le projet COSYDOR [JER 01] destiné aux non


voyants afin de les aider à rechercher de l’information selon le profil. Dans ce projet, un cas est représenté par un quadruplet (U, Q, D, E) où U représente le profil utilisateur, Q est la requête demandée (besoin d’information), D est la liste des documents extraits qui constitue la partie solution, E est les évaluations effectuées par U sur D par rapport à Q. Ce cas est stocké dans la base de cas.

Profil utilisateur + contexte de recherche + requête+ bouclage de pertinence

Solutions = D

Figure

. Pour certaines applicati

dont la tâche est accomplie par des humains expérim

tion d’un cas, le choix du meilleur cas, les bonnes mesures de similarité pour la recherche de cas et l’organisation de la base de cas, la définition d’une stratégie d’adaptation à partir du (ou des) cas retrouvé(s), l’apprentissage de nouveaux indices, etc.

Evaluations = E

2.5 Utilisation du raisonnement à partir de cas dans Cosydor Lorsqu’un utilisateur souhaite rechercher une information, il

reformule sa requête ; ensuite le système associe les termes de son profil U à la requête Q. Avant de lancer la recherche, il vérifie l’existence d’un cas similaire dans la base de cas (similarité du profil avec la requête). Si c’est le cas, il propose les solutions D sinon il effectue la recherche à partir des ressources de données. Ce système utilise le modèle vectoriel pour calculer la similarité entre les termes.

L’approche RàPC offre de nombreux avantagesons, la démarche RàPC est plus simple à mettre en œuvre que

celles basées sur un modèle du domaine (i.e. base de règles). Elle permet d’éviter les problèmes d’acquisition de connaissance qui rendent difficile la conception de bases de connaissances de taille importante. Le raisonnement à partir de cas est une méthode particulièrement bien adaptée aux applications

entés dans leur domaine et dont les expériences sont disponibles dans une base de données et sont réutilisables par des utilisateurs ayant des buts et des préférences similaires.

Cependant elle représente des inconvénients qui sont fréquemment liés : à la définition et la représenta


Cette technique rencontre également des problèmes lorsque le système

2.3.3.1.2

doit connaître l’utilisateur pour pouvoir comparer les situations précédentes avec les nouveaux cas. Vu que l’approche est incrémentale, elle demande des ressources de calcul considérables pour comparer un nouveau cas avec tous les autres cas du système.

Les classificateurs / réseaux bayésiens

Les classificateurs bayésiens représentent la technique jugée la plus performante par plusieurs systèmes d’information. Cette technique est particulièrement adaptée à la prise en compte de l’incertitude dans le raisonnement. Elle a comme avantage par rapport aux autres techniques d’être une approche quantitative.

Le réseau bayésien est un graphe orienté acyclique qui représente une distribution probabiliste. Les noeuds décrivent des variables aléatoires et les arcs représentent les corrélations entre les variables. Les tables conditionnelles de probabilité indiquent des informations quantitatives probables. Pour chaque nœud, on a une table qui spécifie la probabilité de chaque état du nœud en fonction de toutes les combinaisons possibles des états de ses prédécesseurs.

[SCH 00] propose une technique alternative qui combine la technique des réseaux bayésiens avec la technique de raisonnement à partir de cas. Chaque requête de l’utilisateur est prise comme un cas. Chaque nœud du réseau représente un attribut ou une caractéristique utilisée dans la requête. Les arcs décrivent les relations entre les attributs comme étant les fréquences d’apparition des attributs dans les requêtes ende l’utilisateur. Ces fréquences représent

r final. Elles sot également

l’import nt calculées en analysan

Le profil utilisateur est construit d’après les informations ns le réseau bayésien. Un profil

ance des attributs pour l’utilisateut les cas stockés dans la base des cas. Lorsqu’une nouvelle

requête est lancée, elle est stockée sous forme d’un cas et pour chaque attribut, un nœud est ajouté dans le réseau. Ensuite les liens entre ces caractéristiques sont rajoutés et les fréquences d’apparition sont mises à jour. Chaque variable peut avoir seulement deux valeurs :

- vrai pour les attributs présents dans la requête - faux pour les attributs absents.

stockées dans la base de cas et dacontient des données statistiques concernant les requêtes posées et les intérêts de l’utilisateur ; exemple : les buts les plus fréquents, les attributs les plus fréquents et les valeurs les plus fréquentes pour un attribut.


2.3.3.1.3 Les méthodes de clustering

A la différence de la classification, les techniques de clustering utilisent les groupes d’objets qui ne sont pas connus à l’avance. C’est l’algorithme qui se charge de la réparation des éléments en essayant de minimiser la similarité entre les éléments de deux clusters différents et de maximiser la similarité entre les éléments du même cluster.

Parmi les techniques de clustering les plus utilisées, nous citons PACT (Profile Aggregation Based On Clustering Transactions) qui utilise les transactions et la technique ARPH (Association Rule Hupergraph Partitioning) qui prend en compte les pageviews apparaissant souvent ensemble. Les deux techniques (PACT et ARHP) peuvent être utilisées pour la personnalisation anonyme basée sur les données de navigation des clients.

La technique PACT consiste à regrouper les transactions similaires d’un utilisateur. Chaque transaction est un vecteur multidimentionnel de pageviews (vues sur ls pages web), et le regroupement est fait à la base de la distance ou de la similarité entre les vecteurs. Pour chaque cluster, le vecteur moyen mc est calculé.

e pageview est calculée comme étant le rapport de la som

d’un

Dans ce vecteur, la valeur moyenne de chaqume des poids de la pageview dans

toutes les transactions du cluster sur le nombre total de transactions du cluster sur le nombre total de transactions dans le cluster.

Moyenne (p,c) = Σ poids(p,t) / |c|

Cette valeur est normalisée de façon à être comprise dans l’intervalle [0,1]. Ensuite les pageviews dont le poids normalisé est intérieur à un seuil donné sont éliminées. Un profil est donc obtenu sur la base d’un cluster c de transactions et représente un ensemble de couples (pageviews, poids associé).

La méthode PACT est très performante dans les systèmes de recommandations anonymes au début de l’arrivée d’un nouvel utilisateur ou avant de connaître son profil. Cette technique est à utiliser lorsque l’on veut une solution généralisée intégrant les pages de navigation et de contenu.

Dans la technique ARHP, l’algorithme trouve d’abord des groupes d’éléments (URLs) qui apparaissent souvent ensemble dans les transactions, appelé ensemble d’éléments fréquents (L). Chaque élément fréquent l est associé un support comme le rapport du nombre de transactions dans lequel l apparaît sur le nombre total de transactions. Les ensembles d’éléments dont le support est inférieur à un certain seuil sont éliminés. L’étape suivante est la construction


hypergraphe H=(V,E) où V est un sous ensemble de pageviews et chaque a

’éliminer les nœuds de faible connecti té

s clusters. La connectivité d’un élément est prise comme facteur de base pour

produire des s. Il peut être utilisé lorsqu’on veut

produire

rête E est un élément de IS. L’hypergraphe est un graphe dans lequel les arêtes peuvent relier plus de deux éléments. A chaque arête est associée un poids ou intérêt : Intérêt = Support(I) / Support

Le graphe est partitionné en ensemble de clusters dans lequel chaque partition est examinée afin d

vi par rapport aux autres nœuds de la partition. La connectivité d’un nœud dans un cluster c est obtenue en divisant la somme des poids des arêtes de c auxquelles le nœud appartient par la somme totale des poids des arêtes de c.

L’hypergraphe est partitionné de façon récursive jusqu’à un critère d’arrêt pour chaque partition (défini par le rapport des poids des nœuds éliminés sur le poids des nœuds non éliminés). Finalement, certains nœuds sont rajoutés si le pourcentage de nœuds encore dans l’arête d’origine excède un certain niveau spécifié par l’utilisateur. De cette manière, certains nœuds peuvent appartenir à plusieur

déterminer son poids dans le profil. ARHP a tendance à recommandations plus intéressante

un petit ensemble de recommandations spécifiques.

2.3.3.1.4 Les règles d’association

Les règles d’association ont pour but de définir des règles générales décrivant le comportement d’un utilisateur, l’appartenance d’un client à un groupe de clients ou une relation entre des objets. En principe, les règles d’association sont utilisées dans les systèmes de recommandation puisqu’elles permettent d’exprimer les affinités entre les éléments, entre les caractéristiques d’un élément ou entre les utilisateurs. Un exemple de règle d’association est par exemple : « les client qui achètent des appareils photos, achètent aussi des pellicules ».

Parmi les systèmes qui utilisent les règles d’association, on peut citer « Font Mind » qui comprend cinq composants interfaces. Le premier est Front Mind client. Il permet aux clients d’envoyer des évènements au serveur (login, requêtes, etc.) et de recevoir des recommandations en retour. Front Mind server fournit un environnement personnalisé basé sur des règles actives grâce au sous-composants Rule Evaluator et Learning and inference Engine. Rule Evaluator effectue le matching entre les événements envoyés par le client et les règles qui sont actives au moment de l’évaluation. Ensuite,


sur la base des règles actives dont les préconditions sont vérifiées, le système renvoie le résultat au client. Learning and Inference Engine construit et maintient des modèles pouvant être construits de façon hiérarchique qui décrivent le comportement des utilisateurs. Les dimensions importantes de ces modèles incluent des pages référencées, des critères extraits des requêtes, des historiques des achats et des données démographiques. Un autre composant, Business Command center, permet aux non techniciens d’effectuer la définition et la maintenance des règles d’adaptation ainsi que de simuler leur performance sur la base des données historiques. Business Object developer est l’outil grâce auquel les techniciens peuvent développer des objets de business qui représentent la base des règles d’adaptation. Ces objets peuvent contenir des requêtes, des appels de fonctions et des procédures externes ou internes. Finalement, Console Manager gère la configuration du système. Les communications entre les composants sont effectuées via des messages représentés en XML. Toute action

me événement pour enclencher un eur (acquisition d’informations sur le

d’un utilisateur peut servir comcertain nombre de règles du servclient).

2.3.3.1.5 Les agents intelligents

Les chercheurs ont défini les agents comme des logiciels plus complexes qui réagissent avec l’environnement, s’adaptent aux circonstances et peuvent prendre des décisions, enrichissent leur comportement sur la base d‘observations qu’ils effectuent [VAS 03] [WOO 95]. A partir d’un profil défini, l’agent sélectionne alors les documen

esoins de l’utili

de nerrones

hnique, un agent intelligent doit : - communiquer pour coopérer avec les autres agents, se

partager les tâches de la recherche et comparer les résultats obtenus ;

ts, les filtre suivant certains critères et les classe par ordre de pertinence et de proximité et les présente aux utilisateurs. Ces agents ont la capacité de construire et de mettre à jour un profil utilisateur en analysant son comportement [HAR 05] [ANL 05a].

L’objectif des agents intelligents est de trouver des solutions aux problèmes liés aux effets de surinformation, de confidentialité des accès et d’extraction de l’information pertinente en fonction des b

sateur et de ses préférences en un délai raisonnable. Ces agents utilisent des techniques de l’intelligence artificielle

comme la technique de raisonnement à partir de cas, les réseaux , les classificateurs bayésiens et l’évolution génétique. D’un point de vue tec


- être capable de coordonner ses actions par rapport à un utilisateur ou un autre agent ;

- avoir d’un module d’apprentissage pour apprendre les préféren

ent ;

nt faire ; ê

ces qui présentent les informations selon les préférences des utilisateurs et offrent une véritable assistance lors de la navigation sur

se limiter à ce qui est connu ou souhaité

énient de cette méthode qui se base sur les mots clefs pondérés est de ne pas maîtriser les effets de synonymie, d’homonymie et d’effets

ces des utilisateurs, mettre à jour un profil utilisateur et apprendre à s’adapter à l’environnem

- se renseigner sur les autres agents, sur ce qu’ils connaissent et ce qu’ils save

- tre mobile pour parcourir le réseau à la recherche d’information.

Plusieurs types d’agents existent : les agents de recherche qui aident les utilisateur à trouver l’information, les agents de filtrage d’information qui essaient de résoudre le problème de la surcharge d’information en limitant et en triant les informations et les agents d’interfa

le web.

2.3.3.2 Algorithmes de filtrage social Cette méthode nécessite généralement une large communauté d’utilisateurs. Elle déduit les préférences d’un utilisateur à partir des préférences d’autres utilisateurs. Ce modèle social s’oppose au modèle individualiste. Contrairement à ce dernier, il permet de ne pas simplement

de l’utilisateur, mais d’utiliser une connaissance élargie héritée d’une relation sociale implicite [PER 03] [ZHA 05].

Cette approche est fréquemment associée à la recherche personnalisée sur le web. Des travaux dans ce domaine ont classifié l’utilisateur dan un stéréotype à partir de la construction d’un vecteur de mots clefs pondérés, de la détermination d’un cluster d’utilisateurs avec son centre. Chaque cluster correspond à un stéréotype et une projection d’un utilisateur particulier sur le centre le plus proche. L’inconv

des sens contextuels.


rédire la préférence inconnue d’un no

Le filtrage collaboratif est le plus souvent utilisé dans le cas où il le de l’utilisateur pour faire des recommandations.

Figure 2.6 Filtrage collaboratif

Le filtrage collaboratif [CAN 02] est l’une des approches basées sur le filtrage social (Figure 2.6). Il consiste à produire des recommandations personnalisées en se basant sur les corrélations qui existent entre le profil d’un individu et ceux d’autres personnes [GAL 03]. Il est ainsi possible, par exemple, d’aider un utilisateur à choisir un film de cinéma en lui proposant une liste de films qui ont été appréciés par des personnes dont les goûts en matière de cinéma sont proches des siens. En effet, le terme de filtrage collaboratif décrit les techniques d’un groupe d’utilisateurs pour p

uvel utilisateur. Les recommandations pour le nouvel utilisateur sont basées sur ces prédictions [PAW 04] [ZHA 04].

n’existe pas de profil stab

2.3.4 Conclusion

Tout processus d’adaptation, quel qu’il soit, repose sur un modèle utilisateur, c'est-à-d

rit les différentes classifications et représen

r, les questions les plus ment, Quand:

r ?

- Quell

ire une représentation de ses caractéristiques dont le système tient compte dans la mise en œuvre des adaptations.

Dans cette partie nous avons déctations du modèle utilisateur ainsi que les techniques les plus adaptées

dans la construction du modèle utilisateur. Lors de la construction d’un modèle utilisateu

abordées sont de type Quoi, Com - Quelles informations pour représenter l’utilisateu - Quel contexte d’utilisation ? - Comment construire le modèle de l’utilisateur ?

e est la technique à utiliser pour implémenter le modèle utilisateur ? - Quand faut il mettre à jour le modèle de l’utilisateur ?


Lors de la construction d’un modèle utilisateur, il faut prendre en compte la modélisation de l’utilisateur lui-même ainsi que la modélisation du contexte d’utilisation du système. En effet, dans la majorité des applications d’adaptation, l’utilisateur et ses différents besoins sont l’élément clé à considérer sans le processus d’adaptation alors que l’environnement de l’utilisateur et les différents contextes ont été complètement ou partiellement ignorés. Donc la prise en considération de l’utilisateur dans le processus d’adaptation ne suffit pas, surtout avec l’apparition des nouvelles technologies mobiles qui rendent l’informatique accessible n’importe où et à n’importe quel moment. Donc il faut tenir compte du contexte qui peut influencer l’interaction de l’utilisateur avec la machine [SPI 05]. Nous allons détailler dans la prochaine partie la notion du contexte et dans quel cadre il a été fondamentalement utilisé.

contexte et système pervasif 2.4 Système sensible au

2.4.1 Système pervasif

L’évolution technologique des systèmes embarqués et des moyens de communication informatiques a incité les développeurs à intégrer les terminaux mobiles dans leurs applications, donnant ainsi naissance à des nouveaux système

garantir une utilisation convena

passante est plus limitée,

se présentent aux concepteurs de ce genre d’

nflue sur la conce

s d’information dits pervasifs ou ubiquitaires. Ces systèmes permettent de rendre l’information disponible partout et à tout moment.

Dans les systèmes pervasifs, il faut assurer une adaptation au type de terminal et au type d’utilisateur connecté pour

ble des applications dans ces nouveaux environnements. Pour réaliser cette adaptation, plusieurs paramètres entrent en jeu :

- Paramètres réseau : dans les réseaux sans fil la bande les connexions sont intermittentes, la qualité de service n’est pas

évaluée de la même façon… - Paramètres de l’utilisateur : l’utilisateur est devenu une autre

contrainte de conception des systèmes d’information pervasifs. En effet, des contraintes d’utilisabilité et d’ergonomie

application. Ainsi, on doit prendre en considération ses préférences, son emplacement géographique, son profil…

- Paramètres du terminal : la diversité des terminaux mobiles iption de ces systèmes d’information. Le comportement de ces systèmes

doit s’adapter aux capacités matérielles et logicielles de ces appareils.


Tous ces paramètres forment des contextes d’utilisation différents. Dans la plupart des cas, ces paramètres n’ont pas été pris en compte lorsque l’application a été développée.

2.4.2 Sensibilité au contexte

La prise en compte du contexte d’utilisation dans les applications est un domaine de recherche d’actualité connu sous le nom de « sensibilité au contexte

lications qui déclenchent une commande, ou reconfig

et 3) délivrer

» (ou context-awarness en anglais). Une application sensible au contexte doit avoir la possibilité de percevoir la situation de l’utilisateur dans son environnement et d’adapter par conséquent son comportement à la situation en question [CHE 02].

Selon Dey et Abowd [DEY 00], un système est sensible au contexte s’il utilise le contexte pour fournir des informations et des services pertinents pour l’utilisateur où la pertinence dépend de la tâche demandée par l’utilisateur. Cette définition a mis en évidence trois catégories de fonctions liées à la présentation d’information, d’exécution de services et le stockage d’information selon le contexte. La première catégorie, présentation d’information et services, se rapporte aux applications qui proposent des choix d’actions appropriées à l’utilisateur [MCC 00][DAV 98]. La deuxième catégorie, exécution automatique de services, décrit les app

urent le système à la place de l’utilisateur selon les changements de contexte [BEI 00][MAR 00]. La troisième catégorie, stockage d’information selon le contexte, décrit les applications qui associent des données au contexte de leur utilisation [DOU 04].

Chaari et al. [CHA 04], considèrent la sensibilité au contexte comme la capacité de percevoir la situation de l'utilisateur en plusieurs aspects, et d'adapter en conséquence le comportement du système, et l'adaptation comme la capacité de fournir différentes versions d'un service ou différentes présentations d'un document afin de satisfaire les besoins de l'utilisateur, les contraintes de l'environnement, du dispositif, etc. L'informatique sensible au contexte est donc liée à la question de l'adaptation. Cette adaptation est surtout liée aux limitations des dispositifs mobiles [SCH 94]), à la localisation de l'utilisateur [LEM 04] [Banerjee 2002], et au filtrage des informations selon le contexte. De manière générale, pour qu'un système soit sensible au contexte, il lui faut trois étapes de base [CHA 04] : 1) capturer les données contextuelles (données de bas niveau) à partir des capteurs; 2) interpréter les données capturées afin de construire l'information contextuelle (haut niveau) pertinente pour le système;

cette information au système. Pour réussir ces trois étapes, il faut donc répondre à ces questions : « qu'est-ce que le système doit adapter et comment ?


», « qu ls éléments du contexte e de l'utilisateur doivent être détectés et comment ? », et « comment représenter, à l'intérieur du système, ce contexte ? ».

Nous remarquons dans les définitions citées ci-dessus l'importance de la notion de contexte d'utilisation pour les systèmes sensibles au contexte [DOU 04]. Dans la section suivante, nous allons parler de cette notion.

2.4.3 Notion du contexte

D’une manière générale, nous pouvons définir le contexte comme ce qui entoure le centre d'intérêt de l'individu et qui apporte des informations additionnelles capables d'aider à la compréhension de ce centre d'intérêt [MOS 04]. Pour Dey [DEY 00] le contexte est construit à partir de tous les éléments d’information qui peuvent être utilisés pour caractériser la situation d’une entité. Une entité correspond ici à toute personne, tout endroit, ou tout objet (en incluant les utilisateurs et les applications eux-mêmes) considéré(e) comme pertinent(e) pour l’interaction entre l’utilisateur et l’application. Selon Chaari et al. [CHA 05] cette définition est source de conflits surtout qu’elle ne précise pas de limite entre ce définitio

t d'une application en définissa

».

urant (sa localisat

du quartier où se trouve l'utilisateur);

posteriori des requêtes (comme associer

isateur (par exemple, transférer les appels d'un bureau à un autre selon les

selon le contexte (trouver l'imprimante ou le téléphone le plus proche) ;

ar exemple, des services particulièrement proposés à l'utilisateur selon sa localisation ou son

qui fait partie du contexte et ce qui n’en fait pas partie. Il fournit unen du contexte comme « l'ensemble des paramètres externes à

l'application pouvant influer sur le comportemennt de nouvelles vues sur ses données et ses services. Ces paramètres

peuvent être dynamiques et peuvent changer durant l’utilisation de l’application

Nous identifions donc six usages possibles pour la notion de contexte : - présenter à l'utilisateur les informations sur son contexte coion, la température de l'environnement, etc.) ; - délivrer le contenu qui soit le plus approprié au contexte d'utilisation

(comme montrer automatiquement le plan- associer à une ou à un ensemble de données une information

contextuelle précise pour la réalisation a à une annotation la localisation mentionnée par son contenu) ; - exécuter automatiquement une action selon le contexte dans lequel se

trouve l'util déplacements de l'utilisateur) ; - découvrir les ressources disponibles

- proposer des services spécialisés selon le contexte (p

dispositif). Pour terminer cette étude bibliographique, nous nous intéressons à

l’architecture d’un système sensible au contexte.


2.4.4 Architecture d’un système sensible au contexte

Dey [DEY 99] a été le premier a pensé à séparer l’acquisition de contexte de son utilisation dans les applications afin de pouvoir développer une plateforme générique de développement et déploiement d’applications sensibles au contexte. Dey a défini quelques abstractions qui aident à inférer une interprétation de haut niveau du contexte, et qui supporte la séparation entre la gestion du contexte et Cette proposition d’architecture se basent sur cinq couches princ ntexte, interprétation/ agrégation du contexte, stockage/historique du contexte, dissémination du contexte et

Application

l’application.ipales : capture du co

application.

Dissémination Stockage / Historique Interprétation / Agrégation Acquisition

Figure 2.7 Architecture générale d’un système sensible au contexte

s sont capturées. Selon Grudin [GRU 01], les concepte

t acquis à travers des capteurs physiques ou logiciels tels que

Cette idée a été reprise par la majorité des travaux actuels [MAT 07]

dans le domaine de la sensibilité au contexte. Dans les paragraphes suivants, nous détaillons les fonctions de ces cinq couches et leurs différents éléments.

2.4.4.1 Couche d’acquisition du contexte L’acquisition du contexte correspond au processus à travers lequel les informations contextuelle

urs doivent déterminer quels éléments seront capturés et où placer le seuil qui détermine leur utilisation ou non. Toutes ces décisions se basent, selon cet auteur, sur le type et l'importance d'information, ainsi que sur le fait que cette information puisse être capturée ou inférée facilement, ou d'une manière économiquement viable.

Le contexte peut être obtenu par différentes méthodes qui varient selon l'élément détecté. Selon la méthode d'acquisition utilisée, on distingue dans la littérature trois types d'information contextuelle [MOS 04] : (i) Contexte détecté : ce type d'information es

des capteurs de température, de pression atmosphérique ou de niveau de bruit; (ii) Contexte dérivé : ce type d'information contextuelle est calculé lors de l'exécution, tels que l'heure et la date ; (iii) Contexte explicitement fourni : c'est le cas lorsque l'utilisateur communique explicitement au système les informations nécessaires.

L’acquisition du contexte à travers les capteurs ne constitue pas toujours un processus facile et peut comporter des erreurs. Par exemple,


lorsqu'on se trouve à l'intérieur d'un bâtiment, dans un environnement confiné, la détection de la localisation par GPS devient inefficace, la précision des données ainsi obtenues est fortement dégradée [SAM 05]. On observe donc trois difficultés majeures qui concernent l'acquisition de contexte [DEY 00] : (i) le contexte est dynamique : les changements dans l'environnement doivent être

gements

issent généralement des données

techniqu

. Cette couche doit assurer la résolution de conflits causés par

sources peuvent

les stocker pour une

lige des fonctions additionnelles de découve

ries par degré de complex

isation= « y », Time= « t »).

détectés en temps réel et les applications doivent s'adapter à ces chancontinus ; (ii) le contexte est capturé à partir de multiples sources, souvent hétérogènes et reparties ; (iii) le contexte est obtenu à travers la manipulation des périphériques non conventionnels (autres que la souris ou le clavier).

2.4.4.2. Couche d’Interprétation et d’agrégation du contexte Les informations fournies par les capteurs nécessitent d’être interprétées. Cette couche sert à réaliser cette tâche en analysant et en transformant des données brutes fournies dans d’autres formats de haut niveau qui sont plus faciles à utiliser [HEN 02]. En effet, les capteurs fourn

es qui ne sont pas appropriées pour une utilisation directe par l’application. Par exemple, les données obtenues à travers un GPS (la latitude, la longitude, l'altitude) sont souvent interprétées par l'application afin d'être réellement exploitables. Ainsi, un ensemble de coordonnées devient une adresse dans une ville pour un système de navigation

l’utilisation de plusieurs sources de contexte. En effet, ces donner des résultats contradictoires où peuvent aboutir à des situations imprécises. Cette couche doit donc avoir une certaine intelligence d’interprétation pour résoudre ces conflits.

2.4.4.3. Couche de stockage et historique du contexte Cette couche a pour rôle d’organiser les données interprétées et de

utilisation ultérieure. Ce stockage peut être centralisé ou distribué. La solution centralisée est l’option la plus utilisée puisqu’elle facilite la gestion des mises à jour et des variations des valeurs du contexte. La gestion distribuée est beaucoup plus complexe puisqu’elle inf

rte de ressources et d’actualisation des valeurs du contexte. Pour stocker une information, nous avons besoin de définir un modèle

pour la décrire et pouvoir ainsi l’utiliser dans l’application. des approches de modélisation de contexte ont été classifiées en trois catégo

ité de leur structure de données : - Les modèles Attribut-valeur : ces modèles représentent le contexte

sous forme de paires (attribut, valeur). L’attribut représente un nom d’une information contextuelle. La valeur représente la valeur actuelle de cette information. Par exemple, (local


- Les modèles fondés sur XML : Ces modèles utilisent une structure de données hiérarchiques. La profondeur de cette structure dépend du contexte décrit. Les langages à base de profils sont largement utilisés dans cette catégorie de modèles. Par exemple, nous citons le profil CC/PP (composite Capabilities / Preference Profile) [W3C 04].

- Les modèles fondés sur les ontologies : Ces modèles utilisent les ontologies [Costa03] qui permettent de partager les connaissances dans un système distribué, de comprendre les sémant

iques déclaratives permettant d’assure

nvénients. Les deux premiers modèles sont généralement faciles à implémenter. Le premier modèle a

e de conflits. Le deuxième

à l’application. Ces informations sont distribuées de manière transparente sur

et proviennent de plusieurs types de

La couche application offre ses services aux différents clients concernés. Cette l’extraction des informations des différentes sources

de données attachées à l’application. Chaque application s’abonne à la couche

r une interopérabilité des applications et des terminaux avec une représentation explicite d’une ontologie commune. CoOL [STR 03] est un exemple de langage de description de contexte utilisant les ontologies. Il considère qu’une information du contexte a un certain aspect (ou représentation) et représente une certaine entité.

Ces modèles ont chacune des avantages et des inco

l’inconvénient d’être trop plat et constitue une sourcmodèle présente un modèle plus structuré et organisé mais n’atteint pas la richesse et le degré d’expressivité des ontologies. Cependant le troisième modèle reste très complexe à implanter dans des cas réels.

2.4.4.4. La couche dissémination du contexte Cette couche assure la transmission des différentes informations contextuelles

différents endroits géographiques dispositifs, comme expliqué dans le paragraphe 2.5.4.1 de cette section. Cette couche offre des moyens de communication standards pour notifier l’application des changements de contexte et leur transmission à l’application.

2.5.4.5. La couche application

couche est responsable de

de dissémination de contexte pour qu’elle puisse accéder aux différentes informations contextuelles et être informée de leurs changements.

2.6 Conclusion

Dans ce chapitre, nous avons plus particulièrement abordé la thématique de l'informatique sensible au contexte qui s'intéresse aux applications capables d'avoir un comportement adapté à une utilisation mobile. La conception de telles applications pose des défis liés notamment à l'acquisition, à la représentation et


à l'utilisation de la notion de contexte pour l'adaptation des services, du contenu, ou de la pr tioésenta n de ce contenu. Ces tâches se compliquent car les chercheu

ont référence au contexte de celles q

nérique et évolutive est exigée afin d’apporter une solution efficace aux différents problèmes cités ci-dessus. Cette stratégie doit identifier les outils et les techniques qui permettent de capturer de manière efficace interpréter, le stocker pour ensuite l’utiliser dans le processus d’adaptation.

rs n’ont pas encore abouti à une définition générale de la notion de contexte qui soit à la fois générique et pragmatique. En effet, les définitions déjà proposées sont ou bien très abstraites ou bien très spécifiques à un domaine particulier.

Par ailleurs, la majorité des systèmes sensibles au contexte exploite une notion de contexte qui se limite à la localisation de l’utilisateur et aux caractéristiques de son dispositif (voir, par exemple, [BUR 02]). Ces systèmes ne séparent pas non plus les informations qui f

ui sont relatives au domaine d’application traité par le système [CHA 04]. Par conséquent, ces systèmes deviennent difficiles à concevoir, et les composants liés à l'acquisition et à la manipulation du contexte ne sont pas (ou sont très peu) réutilisables par d’autres systèmes.

En plus, les travaux existants dans la conception de plateformes de déploiement et de développement d’applications sensibles au contexte se fondent sur le fait que la réaction de l’application par rapport aux changements du contexte capturé doit être assuré d’une manière ad-hoc et spécifique par l’application elle-même. Ces travaux considèrent que les modifications du comportement de l’application restent une tâche propre au développeur de l’application et qu’elles restent un paramètre à prendre en compte lors de son développement. Une question se pose alors, que faire si l’application a été déjà développée pour supporter un contexte particulier et si on veut l’adapter à de nouveaux contextes d’utilisation. Les solutions existantes n’ont qu’une réponse à cette question : reprendre tout le cycle de vie de l’application et redévelopper une nouvelle version ? Cette solution est très lourde à effectuer et très coûteuse. Donc une stratégie complète, gé

le contexte, de pouvoir l’


3 Architecture générale de l’approche de la personnalisation

3.1 Introduction Le besoin de personnalisation a été principalement motivé par la croissance considérable de la masse d’informations dans les sources de données, sa large accessibilité à travers le web et par l’hétérogénéité des besoins et des rôles des utilisateurs qui utilisent les systèmes d’information. Certes ces systèmes d’information améliorent sans cesse la qualité d’accès à l’information et facilitent l’échange et la communication entre les usagers, mais ils proposent généralement une organisation, un contenu, un mode d’interaction et une présentation uniques pour tous. Ceci peut être suffisant dans certains cas. Mais face aux contraintes de partage et d’enrichissement de l’information, ils sont confrontés à des sérieux défis qui se matérialisent dans l’accès personnalisé à l’information.

Ce besoin de personnalisation a été accentué par le large développement des systèmes pervasifs qui a permis à l’utilisateur d’être de plus en plus mobile et ainsi d’accéder à des informations quelque soit le lieu, le temps et le dispositif utilisé. Ainsi la qualité d’accès à l’information est conditionnée par « l’accès à la bonne information, quelque soit le lieu, le support et les contraintes ». Dans cette optique, il est important de tenir compte des besoins et des connaissances des utilisateurs lors de l’accès à l’information ainsi que de la situation contextuelle afin de lui fournir une information pertinente, adaptée à ses besoins et son contexte d’utilisation.

3.2 Présentation de l’approche de personnalisation

3.2.1 Cadre général de l’approche de la personnalisation

Le cadre général que nous proposons s’articule autour de trois éléments : 1. l’utilisateur : il utilise le système d’information afin d’accéder à des

informations à l’aide de requêtes ou en navigant dans la masse d’informations délivrée par le système et présentée dans une interface graphique ;


2. un ensemble de ressources : ces ressources sont extraites à partir des sources de données variées suite à une requête utilisateur ; Ces ressources sont représentées de manière hiérarchique dans un document XML.

3. un module logiciel : il permet de gérer la personnalisation de l’accès à l’information. Cette gestion est basée sur le principe de gestion des profils qui prennent en compte le contexte. Donc ce module est composé en deux grandes parties : la gestion des profils et la mise en œuvre de la personnalisation en utilisant les profils.

La Figure 3.1 illustre le cadre général de l’approche de la personnalisation.

Gestion des profils Mise en œuvre de la Personnalisation

Approche de la personnalisation

Ressources structuréesen XML

igure 3.1 Cadre général de l’approche de la personnalisation

Cette approche de personnalisation doit être implémentée de manière dépendante de l’application qui l’exploite. Dans un souci d’évolutivité, elle

ourrait être développée de manière indépendante du domaine de l’application et plémentée sous forme d’une surcouche logicielle aussi bien sur des nouvelles

pplications que des applications existantes (legacy). Les informations des rofils et les paramètres du contexte dépendent uniquement des besoins définis n terme de personnalisation par rapport au domaine d’application.

L’approche de personnalisation que nous proposons s’organise en deux iveaux : un niveau conceptuel et un niveau application. Le niveau conceptuel onsiste à mettre en place des modèles sur lesquels l’approche de la ersonnalisation se basera. Le niveau application a pour objet d’instancier ces odèles et de les utiliser dans la mise en œuvre de la personnalisation.

F

inpimape

ncpm


La Figure 3.2 présente le principe de l’approche de la personnalisation. Au niveau conceptuel, nous modélisons trois modèles en fournissant une description formelle du haut niveau :

1. le modèle de profil qui propose une description formelle des éléments le composant ainsi que leur dépendance avec les éléments du contexte ;

2. le modèle du contexte qui permet de décrire les facettes du contexte qui influencent l’interaction homme-machine ;

Modèle du contexte Modèle du profil Modèle du service

Niveau conceptuel

Module de gestiondes profils

Module de gestion des services

Niveau application

la personnalisation Mise en œuvre de

3. l

Figure 3.2 Principe de l’approche de la personnalisation

application, les modèles conceptuels sont exploités pour mettre en place trois modules :

1. la gestion des profilsinterface, à les m jour ;

2. la gestion des services qui consiste à définir et à programmer les services et à les associer aux profils ;

3. la gestion de la personnalisation en exploitant les profils et les services.

e modèle de services qui permet de mettre en œuvre le processus de personnalisation en se basant sur les connaissances contenues dans les profils.

Au niveau

qui consistent à instancier les profils via une ettre à


3.2.2 Objectif de l’approche de la personnalisation

Ainsi noérique et complète du profil afin de couvrir tous

les contextuelles fin de proposer une information pertinente ;

dans d cation (collaboratifs, réseaux de soins, per

- assurer l’évolutivité de l’approche afin de satisfaire un maximum de ns possibles. De

nouveaux outils et moyens de personnalisation doivent être intégrables ur

être utili

tiles des autres. Cette étape ne

iser des informations délivrées à l’utilisateur de manière transpar

a personna

3.3

us proposons une approche de personnalisation dont l’objectif sera : - fournir une vision gén

besoins de personnalisation en tenant en compte de toutes les situations

- fournir une vision élargie du profil qui laisse la possibilité de l’utiliser ifférents domaines d’appli

vasifs, etc.);

besoins de personnalisation pour un maximum de situatio

facilement à notre approche. Une interface graphique doit être proposée posée dans l’administration et l’instanciation des profils et des services ; - sélectionner les informations pertinentes : Cette sélection se base sur

le principe du filtrage qui permet de séparer les données u doit pas éliminer de manière définitive les données mais elle les

masque en laissant la possibilité à l’utilisateur de les consulter à la demande. - organ

ente, homogène et facile d’accès dans une interface conviviale ; Dans les sections suivantes de ce chapitre, nous allons présenter les

deux niveaux présentés ci-dessus de l’approche de la personnalisation, à savoir le niveau conceptuel et le niveau application. Dans la section suivante, nous commençons par décrire les modèles sous-jacents au processus de l

lisation.

Modèle sous-jacents au processus de personnalisation

3.3.1 Modèle du profil

La majorité des systèmes de personnalisation définissent le profil comme un ensemble de connaissances caractérisant un utilisateur. Donc la modélisation du profil se focalise sur l’utilisateur qui devient le centre du système de la personnalisation. Alors que avec l’avancée technologique, d’autres entités méritent d’être prise en considération dans le processus de la personnalisation afin de répondre à toutes les exigences en matière de satisfaction de l’utilisateur.

Pour répondre à ces préoccupations, nous proposons un modèle du profil qui soit à la fois générique et évolutif. Ce modèle n’est pas exclusif à l’utilisateur. Il permet de caractériser autant d’entités (comme le contexte


d’utilisation) que nécessaire et d’ajouter des nouvelles informations dès qu’un nouveau besoin de personnalisation est présent. Ainsi ce modèle essaie de palier

ains systèmes de personnalisation et s’adapter aux nouvelles exigences de la technologie. Donc une vision plus large du profil est

ntenu peuvent mps. En effet, certains éléments du profil ne

Pour structure de base doit être utilisée par différentes applications sans qu’il soit nécessaire dprofil se gère l’application exprofil.

3.3.1.1 ModélAfin de définir et multi-facettes

1. niveau niveau dentre ces

2. n

les défauts apparus dans cert

proposée dans ce travail qui couvre à la fois l’utilisateur et son contexte d’utilisation et qui est géré de manière complètement générique.

Ce modèle de profil est : o extensible : pour permettre l’ajout et la mise à jour des éléments

à n’importe quel moment. Les éléments du profil ne sont pas forcément tous définis de manière implicite. Des nouveaux éléments peuvent s’ajouter dès que un nouveau besoin apparaît ;

o flexible : ce qui permet de définir librement les éléments du profil et de les organiser selon la catégorisation qui sied le mieux au contexte de l’application ;

o multi-facettes : les profils peuvent être analysés sous différents angles (ensemble d’attributs et / ou dimensions). Ainsi, chaque profil ou combinaison des éléments du profil peut constituer une facette ou vue du profil ;

o évolutif : les éléments du profil ainsi que le coévoluer avec le tesont pas fixes. Ils dépendent de l’évolution des besoins de l’utilisateur ou du contexte d’utilisation. Donc le module de gestion du profil doit permettre toute modification ou mise à jour dès que c’est nécessaire et ceci doit être réalisé de manière facile et compréhensible via des interfaces graphiques. résumer, l’objectif principal d’un modèle du profil est que la

e toucher ou de modifier le code de ces applications. Le module du et s’implémente de manière complètement indépendante de istante. Dans la section suivante, nous décrirons ce modèle du

isation du profil un modèle général du profil qui soit extensible, flexible, évolutif , nous proposons une représentation en trois nivaux :

méta-description du modèle : décrit une abstraction du haut es éléments du profil. Il identifie ces éléments et les relations éléments ;

iveau description du modèle : propose les éléments du profil qui seront utilisés dans le processus de personnalisation. Ces éléments sont une


instanciation de la méta-description du profil relative à un domaine d’application spécifique;

3. niveau instances : représente le contenu des profils. En effet, un profil peut être composé d’une structure (représentée dans le 2ème niveau) et des

es instances des éléments de la structure du

sections suiv tqui le c

3.3 2La méCette r

lisation d’un formalisme par objets de type clasconnu standarrelation tage et de d’agrégation sont bien représentées.

1. La classe sujet : cette classe désigne l’objet qui est décrit par un utilisateur, le dispositif, le rôle,

e d’être décrit. Les obje

tre la classe sujet et ces

s classes peuvent être des paramètres du contexte (la classe utilisateur

données. Ces données sont dprofil.

Les trois niveaux du modèle du profil seront décrits dans les an es. Le but est de préciser le rôle de chaque niveau ainsi que les éléments

omposent et le langage utilisé pour le représenter.

.1. Méta-description du modèle ta-description du modèle fournit une représentation générale du profil. eprésentation sera utilisée dans la définition des profils.

Nous avons choisi l’utise/association pour modéliser le profil, car ce formalisme est largement

et maîtrisé par les concepteurs, à travers notamment l’utilisation du d UML [OMG 04]. De plus, à travers cette représentation par objets, les s d’hériLa Figure 3.4 présente une représentation par objets du modèle du

profil. Cette représentation peut être structurée sous forme d’une hiérarchie de classes qui sont:

profil. Cet objet peut être, à titre d’exemple, l’etc. La classe sujet a une propriété nom. L’instanciation de cette propriété identifie cet objet (utilisateur, machine par exemple) qui demand

ts pour lesquelles les profils sont définis peuvent être organisées en un ensemble de classes. La classe sujet peut être vue comme la super-classe de ces classes. On notera donc, une relation de généralisation/spécialisation entre la classe sujet et les classes représentant les objets dédiées à être décrites par des profils. La figure 3.3 illustre cette relation de spécialisation en

sous-classes. En réalité, ces sous-classes représentent des classes appartenant à l’application pour laquelle le processus de personnalisation est proposé. Certaine

par exemple)


Sujet nom

utilisateur

rôle

machine

Autre_classes ……………..

Figure 3.3 Classe sujet vue comme une super-classe des objets décrits par des profils

référence. aractériser le sujet utilisateur; U1 et U2 sont deux instances de la classe tilisateur. Donc pour ces deux instances, deux profils sont respectivement éfinis (P1 U1 et P2 est pour U2). Ainsi chaque instance d’

donné peut avoir un profil. Cette instance est définie par la propriété propriétaire de la classe profil.

isant un profil telles que les compétences, les préférences, etc. En effet, es informations peuvent être regroupées et structurées sous forme d’un

ensembl

ibuts (simples ou complexes). Nous avons choisi de nommer cette cla

de traduction du modèle du profil en schéma

2. La classe profil : cette classe décrit les critères qui caractérisent un sujet donné tel que l’utilisateur, le rôle, etc. Cette classe définit une propriété propriétaire. Cette propriété est une instance de la classe auquel le sujet fait

Par exemple, soit deux profils P1 et P2 qui sont créés pour cud est pour un sujet

3. La classe dimension : cette classe décrit des informations caractérc

e de dimensions ouvertes. Donc nous pouvons dire qu’un profil est composé d’un ensemble de dimensions.

4. La classe attribut_complexe : les informations qui sont regroupées et structurées en dimensions seront à leur tour structurées en attributs complexes. Par exemple, la dimension préférences pourra être caractérisée par l’attribut complexe Activité, l’attribut complexe Présentation, etc. Donc un attribut est définit comme une caractéristique de la dimension et dans une dimension, nous pouvons trouver une à plusieurs caractéristiques. Cet attribut peut être composé d’un à plusieurs attr

sse « attribut complexe » du fait que le modèle du profil sera ensuite implémenté en schéma XML et ce dernier utilise cette appellation pour désigner les attributs qui sont composés d’autres attributs. Donc nous avons trouvé que l’utilisation de cette appellation dès le modèle conceptuel pourrait faciliter, par la suite, la compréhension du processus

XML. 5. La classe attribut_simple : cette classe représente un attribut

élémentaire ou non décomposable auquel un contenu est affecté. Par exemple :


la taille, la couleur, etc. Ce nom est attribué à cette classe pour la même raison que l’attribut complexe. En fait le langage schéma XML utilise également l’appellation de l’attribut simple pour désigner les attributs élémentaires.

6. La classe contenu qui décrit les valeurs possibles qui sont associées à chaque attribut simple. Cette classe est composée d’une valeur qui représente les données réelles et d’un type donné (numérique, alphanumériques, booléen, etc.). Par exemple : la valeur rouge est associée à l’attribut couleur.;

7. La classe concept : cette classe a pour rôle de spécifier si l’attribut complexe fait référence à une classe interne à l’application (destinée à être personnalisée). Par exemple, un attribut complexe localisation peut faire référenc

et type. La

e, à titre d’exemple, à la classe lieuTravail appartenant à la source de données de l’application. Ainsi les valeurs de cet attribut complexe seront sélectionnées à partir des instances de la classe dont cet attribut fait référence. Une autre possibilité consiste à indiquer si l’attribut complexe fait référence à un paramètre du contexte. La classe concept contient deux propriétés nom

première propriété est destinée à spécifier le nom de la classe où éventuellement le paramètre du contexte. La deuxième propriété spécifie si l’attribut complexe fait référence à une classe et (ou) à un paramètre du contexte. Dans ce cas, type prend trois valeurs possibles :

1) type = [1,0] dans le cas où l’attribut complexe fait référence seulement à une classe appartenant à l’application en cours de personnalisation ;

2) type = [1, 1] dans le cas où l’attribut complexe fait référence à une classe qui désigne également un paramètre du contexte ;

3) type = [0, 1] dans le cas où l’attribut complexe fait référence seulement à un paramètre du contexte.


profil proprietaire

dimension nom

attribut_simple nom type

attribut_complexe nom

1..*

1..*1..*

sujet nom

contenu Valeur

EstAssocie

refConcept nom type

PContexte nom

*

TypeClasse nom

+classe

0..1 depend 1

*

1 EstDecrit

Figure 3.4 Modélisation générale du profil

En ce qui concerne la description des différentes associations, le

modèle du profil comporte cinq types d’association : EstDecrit, EstAssocie, agrégation/décomposition, depend.

1) Association EstDécrit : elle est définie entre la classe profil et la classe sujet pour signifier qu’un profil est créé pour décrire un sujet donné. La Figure 3.5 présente un exemple de cette association : un sujet utilisateur est décrit par un entité utilisateur qui devient le propriétaire de ce profil.


:sujet

nom= utilisateur

:profil Proprietaire=Pro1

estDecrit

Figure 3.5 Association EstDecrit 2) Relation d’agrégation : plusieurs relations de

décomposition/d’agrégation existent entre les classes : une relation d’agrégation entre la classe profil et la classe dimension pour signifier qu’un profil peut être composé d’une ou plusieurs dimensions, une relation d’agrégation entre la classe dimension et la classe attribut complexe pour signifier qu’une dimension est composée d’un ou plusieurs attributs complexes et une relation d’agrégation entre la classe attribut_complexe et lui-même pour signifier qu’un attribut complexe peut être composé d’autres attributs complexes. Une relation d’agrégation existe également entre la classe attribut_complexe et la classe attribut_simple pour signifier qu’un attribut complexe peut être composé d’un à plusieurs attributs simples.

:profil

:dimension nom= préférences

:dimension nom= droit d’accès

:sujet nom=utilisateur

Figure 3.6 Exemple d’une relation de décomposition entre la classe profil et la classe dimension

Donc trois relations d’agrégation existent dans la méta-description du

profil. La Figure 3.6 donne un exemple d’une relation d’agrégation. Un profil décrivant un sujet utilisateur est composé de deux dimensions : préférences et droit d’accès.


3) Association estAssocie : Cette association est définie entre la classe attribut_simple et la classe contenu pour signifier qu’un attribut simple est associé à une ou plusieurs valeurs. En d’autres termes, ces valeurs peuvent être considérées comme des instances des attributs simples. En principe, ces valeurs constituent les données qu’un profil donné peut contenir. La Figure 3.7 donne un exemple de cette association : l’attribut complexe objet contient un attribut simple libellé qui est associé à deux valeurs alphanumériques O1 et O2. L’attribut complexe objet composent l’attribut complexe autoriser qui compose la dimension droit d’accès.

:attribut_complexe :attribut_complexe :dimension Nom= droitd’accès

:attribut_simple

:contenu

valeur=O1

:contenu valeur=O2

estAssoci

estAssocie

Figure 3.7 Exemple de l’association estAssocie

4) Association depend : cette association est proposée entre la classe

attribut_complexe et la classe refConcept pour signifier qu’un attribut complexe peut ne pas être isolé et dépendre d’un autre concept. Ce concept désigne une classe appartenant à la source de données de l’application en cours. Cette dépendance est concrétisée par le fait que les valeurs associées à l’attribut complexe en question proviennent des instances du concept dont l’attribut complexe dépend. Ce concept peut représenter un paramètre du contexte ou une autre classe de l’application. Le rôle d’association classe signifie que le concept est une classe. La Figure 3.8 donne deux exemples d’instances d’objets entre la classe attribut_complexe et la classe refConcept. Le premier exemple spécifie que l’attribut simple localisation dépend de la classe localisation qui est du type contexte. Le second exemple désigne un attribut complexe objet qui dépend de la classe objet. Ce dernier n’est pas un paramètre du contexte.


:attribut_complexe nom=localisation

:refConcept Nom=localisationType=[1,1]

+class

:attribut_complexe nom=objet

depend

:refConcept Nom=objet Type=[1,0]

+class depend

Figure 3.8 Exemple de l’association depend Ainsi nous avons décrit la composition de notre modèle conceptuel du

profil (classes et relations entre ces classes). Ce modèle qui est considéré comme générique doit permettre d’ajouter autant de profils que nécessaire.

3.3.1.3 Description du profil

A partir de la méta-description du profil, nous allons pouvoir concrétiser les besoins de l’application en terme de personnalisation par rapport à un domaine spécifique. Il s’agit de définir les éléments d’un profil qui décriront un sujet donné dans un domaine précis. Ces éléments permettent de définir la structure d’un profil donné. En effet, chaque profil peut être composé d’une structure et des données. La définition des éléments composant la structure dépend essentiellement de la bonne estimation des besoins en terme de personnalisation. En effet, lorsqu’un nouveau besoin de personnalisation est présent, il est modélisé en un ensemble de classes et relations entre ces classes. Ensuite ces éléments de cette représentation conceptuelle sont traduits en éléments du profil. Les étapes de traduction des éléments de la représentation conceptuelle en éléments du profil sont décrites dans le chapitre 4 de cette thèse.

Ainsi une fois que le besoin de personnalisation est déterminé et représenté sous forme d’un modèle objet du type classe/association, la structure du profil est construite. Cette structure concerne précisément les classes dimension, attribut_simple et attribut_complexe du modèle conceptuel du profil. A ce niveau de conception, les données (le contenu) ne sont pas encore définies.

La Figure 3.9 illustre un exemple de description d’un profil. Ce profil est défini pour décrire l’utilisateur. Donc des dimensions ainsi que des attributs sont définis pour constituer la structure générale du profil utilisateur. Dans cet


exemple, nous proposons de modéliser l’objet préférences de la classe dimension. Cette dimension est formée de deux attributs complexes activité et présentation. L’attribut complexe activité est composé de trois attributs simples : localisation, objet et tâche. L’attribut complexe présentation est composé à son tour de deux attributs simples : couleur et taille.

:sujet nom= utilisateur

:profil Id=1

:dimension nom=préférences

:attribut_complexe nom=activité

:attribut_complexe nom=localisation

estDecrit

:attribut_complexe nom=tache

:attribut_compelxe nom=objet

:attribut_complexe nom=présentation

:attribut_simple nom=couleur

:attribut_simple nom=taille

:refConcept nom=localisation type=[0,1]

:refConcept nom=objet type=[1,0]

depend

depend

Figure 3.9 Exemple de description d’un profil


Nous avons déjà expliqué que l’attribut complexe peut dépendre d’autres classes. Ces classes désignent, soit des classes internes à l’application, soit des paramètres du contexte. Ici, à titre d’exemple, nous considérons que le contexte est composé de deux paramètres : l’utilisateur et la localisation et l’application interne comporte objet parmi ses classes. Donc si nous analysons les attributs complexes de l’exemple, nous pouvons dire que l’attribut complexe localisation dépend du paramètre du contexte localisation et l’attribut complexe objet dépend de la classe objet.

Ainsi lorsqu’il existe un besoin de définir un profil pour un sujet donné, une description générale est proposée en définissant les dimensions et les attributs après avoir analyser les besoins en terme de personnalisation par rapport à un domaine spécifique.

3.3.1.4 Instanciation du profil L’instanciation du profil est décrite en détail dans le prochain chapitre. Mais nous donnons quelques précisions sur ce thème. En effet, le contenu d’un profil est défini en instanciant la classe contenu. Cette instanciation est réalisée en associant des valeurs aux attributs simples. Pour illustrer ceci, l’exemple présenté dans la Figure 3.10 décrit une dimension préférences composée d’un attribut complexe présentation. Cet attribut est composé de deux attributs simples : couleur et taille. Des contenus sont associés à ces deux attributs simples.

:Attribut_complexe Nom=présentation

:dimension Nom=préférences

:Attribut_simple nom=taille type=alphanumérique

:Atribut_simple Nom=couleur Type=alphanumérique

:contenu valeur=12

:contenu valeur=21

:contenu valeur=noir

estAssocie estAssocie

estAssocie

Figure 3.10 Exemple d’instanciation d’un profil


3.3.2 Modèle du Contexte d’utilisation

3.3.2.1 Formalisation du contexte d’utilisation Plusieurs travaux étudiés dans l’état de l’art ont abordé la question de la formalisation du contexte. En s’inspirant de ces travaux, nous proposons un modèle du contexte d’utilisation représenté par un ensemble de paramètres. Ces paramètres sont regroupés par un ensemble de facettes. Nous définissons deux facettes : Communauté, Espace. Le choix de ces facettes a été principalement conditionné par l’objectif attendu de la personnalisation de l’information.

Etant donné que la majorité des systèmes sensibles au contexte ont pris en considération l’adaptation au dispositif, nous ne comptons pas traiter cette facette. Notre système, ayant un caractère générique et évolutif, permet d’intégrer facilement des nouveaux besoins d’adaptation tels que la prise en considération du dispositif.

Donc les deux facettes (Communauté, Espace) doivent permettre de satisfaire les besoins de l’utilisateur dans toutes les situations contextuelles. La facette Communauté concerne les paramètres liés à l’individu et aux groupes auxquels il participe. L’objectif ici est d’identifier qui participe directement ou indirectement au contexte d’utilisation (la question « qui ? »). Dans cette facette, nous identifions trois paramètres : l’utilisateur, le groupe et le rôle. En effet, un utilisateur peut être membre d’un groupe. Un groupe peut être défini comme un ensemble d’individus qui coopèrent pour atteindre un objectif commun. Cet utilisateur possède un rôle qui indique ses responsabilités au sein de ce groupe. Ces trois paramètres permettent donc de considérer le contexte collaboratif, un facteur très essentiel à prendre en compte dans les systèmes d’information. En plus, le paramètre rôle permet de faciliter l’administration de certaines informations telles que les droits d’accès. Au lieu de définir des règles d’accès à chaque utilisateur ayant un rôle r, elles seront définies pour les rôles et les utilisateurs hériteront les règles des rôles auxquels ils appartiennent.

La facette Espace permet de localiser l’endroit où se déroule l’interaction entre l’utilisateur et le système (la question « où ? »). Ceci conduit donc à considérer le contexte physique de l’utilisateur qui influe sur le comportement d’un utilisateur et peut, à lui seul, donner plusieurs indications sur le contenu voulu par l’utilisateur. Ce paramètre peut être capturé ou calculé par des différentes méthodes, telles que l’utilisation des capteurs de type GPS ou basées sur la puissance du signal des principaux éléments observés par les systèmes sensibles au contexte.


La Figure 3.11 illustre la représentation du modèle du contexte d’utilisation.

Espace Communauté

Utilisateur

Rôle Groupe

Localisation

Figure 3.11 Facettes du contexte A l’image de la vision générique du profil utilisateur, une vue générique

est fournie pour modéliser le contexte. Ce modèle utilise le formalisme par objets (UML) ce qui permet de l’étendre par l’ajout d’autres facettes et paramètres. Ainsi, dans ce modèle illustré dans la Figure 3.12, le contexte est représenté par la classe ContextProfile qui décrit les facettes identifiées précédemment. Chaque facette représentée par la classe ContextFacet contient des paramètres du contexte représentés par la classe PContext.

ContextProfile

description

ContextFacet Name

PContext Name

Figure 3.12 Description du contexte Chaque paramètre du contexte est représenté par une classe dans un modèle

dédié au contexte. Ces classes ne sont pas indépendantes. Des relations de dépendance existent entre elles.

La figure 3.13 présente le modèle qui représente les classes ainsi que les relations de dépendance entre ces classes comporte sept classes : Utilisateur, Groupe, Rôle, Localisation. Des relations de dépendance existent entre les classes utilisateur,


Groupe et Rôle pour décrire qu’un utilisateur appartient à 0 ou plusieurs groupes à travers les rôles qu’il tient. Un groupe admet plusieurs rôles. La dépendance entre ces trois classes est modélisée par l’association communauté. Par exemple, dans une équipe médicale M qui soigne un patient X à domicile, nous trouvons l’utilisateur U1 avec un rôle médecin, l’utilisateur U2 avec un rôle infirmière et l’utilisateur U3 avec un rôle auxiliaire de vie. L’utilisateur U2 peut aussi exercer le rôle du pédiatre sans qu’il appartienne à un groupe. Donc nous obtenons pour l’utilisateur U1, communauté (U1, médecin, X), communauté (U1, pédiatre). D’autre part, la localisation d’un utilisateur est exprimée par l’association Espace qui décrit qu’un utilisateur localisé à un endroit donné. Par exemple, le médecin U1 est localisé à domicile chez le patient.

<xml> <ContexteProfile> <ContextFacet name=’communaute’> <ContextParameter name=’Utilisateur’>Marie</ContextParameter> <Contextparameter name=’Groupe’>G1</ContextParameter> <Contextparameter name=’Rôle’>Infirmière</Contextparameter> </ContextFacet> <ContextFacet name= ‘Espace’> <ContextParameter name=’Localisation’>Domicile du patient X</ContextParameter> </Contextfacet> </contextProfile>

Marie :Utilisateur

G1 : Groupe

Infirmière : Rôle

Domicile du patient X : Localisation

communauté

Espace

Figure 3.13 Représentation conceptuelle des paramètres du contexte

3.3.2.2 Situation contextuelle L’instanciation des paramètres du contexte caractérise une situation contextuelle. La considération du contexte ne doit modifier en aucun cas l’information que l’utilisateur veut avoir de l’application mais peut conduire à la traiter ou à la présenter différemment.

Figure 3.14 Exemple d’une situation contextuelle Pour stocker les paramètres du contexte, nous utilisons une

représentation en XML (Figure 3.14). La structure XML définie un élément XML pour chaque facette ContextFacet. Une facette est composée d’un


ensemble de paramètres PContext. Dans notre contexte, nous définissons deux éléments ContextFacet : communauté et Espace. L’élément Communauté comporte trois PContext : rôle, utilisateur et groupe. La facette Espace comporte localisation. A chaque PContext, une valeur est associée. Le langage XML a pour avantage d’être générique et évolutive. Ainsi il permet d’ajouter des paramètres additionnels selon le domaine d’application.

3.3.2.3 Relation d’héritage entre les profils

Une relation d’héritage existe entre les profils. Cette relation d’héritage est calculée en fonction de la relation de dépendance entre les sujets auxquels appartiennent les profils.

Intuitivement parlant, soit trois sujets A, B et C, A possède un profil Pa, B possède un profil Pb et C a un profil Pc.

- Nous disons que Pa hérite de Pb si et seulement si A dépend de B ;

- la relation de dépendance est antisymétrique : si A dépend de B => B ne doit pas dépendre pas de A ;

Rôle :sujet Profil_role :profil

Utilisateur :sujet Profil_utilisateur :profil

estDecrit

Joue

estDecrit

Hérite

- la relation de dépendance est non transitive : si A dépend de B et B dépend de C => A ne doit pas dépendre de C.

Figure 3.15 Exemple d’héritage entre les profils Afin d’illustrer ceci, nous proposons l’exemple suivant illustré dans la

Figure 3.15 : nous avons montré lors de la modélisation du contexte qu’un utilisateur joue un à plusieurs rôles (une dépendance existe entre l’utilisateur et le rôle). Si un profil Profil_utilisateur est défini pour un utilisateur et un profil Profil_role est proposé pour décrire un rôle, le profil de l’utilisateur hérite le profil du rôle qu’il joue.

La dépendance entre les sujets est indiquée lors de la définition d’un nouveau sujet. Un sujet peut dépendre d’un à plusieurs sujets. Cette relation de dépendance entre les sujets est exprimée à l’aide d’un document xml. La figure


3.16 présente un exemple de description xml de cette relation de dépendance. Le noeud racine de la structure xml est relation_heritage. L’élément Profils décrit la relation de dépendance entre les sujets. L’exemple présenté dans la Figure 3.16 décrit une dépendance entre trois sujets : l’utilisateur, le rôle et le groupe. Un utilisateur joue un ou plusieurs rôles et est membre d’un ou plusieurs groupes. Donc cet utilisateur possédant un profil, hérite les profils de rôle et de groupe. Cet héritage est représenté dans la structure xml par le noeud herite qui désigne le sujet qui hérite les profils et le nœud est_herite qui désigne les sujets qui sont hérités à travers le nœud sujet. Ces sujets correspondent aux propriétaires des profils.

<xml> <relation_dependance> <sujets> <herite>utilisateur</herite> <est_herite> <sujet>rôle</sujet> <sujet>groupe</sujet> </est_herite> </sujets> < !autres sujets> </relation_dependance>

Figure 3.16 Représentation de la relation de dépendance en XML

3.3.3 Modèle des services

Nous avons vu que la personnalisation de l’accès à l’information se fonde sur l’utilisation générique des profils afin de couvrir tous les besoins de personnalisation pour l’ensemble des scénarios d’utilisation. Toutefois cette gestion générique des profils pose des nouveaux défis. En effet, elle ne permet pas de définir à l’avance l’ensemble des fonctionnalités qui sont chargées de mettre en oeuvre la personnalisation de l’information guidée par les profils. Les profils sont des conteneurs de connaissances qui caractérisent une entité. Donc ils sont incapables, seuls, de réaliser les objectifs attendus de personnalisation. Un module additionnel doit être conçu afin de prendre en charge la mise en œuvre de la personnalisation. Ce module permet de proposer un ensemble de fonctionnalités qui tiennent compte des données contenues dans les profils. Ces fonctionnalités sont organisées dans des services. Donc formellement parlant, un service est décrit comme un programme autonome composé d’un ensemble de fonctionnalités définissant un ensemble de règles de personnalisation.

Ces services a pour but d’exécuter deux objectifs de personnalisation : La personnalisation du contenu (phase I) et la personnalisation de la présentation


(phase II). En effet, lors de la création d’un service, la phase à laquelle il appartient doit être spécifiée. Ainsi les services seront classifiés en deux groupes : services dédiés à personnaliser le contenu (données) et services dédiés à personnaliser la présentation du contenu (interface).

Ainsi, la combinaison des profils et des services permet de développer un système de personnalisation qui soit à la fois générique, indépendant et évolutif. De ce fait, lorsqu’une nouvelle entité (dimension ou attribut) s’ajoute aux profils, un service regroupant un ensemble de fonctionnalités nécessaires pour l’exploitation de cette entité sera créé.

3.3.3.1 Notion du service Un service peut être défini comme un processus applicatif autonome. Un service est principalement composé d’un ensemble de paramètres d’entrée PEntree = {e1, e2, e 3, …., em} et d’un ensemble de paramètres de sortie PSortie ={s1, s2, s3, …., sm}, du critère d’exécution, de la phase d’exécution et d’un type qui permet de spécifier si le service sera exécuté de manière générale pour toutes les sessions ou s’il sera destiné uniquement à la session en cours. Ainsi nous proposons de modéliser un service S de la façon suivante :

S = nomS(id, type, critère, PEntree, PSortie, phase)

- Où id est l’identifiant du service - type prend pour valeur : générale ou spécifique. Par exemple, dans une

situation exceptionnelle (une urgence par exemple), le médecin est autorisé à consulter le dossier d’un patient quelconque. Donc lorsque l’utilisateur ouvre une session dans cette situation, seuls les services dont le type a pour valeur spécifique seront exécutés sinon les services avec une valeur générale seront appelés ;

- Critère concerne la manière dont un service sera exécuté. Nous distinguons trois critères :

- séquentiel : ce critère spécifie que le service peut s’exécuter indépendamment des autres services.

- ordre : ce critère spécifie que l’exécution du service dépend de l’exécution d’un autre service.

- conditionnel : ce critère spécifie que l’exécution du service dépend du respect de la condition définie pour ce service.

Ce critère est exprimé à travers deux attributs (nom et valeur) de la façon suivante :

nom= {séquence, conditionnel, ordre} Si Nom = séquence alors valeur = ";" ; Si Nom = ordre alors valeur = "nomS2 → nomS1" (→ indique que

nomS2 dépend de nomS1);


Si Nom = conditionnelle alors valeur= "if" <condition> "then" opération

["else" opération] "end if" ; - PEntree est une liste des paramètres d’entrée {e1, e2, e 3, …., em} ; - PSortie est une liste des paramètres de sortie {s1, s2, s3, …., sm} ; - Phase permet de spécifier si le service sera invoqué lors de la première phase ou la deuxième phase

Comme illustré dans la Figure 3.17, chaque paramètre d’entrée ei de la liste PEntree et paramètre de sortie si de la liste PSortie est une classe qui a un nom et un type (numérique, alphanumériqe, etc). Nous associons à chaque composant ei, une valeur possible vi.

ci vi

Nom Type

Value

Service S

Service S’

PEntree (S)

PSortie (S)

PEntree (S’)

PSortie (S’)

S’ dépend de S S’.si = S.ei

*

Figure 3.17 Modélisation des paramètres d’entrée et des sorties d’un service

Cette définition générique des paramètres d’entrée et de sortie va permettre d’établir un échange de valeurs entre les services (Figure 3.18). En effet, les paramètres d’entrée d’un service S associés à des valeurs peuvent provenir des paramètres de sortie associés à des valeurs d’un ou plusieurs services S’ d’où la nécessité de prendre en considération cette dépendance entre les services qui influence nettement l’ordre d’exécution de ces services.

Figure 3.18 Principe de fonctionnement des services

Un service est programmé sous forme d’un ensemble de fonctionnalités {f1, 2, .., fm} regroupées dans une fonction globale qui porte le nom du service nomS. Ces

être exécutées lorsqu’un service nomS est invoqué. La fonction globale ainsi que les fonctionnalités F sont définies comme un tuple composé d’une liste de paramètres d’entrée

ffonctionnalités représentent des fonctions développées afin d’


Kari 66

ne ABBAS / Thèse en informatique / 2008 / Institut national des sciences appliquées de Lyon

Service Nom Type

Paramètre Nom type

Fonctionnalité Nom

Entrée

Sortie

Critère DescripType

tion

phase description

1

1

*

*contient

1,*

1,*

(<e1,e2...en>) et une liste de paramètres de sortie (<s1,s2...sk>) et sont modélisées comme suit :

ns une situation contextuelle donnée. Nous modélisons une règle par une paire (Expressions, Actions).

par le

amme de classes de la modélisation des services

F = nomf(<e1,e2...en>, <s1,s2...sk>)

A l’identique des services, une dépendance existe entre les fonctionnalités. En effet, les paramètres d’entrée d’une fonctionnalité peuvent provenir de la sortie d’une ou plusieurs fonctionnalités. La chaîne d’exécution de ces fonctionnalités dépend de l’ordre de leur codage dans la fonction globale. Si f2 dépend de f1 => f2 sera écrite à la suite de f1.

Une règle de personnalisation définit les actions de personnalisation à effectuer sur le modèle fonctionnel de l’application da

3.3.3.2 Modélisation des services Les services sont donc des fonctions développées pour mettre en œuvre la personnalisation des informations. Chaque service a un identifiant et un nom. Lorsqu’un profil est créé, un ensemble des services sont créés. Des services seront classifiés en deux phases : phase I (personnalisation du contenu) et phase II (personnalisation de la présentation). Des dépendances peuvent exister entre les services de deux phases. Cette dépendance est spécifiée lors de l’affectation d’un service à la phase II. La modélisation des services est présentée digramme des classes de la Figure 3.19.

Figure 3.19 Diagr

Nous utilisons le langage XML pour stocker les services (Figure 3.20). services comme nœud racine. Les services seront ensuite décrits par

Service. Dans ce nœud, nous définissons l’identifiant du service, son nom, paramètres d’entrée, les paramètres de sortie, la phase d’exécution, le critère et le

pe.

Cette structure a le noeud les ty

Figure 3.20 Représentation des services en XML

La programmation des services ainsi que les techniques utilisées pour les implémenter seront détaillées dans les chapitres suivants.

3.4 Conclusion

<XML> <services> <service id=1> <nomS>preferences</nomS>

<PSortie> <paramètre2>valeur< /paramètre2> <paramètre3>valeur</paramètre3> </PSortie> </service>

<phase>1</phase> <critère>

<nom>sequentiel</nom> <valeur> ;</valeur> </critère> <PEntree> <paramètre1>valeur</paramètre1> </PEntree>

<service id=2> <nomS>preferences</nomS> <phase>1</phase> <critère>

<nom>sequentiel</nom> <valeur> ;</valeur> </critère>

<PEntree> <paramètre1>valeur</paramètre1> </PEntree> <PSortie> </P

<paramètre2>valeur< /paramètre2> <paramètre3>valeur</paramètre3>

Sortie> </service>

Dans ce

ion se fondera. D’un coté, la combinaison des services avec des

ofils va permettre d’assurer une gestion générique de la personnalisation. D’un utre côté, le prise en considération du contexte améliore considération le nctionnement de l’approche de la personnalisation en tenant en compte de ensemble des situations contextuelles de l’utilisateur.

chapitre, nous avons décrit spécifiquement les modèles du niveau conceptuel de l’approche de la personnalisation, à savoir le modèle du profil, le modèle du contexte et le modèle des services. Ces trois concepts : profil, contexte et services forment les trois piliers sur lesquels l’approche de la personnalisatprafol’


Dans le chapitre suivant, nous allons présenter l’architecture globale de approche de la personnalisation. Ensuite, une description détaillée de chaque odule de cette architecture sera fournie. Parmi ces modules, nous trouvons la

gestion des profils qui exposera les différentes étapes de création et d’instanciation d’un profil.

l’m


4 Exploitation des modèles de profils dans le processus de personnalisation

4.1 Introduction

Nous avons vu dans le chapitre 3 que la personnalisation de l’information se base sur l’utilisation générique des profils afin de couvrir tous les besoins de personnalisation pour l’ensemble des scénarios d’utilisation. Le chapitre précédent a présenté la modélisation des trois piliers sur lesquels l’approche de la personnalisation se fondera, à savoir les profils, le contexte et les services. Les services exploitent les données stockées dans les profils pour mettre en œuvre la personnalisation de l’information. La combinaison du contexte avec le profil est un avancement considérable dans le domaine de la personnalisation, ce qui permet de considérer à la fois l’utilisateur et son contexte. Ainsi dans ce chapitre, nous allons décrire la gestion de ces trois facteurs. Nous avons vu dans le chapitre précédent que chaque facteur est géré à deux niveaux : le niveau conceptuel et le niveau applicatif. Le premier niveau est dédié à la modélisation de ces facteurs. Toutes les étapes de cette modélisation ont été décrites dans le chapitre précédent. Le deuxième niveau décrit les différentes étapes de mise en application de ces trois facteurs. Ces étapes sont exposées dans ce présent chapitre.

4.2 Architecture générale de l’approche de la personnalisation

La mise en œuvre de la personnalisation s’articule autour d’un ensemble des modules afin de gérer l’ensemble des facteurs sur lesquels la personnalisation est basée. Rappelons que chaque facteur a un rôle bien précis : les profils sont des conteneurs d’informations qui caractérisent un sujet quelconque (utilisateur, machine, application, etc.); le contexte représente les informations externes qui peuvent influencer l’interaction entre l’utilisateur et l’application ; les services sont des programmes autonomes chargés de mettre en œuvre la personnalisation.

La Figure 4.1 présente l’architecture générale de notre approche de la personnalisation. Dans cette architecture, nous distinguons cinq modules :


Module 1 : gestion des profils Ce module consiste à gérer un ensemble de tâches : créer un profil, représenter un profil, ajouter des données dans un profil donné, mettre à jour un profil (y compris supprimer ou modifier les composants ou les données d’un profil).

Module 2 : Gestion du contexte Ce module est défini afin de réaliser des étapes considérées comme classiques dans les systèmes sensibles au contexte : la capture, l’interprétation, le stockage et la dissémination du contexte. Module 3 : Gestion des services Ce module gère un ensemble des tâches telles que la représentation des services, l’association entre les services et les profils, l’ordre d’exécution des services.

Module 4 : exploitation des profils dans le processus de la personnalisation Ce module décrit les étapes de sélection des profils qui sont valides par rapport au contexte courant de l’utilisateur. Cette phase se base sur le principe de comparaison entre les paramètres du contexte et les éléments des profils. En final, les profils valides seront utilisés dans la mise en œuvre de la personnalisation.

Module 5 : mise en oeuvre de la personnalisation Une fois que la phase de l’extraction des profils est finie, la phase suivante consiste à décrire comment utiliser ces données dans la mise en œuvre de la personnalisation. Deux types de personnalisation sont pris en compte : - Personnalisation du contenu : qui consiste principalement à filtrer les données renvoyées par les sources de données suite à une requête utilisateur en tenant compte des critères définis dans les profils correspondant à l’utilisateur final. - Personnalisation de la présentation : qui consiste à générer une interface graphique personnalisée à l’utilisateur final en fonction de son profil et de son contexte


Gestion des profils Gestion du contexte

Base des profils

Gestion des services

Exploitation des profils dans le processus de la personnalisation

Mise en œuvre de la personnalisation

Personnalisation de la présentation Personnalisation du contenu

Architecture générale de l’approche de la personnalisation

L’ensemble de ces modules est décrit dans les sections suivantes de ce hapitre.

.3 Gestion des profils

Figure 4.1

c

4 La gestion des profils est un module important dans l’approche de la

rsonnalisation de l’information. Ce module regroupe un ensemble de tâches parties en deux groupes : la gestion de la structure des profils et la gestion des

onnées (Figure 4.2). Un profil est composé de deux parties : sa description (appelée

galement structure) et son contenu. La description d’un profil définit les étadonnées qui composent ce profil. Ces métadonnées représentent notamment

es instances des classes dimension, attribut_simple et attribut_complexe du odèle du profil. Le contenu concerne particulièrement les données du monde el. Ces données sont des instances de la classe contenu du modèle de profil.

pered

émdmré


Gestion des structures des profils

Ajout des éléments

Suppression des éléments

Modification des éléments

Gestion des données

Insertion des données

Suppression des données

Modification des données

Création des structuresdes profils

Mise à jour de lastructure des profils

Mise à jour desdonnées

STRUCTURE CONTENU

Figure 4.2 Ensemble des tâches du module de gestion des profils Ce module de gestion des profils s’opère en deux grandes étapes :

La création des profils : Cette étape consiste à décrire les étapes de définition des profils. Cette définition concerne la structure des profils ainsi que les données. En final, nous avons des profils stockés dans des documents XML (section 4.3.1).

l’interface de gestion des profils. Dans les paragraphes suivants, nous détaillons le fonctionnement de

chaque étape.

4.3.1 Création des profils

La mise à jour des profils : cette étape consiste à mettre à jour la structure d’un profil ainsi que les données pour satisfaire une certaine évolution dans les besoins. Cette étape peut s’effectuer de manière manuelle à travers

La re d’un profil est conçue pour satisfaire un à plusieurs besoins de personnalisation. Le profil qui décrit un utilisateur peut contenir, à titre d’exemple, une dimension qui gère les droit d’accès, une dimension qui définit les préférences et ainsi de suite. Donc à l’intérieur d’une structure d’un profil

à des besoins fonction des

caractér chine e peuv ateur

peut con

structu

donné, nous pouvons définir autant d’éléments qui répondent différents. Les structures des profils créés diffèrent en

istiques des sujets. Par exemple, le sujet utilisateur et le sujet maent pas avoir la même composition de profil. Le profil de l’utilisntenir les préférences, les compétences, etc. Par contre le profil de la

machine contient la capacité, la mémoire, la taille de la machine, etc.


Les profils créés sont des instances du modèle du profil. Nous avons vu dans le chapitre 3 une description abstraite du profil. Les éléments composant la structure

fils.

ents XML. En principe, un document est considéré comme une instance du schéma XML. Malgré que le langage

la fois les métadonnées et les données, mais ur décrire la structure du profil (métadonnées)

faciliter la gestion des éléments composants les profils. Donc les documents

mence dès qu’un be

ensemble de classes et relations en utilisant

s la structure du profil relatif à un sujet

u profil du sujet concerné. Pour ceci, nous devons en premier lieu vérifier si le profil, auquel le schéma XML sera ajouté, a déjà été créé. Si c’est le cas, le schéma XML sera intégré à la structure du profil qui est

d’un profil sont des instances des classes sujet, dimension, attribut_complexe et attribut_simple. Le contenu d’un profil donné représente une instanciation de la classe contenu. Cette instanciation est effectué lors de l’insertion des données dans les pro

Nous avons choisi d’exprimer la structure des profils en schéma XML et le contenu des profils dans des documXML XML permet de représenter à l’utilisation du schéma XML podoit XML servent seulement à stocker les données.

Dans les sections suivantes, nous décrivons les deux étapes principales de la création des profils : la création de la structure du profil et l’insertion des données dans les profils.

4.3.1.1 Création de la structure d’un profil Cette structure doit tenir compte des situations contextuelles dans lesquelles l’utilisateur peut se trouver au moment où il accède au système. Ensuite à partir de cette structure, des données peuvent être insérées dès que c’est nécessaire.

Le processus de création d’une structure d’un profil donné comsoin de personnalisation relatif à un sujet donné est présent. Ce processus est

réalisé en un ensemble d’étapes (Figure 4.3) : Etape 1 Modélisation du besoin Lorsqu’un nouveau besoin se présente, le concepteur commence par

l’analyser. Ensuite il le modélise en un une représentation conceptuelle.

Etape 2 Traduction de la représentation conceptuelle du besoin en schéma XML

Une fois le besoin modélisé, il est traduit en schéma XML. Les règles de traduction en schéma XML sont décrites dans la section suivante.

Etape 3 Intégration du schéma XML dandonné Après avoir défini le schéma XML correspondant au besoin en cours, il

est intégré à la structure d



[Profil déjà créé] [Profil non créé]

Modéliser les besoins

Traduire le modèle conceptuel en schéma XML

Analyser les besoins

Déterminer le profil dans lequel la structure du schéma XML sera insérée

Créer le profil

Ajouter le schéma XML au profil

créé. Puis le schéma XML y

Diagramme d’activités de la création d’une structure d’un profil

un besoin de personnalisation relatif à un sujet donné est présent, il est ble de concepts. Ensuite ces concepts sont organisés dans un

odèle conceptuel (diagramme de classe UML). Par souci de simplification du nous ferons dorénavant référence à cette représentation conceptuelle du

esoin simplement comme modèle du besoin. Une fois le modèle du besoin défini, l’étape suivante consiste à

odèle de besoin qui peuvent faire référence à des roche de la personnalisation

implémentée ou à des paramètres de contexte. Dans ce cas, une classe refConcept, est ajoutée au modèle du besoin. Cette classe

nom et type qui servent à fournir des informations sur la

défini en schéma XML. Sinon, le profil doit être sera intégré. Cette intégration est détaillée plus loin.

Figure 4.3

4.3.1.2 Modélisation du besoin Lorsqu’traduit en un ensemmlangage, b

identifier les classes du mclasses utilisées par l’application dans laquelle l’appsera additionnelle, appelée contient deux propriétés

dépendance

:Utilisateur

:Rôle

:Objet

:Action type

joue

:refC nomtype

oncept

= utilisateur = [1,1]

:refConcept

bjet 0]

nom=otype= [1,

:ref

Concept

nom=rôle type= [0,1]

Autoriser

des classes du modèle de besoin avec des classes de l’application ou ètres du contexte.

Donc lors de l’analyse de la dépendance de toute classe C du modèle du e (classe de l’application ou paramètre du contexte), la

dépendante sera attachée par une relation d’association avec la classe . La propriété nom de cette dernière aura comme valeur le nom de

élément dont la classe C dépend et la propriété type aura une valeur définie me suit :

Soit P l’ensemble des paramètres de contexte et E l’ensemble des

- Si C correspond à e et e appartient à E et e n’appartient pas à P,

des param

besoin avec un concept classe refConceptl’com

classes de l’application

alors nom = e et type =[1,0] ; - Si C correspond à e, e appartient à E et e appartient à P, alors nom = e et type =[1,1]; - Si C correspond à e, e n’appartient pas à E et e appartient à P, alors nom = e et type =[0,1].

La Figure 4.4 illustre un simple exemple de modélisation d’un besoin. En fait, ce besoin consiste à gérer les droits d’accès pour le sujet utilisateur. Un utilisateur est autorisé à effectuer une à plusieurs actions sur des objets. Cet accès dépend du rôle qu’il exerce. Si nous analysons ce besoin, nous observons que l’utilisateur joue un à plusieurs rôles et les droits d’accès aux objets dépendent du rôle de l’utilisateur. Donc quatre classes utilisateur, rôle, action, objet et deux relations du type association autoriser et joue sont identifiées. Tout d’abord, nous supposons que la classe utilisateur, qui désigne aussi le sujet pour lequel le besoin de personnalisation est spécifié, ainsi que la classe objet ont des classes correspondantes dans la base de données de l’application. Ensuite, la classe utilisateur et la classe rôle sont deux paramètres du contexte.

Figure 4.4 Exemple d’un modèle de besoin


Ainsi la modélisation d’un besoin est réalisée en deux étapes : - définir les classes et les organiser dans un modèle conceptuel - identifier les classes qui dépendent d’autres concepts (classes

appartenant à l’application en cours ou paramètres de contexte) Une fois que les éléments d’un besoin sont organisés dans un modèle

UML, l’étape suivante consiste à traduire ce modèle dans un schéma XML afin d’intégrer ce dernier dans la structure du profil représenté en schéma XML [MAL 02][ROU 02] [COM 06].


Modèle UML

Schéma XML

Document XML

Validé par Instance de

Traduit

Traduit

Modèle du besoin

Instances du modèle du besoin

Instance objet de

En principe, nous explorons deux types de traduction entre UML et XML :

tances d’objets vers document XML : une instance du èle du besoin est exportée vers une ou plusieurs instances de documents XML.

- Définition de classes vers schémas XML : la structure du modèle u esoin (c'est-à-dire ses classes, attributs et associations) est exportée dans un chéma XML qui permettra de valider les instances de documents XML

correspondantes.

Figure 4

- Ins mod

dbs

.5 Principe de traduction entre UML et schéma XML

La Figure 4.5 illustre la relation qu’entretiennent ces composants UML et XML. Le modèle conceptuel est traduit en schéma XML. Lorsqu’on crée un profil donné, le résultat obtenu est une instance du modèle conceptuel du profil. La structure ainsi que les données sont traduites séparément dans des documents XML. Dans la section suivante, nous décrivons les principales règles de traduction d’un modèle UML en schéma XML.

4.3.1.5 Règles de traduction d’un modèle UML en schéma XML Le modèle du besoin peut être vu comme avec un point de départ la classe qui désigne le sujet. A partir de cette classe, le modèle est parcouru dans le sens de la navigation du haut vers le bas. A chaque fois que nous rencontrons une relation du type association, déco ou héritage, la traduction est réalisée. Cette traduction concerne la relation ainsi que les classes.

Dans la suite, nous décrivons de manière générale, les différentes règles e traduction éléments (classes, attributs, relation d’association, relation de

position/d’agrégation, relation d’héritage) d’un modèle du besoin en a XML. Lors de cette traduc ces éléments seront donc présentés

me dèle du profil.

classe du modèle du besoin est transformée en instances d’objet de la classe attribut_

ents

éclarés comme des éléments dans les types complexes.

un arbre hiérarchique

mposition

d des décomschém tion, com des instances du mo Règle1 : classe et attributs Une

complexe du modèle de profil. Les attributs de cette classe sont traduits en instances d’objets de la classe attribut_simple.

Par ailleurs, pour chaque classe UML, un element de type complexType est défini dans le schéma XML. Cet élément aura le nom de la classe. Un attribut est transformé en un élément de type simple ayant le nom de l’attribut.

Nous avons choisi d’exprimer les types simples comme des élémcomposant les types complexes du schéma XML. Donc les types simples seront d

La figure 4.6 illustre un exemple de transformation d’une classe UML en un élément du type complexType et un attribut UML en element déclaré dans l’élément complexType.



nomClasse1 Attribut1 :string Attribut2 :integer

:attribut_complexe nom=nomClasse1

:attribut_simple Nom=Attribut1 Type = string

:attribut_simple nom=Attribut2 type=integer

<xsd :complexType name= ‘nomClasse1‘> <xsd : sequence> <xsd:element name=”Attribut1” type=”xsd:string”/> <xsd:element name=”Attribut2” type=”xsd:integer”/> </:sequence> </xsd:complexType>

nomSujet Att1 Att2 ……

:sujet nom=nomSujet

<xsd :complexType name= « nomSujet »>

</:seque</xsd:complexType>

Traduction des classes et attributs

a racine est l’ancêtre de tous les éléments du schéma XML. Dans le modèle du

besoin, la racine désigne la classe qui représente le sujet. Cette classe sera traduite me un élé e complexType. Les attributs de cette classe ne seront pas traduits.

Figure 4.7 Choix de la racine

La figure 4.7 illustre la transformation de la classe nomSujet (qui désigne une classe représentant le sujet) en élément de type complexe dans le schéma XML. La balise nomSujet (Att1 et Att2 des élémen du modèle et la classe désignant le sujet.

Figure 4.6 Règle 2 : choix de la racine

L

en schéma XML com ment du typ

<xsd : sequence> ……………..

ce> n

sequence ne contiendra pas les attributs de la classe ne seront pas traduits). Par contre, elle pourra contenir

ts qui expriment des liens de dépendances entre des classes

R


nomClasse1 :attribut_complexe nom=nomClasse1

nomClasse2 :attribut_complexe nom=nomAssociation

:attribut_complexe nom=nomClasse2

nomAssociation

<xsd :complexType name= « nomClasse2 »> <xsd : sequence> ……………………. </:sequence> </xsd :complexType> <xsd :complexType name= « nomAssociation »> <xsd :sequence> <xsd :eleme = “nomClasse2” type= “ </xsd:sequence> <xsd:complexType> <xsd :complexType name= « nomClasse1 »> <xsd :sequence> <xsd :element name = “nomAssociation” type= “nomAssociation” /> </xsd:sequence> <xsd:complexType>

nt name nomClasse2” />

ègle 3 : traitement des associations

ans une relation d’association entre deux classes, nous avons trois éléments : eux classes (nomClasse1 et nomClasse2) et l’association (nomAssociation). orsque nous avons une relation d’association entre deux ou trois classes, au remier niveau, nous avons la classe qui désigne le sujet, au deuxième niveau, ous avons l’association et au troisième niveau, nous avons les autres classes. Si association contient des attributs, ils sont traduits en éléments de type simple.

igure 4.8 Traitement des associations

comme un élément du type

DdLpnl’

F

Règle 4 : relation de décomposition / d’agrégation

La relation d’agrégation ou de composition est équivalente en termes de dépendances à une association de type 1…*. La Figure 4.9 montre le principe de transformation d’une relation d’agrégation entre deux classes en schéma XML. Donc la classe nomClasse2 est déclarée


omClasse2 qui veut dire que cet élément fait référence à l’élément portant le

Figure 4 grégation

Règle 5

L est mappé selon une stratégie de copie descendante : tous les aisons d’associations sont copiés de façon descendante, des super-classes à chaque définition de sous-classe.

nmême nom.

nomClasse1

nomClasse2

1..*

:attribut_complexe Nom=nomClasse1

:attribut_complexe Nom=nomClassse2

<xsd :complexType name= « nomClasse2 »> ……………………. </:sequence>

:complexType>

<xsd :complexType name= « nomClasse1 »> <xsd :sequence> <xsd :element name = “nomClasse2” type= maxOccurs=”nbounded”/> </xsd:sequence> <xsd:complexType>

“nomClasse2” minOccurs=1

</xsd

<xsd : sequence>

.9 Relation de décomposition/d’a

: l’héritage

L’héritage UMattributs et les rôles de termin

nomClasse2 att2

nomClasse3

nomClasse4




:attribut_simple Nom=Att2

:attribut_simple Nom=Att2

nomClasse1

<xsd :complexType name= « nomClasse3 »> <xsd : complexContent> <xsd:extension base=”nomCla <xsd:sequence>

sse2”>

……………….

</:complexContent>

d :complexType>

<xsd :complexType name= « nomClasse2 »> <xsd:sequence> <xsd:element name=”att2” type=”xsd:string”/> </xsd:sequence> </xsd :complexType>  <xsd :complexType name= « nomClasse1 »> <xsd:choice minOccurs=”0” maxOccurs=”unbounded”> <xsd:element name=”nomClasse3” type=”nomClasse3”/> <xsd:element name=”nomClasse4” type=”nomClasse4”/> </xsd:choice> </xsd :complexType>

</xsd:sequence> </xsd:extension>

</xsd :complexType> < !-------------------------------------------------------------------------------------------------------> <xsd :complexType name= « nomClasse4 »> <xsd : complexContent> <xsd:extension base=”nomClasse2”> <xsd:sequence> ………………. </xsd:sequence> </xsd:extension> </:complexContent> </xs< !------------------------------------------------------------------------------------->

Figure 4.10 Relation d’héritage

<xsd :complexType name= « nomClasse2 »> <xsd : sequence <xsd:element name=”concept” type=”conceptUser”/>


</:sequence> </xsd :complexType> <xsd :complexType name= « conceptUser »>

:element name = “nom” default=”utilisateur” /> ent name = “type” default =”[1,0] />

<

<xsd :sequence> <xsd <xsd :elem

</xsd:sequence> xsd:complexType>

:Utilisateur nom

conceptUser:Concept Nom = utilisateur Type = [1,0]

La Figure 4.10 illustre que les deux sous-classes nomClasse3 et nomClasse4 sont définies comme des sous types de nomClasse2 et sont dérivées par extension. Règle 6 : déclaration des concepts dont une des classes du modèle dépend

Nous avons déjà souligné qu’une classe du modèle du besoin peut dépendre d’un paramètre du contexte ou/et d’une classe de l’application existante. Donc cette dépendance doit être signifiée dans ce schéma XML. Le nom du paramètre ou le nom de la classe sera indiqué par défaut dans le schéma. La Figure 4.11 montre un exemple de traduction de la classe utilisateur qui a une dépendance avec un concept du type contexte. L’attribut nom de la classe concept indique le nom de contexte et l’attribut type indique la nature de ce concept (du type contexte ou/et classe interne à l’application).

igure 4.11 Traduction de la classe Concept

Cette dépendance entre une classe du modèle du besoin et un concept du type contexte ou/et classe interne sera notifiée dans le schéma XML sans

u’elle soit reporté dans les documents XML. En effet, cette information est nécessaire lors de la gestion des structures et l’instanciation des profils afin de onnaître la source des informations à laquelle la classe du modèle doit faire

référence. Donc son apparition dans le document XML n’a pas d’utilité et sera pétée autant de fois que l’élément, à qui elle est attachée, apparaît dans le

ent XML.

F

q

c

rédocum

< ?xml version= “1.0” ?> <xsd :schema xmlns :xsd= http://www.w3.org/2000/10/ XMLSchema>  <xsd :complexType name= « role»> <xsd :sequence> <xsd :element name = “nom” type= “xsd:string” /> <xsd :element name= “estJoue” type= “autoriser” minOccurs= “1” maxOccurs=“unbouded” /> <xsd:element name=”concept” type=”conceptRole”/> </xsd:sequence> <xsd:complexType> <xsd :complexType name= « autoriser»> <xsd :sequence> <xsd :element name = “privilège” type= “xsd:string” /> <xsd :element name = “action” type= “action” /> <xsd :element name = “objet” type= “objet” minOccurs= “1” maxOccurs=“unbouded” /> </xsd:sequence> <xsd:complexType> <xsd :complexType name= «action»> <xsd : sequence> <xsd :element name = “type” type= “xsd :string” /> </:sequence> </xsd :complexType> <xsd :complexType name= «objet»> <xsd : sequence> <xsd :element name = “id” type= “xsd :string” /> <xsd:element name=”concept” type=”conceptObjet”/> </:sequence> </xsd :complexType> <xsd :complexType name= « conceptObjet »> <xsd :sequence> <xsd :element name = “nom” default=”objet” /> <xsd :element name = “type” default =”[1,0] /> </xsd:sequence> <xsd:complexType> <xsd :complexType name= « conceptRole »> <xsd :sequence> <xsd :element name = “nom” default=”role” /> <xsd :element name = “type” default =”[0,1] /> </xsd:sequence> <xsd:complexType>

Figure 4.12 Traduction d’un modèle de besoin en schéma XML Après avoir décrit l’ensemble des règles de transformation des éléments

en éléments du schéma XML, nous allons élaborer un exemple de des éléments du modèle que nous avons proposé dans la figure

a XML (Figure 4.12). Nous considérons que la classe rôle est la racine de ce schéma XML. La

utilisateur ne sera pas prise en compte dans ce schéma. relation concerne le sujet utilisateur et non pas le sujet rôle. Donc seule la

autoriser sera prise en considération dans cette traduction. Ainsi nous avons élaboré un exemple de schéma qui applique les règles

traduction d’un modèle UML en schéma XML. Les classes et les associations

UML représentation 4.4 en schém

relation entre le rôle et l’Cette relation

de

UML sont transformées en complexType elements. Ces éléments comportent parties : un élément pour chaque attribut de classe UML et un à plusieurs

ents pour faire référence à d’autres éléments du type complexType.

relative à un sujet donné

fois que le modèle du besoin est traduit dans un schéma XML, ce dernier être intégré dans la structure du profil relative à un sujet donné. Mais avant

intégration de ce schéma, nous devons vérifier si le profil décrivant le sujet

ent qui a le même nom que le sujet. Nous examinons donc deux cas : 1) profil n’est pas encore créé : Dans ce cas, plusieurs étapes seront réalisées :

XML du profil sera créé (fonction creerProfil (sujet)). ce document aura le même nom que le sujet

b. Deux éléments sont ajoutés au schéma XML du profil. Le premier désigne le sujet qui est une instance de la classe

à la

nt de l’élément sujet.

du profil qui utilise le schéma XML. Le paramètre sujet est utilisé pour trouver le fichier du profil et le paramètre element concerne l’élément à créer. Cette création utilise le schéma XML qui définit l’élément à insérer comme un élément du type complexe. La deuxième fonction permet d’insérer un élément donné dans la structure du profil. Le paramètre elementPere de la deuxième fonction détermine l’élément qui doit contenir l’élément en cours à insérer. Si ce paramètre est vide, ceci veut dire que l’élément en cours est l’élément racine du schéma XML.

c. Une nouvelle dimension est créée pour remplacer l’élément sujet du schéma XML du besoin M. Nous rappelons que l’élément racine du schéma xml du besoin est attribué au

deux élém

4.3.1.6 Intégration du schéma XML dans la structure du profil

Une doit l’concerné a déjà été créé. Pour cela, nous cherchons dans la base des profils, un docum

a. Le document

concerné par le modèle du besoin. Il contiendra la structure du profil ;

sujet du modèle de profil. Le deuxième correspondtraduction de la classe profil en schéma XML. Les deux éléments seront définis en schéma XML comme deux éléments complexes. L’élément profil est inséré dans le schéma XML comme un sous élémeNous proposons deux fonctions : la fonction creerElement( sujet, element) et la fonction insererElement (S_profil, elementPere, element). La première fonction est utilisée pour créer un élément du type complexe dans la structure


sujet concerné par le besoin. Pour ceci, un nom est attribué à cette dimension. Ensuite, l’élément racine sujet du schéma xml du besoin sera supprimé pour être remplacé par l’élément dimension. Cette dimension est considérée comme

ension du modèle du profil. ion remplacer (dimension, M) pour

elementPere concerne l’élément profil et le paramètre element concerne l’élément dimension. Donc la dimension sera insérée comme un sous-élément de l’élément profil.

2) Le profil est déjà créé : Dans ce cas, l’intégration du schéma XML du modèle de besoin M dans la structure du profil s’effectuera en exécutant les étapes suivantes :

i. Avant l’intégration de M, nous devons spécifier dans quel élément de la structure du profil l’élément racine de M sera inséré. Nous avons deux possibilités pour l’intégration de M :

a. L’élément racine de M est un sous-élément de l’élément profil ; Dans ce cas, nous exécutons le point c et le point d du 1er cas de ce processus de l’intégration.

b. Le contenu de M est intégré dans une dimension d du profil. Dans ce cas, le nom de la dimension est désigné. Ensuite tous les sous éléments SE de l’élément racine de M seront considérés comme des sous éléments de la dimension d. Nous utilisons la fonction insererElement (S_profil, elementPere, element) pour insérer ces sous-éléments dans l’élément qui désigne la dimension d dans la structure d’un profil donné S_profil. Le paramètre elementPere désigne le nom de la dimension et le paramètre element désigne chaque élément de l’ensemble SE.

une instanciation de la classe dimNous proposons une foncteffectuer le remplacement de l’élément sujet par l’élément dimension.

d. Le schéma M est inséré dans la structure du profil. Pour cela, le contenu du schéma M est copié dans le schéma XML de la structure du profil S_profil en proposant une fonction copier (S_profil, M). La fonction insererElement (S_profil, elementPere, element) sera utilisée. Le paramètre


fonction integrerSchema (M, sujet) {

cd = VerifierProfil (sujet) // vérifier su un profil est déjà créé pour le sujet s

sinon

t du profil qui englobera les éléments du M

insererSchema (M)

prof l

sinon

} }

Figure 4.13 Algorila structure du prof

i cd = 0 alors // le profil n’est pas créé {

// créer un fichier du profil avec une racine qui désigne le sujet createProfil (sujet)

// l’élément profil est créé et insérés dans la structure du profil insererElement (profil)

// l’élément racine de M est remplacé par le nom d’une nouvelle dimension dimension= getNameDimension () remplacerRacine (dimension, M) // copier le schéma M dans le profil insererSchema (M) // insérer l’élément racine de M comme un élément dans l’élément profil ajouterDimension (dimension)

}

{ // déterminer l’élémen

= getElement(sujet) e // si e désigne l’élément profil de la structure si correspond (e, ‘profil’) = 0 alors { // l’élément racine de M est remplacer par le nom d’une nouvelle dimension

remplacerRacine (dimension, M) // copier le schéma M dans le profil

// insérer l’élément racine de M comme un élément dans l’élément i

ajouterDimension (dimension) }

{ SE = getFilsRacine(M)

deleteRacineSchema() insererSchema (M) Pour tout se de SE faire ajouterAttributComplexe(se, e) fin }

thme général de l’intégration du schéma xml du besoin dans il


Nous avondonné sous forme Ainsi, la structure des nouveaux besoi

Dans la seprofil. Nous décriro

4.3.1.7 Insertion Un profil est dépar le formalisme document XML. Econsidéré comme u

Figure 4.14 PrinciXML

Nous avon

à un ou plu rée dans le

chéma xml du profil comme un élément simpleType. Donc les données sont

Par ailleudonné. Les élémende manière généraleréférence aux instances utilisateur fournit une deque les préférences, les d s compétences, etc.

De ce fait, ll’instanciation de la clal’attribution des données

s décrit les différentes phases d’expression d’un besoin d’éléments d’un profil donné relatif à un sujet quelconque. du profil donné se construit au fur et à mesure d’apparition ns. ction suivante, nous allons nous intéresser au contenu d’un ns les étapes d’insertion des données dans des profils.

des données dans les profils

crit par sa structure et son contenu. la structure est représentée schéma XML tandis que le contenu est représenté dans un n principe, un fichier XML conforme à un schéma XML est ne instance de document.

Schéma XML

profil

structure

pe de représentation de la structure et du contenu en schéma

s vu dans le modèle du profil qu’un attribut simple est sieurs contenus. Donc toute donnée, définie pour être inséassocié

profil, est considérée comme une instance de la classe contenu du modèle du profil associé à une instance de la classe attribut_simple. Cet attribut est défini dans le s

contenues dans des éléments de type simple. rs, chaque profil défini dans le schéma XML décrit un sujet ts de ce profil représentent les critères qui distinguent un sujet

. A ce niveau de la représentation, nous ne faisons pas de ce sujet. Par exemple, le schéma xml du sujet scription des éléments caractérisant l’utilisateur telles roits d’accès, le

’insertion des données dans le profil concerne aussi bien sse contenu que la classe profil. En effet, lors de aux attributs simples, le propriétaire de ces données

contenu Document XML

Traduit par

Validé par

Traduit par


sujet

classe

instance


Document XML

profil

contient

1,*

1

Correspond 1 0,1*

Correspond 1 1

our toute instance d’un sujet donné, une instance d’un

jet est identifiée par l’attribut propriétaire de l’élément

doit être désigné. Ainsi pprofil est définie. Ce profil est désigné par un identifiant qui est affecté à ce profil et l’instance du suprofil.

ntre les éléments de profil en UML et XML

iner effectue pour

premiè des données du pr première étape consiste à créer un document e le sujet utilisateur.xml par exemple). Ens ent xml qui désigne le sujet (par exemple utili e, etc.) et l’élément profil sont créés. Les attributs de l’ e valeur incrém es profils créés dans le document xml et me valeur l’identifiant de l’instance du sujet. En effet, une instance de la classe désignée par le sujet devient le propriétaire du profil en cours de création. La classe sujet est une super-classe

re et. Ainsi l’attribut

consiste à

tribuer des valeurfié que les éléments sujet et profil sont déjà créés dans le document

xml, nous pouvons p ans s attributs simples. Cette insertion est e omplexe qui contient ces attributs simples. Un valeurs sont représentées comme suit :

Figure 4.15 Correspondance e

Lors si l’insertion des données dans un profil relatif à un sujet donné s’

de la définition des données dans un profil, nous devons exam

la re fois. Ceci veut dire que le document xml dédié au stockage ofil n’est pas encore créé. Donc la xml qui aura le même nom qu (

uite l’élément racine de ce documsateur, rôle, machinélément profil sont ensuite d

apport au nombre déterminés. L’attribut id aura un

entale par r l’attribut propriétaire prend com

d’un ensemble de classes. Donc lorsqu’on désigne un sujet donné, le propriétaiest choisi parmi le instances de la sous-classes du sujproprietaire aura comme valeur l’identifiant de l’instance désignée.

s le processus d’insertion des données Une seconde étape danat s aux attributs simples du profil. En effet, une fois que nous avons véri

rocéder à l’insertion des données d leffectuée en désignant l’attribut cattribut simple peut contenir une à plusieurs valeurs. Ces

<nom < !A </nom_at le>

englobe les attributs simples est inséré dans le

plexe>

< valeur>donnee1</valeur> </nom_attribut_simple1>

ribut_complexe>

des données dans les profils.

_attribut_simple> <valeur>donnée1</valeur>

<valeur>donnée2</valeur> utres valeurs>

tribut_simp

plexe quiEnsuite l’attribut comdocument XML.

<nom_attribut_com <nom_attribut_simple1>

<nom_attribut_simple2> < valeur>donnee2</valeur>

</nom_attribut_simple2> </nom_att

L’algorithme, illustré dans la Figure 4.16, décrit le principe d’insertion



{ as = ajouterData (as, data) // ajout de l’attribut simple à l’attribut complexe ajouterAttributSimple (as, AttComp) }

//vérifier l’existence d’un document xml correspondant au sujet cd = verif_docXml (sujet) Si cd = 1 // le document existe déjà { // verifier si le profil existe dans le document xml

ct = verif_profil (proprietaire, sujet)

{

Figure 4.16 Algorithme général d’insertion des données dans les profils

Fonction insertData (AttComp, profil) {

// sélection des attributs simples contenus dans l’attribut complexe choisi AS = ListerAttributSimple(AttComp) // insertion des données dans les attributs simples sélectionnés Pour tout as de AS faire

} Fonction insertDataInProfil (sujet, proprietaire) {

si ct = 1

Profil = getProfil (proprietaire, sujet) // sélection du profil // sélectionner l’attribut complexe dans lequel des données seront insérées

AttComp = SelectAttributComplexe () insertData (AttComp, profil) // appel de la fonction insertData

} sinon { // créer une instance du profil createProfileInstance(proprietaire) AttComp = SelectAttributComplexe()

// appel de la fonction insertData insertData (AttComp, profil)

} } sinon { // le document xml sera créé ainsi que la racine

createDocXmlProfil (sujet) createProfileInstance(proprietaire) // créer une instance

du profil AttComp = SelectAttributComplexe()

insertData (AttComp, profil) }

}

Après avoir désigné l’attribut complexe et inséré des données dans les attributs simples de cet attribut complexe, les éléments ascendants de ce dernier à partir l’élément profil doit être connus. Nous rappelons que l’élément profil peut être composé d’attributs complexes qui peuvent être composés d’attributs complexes ou/et d’attributs simples. Donc le chemin depuis l’attribut profil jusqu’au n doit être connu. Cette opération est nécessai te déjà dans le profil. Si c’est le cas, l’attribut mme un sous élément du dernier élément ce partir de quel élément de ce chemin faut-il insérer d suite l’attribut complexe en cours est inséré

ées. d’insertion des données

dans les profils. Nous avons pris en considération le fait qu’un profil peut exister ou pas. La prochaine étape consiste à définir les acteurs qui interviennent dans le processus de e définir leurs droits d’accès aux profils.

.3.1.8 A des profils

n rôle consiste à analyser les nouveaux besoins de la ersonnalisation et à définir les structures des profils. Ces structures sont ensuite aduites dans un schéma XML. Il est amené à contrôler la validité des schémas t documents XML.

L’administrateur : son rôle concerne à l’insertion des données dans les rofils et à leur mise à jour. Cette dernière opération intervient à la fois les tructures et les contenus des profils.

L’utilisateur : son rôle consiste à saisir des données dans les profils, oir à modifier ou supprimer des données. L’utilisateur peut être autorisé à éfinir des données dans son propre profil ou de modifier son profil suite à une volution de ce dernier. En effet, il est important de laisser à l’utilisateur la ossibilité de définir ses besoins et ses préférences.

Ainsi l’utilisateur a le droit d’accès au module de gestion des profils. our cette raison il est important de définir les droits d’accès à ces profils et de pécifier les actions qu’il a le droit d’exercer sur les composants ou les données e ces profils.

de

l’attribut complexe en questiore pour vérifier que ce chemin exis

complexe en question est intégré code chemin. Sinon, à ans le profil en cours ? En

dans le chemin. L’insertion des données dans l’attribut complexe en question est répétée

tant qu’il est nécessaire d’insérer des donnAinsi nous avons décrit les différentes étapes

gestion des profils afin d

4 cteurs du module de gestionLe rôle des acteurs est bien défini pour gérer les profils. Nous avons distingué trois acteurs :

Le concepteur : soptre

ps

vdép

Psd


4.3.2 Gestion des droits d’accès aux profils

La gestion des droits d’accès est destinée à contrôler l’accès aux profils afin ’éviter les manipulations non autorisées qui pourraient endommager les profils

ivulgation non autorisée des données. peut être résumé en trois fonctions :

gestion des pro accéder au module de gestion des profils passe.

suite le système doit vérifier qu’il est bien la person

rer et à vérifier les droits d’accè que de sécurité. Ces règles indiquent qui a le droit d’accès à quelles informations au sujet de qui, quand, où

éventuellement sous quelles conditions. La combinaison de ces différentes fonctions est au cœur des principaux

trôle d’accès. Ils doivent gérer icace ble de menaces

telles qif es données ;

ou éventuellement des éléments des p

- l’ajo nnées qui pourrait provoquer du bruit à la bonne qualité des données ;

-

4.3.2.1 Modèles de

Plusieurs d contrôle d’accès ont été proposés dans la littérature. La plupart de ce oser des objectifs de sécurité à satisfaire et de définir des règles décrivant les actions autorisées et ce conformément aux objectifs soulevés. Certains de ces modèles offrent une politique de sécurité retionnary Access Control) [ELK 03]. D’ res sur une politique de sécurité obligatoire (MAC - Mandatory Access Control) [SOL 04]. Des politiques basées sur les rôles (RBAC - Role Based Access Control) [SAN 96] [ZHA 04] ont été égalem s spécifiques dans des organisations

d(structure et données) et à interdire la d

Cette gestion de droits d’accès- l’identification : tout utilisateur, avant d’utiliser le module de

fils, doit être identifié. En effet, pour, l’utilisateur doit saisir son code utilisateur et son mot de

- l’authentification : En n qu’il prétend être. e

- l’autorisation : l’autorisation consiste à géen litis fonction des règles spécifiées dans la po

et

enjeux du développement des systèmes de coneff ment les droits d’accès eux profils afin d’éviter un ensem

ue : - les mod ications non autorisées d- la suppression non autorisée des données

rofils ; ut des do

l’accès à des données non autorisées.

contrôle d’accès

mo èles des modèles ont pour but de prop

discrétionnaire (DAC - Discaut proposent des modèles basés

ent proposées afin de répondre à des besoinparticulières.


4.3.2.2 Modèles de contrôle d’accès discrétionnaire

e modèle de contrôle d’accès discrétionnaire DAC popularisé par UNIX est centré sur les ressources physiques (fichier, exécutable) et identifie le

à accéder à un objet mations contenues dans

ifie que :

possède un niveau d’autorisation. Celui-ci est présenté par un ensem

L

propriétaire et un groupe d’utilisateurs ayant des droits sur les ressources.Dans ce modèle, les permissions s’appliquent directement aux

utilisateurs. Il est constitué essentiellement de 3 entités principales : le sujet, l’objet et l’action.

Selon ce modèle, le sujet désigne les utilisateurs du système. L’objet représente un conteneur d’informations comme un fichier. L’entité action correspond principalement au droit de lecture ou d’écriture.

La politique de sécurité dans ce modèle est restreinte aux permissions. Elle est exprimée sous forme d’une matrice (s, o, α). Si s est le sujet et o, l’objet alors A(s, o) définit l’ensemble des actions α que le sujet est autorisé à faire sur l’objet o.

L’inconvénient de ce modèle est qu’il ne permet pas d’exprimer d’autres politiques de sécurité comme des interdictions, des obligations ou des recommandations. Elle pose le problème de la fuite d’information.

4.3.2.3 Modèles de contrôle d’accès obligatoires

Dans ces modèles, l’accès aux objets est basé sur le niveau de sensibilité de l’information contenue dans les objets. Un sujet est autorisé si et seulement si le sujet est autorisé à accéder aux inforl’objet. Cette politique a été raffinée en créant le concept de politique de sécurité multi-niveau qui spéc

- Tout objet du système possède une classe de sécurité. Cette classe est représentée sous forme d’un niveau de sensibilité (non classifié, confidentiel, secret, top secret).

- Tout sujet ble de domaines (ou catégories) qui montre l’appartenance d’un objet

ou d’un sujet à une activité de l’organisme (nucléaire, défense, administration, etc).

- Les niveaux de sécurité constituent un treillis avec une relation d’ordre partiel de dominance notée ‘≤’. Soient n = (cl, C) et n’ = (cl’, C’), deux niveaux de sécurité

Si n ≤ n’ ⇔ (cl ≤ cl’ et C ≤ C’ )


Les objectifs de sécurité du modèle de contrôle d’accès obligatoire sont :

- interdire toute fuite d’information d’un objet vers un autre ayant une classification inférieure

- interdire à tout sujet possédant une certaine habilitation d’obtenir des t supérieur.

systèmes médicales. Considérons un médecin

té , néanmoins, il n’a aucun droit de connaître les données médicales d’un pat pas.

les de contrôle d’accès sont apparus. Ces modèles sont basés essentie modèles les plus célèbres, nous citons RBAC. Le modèle RBAC définit un ensemble des concepts basiques : les

es permissions (PMR), les opérations

informa ions d’un objet d’un niveau de classification

Cette politique définit un ensemble des règles : Un sujet s n’est autorisé à accéder en lecture aux informations

contenues dans l’objet o que si le niveau de sécurité de s est supérieur ou égal au niveau de sécurité de o.

Un sujet s n’est autorisé à accéder en écriture aux informations contenues dans l’objet o que si le niveau de sécurité de s est inférieur ou égal au niveau de sécurité de l’objet o.

Un sujet s est autorisé à accéder aux informations de niveau de sécurité n1 ou aux informations de niveau de sécurité n2 mais pas aux deux à la fois.

Cette politique de sécurité est difficile à mettre en place et impose des contraintes fortes sur les organisations et sur le personnel ayant accès au système d’information. Nous donnons un exemple qui montre que la technique de multi-niveau ne peut pas s’appliquer aux

-chef dans une clinique et un médecin d’un service donné. Selon la politique de multi-niveaux, le niveau de médecin chef devrait dominer celui de médecin. Ce qui n’est pas conforme à la réalité : certes le M-C possède plus de responsabili

ient P que le médecin M traite et que M-C ne traite

4.3.2.4 Modèles de contrôle d’accès basé sur les rôles

D’autres modèllement sur la notion de rôle. Parmi ces

utilisateurs (USERS), les rôles (ROLES), l(OPS) et les objets (OBJ). Les rôles représentent généralement les fonctions au sein d’une organisation (par exemple infirmière à l’hôpital). Les objets désignent les données informatiques à protéger et les opérations sont les actions à réaliser sur les objets. Une permission désigne une approbation d’exécuter des opérations sur un objet.

Des associations impliquent ces concepts : l’affectation des utilisateurs aux rôles (UA) et les permissions aux rôles (PA). Les utilisateurs obtiennent les permissions accordées aux rôles qu’ils jouent.


Ce modèle inclut également les concepts de session. Ils représentent des sessions temporelles. Chaque session est associée à un utilisateur pour un temps

mité. Au cours d'une session, il peut être nécessaire qu'un utilisateur n'ait qu'un t un seul rôle. C'est la notion de rôle actif.

Dans ce modèle, un utilisateur peut avoir plusieurs rôles et un rôle peut ions. Un rôle peut

e modèle inclut également les concepts de session et de hiérarchie de rôles. U

ntre les rôles. Ce modèle met en place des contraintes pour éviter le conflit d’intérêts. Par

de l’anesthésiste et du

on est accordée à un rôle, alors tous les utilisateurs qui jouent ce rôle

le droit d’accéder aux dossiers médicaux des patients, RBAC

entialité puisqu’un médecin peut consulter les dossiers de tous les

lie

être affecté à plusieurs utilisateurs. De même pour les permissêtre affecté à plusieurs permissions et une permission peut être affectée à plusieurs rôles.

UA PA

ROLES

USERS PRM

Figure 4.17 Modèle RBAC

Cn utilisateur peut ne pas activer tous ses rôles, mais uniquement le sous-

ensemble de ses rôles nécessaires à la réalisation de la tâche à accomplir. La hiérarchie de rôles désigne un concept d’héritage des permissions e

exemple, un utilisateur n’a pas le droit de jouer le rôle une opération. chirurgien lors d’

Cette politique est facile à administrer. Néanmoins, elle présente quelques inconvénients qui se résument dans l’impossibilité d’exprimer des permissions qui dépendent du contexte. Plus précisément, si une certaine permissihéritent de cette permission. Par exemple, si le système donne aux utilisateurs exerçant le rôle médecin

ne peut pas spécifié que ces médecins ont la permission de voir uniquement les dossiers de leurs patients. En conséquence, il ne garantit pas la propriété de confid

patients, y compris ceux qu’il ne traite pas. De plus, ce système définit uniquement des permissions.

SESSIONS Contraintes

OBJ OPS



Objet Name_file Type Element_path

4.3.2.5

L’ règles d’accès pour chaque utiliser le module de gestion des profils. Cet utilisateur

ené à visualiser des données, ajouter, modifier ou supprimer des données

t de faire quoi et à quel moment. La modélisation de notre proposition est basée su

cilite largement l’administration des droits d’accès.

toute personne uscepti ’entité Rôle présente le

rôle qu’

’un profil e

e présente une odélisation de l’objet sous forme d’une classe composée de trois propriétés

ur « P » si c’est ns le profil tout

Modélisation des droits d’accès dans notre module de gestion des profils

objectif de notre proposition est de définir les utilisateur susceptible d’peut être am

. Donc notre proposition doit gérer ces droits d’accès en indiquant qui a le droi

r le modèle RBAC du fait qu’il considère les rôles. En effet, la prise en considération des rôles fa

Notre modélisation définit un ensemble d’entités basiques : Utilisateur, Rôle, Action, Objet, Privilège. L’entité Utilisateur désigne s ble d’utiliser le module de gestion des profils. L

exerce un utilisateur dans une organisation donnée. L’entité Privilège présente deux cas : Permis ou Interdit. L’entité Action détermine les mécanismes de contrôle d’accès sur un objet. Dans notre système, nous utilisons les actions suivantes : R pour Read, I pour insert, D pour Delete, U pour Update. L’entité Objet désigne un ensemble des documents parmi lesquels nous trouvons des formulaires servant à initialiser les profils, les documents xml des profils. D’autres types d’objets peuvent être concernés, à savoir les éléments des profils. Nous savons qu’un profil donné est constitué d’une structure et des données. Ce

quprofil est représenté dans un arbre hiérarchique en XML. Nous rappelons st composé d’un ensemble d’éléments tels que l’élément racine qui

désigne le concept pour lequel le profil est défini, l’élément profil qui a un attribut Proprietaire, l’élément dimension qui peut être composé soit d’attribut simple ou d’attribut complexe. L’attribut simple a un sous élément valeur qui sert à définir les données. Donc un profil est représenté par une hiérarchie d’éléments. Le module de gestion des profils comporte un ensemble de profils stockés dans des documents XML. Donc lorsqu’on spécifie un objet, nous devons indiquer le nom du document, son type en précisant s’il s’agit d’un profil ainsi que l’élément concerné de la structure du profil. La figurmName_file pour désigner le nom du fichier, type qui aura la vale

ent_path pour désigner l’élément concerné daun profil et Elemen spécifiant le chemin de cet élément dès le nœud racine.

Figure 4.18 Classe Objet

Pour modéliser les droits d’accès, nous proposons la relation suivante : Autorise (Privilège, Rôle, Action, Objet)

rivilège d’effectuer une action sur un objet

a seconde relation spécifie qu’un utilisateur peut jouer un à plusieurs rôles et

dans notre modélisation, ce qui permet de simplifie

Joue (Utilisateur, Rôle)

La première relation spécifie qu’un rôle a le p.

Autorise Privilège

Figure 4.19 Relation Autorise

Lun rôle peut être attribué à un ou plusieurs utilisateurs. 1. n 1.n

Figure 4.20 Relation Joue

Dans notre approche, nous prenons en compte la hiérarchie dans la définition des règles d’accès. Rappelons que les objets et les rôles sont tous les deux représentés de manière hiérarchique. Donc il est intéressant de prendre en considération cette hiérarchie

r largement l’administration des règles d’accès en automatisant partiellement l’attribution des privilèges.

En effet, sans considérer la hiérarchie, les règles d’accès sont construites sous forme du produit cartésien. Celui-ci est représenté sous forme de E x R = { (e, r) ⎢e ∈ E , r ∈ R } avec E l’ensemble des rôles représentés au dernier niveau de la hiérarchie des rôles et R l’ensemble des objets autorisés représentés au dernier niveau de la hiérarchie des objets. Supposons que nous ayons 30 rôles et 40 objets, en résultat, nous avons 1200 règles. Mais en prenant en compte la hiérarchie, ce nombre sera réduit considérablement.

Rôle Objet Name_file Type Element_path

Action

type

1..n

1,n 1

Utilisateur Rôle

Joue 1,* 1,*


4.3.2.6 Hiérarchie d’accès entre les rôles Cette hiérarchie est basée sur4.3.2.6 Hiérarchie d’accès entre les rôles Cette hiérarchie est basée sur le principe de généralisation/spécialisation. Elle peut être modélisée par la relation : Généraliser (R1, R2) qui signifie que le rôle R2 est un sous-rôle de R1 ou une généralisation de R1. Par exemple :

médecin

d’accès entre les objets e principe de l’héritage entre objets est identique à celle des rôles. Si un rôle a autorisation d’effectuer une action sur un objet. Il aura l’autorisation


le principe de généralisation/spécialisation. Elle peut être modélisée par la relation : Généraliser (R1, R2) qui signifie que le rôle R2 est un sous-rôle de R1 ou une généralisation de R1. Par exemple :

médecin

d’accès entre les objets e principe de l’héritage entre objets est identique à celle des rôles. Si un rôle a autorisation d’effectuer une action sur un objet. Il aura l’autorisation

Généraliser (médecin, pédiatre) pour dire que pédiatre est un sous-rôle de .

Généraliser (médecin, pédiatre) pour dire que pédiatre est un sous-rôle de .

Figure 4.21 Relation Generaliser

Role Nom

Figure 4.21 Relation Generaliser

Role Nom

Generaliser

R1

R

*

Cette hiérarchie de rôles permet aux rôles descendants d’hériter les droits d’accès des rôles ascendants.

Cet héritage est spécifié par la règle suivante : Autorise ( Privilège, R, Action, Objet, Option ) et Généraliser ( R, R1 ) ⇒ Autorise ( Privilège, R1, Action, Objet, Option )

Lorsque la hiérarchie des rôles est représentée sous plusieurs niveaux, l’héritage de droits d’accès pourra s’appliquer à tous les sous-rôles d’un rôle R en se basant sur le principe de transitivité.

Si Généraliser (R, R1 ) et Généraliser (R1, R3 ) Généraliser (R, R3 )

Figure 4.4.22 Hiérarchie des rôles

Cette hiérarchie de rôles permet aux rôles descendants d’hériter les droits d’accès des rôles ascendants.

Cet héritage est spécifié par la règle suivante : Autorise ( Privilège, R, Action, Objet, Option ) et Généraliser ( R, R1 ) ⇒ Autorise ( Privilège, R1, Action, Objet, Option )

Lorsque la hiérarchie des rôles est représentée sous plusieurs niveaux, l’héritage de droits d’accès pourra s’appliquer à tous les sous-rôles d’un rôle R en se basant sur le principe de transitivité.

Si Généraliser (R, R1 ) et Généraliser (R1, R3 ) Généraliser (R, R3 )

Figure 4.4.22 Hiérarchie des rôles

R

.....R1 R2

R3 …..

….

4.3.2.7 Hiérarchie4.3.2.7 HiérarchieLLl’l’


d’effectuer la même action sur tous les descendants de cet objet. Cette hiérarchie ’applique dans le cas ou nous manipulons des éléments de l’arbre hiérarchique es profils. Pour rechercher les descendants d’un élément, nous proposons la

hie_objet (N) qui utilise la technique XPATH pour quel les

descend

Soit desc[]= {N1, N2, ……, Nn} l’ensemble des noeuds fils d’un noeud N.

Autorise ( Privilège, Rôle, Action , N, Option)

Autorise ( Privilège, Rôle, action , N2, Option) Autorise ( privilège, Rôle, action , Nn, Option)

ettent de restreind es cas dans lesquels des permissions être accordées aux utilisateurs pour réaliser des actions sur des objets.

n principe, chaque utilisateur e droit d’accès à son propre profil. Mais ertains utilisateurs ne peuvent pas accéder à n’importe quelle information

appartiennent le permet. Certaines situations

ent spécifiées sur les autorisations accès aux données. Rappelons que lorsque un rôle a le privilège d’exécuter

action sur un objet, cela signifie que tous les utilisateurs jouant ce rôle uront les mêmes droits d’accès. Toutefois cette règle n’est pas toujours vraie.

euvent être empêchés (respectivement autorisés) à

sdfonction desc[] = Hierarcaccéder aux noeuds. Le paramètre d’entrée N désigne l’élément pour le

ants sont recherchés.

Si Donc Autorise ( Privilège, Rôle, Action , N1, Option)

4.3.2.8 Contraintes

Les contraintes perm re lpeuvent E a lcmême si le rôle auxquels ilspeuvent imposer des contraintes sur l’accès de ces utilisateurs aux données. De ce fait, pour que notre système gère efficacement l’accès aux profils, il doit tenir compte de toutes ces situations exceptionnelles.

Ces contraintes sont principalemd’une aEn effet, des utilisateurs pvisualiser un objet habituellement autorisé (respectivement interdit) au rôle auquel appartient ces utilisateurs. La modélisation de ce type de contraintes s’exprime en proposant la relation suivante : Autorise_user (Privilège, ref_joue1, Action, Objet, contrainte). Cette relation permet d’attribuer à un utilisateur donné jouant un rôle donné (exprimé par l’intermédiaire de l’entité ref_joue1) un privilège (permis ou interdit) d’effectuer une action sur l’objet tout en respectant la contrainte définie.

En ce qui concerne la définition de la contrainte, elle est exprimée sous forme des clauses dans lesquelles des conditions sont définies.

Contrainte = Clause1∪ Clause2…..Clausei

Clause = Condition1 ∩ Condition2 ∩ …. ∩Conditionj


Condition = <Paramètre><OP><VALUE> avec OP ={>,≥,<,≤,=,≠}

Une condition est composée donc d’un paramètre, d’une opération et d’une valeur. Les paramètres sont composés d’un quadruplet lié au temps (par

e la localisation (par exemple

4.3.2.9 Mise en œuvre du système d’accès

Ainsi nous avons modélisé le système d’accès au module de gestion des profils en proposant quatre relations :

R1 : Autorise (Privilège, Rôle, Action, Objet) R2 : Joue (Utilisateur, Rôle)

ège, Utilisateur, Action, Objet, contrainte)

ls pour représenter ces relations et stocker les donn profils est créé. Le sujet est doncet assoc

e les rôles est également représen

e la représentation de ce profil. Pour simplifier sa e d’un arbre hiérarchique.

exemple, date, heure, mois, jour, année, etc.), dlieu d’exercice), des éléments composant les profils, aux documents des profils.

Ainsi, des contraintes sur l’accès aux profils sont définies pour éviter une utilisation abusive du système. Cette attribution des contraintes se réalise lors de l’affectation d’un utilisateur au système pour réglementer ses droits d’accès.

R3 : Generaliser (R1, R2) R4 : Autorise_user (Privil

Nous adoptons le principe des profi

ées. Un profil dédié au module de gestion des ‘module de gestion des profils’. Une dimension droit d’accès sera créée iée à l’élément profil. Ensuite les relations R1, R2, R4 sont ajoutées à la

structure du profil comme des attributs complexes. La structure de ce profil est décrite dans un schéma XML tandis que les données seront représentées dans un document XML. La relation Generaliser qui exprime la hiérarchi entre

tée dans un document XML. La Figure 4.23 illustr

représentation, il sera décrit sous form


Module du gestion des profils

profil

Droit d’accès

joue Autoriser Autoriser_user

rôle Action Privilège objet contrainte

ous avons dit que la première étape pour accéder au module de gestion des profils est l’identification. Donc l’utilisateur s’identifie en tapant son

l’utilisateur est

Figure 4.23 Profil des droits d’accès N

code utilisateur et son mot de passe. Ensuite le système vérifie sienregistré.


Figure 4.24 Principe de fonctionnement des droits d’accès

Un service est développé et associé à ce profil. Nous Rappelons qu’un

service est un programme autonome composé d’un ensemble de fonctions dédiées à mettre en place l’objectif attendu d’un composant du profil donné. De ce fait, le service proposé doit gérer les droits d’accès en fonction des informations contenues dans le profil.

Identification

Base desprofils

Règles sous forme de R1 = (Action, Objet) R2 = (privilège, Objet, Action, contrainte)

Authentification = OK

Application desrègles d’accès

Recherche des règles de droitd’accès

Identification du rôle Rôle identifié

Règles Comparaison deces deux ensemblesdes règles

définitives

Les différentes étapes du fonctionnement de ce service se résument comme suit :

- Une fois l’utilisateur identifié, le service recherche l’ensemble des règles de droit d’accès autorisées à cet utilisateur. Pour ce faire, il recherche le rôle que odule de gestion des profils. Cette in du contexte. En connaiss ble des règles d’accès du documen tion des profils. Cette extraction sera réalisée

m

uite, pour chaque rôle de Rolei nous recherchons les droits d’accès

des contraintes déclarées dans

s associées à l’utilisateur sont représentées de la manière tej).

ble des règles (Ri et Rj), l’étape suivante x ensembles des règles pour définir les règles d’accès

définitiv un ocument XML. Une règle d’accès dans ce document est exprimée comme suit

tion, objet et contrainte. Le dernier sous-élément

ribut num et un attribut idref qui fait référence à la règle dont il dépend.

n ce qui concerne la comparaison entre les règles Ri et Rj, trois conditions sont à vérifier :

Soit r = (a,o) une règle qui apprtient à Ri

l’utilisateur joue lorsqu’il se connecte au mformation est fournie par le module de gestion ant ce rôle, le programme extrait l’ensemt XML du module de ges

notam ent à partir de l’attribut complexe autoriser. Nous utilisons le langage de requêtes Xquery pour accéder aux données dans le document XML. Le résultat sera renvoyé et représenté sous forme de Ri = (Actioni, Objeti). Les objets peuvent être des documents ou des éléments de la structure des profils. Ces informations sont indiquées dans les paramètres servant à décrire un objet donné. Les actions peuvent être la lecture, l’écriture ou la modification.

- L’étape suivante consiste à rechercher si le rôle courant à des rôles ascendants Rolei en accédant au document XML qui stocke la hiérarchie des rôles. Enscomme c’est décrit dans l’étape précédente.

- Ensuite le programme vérifie s’il existele profil en extrayant les règles d’accès dans l’attribut complexe autoriser_user. Si c’est le cas, les règles d’accè

suivante Rj= (privilègej, actionj, objetj, contrain- Après avoir extrait l’ensem

consiste à comparer les deues pour l’utilisateur. Ces règles définitives seront représentées dans

d<regle num=1 idref=2> <privilege>privilege1</prvilege> <action>action1</action> <objet>objet1</objet> <contraine>contrainte1<contrainte> </regle> Donc la règle est définie dans l’élément regle. Cet élément est composé

de quatre sous-éléments : privilege, acest optionnel. Ainsi l’ensemble des règles définitives sont représentées

dans ce document. Chaque règle a un identifiant présenté par l’att

E


Soit r’= (a’,o’,c’) une règle qui appartient à Rj our chaque r’ appartient à Rj Pour chaque r appartient à Ri ) Si l’objet o’ de r’ ne correspond à aucun objet o de r alors r’ indique

une autorisation à exercer l’action a’ sur l’objet o’ en respectant la contrainte c’. Dans ce cas, la règle r = (a’, o’, c’) sera intégrée dans le document XML.

2) Si un objet o’ de r’ correspond à un objet o de r et a’ de r’ ne correspond pas à a de me une règle autorisant à exercer une action sur un objet. Dans ce cas, la règle r = (a’, o’, c’) est insérée dans le document XML.

3) Si un objet o’ de r’ correspond à un objet o de r et une action a’ correspond à une action a de r valeur nulle, alors la règle r’ indique une interdiction d’exercer une action a’ sur l’objet o’. Dans ce cas, la règle r est supprimée de l’ensemble Ri.

4) Si un objet o’ correspond à un objet o e action a’ de r’ correspond à une action a de r et c’ n’a pas de valeur nulle, alors r = (a, o) est insérée dans le document xml avec un identifiant et r’=(a’, o’, c’) est également insérée dans docum l’attribut idref aura l’identifiant de r comme valeur. La règle r est supprimé de Ri. Ainsi, en traitant chaque règle r du document xml, nous vérifions si un autre règle r’ possède un idref avec un valeur égale à

lège de r’ ainsi que la contrainte soient

s, les objets autorisés sont accessibles. Le service lié à ce module doit tenir compte de ces règles lors de la gestion de l’accès au module des

’administrateur est chargé de gérer ces droits d’accès. Les utilisateurs n’ont pa

écutées pendant sa connexion.

d ntenu ils et d’organiser l’accès aux éléments

P 1

r alors r’ est considérée com

et c’ a une

de r et un

le ent et

l’identifiant de r pour que le priviappliqués.

5) En finale, les règles restantes de l’ensemble Ri seront insérées dans le document XML.

Ainsi un ensemble de règles est déclaré dans un document XML. Ces règles seront appliquées lors de l’accès aux objets du module de gestion des profils. Seul

profils. Ls accès à ce système de sécurité. Si un utilisateur souhaite contester ou

modifier un droit, il signifie sa demande en contactant l’admystème doit mettre en place un journal d’audit qui enregistre toutes

les actions réalisées par l’utilisateur. De cette façon, nous pouvons avoir accès à tout son parcours et aux tâches qu’il a ex

inistrateur. Le s

Ainsi les droits d’accès aux profils sont gérés afin de garantir la co entialiténfid es données co

fils. es dans les prof

des pro


4.3.2.10 Conclusion Dans la section gestion des profils, nous avons développé un ensemble de processus, à savoir la création des profils, l’insertion des données dans les profils et la gestion des droits d’accès aux profils. Nous avons vu qu’un profil est composé d’une structure et d’un contenu. La structure est représentée dans un schéma XML et le contenu est exprimé dans un document XML. Une structure de profil est créée pour décrire un sujet donné. Cette structure est composé

its d’accès était nécessaire pour organise

c le profil rend la personna

4.4

e de dimensions, d’attributs complexes et d’attributs simples. Ainsi cette décomposition va garantir une gestion générique et indépendante des profils.

Le processus de gestion des dror l’accès aux profils. En effet, n’importe qui n’a pas le droit d’accéder à

n’importe quoi. Pour ceci, il était important de définir les règles d’accès. Dans la section suivante, nous allons décrire un nouveau module qui

gère le contexte. En effet, la combinaison du contexte avelisation plus efficace et plus intéressante en tenant en compte de

l’utilisateur et son environnement.

Gestion du contexte

Pour pouvoir prendre en considération le contexte de l’utilisateur, des moyens doivent être définis pour capturer le contexte, l’interpréter, le stocker et le dissémin lons pas traiter ce sujet dans la mesure où il existe des travaux récents qui ont proposé un plateforme qui permet de capturer et de gérer le contexte [CHA 07]. Dans notre travail, nous allons nous ba

apture du contexte. Le contexte

emple), les capteurs logiques (modules logiciels) ou les capt mple). Puisque le contexte capturé s son format brut, un module aduit le contexte de bas niveau en une représentation de niveau élevé. Par exemple, il transforme des coordonnées géograp

odule d’adaptation d’un changement éventuel du contexte. La Figure 4.25 présente les

er. Dans ce travail de thèse, nous n’al

ser sur ces travaux et notamment le plateforme SECAS. Nous considérons par hypothèse que le contexte est stocké dans un document XML après avoir été capturé et interprété.

La gestion du contexte est une des couches de l’architecture de ce plateforme. La fonction principale de cette couche est la c

peut parvenir de plusieurs sources comme les capteurs physiques (appareils de mesure par ex

eurs virtuels (historiques d’accès par exepeut ne pas être significatif à l’application dand’interprétation du contexte tr

hiques en une adresse physique (rue, ville, pays). Ensuite, les données contextuelles interprétées sont stockées dans un registre contextuel (context repository) sous le format XML. Un courtier (broker) informe le m



Stockage ducontexte

Gestionnaire de contexte Broker

Fournisseur decontexte

différen

Figure 4

ts composants de la couche de gestion du contexte qui seront détaillés dans la suite de cette section.

.25 Gestion du contexte

4.4.1 Fournisseur du contexte (Context provider)

Le fournisseur du contexte est un composant logiciel lié à un ou plusieurs dispositifs matériels qui assurent la capture du contexte de l’environnement de l’utilisat

é à un module

eur ou de l’application. Le composant logiciel assure l’interprétation des données capturées dans le format directement exploitable par la couche de la personnalisation. Par exemple, un capteur température peut être associ

logiciel pour détecter le dépassement d’un seuil fixé. La Figure 4.26 présente la modélisation d’un fournisseur de contexte.

Figure 4.26 Modélisation d’un fournisseur de contexte

ContextParameter name

ContextInterpreter Name InterpreterData()

ContextSensor Name ProduceRowData()

High Level Context Low Level Context

1

Concerns Interacts with

1 11

2.4.2 Registre de contexte

ession utilisate

. La Figure 4.27 illustre la modélisation d’un registre de contexte. Il

fournit deux fonctions principales : getContextParameter() et setContextparmeter() pour accéder ou modifier la valeur d’un paramètre de

xte dant.

Modélisation d’un courtier de contexte

4.4.3 Conclusion

Le registre de contexte stocke les paramètres interprétés du contexte sous le format XML défini dans le paragraphe 3.3.2 du chapitre 3. Pour chaque s

ur, un profil de contexte est créé comme présenté dans la figure 3.15. Dès la connexion de l’utilisateur, le dernier contexte associé à cet utilisateur est chargé. Ensuite il est rafraîchi par les différents fournisseurs de contexte en cours de l’utilisation de l’application

conte dans son profil correspon


Figure 4.27 Modélisation d’un registre de contexte

Cette couche utilise le courti

contextRepository getContextParameter() setContextParameter()

contextProfile

*1

holds

er de contexte (context Broker) qui permet d’assurer l’échange de données entre la couche de personnalisation et la couche de contexte d’une part et entre les fournisseurs et le registre d’autre part. Les différents composants de la couche d’adaptation doivent s’abonner au courtier pour pouvoir accéder aux différents paramètres du contexte dans le registre. Les fournisseurs doivent également s’abonner un courtier pour pouvoir stocker les paramètres de contexte capturés et interprétés dans le registre du contexte. La Figure 4.28 présente la modélisation d’un courtier.

ContextBroker Subscribe()

ContextChangeSupport addClient() removeClient() notifyClient()

ContextParmeter Name Type value

1 1

holds instanciates

1 1

Figure 4.28

Ainsi dans cette section, nous avons exposé les différents composants qui peuvent être utilisés afin de capturer la situation contextuelle et de la représenter

dans un document XML. Nous rappelons que le contexte est caractérisé par un nsemble de paramètres qui doivent être capable de couvrir l’ensemble des ituations contextuelles de l’utilisateur. Un lien de dépendance est créé entre les omposants des profils et les paramètres du contexte afin d’extraire des profils s données qui correspondent à la situation contextuelle de l’utilisateur. Cette hase sera détaillée dans une des sections suivantes.


esclep

4.5

Pour garantir une gestion générique et indépendante


Base de donnéesdes services

Base de donnéesdes profils

Gestion des services Gestion des profils

Assoc eà une dimension (ouattribut complexe)

iation d’un servic

du processus de personnalisation, des services sont créés et associés aux dimensions (ou attributs

Fig cipe d’association entre les services et les profils Par ailleurs, le processus de personnalisation que nous proposons

données ont été extraites à partir des diverses sources de données suite à une requête envoyée par l’utilisateur. En effet, lorsqu’un utilisateur souhaite accéder à une information, il formule sa requête qui sera ensuite envoyée à l’ensemble des sources de données. Une réponse à cette requête sera retournée sous forme d’une structure XML. L’utilisateur final accède à ces données à travers une interface graphique. Donc le résultat de la personnalisation des données sera visualisé lors de la phase finale du processus d’accès à l’information, c’est-à-dire l’interface de navigation. Le processus de la personnalisation touche donc deux facteurs : 1) les données et 2) l’interface. Ainsi le processus de mise en œuvre de la

complexes) des profils. En effet, les profils sont des conteneurs de connaissances qui caractérisent un sujet donné. Donc ils sont incapables, tous seuls, de réaliser les objectifs attendus de la personnalisation. Pour cela, lorsqu’une dimension (ou attribut complexe) s’ajoute à la structure d’un profil donné, un service associé à cette dimension (ou attribut complexe) doit être proposé.

ure 4.29 Prin

s’applique aux données structurées en XML. Ces

Données en XML Suite utilis e

à une requêteat ur

Interface utilisateur Phase I : personnalisation du Phase II : personnalisation de la Contenu présentation

Service {S1, S2,..,Sm} Service{S1, S2, …, Sp} Données enXML

modules : la personnalisation du contenu et la personnalisation de la présentation. Cependant nous avons déjà signalé que

application à qui le processus de personnalisation sera implémenté ne doit

ront détaillés dans le chapitre suivant. Dans ce

se de personnalisation, des services sont proposés. La première phase qui concerne la personnalisation contenu est définie par un triplet associant le document XML entrée, l’ nsemble des services et un document XML personnalisé en sortie. Lors de cette phase les services seront chargés de personnaliser les données. Cette phase se base principalement sur le principe de filtrage du contenu afin de filtrer les données qui ne sont pas pertinentes ou qui nécessitent d’être traitées

ment. isation de la présentation est

ents XML personnalisé en entrée, un ensemble de services ur qui affiche les données personnalisées. Le rôle principal

de cette phase est d’afficher les données du document XML dans l’interface de

personnalisation se résume à deux

l’subir aucune modification. En conséquence, le document XML qui contient les données renvoyées suite à une requête utilisateur ne doit pas être modifié. De ce fait, un module additionnel doit être proposé pour gérer efficacement l’application de la personnalisation au niveau de l’interface. Les deux modules de personnalisation, à savoir la personnalisation du contenu et la personnalisation de la présentation, se

chapitre, nous nous intéressons à décrire la gestion des services, leur utilisation ainsi que l’utilisation des profils dans le processus de la personnalisation.

personnalisées

Figure 4.30 Services dans les deux phases de la personnalisation Donc la mise en œuvre de la personnalisation s’opère en deux phases

comme illustré dans la Figure 4.30. A chaque phadu

en e

différemLa deuxième phase concernant la personnal

définie par des documet l’interface utilisate

navigation en tenant compte des différentes étapes de personnalisation que les données ont subies. Ainsi l’utilisateur final accède à des données personnalisées en fonction de son profil et son contexte d’utilisation. Le fonctionnement de ces deux phases sera présenté en détail dans le prochain chapitre.

Dans la section suivante, nous allons décrire l’association d’un service à un élément du profil.


4.5.1 Association d’un service à une entité du profil

Un service est associé à un élément d’un profil. Cet élément pourra être soit une dimension, soit un attribut complexe dans le cas où la dimension exprime

ren ion décrits à travers la définition de plusieurs

eloppés: un serv hase I (personnalisation du contenu) et un service dans la phase II (personnalisation de la présentation). Le service de la phase II complète la tâche du service de la phase I ce qui implique une dépendance d’exécution entre les deux services. Cette association est spécifiée par l’attribut Type de la classe Est_associé qui considère le premier service comme un service source et le deuxième service comme un service destination.

ous utilisons le langage XML pour exprimer cette association. Le nœud racine de la structure XML est « association ». L’association d’un service à une mension ou un attribut complexe est représentée par le nœud « est_associe ». Le service est représenté par le nœud « service ». Si un service

exprimée par deux nœuds : le nœud services qui désigne le (ou les) service(s) concerné(s) ainsi le

diffé ts besoins de personnalisatattributs complexes (Figure 4.31).

Service

Element 11,2

Profil D i ti

Contient

1,n 1,n

Est_associé Type

Dimension Attribut

Figure 4.31 Modélisation de l’association d’un service à une entité du profil

Un élément d’un profil peut être associé à un ou deux services. Pour certains éléments, deux services sont dév ice dans la p

N

di

est associé à une dimension d’un profil donné, cette association est

type du service si deux services sont affectés à la dimension et le nœud dimension qui fournit l’identifiant de la dimension désigné ainsi que l’identifiant du profil auquel elle appartient. Si l’association est entre un service et un attribut complexe, cette association sera exprimée par le nœud services qui englobe un ou deux services et le nœud attribut qui fournit l’identifiant de l’attribut complexe ainsi que l’identifiant de la dimension et du profil auquel cet attribut appartient.



<xml> <association> <est_associe id=1> <dimenison id = 1 profil=1/> <services> <service id=1> <type>service_source</type> </service> <service id=3> <type>service_destination</type> </service> </services> </est_associe> <est_associe> <services> <service id=2/> </services> <attribut id=1 dimension=1 profil=1/> </est_associe> < !autres associations…> </association>

Figure 4.32 Extrait de la représentation XML de l’association entre les services et les entités d’un profil

re 4.32 donne un extrai il pour le sujet Rôle. Ce profil est composé de deux dimensions préférences et droit d’accès. La dimension préférences est codésignant chacun un plexes sont composés à leur tour d’attributs simples. La dimension droit d’accès est composée de l’attribut complexe autoriser. Donc deux services seront créés pour la dime préférences et seront attachés aux attributs complexes de cette

mé pref_activ est associé à l’attribut complexe ié à l’attribut

complexe

La Figu t d’un prof

mposée de deux attributs complexes : activité et présentation besoin de personnalisation. Ces deux attributs com

nsion dimension : un service nomactivité et un deuxième service nommé pref_affich est assoc

présentation. Pour la dimension droit d’accès, un seul service droitacces est défini du fait que la dimension est composée d’un seul attribut complexe désignant un seul besoin de personnalisation.


Activité :Attribut _Complexe

Présentation :Attribut_complexe Attribut_complexe :autoriser

Droit d’accès :Dimension Préférences :Dimension

Prole : profil

Rôle :sujet

Service_destination

Pref_activ :Service

Pref_affich:Service

Service_destination

droitAcces:Service

Service_source

Figure 4.33

Lorsqu’une dimension est composée de plusieurs attributs complexes

désignant des besoins de personnalisation différents, des services sont proposés pour tout attribu exe. Sino rvice peut est associé à la dimension.

Néanmoins une contrainte apparaît à cette association dans le cas

Supposons une dimension d comportant un seul attribut complexe ac2 au

ituation

Exemple d’association entre les éléments d’un profil et les services

t compl n le se

suivant :

est associé à un service s. Un attribut complexe ac1 désignant un nouveesoin de personnalisation est ajouté à cette dimension d. Donc une nouvelle b

s se présente : avant l’ajout, nous avions une dimension associée à un service, après l’ajout nous avons une dimension associée à un service et composée de deux attributs complexes. Nous savons que lorsqu’une dimension comporte plus d’un attribut complexe répondant à différents besoins de personnalisation, les services seront associés aux attributs complexes et non plus à la dimension. Pour cette raison, le service qui était associé à la dimension sera attribué à ac2 qui composait la dimension d avant l’ajout et un nouveau service sera proposé à l’attribut ac1. De cette manière, les services seront associés uniquement aux attributs complexes.

Ainsi, nous avons décrit comment les services sont créés et associés à des éléments du profil. Dans la section suivante, nous allons exposer comment ces services sont organisés avant qu’ils soient exécutés.

4.5.2 Ordre d’exécution des services

L’exécution d’un service peut ne pas être totalement indépendante d’autres services. En effet, les paramètres d’entrée d’un service peuvent provenir de la sortie d’autres services. Donc un lien de dépendance entre certains services existe. Ce lien peut spécifier deux critères : 1) l’ordre d’exécution d’un service par rapport à un autre ou 2) le fait que certains paramètres de sortie d’un service seront utilisés dans l’exécution d’un autre service. Ces critères de dépendance sont définis lors de la création d’un service via le paramètre critère. Comme c’est la section 4.2.2, ce critère permet de définir trois manière d’exécution ordre, conditionnelle. Le premier critère signifie que le se rvices. Le deuxième critère fournit l’ordre d’exécution d’un service par rapport à un autre. Ainsi l’exécution du secon remier service a été exécuté avec ne condition qui doit être respectée pour ernier critère présente deux poss ilités : 1) l’analyse de la condition montre une dépendance entre le service concerné et un autre service (certains param entrée d’un service dépendent du résultat du sorti utilisés dans la co dition ne conc r exemple, une condition qui comp re la date d’aujourd’hui à une date prédéfinie pour une utilisation donnée, montre que cette condition est complètement indépendante des services. Donc nous distinguons deux classes de services : les services indépendants et les services

d’autres services. Lors de l’exécution des services, cette

d’exécution des services peut être déterminée en nalysan

indiqué dans : séquentielle,

rvice concerné ne dépend pas d’autres se

d service ne peut être déclenché que si le p succès. Le troisième critère décrit u l’exécution du service. Ce d ib

ètres d’e d’un autre service) ou 2) les paramètres nernent pas les services. Pa a

dépendants classification doit être prise en considération.

Ainsi la chaînea t le critère défini pour chaque service. Ces services seront classifiés en fonction de leur dépendance à d’autres services. Aux premiers rangs seront classifiés les services indépendants qui seront suivis ensuite par les services dépendants.



La classification de ces services se réalise en plusieurs étapes que nous étaillerons dans l’algorithme suivant :

aramètres d’entrée : Soit SV l’ensemble des services ayant le même type et la ême phase d’exécution aramètres de sortie : L1 iste L1=0 iste L2=0 1ère étape :séparation entre les services indépendants des autres our chaque service sv appartient

Si RechercheCritere(sv) = ’ ;’ alors L1= Insert (L1, sv )

Sinon L2 = Insert (L2, sv ) Fins

n 2ème étape : comparaison des dépendances entre les services

Pour chaque sv’ appartient à L2, faire r chaque sv Si depend (sv, sv’) = 1 alors // si sv’ depend de sv // sv’ est ajouté à L1 et inséré derrière sv

= insertSe ) Supprimer (L2, sv’)

Finsi Fin

in

Figure 4.34 Algorithme de calcul de l’ordre d’exécution des services

ure présente

ns deux listes entre les services dont le critère est séquentiel et les autres s

n’est plus de services dans L2.

d PmPLL//P SV, faire i fi//

Pou appartient à L1

L1 rv (L1, sv, sv’

F

La Figure 4.35 illustre les étapes décrites ci-dessus permettant de

définir l’ordre d’exécution des services dans une liste chaînée. Cette fig cinq services avec cinq critères. Donc la première étape consiste

séparer daervices. Nous avons les services SV1 et SV3 qui ont un critère

séquentiel. Donc ils seront insérés dans L1. Les services SV4, SV2 et SV5 dépendent d’autres services, donc ils seront insérés dans une deuxième liste L2. La deuxième étape consiste à insérer les services de la liste L2 dans la liste L1 en respectant l’ordre de dépendance entre les services. Donc avant qu’un service de L2 ne soit inséré dans L1, il sera comparé à l’ensemble des services de L1 pour trouver le service dont il dépend. Si le service de L1 est trouvé, le service de L2 est inséré à la suite du service de L1. Cette opération est répétée jusqu’il

SV1 Critère : « ; »

SV2 Critère : SV2 dépend deSV4

SV3 Critère : « ; »

SV4 Critère : SV4 dépend deSV1

SV5

Critère : SV5 dépend deSV3

1ère étape : séparation desservices en deux listes

SV1 SV3 SV2 SV4 SV5

Liste L1 Liste L2

Figure 4.35 Ordre d’exécution des services

Dans cette section, nous avons fourni une méthode qui permet de définir l’ordre d’exécution des services au sein d’une phase donnée. Ainsi lors de la mise en œuvre de la personnalisation sur les données, l’invocation des services sera réalisée en fonction de l’ordre défini dan la liste.

4.6 Exploitation des profils et des services dans la mise en œuvre de la personnalisation Ce module s’oriente autour l’utilisation des profils et l’exploitation des

services dans la mise ne œuvre de la personnalisation. Nous avons vu jusqu’au maintenant les différentes modèles nécessaires pour construire l’approche de la personnalisation. La prochaine étape consiste à décrire comment ces modèles seront servis pour exécuter les tâches de la personnalisation qui doivent répondre en principe à des objectifs attendus de cette approche en terme de personnalisation.

2ème étape : comparaisonde la dépendance desservices entre les deuxlistes

SV1 SV3 SV4 SV5 SV2

SV1 SV3 SV4 SV5 SV2 L’ordre des servicesdans une Liste chaînée

Ce module s’organise en deux étapes principales comme illustré dans la Figure 4.36:

- Sélection de l’ensemble des profils qui correspondent à la situation contextuelle

- Utilisation des profils et des services pour personnaliser l’information.

ans les sections suivantes, nous allons procéder à l’explication de ces deux grandes étapes.

D



Exploitation des profils et des services

Interface utilisateur personnalisé Etape 2 : utilisation desprofils des services dansle processus depersonnalisation

et


Base de donnéesdes profils

Situation contextuelle

Sélection de l’ensemble des profils

Etape 1 : Sélection desprofils en fonction dela situationcontextuelle

profils

se en œuFigure 4.36 Principe de mi

vre de la personnalisation

eux étapes, nous allons définir quelques une structure XML.

le processus de la personnalisation

Avant de présencipes sur la décomposition d’

ter les dprin

4.6.2 Utilisation des profils dans

Cette étape de la personnalisation consiste à sélectionner les profils qui sont

. En d’autres termes, nous s la base des profils, ceux qui sont

quelle se trouve l’utilisateur. Les profils rincipe, ceux dont l’utilisateur en question est le

riétaire, ainsi que tous les profils dont les propriétaires se trouvent dans le

nous cherchon

valides par rapport au contexte courant de l’utilisateurcherchons parmi les profils disponibles danapplicables à la situation dans ladisponibles sont, en ppropcontexte courant de l’utilisateur. Par exemple, soit une situation contextuelle C déterminée par (utilisateur = val1, rôle=val3, localisation= val4). Donc

s parmi les profils de la base ceux qui sont inclus dans ces trois éléments du contexte: utilisateur, rôle et localisation.

Par ailleurs, les éléments du contexte courant sont exprimés dans une structure XML dont la balise situation_contextuelle est la racine comme illustré dans la figure 4.37. Cette balise enveloppe les éléments du contexte courant sous forme <attribut>valeur</attribut>.

<XML> <situation_contextuelle> <utilisateur>U1</utilisateur> <role>val3</role> <localisation>lieu1</localisation> </situation_contextuelle>

Figure 4.37 la situation contextuelle exprimée dans une structure XML

Avant de décrire les différentes étapes de sélection des profils, il est

important de faire un rappel sur la composition de la structure xml d’un profil. s avon dans la chap 3 qu’u rofil dont le propriétaire est un

c é d’ s dimension est composée d’un ensemble d’attributs (simples ou complexes). ous avons vu égale ue lorsque certains attributs simples ont des liens de

e ments du contexte (tels que la localisation, le rôle, etc.), ans la structure XML d’un profil par la balise depend.

La figure 4.38 illustre un exemple d’une structure d’un profil qui est omposé de la dimension préférences. Cette dimension est composée de attribut complexe activité qui est composé de trois attributs complexes :

, lieu, objet. L’attribut lieu a une dépendance avec un paramètre du localisation.

Pour chaque profil contenant une structure, vérifier si profil contient l’élément depend.

plexe contenant l’attribut

ttribut ascendant attAsc de attCom. Un attribut ascendant peut contenir un à plusieurs attributs dépendant du contexte. Puis ces éléments

omSujet</sujet>

Nou s vu itre n pparamètre du contexte est ompos un en emble de imensions et une dN ment qdépendance avec d s éléils sont représentés d

cl’tachescontexte

La sélection des profils est effectuée en plusieurs étapes : 1)

chaque attribut de ce Ensuite pour chaque attribut comdepend, vérifier deux cas : si l’attribut représente le sujet, dans ce cas extraire le nom du sujet nomSujet, sinon extraire le nom de cet attribut complexe attCom, le nom de l’attribut depend attDep et le nom de l’a

seront insérés dans une structure xml struct.xml commesuivant :

<sujet>n<attAsc> <attCom> </attDep> </attCom> < !—autres attributs dependant-> </attAsc>


<xsd :complexType name= « profil»>

<xsd :element name = “proprietaire” type= “xsd:string” />

<xsd :complexType name= « preferences»>

<xsd :element name = “activite” type= “activite”

xType>

 <xsd :complexType name= « activite»> <xsd :sequence> <xsd :element name = “tache” type= “tache” /> <xsd :element name = “lieu” type= “lieu” />

<xsd :element name = “objet” type= “objet” minOccurs= “1”maxOccurs=“unbouded” /> </xsd:sequence> <xsd:complexType>  <xsd :complexType name= «objet»> <xsd : sequence> <xsd :element name = “nom” type= “xsd :string” /> <xsd: element name = “valeur” type= “xsd :string” /> </:sequence> </xsd :complexType>  <xsd :complexType name= «tache»> <xsd : sequence>

<xsd :element name = “nom” type= “xsd :string” /> </:sequence> </xsd :complexType>  <xsd :complexType name= «lieu»> <xsd : sequence> <xsd :element name = “type” type= “xsd :string” /> <xsd:element name=”depend” type=”conceptLocalisation”/> </:sequence> </xsd :complexType>  <xsd :complexType name= « conceptLocalisation»> <xsd :sequence> <xsd :element name = “nom” default=”localisation” /> <xsd :element name = “type” default =”[0,1] /> </xsd:sequence> <xsd:complexType>

igure 4.38 Exemple d’un profil 2) Une fois l’extraction des attributs dépendant du contexte

fini, l’étape suivante consiste à chercher de la correspondance entre les éléments de la structure struct et les éléments du contexte courant. Pour le sujet, la correspondance est calculée entre nomSujet et les éléments du contexte. Si une correspondance est trouvée, la valeur de l’élément du contexte est insérée dans l’élément sujet. Par contre pour chaque attCom, la correspondance est calculée

<xsd :sequence> <xsd :element name = “id” type= “xsd:string” />

<xsd :element name= “preferences” type= “preferences” />



<xsd :sequence> <xsd :element name = “nom” type= “xsd:string” /> minOccurs=”1” maxOccurs=”unbounded”/> </xsd:sequence> <xsd:comple

F

Kari

en comparant attCom avec les éléments du contexte. si une correspondance est trouvée, la valeur de l’élément du contexte est insérée comme valeur dans attCom de la

supprimé de la uivante :

/attCom> < !—autres attributs dependant->

3) La troisième étape consiste à extraire le profil valide à

de la structure. En final,

figure 4.38. Nous considérons que l’élément utilisateur est un paramètre du contexte. Cette déclaration ne figure pas dans l’exemple de la structure.

urant la sélection des éléments, nous utilisons deux opérateurs : Contient equals. En général, un élement xml N est représenté par le triplet <n,

, t> où n est l’élément courant, A est l’ensemble des attributs associés à cet n paire (a,v)

où a est un attribut, v est la valeur associée à cet attribut.

structure struct et l’élément attDep eststructure. Ainsi la structure aura la forme s

<sujet>valeurSujet</sujet> <attAsc> <attCom> valeur <

</attAsc>

partir les profils qui contiennent les instances (les données). Pour chaque profil correspondant au profil déjà traité, vérifier si l’attribut proprietaire de l’élément profil contient valeurSujet déjà défini dans la structure struct. Si c’est le cas, l’élément profil ainsi que son contenu sont extraits et insérés dans un document XML profil_temp.xml. Ensuite, pour chaque élément e de la structure déjà extraite, vérifier si e correspond à attAsc. Si c’est le cas, comparer le contenu de attAsc et e. si une correspondance n’est pas trouvée, l’élément e est supprimé nous avons le profil valide à insérer dans une structure qui englobe l’ensemble des profils valides.

La figure 4.39 présente un extrait d’un profil qui défini des instances pour la strucure déjà définie dans la

D et

Aélément et t le texte associé à n. Chaque attribut A est exprimé par u

ne ABBAS / Thèse en informatique / 2008 / Institut national des sciences appliquées de Lyon 119


<xml> <utilisateur> <profil id = 1 proprietaire=’U1’> <preferences> <activité> <objet> <valeur>O1</valeur></objet> <tache><nom>lire</nom></tache>

<lieu><type>lieu1</type></lieu>

</activité>

</utilisat

Figure 4.39 Extrait d4.38

L’opérateur contien ément n inclut parmi ces attributs un autre élément xprimer ceci de manière formelle, nous proposons

si c’econtient( n, n’) =

sinon ui vérifie que N enveloppe le nœud N’.

L’opérateur equals permet de comparer deux attributs xml et leur contenu. Donc l’opérateur equals a un double objectif : 1) vérifier l’égalité entre deux attributs et 2) tester l’égalité entre deux éléments.

- Le premier cas teste si deux attributs (a1,v1) et (a2,v2) sont égaux. Pour ce faire, il vérifie si a1 correspond sémantiquement à a2 et si v1=v2. En principe, un attribut est un nœud feuille qui ne contient pas d’autres attributs.

- Le deuxième cas compare deux éléments pour vérifier s’ils sont égaux. Cette égalité entre deux éléments vérifie deux points : Etant donné deux éléments N1(n1, A1, T1) et N2(n2, A2, T2), N1 correspond à N2 si N1 correspond sémantiquement à N2 et s’il existe un sous ensemble d’attributs An1

de n1 inclus dans les attributs A2 de n2. Cette inclusion vérifie l’égalité entre les attributs de ce sous-ensemble An1 et les attributs de N2. Donc de manière plus formelle, l’égalité entre deux éléments N1 et N2 est exprimée comme suivant :

<activité> <objet> <valeur>O2</valeur></objet>

<tache><nom>lire</nom></tache> <lieu><type>lieu2</type></lieu> </activité> </preferences> </profl> <profil id = 2 proprietaire=’U2’> <preferences> <activité> <objet> <valeur>O3</valeur></objet> <tache><nom>lire</nom></tache> <lieu><type>lieu3</type></lieu> </activité> </preferences> </profl>

eur>

’un profil correspondant à la structure définie dans la figure

t permet de vérifier si un éln’. Pour e

1 st vrai

0 q


1 si N1=N2 N2) =

0 dans le cas contraire orsque l’opérateur equals est proposé avec deux variables en entrée,

cet opérateur vérifie si les deux variables correspondent à des attributs ou à des éléments. En principe un attribut est un nœud feuille qui ne contient pas d’autres attributs. Par contre, l’élément est un nœud qui contient d’autres nœuds. Dans ce cas, nous vérifions si ces derniers sont des attributs feuilles ou des nœuds non feuilles qu’un nœud peut être composé d’une hiérarchie de nœuds. Si c’est le cas, nous descendons dans la hiérarchie jusqu’à trouver un nœud composé d’attributs (nœud feuille avec une valeur).

a sélection des profils qui correspondent à la situation contextuelle courante est décrite par l’algorithme général illustré dans la figure 4.40.

oit C le contexte courant de l’utilisateur. Ce contexte est représenté par un ensemble d’éléments (e1, e2, …, en). Chaque élément est représenté par une paire (attribut, valeur) dans la balise situation_contextuelle de la structure xml com e illustré dans la figure 4.37.

’algorithme présenté dans la figure 4.40 prend en entrée le contexte courant C et un profil P.

Equals (N1,

L

parce

L

S

mL


Fonction getProfilVa{ Pour chaque { { Si correspond (elem, sujet) = 0 Sinon {

scendant (elem) )

} Pour chaque el{

ValeurPour ch{

{ si Contient (elem, attAsc) = 1 && equals (elem, attAsc) = 0 deleteElement(elem) } } R tour profVal

}

Figure 4.40 Algorithme générale d’utilisation des profils dans le processus de la personnalisation

lide (C, sujet)

elem de p faire

Si Contient (elem, ‘depend ‘) = 0

In truct, nomSujet) sert (s

attAsc = getAattDep = getValeur(nomInsertDep (struct, elem, attDep, attAsc)

} }

em de C faire

= getValeur(elem) aque el de struct faire

Si el = ‘sujet’ { nomSujet = getValeur (sujet)

Si Comparer (nomSujet, elem) = 0 remplacer (nomSujet, Valeur)

} Sinon si el = elem

{ ajouterElement (valeur, attCom) deleteElement (attDep) }

} }

Pour chaque elem de proInstanc faire { Pour chaque el de struct faire si el = ‘sujet’ et equals (nomSujet, elem) profVal = selectProfilValide() si correspond (elem, attAsc) = 0

e


<xml> <utilisateur> <profil id = 1 proprietaire=’U1’> <preferences> <activité> < <tache><nom>lire</nom></tache> <lieu><type>lieu1</type></lieu> </activité> </preferences> </profl> </utilisateur>

our illustrer la réalisation de cet algorithme, nous l’appliquons sur l’exemple cité dans la figure 4.37 et la figure 4.38.

Figure 4

ction des services pour personnaliser l’information

P

objet> <valeur>O1</valeur></objet>

.41 Exemple d’un profil valide

4.6.3 Séle

Une fois la sélection des profils achevée, la seconde étape du processus de la personna étape exploite principalement les services . Nous rappelons que chaque service développé est associé à une dimension (ou attribut complexe) du profil. Donc à

algorithme général

e les vale

e associé est extrait pour être ensuite inséré dans une liste. Cette opération est répétée pour tous les profils sélectionnés.

lisation est commencée. Cette qui doivent au préalable être déterminés

partir des éléments des profils sélectionnés dans l’étape précédente, les services seront recherchés et ordonnés avant qu’ils soient exécutés.

Cette étape est réalisée en quatre étapes comme décrit dans l’de la figure 4.42 : - La première étape consiste à extraire les éléments de la structure xml

de chaque profil sélectionné (étape 1 dans l’algorithme). Les attributs ainsi quurs sont exclus lors du processus de l’extraction. Seuls les éléments

(noeuds non feuilles) sont extraits. Nous utilisons XPATH pour parcourir la structure XML et accéder aux éléments de chaque profil pour ensuite les insérer dans une liste ListeE. Puis l’algorithme recherche la liste des services qui sont associés aux éléments de ListeE (étape 1.2 de l’algorithme). Pour chaque élément de la liste ListeE, nous vérifions s’il figure dans la structure xml dédiée à l’association entre service et élément du profil. Si c’est le cas, le servic

- U f s es trouvés (dans ne ois le servic la liste LServices), l’algorithme les classifie en deux groupes (étape 2 de l’algorithme). Les services seront classés en fonction de leur apparten a été spécifié lors de la création n service à travers le paramètre phase. Si phase = 1 le service est classé da

effectuer cette analyse. Une fois

// extraire les services qui sont associés aux éléments d’un profil Lservices = Lservices U extractService (e)

}

Services[] = classifyService (Lservices) ordonnerService(Services) invoquerServices() }

Figure 4.42 Algorithme général de sélection des services

ertains services de la phase I sont associés à des services de la phase II. Cette association signifie que le service de la phase II ne s’exécute que si le service de la phase I auquel il est associé s’est exécuté sans erreur.

4.7 Conclusion

ance aux deux phases. Ceci d’uns LServices1, sinon il sera classé dans LServices2.

L’étape 3 de l’algorithme consiste à ordonner l’ordre d’exécution des services dans chaque phase. Il est important de bien ordonner les services en prenant en compte ces contraintes. Lors de la création d’un service, ces contraintes ont été définies par le paramètre critère. Donc l’ordonnancement de ces services sera effectué en analysant le contenu du paramètre critère. Ensuite en fonction du résultat de l’analyse, l’ordre d’exécution du service est déterminé. Nous avons décrit dans la section l’algorithme qui permet d’

les services ordonnés dans chaque phase, l’exécution de ces services est lancée.

Fonction selectServices (P) {

ListeE = Parcourir (P) Pour tout e de ListeE faire {

C

Dans ce chapitre nous avons montré que la mise en œuvre de la personnalisation s’articule autour deux principes : l’utilisation des profils et des services. En effet, des services sont chargés de mettre en œuvre la personnalisation à partir des données contenues dans les profils qui fournissent une description des informations caractérisant une entité.


De manière similaire aux profils, cette approche a pour avantage de des profils qui s’associent à des services. En

et, un service est défini dès qu’un nouveau besoin de personnalisation se pose une solution complète de l’accès

e la généricité et l’évolutivité nnement de l’application dans laquelle il

’implém un ation sont définis dans des rofils. D autre compte par des services qui ettent en œuvre le processus de la personnalisation. Entre ces deux principes,

un échange des données exis ie. Nous avons montr posée de deux

hases : la personnalisation du contenu et la personnalisation de la présentation. En effet, le p odule est incapable de réaliser de manière complète et satisfai la personnalisation. Le deuxième module vient complé ier et s’occuper d’afficher les données personnalisées ue.

Dans le chapitre suivant, nous présentons en détails les deux phases ainsi que les méthodes fonctionnelles conçues. Nous parlerons également du projet SGI2 da proche de la personnalisation sera implémentée.

permettre une définition générique effmanifeste. Ainsi l’

ersonnal é à l’infoapproche pro

p is rmation basée sur le principe dsans modification du fonctios ente. D’ coté les besoins de personnalisp ’un coté, ces besoins sont pris enm

te via l’association qui les lé que la personnalisation est com

premier m

sante l’objectif attendu detravail du premter le

dans l’interface graphiq

ns lequel l’ap


5 Mise en œuvre de la personnalisation

5.1 Introduction Dans le chapitre précédent, nous avons montré les étapes de sélection des services et de leur classification en deux groupes : services du contenu et services de présentation. Chaque groupe a un objectif de personnalisation. Le premier groupe est chargé de personnaliser les données (contenu) et le second groupe de services permet de compléter le travail des services du contenu en tenant en compte des modifications des données dans l’interface utilisateur.

Dans les sections suivantes, nous détaillons le fonctionnement de deux

5.2 ntenu

phases.

Personnalisation du co La personnalis rnir à l’utilisateur des inform ns pertinentes qui correspondent à ses attentes et ses préférences. Donc la prise en considération de l’information est le facteur central de ce

important de déterminer la qu’elles soient visualisées dans

nous intéressons aux données qui sont présentées de manière hiérarchique dans des documents XML. En effet, nous

rs métadonnées. e processus de personnalisation du contenu s’appuie sur le principe de

filtrage d

r laquelle la personnalisation sera appliquée. Dans les sections suivantes, nous fournirons plus de

e de personnalisation du contenu.

5.2.1

ation de l’information a pour objectif de fouatio

processus de personnalisation. De ce fait, il estmanière dont les données sont stockée

nterface. Dans notre approche, nouss avant

l’ireavons besoin d’avoir à la fois les données ainsi que leu

L’information afin de séparer les informations utiles de celles qui ne le sont

pas. Nous rappelons que la mise en œuvre de la personnalisation ne doit induire aucune modification sur les programmes ou le code de l’application su

détails sur le princip

Principe de la personnalisation du contenu

La personnalisation du contenu s’applique donc sur des données extraites à partir des différentes sources de données pour répondre à une requête adressée par l’utilisateur. Le gestionnaire de personnalisation du contenu est un programme qui utilise le document XML contenant les données ainsi que le profil déjà sélectionné. Ensuite il


Gestionnaire de la personnalisation du

contenu

SERVICES {S1, S2, ……, Sn} Autres documents

XML

Document XML

Document XML personnalisé

Profil sélectionné

invoque

ée du document XML ainsi qu’un ensemble

e fonctionnement du service de la personnalisation du contenu est exposé dans la section suivante. Mais avant ceci, nous allons décrire une notion importante que nous

5.2.2 Principe de l’objet

les services concernés par la personnalisation du contenu (phase I) selon l’ordre d’exécution déjà attribué à chaque service.

Figure 5.1 Principe de la personnalisation du contenu

La figure 5.1 illustre le principe de la personnalisation du contenu. En entrée, nous avons le document XML qui contient les données et le profil valide. En sortie, nous obtenons la version personnalis

supplémentaire de documents XML qui contiennent des informations nécessaires par la deuxième phase de la personnalisation (personnalisation de la présentation). Un ensemble de services est exécuté lors de cette phase. L

allons utiliser dans les sections suivantes.

Le terme objet désigne tout élément du monde réel représentable à travers une structure XML. Cette structure contient les données extraites des différentes sources de données pour répondre à une requête utilisateur. Donc les éléments de la structure XML représentent les métadonnées définies pour exploiter les données contenues dans les différences sources de données. Ces métadonnées représentent en principe une vue unifiée (appelée également schéma global) des différentes sources de données que l’application exploite. Donc en se basant sur ce schéma global, les objets que nous exploitons dans notre approche seront spécifiés. En d’autres termes, dans le module de gestion des profils, lorsque nous avons besoin de faire référence à une métadonnée utilisée par l’application, nous créons un attribut complexe qui portera le nom objet. Ensuite l’attribut simple de cet attribut complexe aura comme appellation le même nom que la métadonnée. De cette façon, lors de la recherche de correspondance entre les éléments du document XML et les éléments d’un profil donné, l’élément objet du profil est le premier concerné par cette correspondance.


Document XML

Element objet

Profil

Correspond

appartient

Fiél

gure 5.2 Relation de correspondance entre un élément du document XML et un ément objet du profil

2.3 Fonctionnement d’un service du contenu

5.

Uco

n ensemble de services est dédié pour mettre en œuvre la personnalisation du ntenu. Chaque service a un objectif de personnalisation bien défini et différent en nction du composant du profil auquel il est associé. Malgré ceci, tous les services opèrent pour accomplir les tâches de la personnalisation. Nous rappelons qu’un rvice est un programme qui a des paramètres d’entrées et qui retourne un ensemble paramètres de sorties (figure 5.3). Certains paramètres de sorties constitueront des ramètres d’entrée pour un autre service.

Figure 5.3 Fonctionnement d’un service

En principe, un service est composé d’un ensemble de fonctionnalités dont le rôle est d’exécuter l’objectif attendu de ce service. A l’image d’un service, chaque fonctionnalité a des paramètres d’entrée et retourne des paramètres de sortie qui seront utilisables dans les autres fonctionnalités. Ces fonctionnalités utilisent XQUERY lorsqu’il s’agit d’effectuer des requêtes XML afin de sélectionner des

focosedepa

Service

Fonctionnalités Paramètres de sorties Paramètres

F1, F2, F3, …., Fn


Service Service


Profil

Document XML

4. Mapping entre leséléments retournés et leséléments du document XML

2. rechercher un correspondant à l’élément

3. retourner tous lesdescendants de l’élément

5. Résultat dela correspondanc

6. exécuter la tâche dela personnalisation

Document XML dédié à l’associationentre les profils et les services

1. rechercher l’élément d’un profil

ermet de parcourir la structure u éventuellement extraire des

nous distinguons quatre principales fonctions:

1) La fonction accesElement qui permet de rechercher l’élément qui on (étape 1 de la figure 5.4). Nous savons que chaque

un profil. Donc la première étape de cette opération

données à partir des documents XML et XPATH qui pd’un document XML et accéder à des éléments oéléments.

Parmi les fonctionnalités d’un service du contenu,

correspond au service en questirvice est associé à un élément d’se

consiste à connaître cet élément e. Pour ce faire, nous recherchons dans le fichier xml dédié à l’association entre les services et les composants des profils l’élément correspondant au service en cours. Une fois que cet élément e est trouvé, il est retourné ainsi que l’identifiant du profil auquel il appartient par la fonction. Cette fonction adresse une requête XML sur le document XML pour trouver cet élément.

Figure 5.4 Principe de la personnalisation du contenu

2) La fonction accesProfil qui permet d’extraire du profil déjà sélectionné

les données qui correspondent à l’élément e. Cette fonction commence par effectuer un mapping entre cet élément e et l’ensemble des éléments E={e’1, e’2, .., e’n) du document XML du profil (étape 2 de la figure 5.4). La correspondance sera



ée entre e et e’j (avec 1≤j≤n), tous les descendants de cet élément trouvé sont extraits et insérés dans un document XML provisoire que nous appelons mapping.xml. La figure 5.6 illustre un exemple du contenu de ce document XML.

La deuxième opération de cette fonction consiste à extraire de ces descendants les valeurs des éléments qui désignent le terme objet. Ces valeurs seront insérées dans un tableau et retournées par la fonction accessProfile (figure 5.5). Ces valeurs vont servir dans la comparaison avec les éléments du document XML contenant des données demandées par l’utilisateur.

Fonction accessProfile (element) {

Objets = Parcours(Branche)

recherchée uniquement sur des éléments qui représentent des dimensions et des attributs complexes. Si une correspondance est trouv

Branche = extract (element) insert (mapping.xml, Branche)

Return Elements }

Figure 5.5 Algorithme de la fonction accessProfile

La figure 5.6 illustre un exemple du contenu du document mapping.xml ainsi que l’opération d’extraction des valeurs des objets. L’extraction des objets donnera cet ensemble d’objets Objets = { Objet1, Objet3, Objet4}

Figure 5.6 Exemple du contenu du document mapping.xml

<dimension> <attribut_complexe>

<attribut> <valeur>valeur1</valeur> </attribut>> <objet> <valeur>Objet1</valeur> <valeur>Objt3</valeur> </objet>

</attribut_complexe> <attribut_complexe>

<attribut> <valeur>valeur2</valeur> </attribut>> <objet>

<valeur>Objet4</valeur>


3) La fonction mapping permet de rechercher une correspondance entre les léments du document mapping.xml et les éléments du document XML qui contient s données destinées à être affichées dans l’interface. Nous donnons à titre provisoire n nom au document XML qui contient les données affich.xml pour faciliter notre xplication. Les deux documents XML sont parcourus à la recherche de

ents de chaque structure de ces documents. Si une effectuer le

ent nécessaire pour réaliser la tâche de la personnalisation définie pour ce executeService sera décrite en détails dans la section suivante.

fonction mapping utilise la fonction Parcours pour parcourir la structure du ent affich.xml afin d’extraire l’ensemble des éléments de ce document. Une

ents sont extraits et insérés dans un tableau, la comparaison entre ces léments et les objets introduits en paramètre d’entrée commence. La fonction xtraire a pour objectif d’extraire tous les valeurs des éléments frères de l’objet en ours de mapping et de les présenter dans une liste V (v1, v2, .., vn) .

Fonction mapping (Objets )

(affich.xml)

Pour tout o appartient à Objets faire (e, o) apping.xml, o, ct)

ctures XML qui permettront d’illustrer opération de mapping. La première structure représente un échantillon du document

XML affich.xml. La deuxième structure XML représente un exemple du document mapping.xml.

éleuecorrespondance entre les élémcorrespondance est trouvée, la fonction executeService est appelée pour changemservice. La fonction Donc la documfois que ces éléméec

{ E = Parcours Pour tout e appartient à E faire

ct = Correspond V = extraire (m if V <> 0 alors

ExecuteService(ct, V, o) fin fin }

Figure 5.7 Algorithme de la fonction mapping

La figure 5.8 présente deux strul’


<xml> ……….. <Objet1> donnée1</Objet1> <Objet2> <Objet3> donnée3</Objet3> </Objet2> < /!autres objets>

<dimension> <attribut_complexe>

</attribut>>

</attribut_complexe>

<attribut> <valeur>valeur1</valeur>

<objet> <valeur>Objet1</valeur> <valeur>Objt3</valeur> </objet>

</attribut_complexe> <attribut_complexe>

<attribut> <valeur>valeur2</valeur> </attribut>> <objet>

<valeur>Objet4</valeur> <valeur>Objt3</valeur> </objet>

mapping

Affich.xml

Mapping.xml

Figure 5.8 Exemple d’une opération de mapping

4) La fonction executeService permet d’exécuter la tâche qui va permettre de personnaliser les données. Cette fonction a trois paramètres d’entrée : l’objet qui va subir le changement, la liste des valeurs V qui accompagnait l’objet dans le document mapping.xml et le code ct qui vaut 1 si la correspondance est trouvée ou 0 dans le cas contraire. Cette fonction fait appel à des fonctions définies et développées pour réaliser des tâches de personnalisation. Une librairie (personalisationLibrary) est crée pour définir et stocker les fonctions qui exécutent des tâches de personnalisation (du contenu et de la présentation). Ces tâches peuvent avoir différents cas de figure en fonction du besoin de personnalisation. Nous définissons les cinq cas les plus probables et qui sont :

- la suppression des données, - le masquage des données, - l’ajout des données, - la modification des données, - l’exécution d’une action sur une donnée. En principe, c’est le concepteur qui se chargera de définir les tâches de la

afin de couvrir tous les besoins. Dans les sections suivantes, nous

personnalisation allons décrire chacun de ces cinq cas.

a. Supprimer des données Cette tâche consiste à supprimer du document XML des éléments non voulus ou

Le cas le plus répandu pour ce type de tâche est la gestion des droits d’accès. effet, certaines informations ne doivent pas être visualisées ce qui pourrait

des données ne oit en aucun cas affecter la qualité ou la structure du document XML afin de ne pas uire au fonctionnement de l’application. Pour ceci, la suppression des éléments eut être observée de deux manières :

- Si l’élément à supprimer contient uniquement des sous-éléments lémentaires (c'est-à-dire des éléments enfants contenant uniquement des données), et élément peut être supprimé de la structure ainsi que ses éléments fils ;

- Si l’élément à supprimer contient des éléments qui englobent à leur tour ’autres éléments, dans ce cas uniquement les éléments enfants de l’élément interdit ront supprimés.

ion des données. Elle propose ne structure hiérarchique composée d’un ensemble d’éléments. Nous supposons que

l’élémen

Figure 5.9 Principe de suppression des données

interdits.

En engendrer une destruction entière des ces données. La suppression dnp

éc

dse

La figure 5.9 illustre le principe de la suppressu

t B ainsi que l’élément C sont interdits. Donc les éléments C et F seront supprimés de la branche droite de la structure, l’élément fils F de l’élément B de la branche gauche sera supprimé.

A

B C

D E F

G H

A

B

D

G H

Avant la suppression Après la suppression


b. Masq

un document. Donc la structure xml sera éclatée en deux parties stockées dans deux ents XML. Le document XML qui contenait les données initiales gardera les

dans un second document Ainsi ces données ne sont pas définitivement perdues mais restent

utilisateur dès que ce dernier manifeste sa volonté de les visualiser. Nous pouvons observer deux fonctions de masquage : le masquage total ou

asquage partiel. Le premier type de masquage consiste à prendre du document l’élément non désirable ainsi que tous ses descendants, de les dupliquer dans un

autre document XML et ensuite de supprimer cet élément ainsi que ses descendants du remier document. Le second type de masquage consiste à prendre uniquement l’élément avec ses éléments fils qui contiennent des données, de les ajouter dans un autre document XML, ensuite de supprimer les éléments fils du premier document. De cette manière, les données sont supprimées du document principal et sont copiées dans un second document et destinées à être affichées en cas de besoin.

En pratique, en plus des descendants de l’élément à dupliquer, les éléments ascendants sont également copiés afin de tracer tout le chemin de l’élément inutile

un document xml peut avoir le m

uer (ou cacher) des données Cette tâche consiste à masquer les éléments jugés non désirables ou inutiles. Contrairement à la précédente tâche, elle ne supprime pas les données non valides,

ais elle les extrait du document qui contient les données pour les insérer dans mautre documdonnées utiles. Tandis que la partie inutile sera stockée donneInutile.xmldisponibles à l’

le mXML

p

dès la racine. L’ajout des ascendants est justifié par le fait que ême élément dans différentes branches ou chemins de la structure xml. Pour

ceci, il est nécessaire d’indiquer les parents de chaque élément masqué pour éviter la confusion.

Les figures 5.10 et 5.11 illustrent le principe de deux types de masquage. La première figure concerne le masquage partiel et la deuxième figure concerne le masquage total. Dans les deux figures, à droite, nous avons le document principal avant le masquage et à gauche le résultat après le masquage. Donc dans les deux cas, la structure du document principal est éclaté en deux structures.



Figure 5.10 Principe de masquage partiel des données

A

B C

D E

G H

A

B

FE

Masquage partiel

A

C

F

Document principal

Après le masquage

Document secondaire

Avant le masquage

donnéInutile.xml

B

D

G H


u de définitions sur des termes ou des objets contenus dans le document XML. Ceci peut dépendre du niveau de compétences (ou de connaissances) de l’utili ifique (médical par exemple) ou de sa maîtrise de l’app x le guider dans sa recherche ou son accès à l’information. De ce fait, des informations additionnelles correspondant à des éléments osées dans un nouveau document XML (ajoutInfo.xml). Cette proposition consistera en premier à extraire l’élément qui

A

B C

D E

G H

A

B

Figure 5.11 principe du masquage total

c. Ajouter des données Cette tâche consiste à apporter des informations supplémentaires jugées importantes pour aider l’utilisateur final dans sa navigation. En effet, l’utilisateur pourra avoir besoin d’explications o

sateur dans un domaine spéclication afin de mieu

du document XML (ou objets) seront prop

D

G

E

H

F

Masquage total

A

C

F

Document principal

Avant le masquage Après le masquage

Document secondaire

donnéInutile.xml

demande

. Tous les ascendants de ce dernier seront marqués galement dans la structure du nouveau document XML afin de tracer le

in dès l’élément racine. La figure 5.12 montre la façon dont l’ajout des données est effectué. Cette

xml composée d’un ensemble d’éléments. Nous

s additionnelles. Donc tous les ascendants de D et C doivent être copiés à la nouve

. Modification des données Cette tâche permet de remplacer une donnée par une autre. En effet, on peut avoir

onnées (métadonnées du document XML

re remplacés par A’ et D’. En résultat, le document XML qui a subi des modifications

à être enrichi par des données de la structure initiale du document xml et à l’insérer dans un nouveau document xml en lui ajoutons un nouvel élément qui contiendra les explications souhaitées

échem

figure propose une structure supposons que l’élément C ainsi que l’élément D nécessitent d’être enrichis par des information

lle structure xml. Ensuite des nouveaux éléments D’ et C’ contenant les informations seront ajoutés aux éléments D et C.

Figure 5.12 Principe de l’ajout des données

d

besoin d’apporter des modifications sur les dprincipal) pour réaliser un objectif de personnalisation donné. Par exemple, le terme patient peut être remplacé par le terme malade ou client selon certaines situations. Donc il est intéressant que le système de personnalisation puisse prendre en considération cette tâche de personnalisation. Les modifications sont effectuées sur les données du document principal ce qui n’engendra pas des nouveaux documents. La figure 5.13 illustre le principe de la tâche de modification des données. Cette figure propose une structure XML représentant le document XML principal qui contient les données. Nous supposons que l’élément A et l’élément D doivent êt

A

B C

D E

G H

F

A

B C

D

D’

C’

A

B C

DAjout des donnée

Extraction desdonnées

ajoutInfo.xml


sera affi

ir une action lors de son affichage dans l’interface. A titre d’exemple, une donnée A est affichée dans l’interface avec une zone de saisie qui spécifie que cette donnée peut être modifiée et dans la base de profils, nous avons prélevé que cette donnée est autorisée seulement en lecture. Dans ce cas, la zone de saisie doit être remplacée par une zone de lecture pour empêcher la modification. Toute action sur une donnée doit être indiquée dans un nouveau document (action.xml) à l’aide de l’élément action.

La figure 5.14 illustre le principe de cette représentation. Nous supposons que l’élément D et l’élément E subissent des actions action1 et action2.

ché dans l’interface. Pour ne pas perdre les données initiales du document XML, il sera dupliqué et les modifications s’effectueront sur la version dupliquée.

Document XML après modificationDocument XML

A A’

Figure 5.13 Principe de la modification des données

e. Exécution d’une action sur une donnée Cette tâche a pour objectif de spécifier qu’une donnée peut sub

B C

D E F

BC

FD’ EModification des données


A

B C

D E F

A

B

D E

Action ActionDocument principal

Action.xml

Figure 5.14 Principe de l’exécution d’une action sur une donnée

5.2.4 Synthèse de la personnalisation du contenu

Nous avons décrit dans les sections précédentes le principe de la personnalisation du contenu qui est exécuté par des services. Cette personnalisation s’applique principalement sur les éléments du document xml qui contient la réponse à la requête utilisateur afin de séparer entre les données utiles et celles inutiles. Ce principe de personnalisation se base donc sur la méthode du filtrage qui consiste à comparer entre les éléments objets du profil et ceux du document xml et effectuer les opérations nécessaires au filtrage. Nous avons décrit cinq opérations : suppression des données, masquage des données, ajout des données, modification des données, exécution d’une action sur des données. Ces opérations ainsi que des nouvelles opérations définies à la demande sont développées et stockées dans une librairie dédiée

lors du développement d’un te phase de personnalisation,

ent xml personnalisé ainsi qu’un ensemble de document xml

à l’ensemble des opérations réalisant des tâches de personnalisation. Ainsi service, ces opérations sont appelées. En résultat de cetnous avons un documcontenant des données nécessaires à la réalisation de la phase de la personnalisation de présentation.

5.3 Personnalisation de la présentation

5.3.1 Principe de la personnalisation de la présentation

La personnalisation de la présentation consiste principalement à répercuter le ent du contenu à travers l’interface de l’utilisateur. En effet, cette phase sera

atérialisée par des modifications produites lors de l’affichage des données dans interface. Nous avons vu que le contenu du document XML qui contient des

changemml’



SERVICES

S1, S2, …., Sn

Autres documentsXML

Docupersonnalisé

résentation. Un gestionnaire de la personnalisation de la présentation se charge d’invoquer ces services dédiés à cette phase. En effet, une fois que le gestionnaire de la personnalisation du contenu a fini son traitement voie un code au gestionnaire de personnalisation de la présentation pour qu’il commence son traitement. Ce code doit signifier que la personnalisation du contenu s’est achevée sans erreur et la deuxième ase peut débuter on travail. Ainsi à la réception e ce code, le gestionnaire de cette phase exécute les services de présentation. En résultat, nous avons une interface utilisateur personnalisée, efficace et intuitive. La figure 5.15 illustre le principe de la personnalisation de présentation.

ment XML

données renvoyées en réponse à une requête utilisateur a subi un ensemble de tâchesodifier le contenu de ce

dans des structures xml. Cet état de fait a dre en compte ce changement lors de la présentation du

l. Ce besoin a été notifié à travers des services de

, il en

s

sentation

5.3.2 Fonctionnement de la personnalisation de la présentation

de personnalisation. Ces tâches ont dû mjoindre d’autres informations stockées

document ou y

induit une nécessité de prencontenu du docume xmnt p

ph d

Figure 5.15 Principe de la personnalisation de pré

Le gestionnaire de la personnalisation de la présentation prend en entrée un ensemble de documents XML : le document principal qui contient les données ainsi que d’autres documents additionnels qui contiennent des informations nécessaires à la phase de la personnalisation de la présentation. A partir de ces documents, l’interface de navigation va être personnalisée.

Avant de décrire le processus de la personnalisation de la présentation, nous indiquons que ce processus de personnalisation va intervenir au niveau du code d’affichage des interfaces (ou des écrans) de navigation. Donc le code de la programmation de l’application ne subit aucune modification. En général, l’interface de navigation une application quelconque peut être constituée des fenêtres contenant des dédiées à la formulation des requêtes (zone d’entrée) ou des zones dédiées à l’affichage des résultats des requêtes (zone de sortie). Dans notre

la

dans zones

approche, nous nous intéressons aux zones de sortie. En général, dans ces zones,

réponse à la requête peut être affichée en diff


Fenêtre nom description

Zone nom description

1,*

Fenêtre

Zone

Zone

Commande

Commande

érentes formes d’objets: liste (ordonnée, hiérarchique, etc.), tableau, icônes, toile de topics, etc. En général, tout élément (mot

bjets fait référence à une information (ou ensemble

igure 5.16 Description abstrai nêtre

Ainsi nous pouvons dire que les données destinées à être affichées dans

interface sont présentées dans des zones Z (que nous appelons zone d’affichage). portant

d’identifier les fenêtres F={f1, f2,.., fn} qui contiennent des zones d’affichage, et à m} peuvent être associées. La

clé, symbole, phrase, etc.) de ces od’informations) stockée(s) dans le document xml et destinée(s) à être visualisée(s).

La figure 5.16 illustre une description abstraite des composants d’une fenêtre. Nous avons la fenêtre principale qui englobe un ensemble de zones (entrée ou sortie). En plus d’informations, une zone peut inclure des commandes sous forme de boutons ou des liens de référence sur d’autres fenêtres (ou zones).

F re d’une fe

l’Une fenêtre f peut contenir une à plusieurs zones d’affichage. Ainsi, il est im

chaque fenêtre, un ensemble de zones Z={z1, z2, …, zfigure 5.17 présente une description conceptuelle de la composition d’une fenêtre.

Figure 5.17 Modélisation des composants d’une fenêtre


d’affichage associées. Une fois que ces éléments sont identifiés, la seconde étape concerne le fonctionnement des services que nous détaillerons dans la section suivante.

5.3.2.1. Fonctionnement d’un service de présentation Un service de présentation a pour objectif de réaliser une tâche de personnalisation sur des données contenues dans une zone d’affichage quelconque. Donc un lien de dépendance existe entre les services et les zones d’affichage. Comme les mêmes données personnaliser ces données sera donc appliqué à une à plusieurs zones. Donc s doit être exécuté pour personnaliser Z={z1, z2, ..,zj}. Plusieurs services S={s1, s2, .., sn} peuvent être appliqués sur une même zone z.

Figure 5.18 Relation d’association entre le service et la zone d’affichage

Donc la seconde étape consiste à associer les services aux zones sur lesquelles la personnalisation appliquer. Cette association est représentée dans un document XML (ServiceZone.xml).

Le fonctionnement des services de présentation dépend du fonctionnement des services de contenu. Nous avons vu que ces derniers peuvent générer des données dans des documents XML additionnels destinées à être exploitées dans la deuxième phase pour personnaliser l’interface. En effet, le service du contenu a pour rôle de personnaliser le contenu du document XML qui contient les données. Il ne peut pas intervenir au niveau de l’interface. C’est au service de présentation de finaliser le travail du service du contenu.

Donc la première étape du processus de la personnalisation de présentation consiste à déterminer les fenêtres d’affichage ainsi que les zones

peuvent être affichées dans différentes zones Z, le service s dédié à

Service id

Zone id

estApplique

1,* 1,*

va s’

Figure 5.19 Fonctionnement d’un service de présentation

Objectifs

Document xml

Service Résultats

Zone

Dans la section de personnalisation du contenu, nous avons cité cinq cas les

savoir le masquage des données, l’ajout des données et la suppression des données, la modification des données et

érer deux résultats : modifier la structure du document principal et générer un à plusieurs nouveaux

plus courants de personnalisation du contenu, à

l’exécution d’une action sur une donnée. Ces cas peuvent gén

documents XML. Les services de présentation doivent tenir compte de ces deux conséquences.

En ce qui concerne la première conséquence, les données seront affichées telles quelles dans le document principal. Nous avons vu que la structure du document xml n’a pas subi des modifications. Donc la visualisation des données du document xml dans l’interface ne nécessite pas de traitement. Par contre la deuxième conséquence traitant les nouvelles données stockées dans des documents xml additionnels D doit être considérée. Chaque service concerné par la deuxième conséquence reçoit en entrée l’ensemble des documents D dont il a besoin dans sa tâche de personnalisation sur des zones d’affichage. L’application d’un service s sur une zone d’affichage z en tenant en compte des données contenues dans D donne un résultat de personnalisation en fonction de l’objectif attendu. Un service peut être chargé d’exécuter un à plusieurs résultats. Plusieurs résultats peuvent s’appliquer sur la même zone.

Pour prendre en considération la génération d’un document additionnel, nous proposons un ensemble de possibilités :

Soit D un document qui contient des nouvelles données, z la zone existante sur laquelle le résultat sera appliqué et f la fenêtre qui contient la zone z.



1. création d’une nouvelle zone newZone permettant de visualiser les données contenues dans le document D. Cette zone sera contenue dans une

nêtre newWindow. Cette fenêtre sera ouverte à la demande de eur. Les données contenues dans D seront affichées sous forme

d’une liste telles quelles sont présentées dans le document. 2. Création d’un nouveau s la zone existante z. Ainsi l’utilisateur, en appuyant sur le bouton, peut visualiser le contenu de D affiché dans la nouvelle zone. Ainsi le résultat result est caractérisé par un ensemble de paramètres

= (newBouton, newZone, newWindow). La figure 5.20 illustre l’enchaînement opérations réalisant la personnalisation de présentation dans le cas ou un nouveau

ent est généré.

nction executeResult (D, result=(newBouton, newZone, newFenetre))

CreerZone (D, newZone, newWindow, langage)

}

ts langages (html, java, visual basic, C++, etc.). Ainsi le

t su le nou

de la zone z.

nouvelle fel’utilisat

bouton dan

resultd’docum

fo{ newBouton = creerBouton( newWindow, langage)

Figure 5.20 Algorithme pour affichage du résultat dans une nouvelle zone

L’opération creerBouton fait appel à la fonction qui permet de créer un bouton. Cette fonction est stockée dans la librairie des fonctions. Vu que tous les langages utilisées dans la construction de l’interface peuvent se différer d’une application à une autre, la fonction creerBouton sera développé en plusieurs versions pour prendre en compte les différen

concepteur précise le langage utilisé dans le développement de l’application destinée à être personnalisée et il récupère le nom de la fonction concernée. Ensuite cette fonction sera insérée manuellement dans le code de la zone z pour définir son emplacement.

L’opération creerZone a le même principe que l’opération creerBouton. Plusieurs versions de fonctions sont insérées dans la librairie pour prendre en considération les différents langages de programmation. Cette fonction a pour rôle d’afficher le contenu de D '(structure XML) dans la nouvelle zone. Donc une nouvelle fenêtre est créée avec une nouvelle zone qui contient les données de D. Ainsi en appuyant sur le bouton créé, cette fenêtre s’ouvre

La figure 5.21 illustre le principe de la personnalisation de présentation. Un nouveau bouton est inséré dans la zone existante qui affiche les données. En appuyan

veau bouton, la nouvelle fenêtre contenant une nouvelle zone est affichée. La nouvelle zone doit afficher les nouvelles données associées aux données existantes

Fenêtre f

newFenetre

Zone z

newBouto

Fenêtre existante

Zone

newZone

En cliquant sur le boutonnewBouton, la fenêtrenewFenetre s’affichepour afficher des donnéesdans la nouvelle zone

Z


igure 5.21 Principe de génération d’une nouvelle fenêtre contenant une nouvelle ne

Pour conclure, tout document additionnel sera affiché dans une nouvelle personnalisation

’existe pas dans la librairie, elle sera

manuelle

anuelle de la part du concepteur. Cette intervention consiste ent à l’affichage d’une donnée selon la valeur de l’action.

Soit aff est la forme d’affichage d’origine d’un née. L’application de la ersonnalisation nnée s’effectue en respectant la règle suivante :

Si condition = action alors

ff par aff’

Fzo

fenêtre. Un nouveau bouton sera créé dans la zone concernée par la pour ouvrir la nouvelle fenêtre. Si une fonction ndéveloppée par le concepteur et insérée dans la librairie. Le code du bouton est inséré

ment par le concepteur dans le code de la zone. Cette opération concerne les cas suivants : ajout des données, masquage des données.

En ce qui concerne la modification des données et la suppression des données, la personnalisation est effectuée dans la première phase. La seconde phase affiche uniquement ces données. En principe, les zones existantes s’occupent déjà de ces opérations. Donc aucune considération n’est prise dans cette phase.

Le cas exécution d’une action sur une donnée est un cas qui nécessite une intervention mprincipalem modifier

e donp sur cette do

aff’=appliquerPerso (donnee, action) Un ensemble de règles peuvent être au préalable définies et stockées dans la base de la librairie pour essayer un grand nombre de personnalisation de la présentation et selon le langage utilisé. Ainsi la fonction appliquerPerso récupère la nouvelle forme d’affichage aff’ sur la donnée concernée. Ensuite le concepteur remplace adans les zones concernées. Ce cas n’est pas facile à gérer.

5.3.3 Synthèse de la personnalisation de la présentation

La personnalisation de la présentation a donc pour objectif de compléter le travail des services du contenu afin d’apporter la personnalisation à l’interface.

Pour conclure, nous avons vu que l’interface de navigation est représentée par un ensemble de fenêtres qui affichent des données dans des zones. Une partie de ces zones sert à afficher les données du document principal. Deux cas doivent être pris en considération : la mise en forme des données et l’affichage des données

pplémentaires à la demande de l’utilisateur. La personnalisation de présentation est spécifique à l’application qui exploite l’approche de la personnalisation. Le

les serv épondre au des

données.

su

concepteur, lorsqu’il développe ices, propose la fon qui doit rpte les caractéristiques d’affichage

ction besoin de personnalisation en tenant en com

5.4 Conclusion Ainsi dans ce chapitre, nous avons présenté le fonctionnement de la personnalisation du contenu ainsi que de la personnalisation de la présentation. Ces deux phases de personnalisation ont pour objectif de personnaliser l’information demandée par l’utilisateur afin de lui fournir des données pertinentes qui correspondent à ses attentes et ses besoins.


liquées de Lyon 149

6 personnalisation

on

Implémentation de l’approche de la

6.1 Introducti

Nous avons présenté dans les deux précédents chapitres les modules du système de plémente

mme une sur-couche de n’importe quelle application existante. Elle ne doit en ucun cas s) de cette application. n effet, le processus de la personnalisation intervient au niveau des données et de

Il considère en entrée la réponse à la requête utilisateur. En sortie, interface qui affiche les données est adaptée afin qu’elle puisse prendre en

personnalisation. L’approche de personnalisation que nous proposons s’imcoa modifier le fonctionnement ou les programmes (codeEl’interface. l’considération la personnalisation des données.

Dans ce chapitre, nous présentons l’architecture logicielle de notre prototype. Nous illustrons le fonctionnement de ce prototype à travers une étude de cas basée sur le projet SGI2 en cours d’élaboration.

Nous n’avons pas implémenté tous les aspects étudiés dans cette thèse, notamment ceux liés à l’étude de cas. Cette implémentation est en cours de développement. Dans la section suivante, nous présentons l’architecture logicielle de l’approche. Nous poursuivrons par un exemple d’implémentation de cette architecture.

6.2 Architecture logicielle de l’approche de la personnalisation

L’objectif de l’approche de la personnalisation que nous proposons est de pouvoir offrir à l’utilisateur des informations qui correspondent à ses besoins et à son contexte

n. Les trois premiers modules déclarent des connaissances qui sont

, l’ es re

déc

. Ainsi dans cette approche, les caractéristiques de l’utilisateur ainsi que son environnement lorsqu’il utilise le système sont pris en considération.

Nous avons organisé notre approche en quatre modules : la gestion des profils, la gestion du contexte, la gestion des services, la mise en œuvre de la personnalisatioensuite utilisées dans le module de la mise ne œuvre de la personnalisation.

Comme l’illustre la figure 6.1 implémentation de trois premiers modulpeut êt organis is couches : l’interface, le contrôle, et le stockage :

- L’interface permet de proposer l’arch qui servent à larer les connaissances de ces trois ration facilite

ée en troitecture des écrans modules. Cette opé

Karine ABBAS / Thèse en informatique / 2008 / Institut national des sciences app

considérablement le travail de l’administrateur et (/ou) de l’utilisateur en interagissant directement avec le système.

- La création des classes permet de présenter les classes qui proposent les attributs et les opérations nécessaires à l’


Interface : architecture des écrans

es Création des class

Stockage : Base des connaissances

implémentation de chaque

Figure 6.1 Architecture logicielle en trois couches d’un module

L’avantage de cette organisation en trois couches est double : d’une part elle

chaque couche peut être

aire représenté par un paquetage est proposé afin de gérer le stockage des connaissances. Le diagramme de paquetage regroupe donc :

- Le paquetage ProfilManagement pour gérer les profils rvicesManagement pour gérer les services ntextManagement pour gérer le contexte

module. - Le stockage est destiné à stocker les connaissances dans une base de

connaissance que certains modules génèrent par le biais de l’interface.

permet une partage de responsabilités entre les trois couches, et par la même occasion une réduction de la complexité pour les développeurs, d’autre part

modifier d’une manière complètement indépendante sans avoir besoin de toucher les autres couches.

Le module de mise en œuvre de la personnalisation utilise uniquement la couche contrôle qui définit les classes déclarant les opérations nécessaires à la réalisation de ce module.

L’architecture de la couche contrôle est définie par le biais du diagramme de paquetage qui regroupe l’ensemble des classes comme illustré dans la figure 6.2. En plus des paquetages qui gèrent les quatre modules cités au-dessus, un module supplément

- Le paquetage Se- Le paquetage Co- Le paquetage PersonalisationManagement pour décrire la mise en

œuvre de la personnalisation

- Le paquetage StorageManagement pour gérer les fichiers xml ainsi que les structures stockées dans ces fichiers.

Ce diagramme montre également la relation de dépendance entre ces de la présentation des modules dans

paquetages. Ces paquetages seront détaillés lors les sections suivantes.

Figure 6.2 Diagramme des paquetages de l’approche de la personnalisation

Dans les sections suivantes, nous présenterons la modélisation fonctionnelle des quatre modules du prototype de la personnalisation ainsi que la modélisation de la base de connaissances.

6.2.1 Gestion des profils

Le module de gestion des profils est l’unité principale de l’approche de la personnalisation. Elle modélise et stocke les besoins de la personnalisation, relatifs aux sujets, sous forme de profils. Les connaissances contenues dans ces différents profils vont servir à personnaliser les informations ainsi qu’à adapter l’interface. Rappelons que l’architecture de ce module « gestion des profils » s’organise en trois couches : l’interface, le contrôle et le stockage :

- La couche interface propose un ensemble d’écrans qui servent à créer la structure et le contenu des profils (figure 6.5).


- La couche contrôle est responsable de la gestion proprement dite des du traitement des

che contrôle

e des profils

Couche de création des classes ensemble des cas d’utilisation décrivant les opérations chargées de gérer les profils

1- Mettre à jour un sujet : permet de gérer les sujets, et plus spécifiquement la création et la modification des sujets. La suppression des sujets est incluse dans la modification.

2- Consulter un sujet : permet d’afficher l’ensemble des sujets à partir de la base de connaissances

3- Créer un profil : permet de créer un nouveau schéma xml qui contient la structure du profil relative à un sujet donné. Pour définir un profil, il faut sélectionner un sujet, donc une relation d’extension existe entre ce cas et le cas « consulter un sujet ».

4- Mettre à jour un profil : permet d’ajouter, de modifier ou de supprimer un composant dans la structure d’un profil.

5- Consulter un profil : permet d’afficher la structure d’un profil donné 6- Créer une instance du profil : permet de définir un nouveau propriétaire

d’un profil. Cette instance est créée à partir d’une structure d’un profil déjà définie dans la base de connaissances d’où la relation d’extension entre ce cas et le cas consulter un profil.

7- Mettre à jour le contenu d’un profil : permet d’ajouter un contenu à un attribut simple, de modifier ou de supprimer les contenus ainsi que de modifier le propriétaire du profil.

Trois acteurs sont impliqués dans la gestion des profils : - le concepteur qui s’occupe de la création des profils ainsi que de la

définition des sujets ; - l’administrateur est responsable des cas de mise à jour des profils,

des sujets et des instances ; - l’utilisateur qui intervient uniquement dans la gestion des instances.

structures et du contenu des profils. Elle s’occupe également requêtes utilisateurs adressés à travers l’interface. Autrement dit, la coufixe les méthodes de gestion des profils (figure 6.3).

- La troisième couche, le stockage, s’occupe de la sauvegard(structures et données) dans une base de connaissances (figure 6.12).

6.2.1.1 L’est présenté ci-après (voir figure 6.3):


Figure 6.3 Diagramme des cas d’utilisation

A chaque cas d’utilisation, un ensemble d’opérations sont définies. Ces opérations utilisent les objets définis par des classes. Les cas d’utilisation Mettre à jour un sujet et Consulter un sujet utilisent la classe sujet qui regroupe un ensemble d’opérations responsables de gérer les sujets. Les cas d’utilisation mettre à jour un profil, Consulter un profil et Créer un profil utilisent un ensemble de classes telles que la classe profil, la classe dimension, la classe attribut_complexe et la classe attribut_simple. Ces classes sont responsables de créer un profil et de gérer ses composants. Les cas d’utilisation Créer une instance du profil et Mettre à jour du contenu d’un profil utilisent la classe Contenu qui contient un ensemble d’opérations permettant de créer des instances des profils et de gérer les instances. La figure 6.4


illustre un paprofils.

quetage qui présente l’ensemble des classes utilisées dans la gestion des

Figure 6.4 Paquetage regroupant les classes de gestion des profils


6.2.1.2 Les opérations déclarées dans les classes de paquetage sont gérées directement via une inte

tructure de l’interface et l’enchaînement des écrans qui sont illustrés par l’arborescence suivante :

- Ecran 1 est dédié à l’identification de l’utilisateur de l’unité gestion des profils.

- Ecran 2 est un écran principal qui présente une liste des actions à réaliser. L’utilisateur sélectionne une des actions afin de passer à l’écran suivant. Nous distinguons trois actions : gérer les sujets, gérer les structures des profils et gérer le contenu des profils.

- Ecran 3 est dédié à la gestion des sujets. Dans cet écran, nous pouvons effectuer un ensemble des actions réalisées dans des écrans propres à chaque tâche : 1) Ecran 3a pour ajouter des sujets, 2) Ecran 3b pour afficher des sujets sous forme d’une liste, 3) Ecran 3c pour supprimer un sujet en le sélectionnant dans la liste, 4) Ecran 3d pour modifier des sujets. Lors de l’ajout d’un sujet, nous devons préciser s’il s’agit d’un paramètre du contexte. Si c’est le cas, nous définissons ce paramètre en le sélectionnant à partir d’une liste déroulante qui affiche l’ensemble des paramètres du contexte.

- Ecran 4 est dédié à la gestion des structures des profils. Dans cet écran, nous pouvons sélectionner un ensemble de tâches : créer un profil, afficher un profil et ajouter automatiquement un composant. Les deux premières tâches sont réalisées à travers un ensemble d’écrans (Ecran 6 et Ecran 7) qui sont accessibles en sélectionnant une de ces deux tâches. L’écran 8 est dédié à la réalisation de la

lait

besoin d’

un profil. Pour créer un profil, des dimensions, des attributs complexes ainsi que des attributs simples doivent être

le sujet concerné par ce profil. Donc à partir de cet

rmet d’ajouter des instances dans un

Interface de gestion des profils

rface graphique. A chaque classe, un ensemble d’écrans est proposé. La figure 6.5 illustre l’architecture de l’interface de l’unité « gestion des profils ». Cette architecture fournit la s

troisième tâche qui consiste à insérer une partie d’un profil décrit par un schéma xmdans le profil. Cette insertion est réalisée atiquement sans que l’utilisateur

autom

ajouter manuellement les dimensions et les attributs. Il suffit de préciser que l’insertion sera effectuée comme une dimension ou attribut complexe.

- Ecran 5 est dédié à la création d’

ajoutés après avoir sélectionnéécran5, nous pouvons accéder aux écrans qui peuvent effectuer les actions d’ajout des éléments du profil.

- Ecran 6 est responsable d’afficher un profil donné. Cet affichage concerne la structure du profil. Il permettra de mettre à jour les éléments de ce profil en effectuant des actions des modifications. La suppression des éléments du profil est incluse dans les actions de modification.

- Ecran 7 est dédié à la gestion des instances des profils en proposant cinq écrans : 1) ajouter une instance, 2) afficher les instances, 3) supprimer les instances, 4) modifier les instances. Le premier écran pe


profil dé

nnées dans les attributs simples composa

affichage des instances pour l’ensemble des attributs complexes sous forme d’un tableau. A chaque

on supprimer, modifier est inséré dans

Figure 6.5

arquons que les scénarios « créer un profil », « ajouter automatiquement d’un i génèrent le plus d’opérations. De ce

ensemble des opération

fini pour un propriétaire donné. Trois principales actions sont effectuées dans cet écran: sélection de la structure du profil en choisissant un sujet, sélection d’un propriétaire existant ou création d’un nouveau propriétaire, puis sélection d’un attribut complexe de la structure afin d’ajouter des do

nt cet attribut complexe. Les autres pages permettent de mettre à jour les instances pour un propriétaire donné. Cette mise à jour nécessite un

attribut simple affiché dans ce tableau, un boutla même ligne pour permettre de supprimer (ou modifier) les données contenues dans l’attribut simple en question.

Ecran 1 : accueil Identification

Ecran 2 : gestion des profils

Ecran - -su -

Ecran 7 : gestion du contenu uter des

des

des

3 : gestion des sujets Ecran 4 : gestion des structures Ecran 3a : ajouter des sujets Ecran 3b : afficher des

- Ecran 6 : créer un profil - Ecran 7 : afficher un profil

- Ecran 7a : ajoinstances

jets Ecran 3c : supprimer des

- Ecran 8 : ajouter automatiqued’un composant

- Ecran 7b : afficher instances - Ecran 7c : supprimer instances

Ecran 5 : créer un profil - Ecran 5a : ajouter dimension - Ecran 5b : ajouter attributcomplexe - Ecran 5c : ajouter attribut simple

Ecran 6 : afficher un profil - Ecran 6a : modifier une dimension - Ecran 6b : modifier un attribut

attribut simple complexe - Ecran 6c : modifier un - Ecran 5a : ajouter dimension -Ecran 5b : ajouter attribut complexe

Architecture de l’interface de gestion des profils

En analysant l’ensemble des tâches effectuées dans ces écrans, nous remprofil » et « ajouter un contenu » sont ceux qufait, il est intéressant de décrire ces scénarios afin de découvrir l’

s réalisées en utilisant un diagramme de collaboration. Nous commençons par le scénario créer un profil. Les opérations nécessaires à la création d’un profil sont :


- Sélectionner un sujet : pour chaque sujet, un profil est créé. Donc la première étape de ce scénario est le choix du sujet.

- Créer le profil : une fois que le sujet est sélectionné, le schéma du profil peut être créé avec deux éléments (sujet et profil) et ajouté dans la base de connaissances.

- Ajouter des dimensions : cette opération consiste à définir des dimensions et à les insérer dans la structure du profil déjà créée. Cette opération peut être réalisée en boucle. Plusieurs dimensions peuvent être ajoutées au profil. La validation de cette opération permet de déclencher l’ajout des attributs complexes.

- Ajouter des attributs complexes : Cette opération consiste principalement à définir l’ensemble des attributs complexes qui peuvent composer les dimensions ou les attributs complexes. Donc deux cas sont observés : ajout d’un attribut complexe à une dimension et ajout d’attribut complexe à un autre attribut complexe. Lors du premier cas, la dimension doit être sélectionnée pour qu’elle englobe l’attribut complexe en cours de création. Lors du second cas, le sujet et l’attribut complexe dans lequel il sera inséré doivent être sélectionnés. Une fois que l’élément père est défini, l’attribut complexe est inséré dans le profil, mais après avoir spécifié s’il dépend d’une autre entité du type classe ou paramètre du contexte en définissant le nom de cette entité.

- Ajouter un attribut simple : cette opération consiste à ajouter des attributs simples aux attributs complexes. Cette opération est réalisée dans l’écran 6c. Une fois que l’attribut complexe qui englobera l’attribut simple est sélectionné, l’attribut simple sera défini en spécifiant son type.


Figure 6.6 Diagramme de collaboration décrivant la création d’un profil

Le diagramme de collaboration illustré dans la figure 6.5 décrit l’ensemble des opérations nécessaires à la création d’un profil. L’opération save() sert à sauvegarder les objets ajoutés dans le profil déjà défini dans la base de connaissance. Les écrans servent à déclencher les opérations.

Figure 6.7 Ecran utilisé pour créer un profil

profileEcran

:dimensionEcran

profil

attributComplexeEcran attribut_Complexe

attribuSimpleEcran

6.ajouterAttComplexe(nom)

3 saveProfil()

8.ajouterAttSimple(nom)

stokage

4. aouterDimensions(nom)

1 :selectionnerSujet()2.creerProfil()

5. saveDimenion()

7. save ()

attribut_Simple

9 save()

dimension


La figure 6.7 illustre une fenêtre de création d’un profil. Cette fenêtre

comporte un ensemble de composants : la colonne de gauche sert à créer un profil. La création est opérationnelle lorsque nous sélectionnons un sujet et nous appuyons sur le bouton créer profil. Cette opération va déclencher automatiquement l’ajout d’une dimensio

nom de la dimension dans le champ de saisie. Cet écran donne la possibilité d’insérer

ajout automatiquement des composants au profil. E

lectionner le type de l’élément qui englobera le schéma S dans le

’insertion automatique du schéma

lesquels la structure du schéma sera insérée. Dans la partie droite de l’écran, nous

n dans la colonne droite de la fenêtre. Pour ajouter une dimension, il faut saisir le

plusieurs dimensions à la fois qui sont insérées à la suite dans une liste. Pour insérer toutes les dimensions de la liste, il faut appuyer sur le bouton valider. Ainsi un profil est créé afin de décrire le sujet sélectionné.

Le deuxième scénario concerne l’n effet, nous avons vu dans le chapitre précédent que tout nouveau besoin

peut être traduit dans un schéma xml. Ce schéma sera ensuite inséré dans un profil donné P. Cette insertion peut être observée comme une nouvelle dimension ou un sous-élément d’un élément du profil du type dimension ou attribut complexe. Donc les opérations de ce scénario sont les suivantes :

- afficher le schéma S - sélectionner le profil - sé

profil - déterminer l’élément - insérer le schéma S

La figure 6.8 illustre le digramme de collaboration d’insertion automatique du schéma xml dans le profil. Cette insertion est effective dans une dimension déjà existante dans le profil.

Figure 6.8 Diagramme de collaboration d

2. selectProfil() 3. choisirTypeElement() 4.selectDimension()

insertEcran

schema insertSchema 1.afficherSchema()

La figure 6.9 illustre l’écran d’insertion automatique du schéma dans un profil. Cet écran est composé de deux parties. La partie gauche est consacrée à l’affichage du schéma. La partie droite est consacrée à la définition des éléments dans

profil

5.insererSchema()


sélectionnons le profil, nous spécifions le type de l’élément qui contiendra le schéma, nous choisissons le nom de cet élément puis nous validons l’insertion.

F ion d profil igure 6.9 Ecran d’insert u schéma xml dans le

profprof les éléments du profil sont affichés, nous pouvons choisir le

psimp

La figure 6.10 illustre tion d il donné. La première action consiste à sélectionner le su d iil. Une fois que

le diagramme de collabora e l’instanciation d’unjet afin ’aff cher le

pro riétaire de cette instance du profil et insérer des données dans les attributs les.


Fig me de collaboration d’ins profils

L’instanciation ée à l’aide d’une interface graphique. Les auteurs qui sont chargés de l’instanciation des profils n’ont pas besoimanipuler directement le ntenant les instances. L’interface permet de les actions nécessaires à l’ ise à jour de ces instances. La figure 6.11 montre le principe d’instanciation via l’interface. La fenêtre

divisée en deux parties : la fenêtre gauche et la fenêtre droite. Dans la fenêtre ir de cette

lection, la structure du profil est affichée. A coté de chaque attribut complexe, un bouton a

ples.

me de collaboration d’ins profils L’instanciation ée à l’aide d’une interface graphique.

Les auteurs qui sont chargés de l’instanciation des profils n’ont pas besoimanipuler directement le ntenant les instances. L’interface permet de les actions nécessaires à l’ ise à jour de ces instances. La figure 6.11 montre le principe d’instanciation via l’interface. La fenêtre

divisée en deux parties : la fenêtre gauche et la fenêtre droite. Dans la fenêtre ir de cette

lection, la structure du profil est affichée. A coté de chaque attribut complexe, un bouton a

ples.

ure 6.10 Diagram0 Diagram tanciation des tanciation des des profils est effectudes profils est effectu

n de n de s documents xml cos documents xml co

réaliser toutes réaliser toutes instanciation et à la minstanciation et à la m

est est gauche, nous sélectionnons le sujet à partir d’une liste déroulante. A partgauche, nous sélectionnons le sujet à partir d’une liste déroulante. A partsésé

dd est affiché. En appuyant sur ce bouton, la liste des attributs simples de l’attribut complexe concerné est affichée dans la fenêtre droite. Donc la fenêtre droite sert aux opérations de saisie. Dans cette fenêtre, nous allons pouvoir définir le propriétaire ainsi que les valeurs des attributs sim

dd est affiché. En appuyant sur ce bouton, la liste des attributs simples de l’attribut complexe concerné est affichée dans la fenêtre droite. Donc la fenêtre droite sert aux opérations de saisie. Dans cette fenêtre, nous allons pouvoir définir le propriétaire ainsi que les valeurs des attributs sim

profil instanceProfilEcran

InstanceProfile

3. defineOwner () 4.createProfileInstance ()8. ajouterData()

Stokage

9.Save ()

1. selectSujet() 2. getProfile()

Attribut_complexe

5. selectAttributComplexe()6.ListerAttributSimple()


Figure 6.11 Ecran illustrant l’instanciation des profils

Stockage des profils Nous avons la

tructure des profi dans d schémas xml et les instances des profils contenues dans des documents xml. Pour stocker les profils, nous créons un

knowledgeManagement dans la même machine et dans le même répertoire ù l’approche de la personnalisation est déployée. Dans ce répertoire, nous créons un pertoire : profileManagement. Dans ce répertoires, nous créons trois sous-pertoires : profileStructure, profileInstances, subjectManagement. Le sous-pectoire profileStructure sera destiné à stocker les structures des profils. Le

même no

6.2.1.3 Les profils sont stockés dans une base de connaissances. vu que s ls est exprimée essont répertoire orérérédeuxième sous-répertoire stocke les instances des profils. Chaque document a le

m que le sujet pour lequel le profil est créé. Supposons que le sujet est utilisateur, donc le document sera nommé utilisateur.xml. Le troisième sous-répertoire est destiné à stocker le document xml (subject.xml) qui gère les sujets. La figure 6.12 illustre l’architecture de la couche de stockage des connaissances des profils.


Répertoire : Knowledgemanagement

Répertoire : profileManagement

Répertoire : Répertoire : Répertoire :

Subject.xml

Figure 6.12 Stockage des profils

.2.1.4 Déploiement du module gestion du profil pplication Intranet ce qui

et a

rtory)qui contiendra les pages HMTL et un répertoire (phpRepertory) pour

6Le module de gestion des profils sera déployé comme une aperm ux utilisateurs y accéder quelque soit leur localisation. Les écrans seront conçus en HTML et les opérations seront développées en langage PHP. Dans la machine qui déploie ce module, nous créons un répertoire général (personnalisationApplication) qui contiendra l’implémentation de tous les modules de l’approche de la personnalisation. Dans ce répertoire, nous créons un répertoire

lRepe(htmstocker les fichiers php.

6.2.2 Gestion du contexte

Le module de gestion du contexte permet principalement de gérer les paramètres du contexte. Cette opération s’appuie sur une classe Context contenant les opérations qui permettent d’ajouter, de supprimer et de modifier des paramètres du contexte. Ces paramètres doivent être les mêmes que la couche de gestion du contexte utilise dans le stockage de la situation contextuelle de l’utilisateur. Nous rappelons que la couche de gestion du contexte a pour objectif de capturer et interpréter le contexte de l’utilisateur que nous avons déjà décrit dans le chapitre et de le stocker dans un document xml. Dans notre travail, nous nous basons sur les travaux de [CHA 07] qui permettent de récupérer des valeurs des paramètres du contexte. A partir de ces paramètres utilisés dans le document xml pour caractériser une situation contextuelle,

classe Context est initialisée. Donc le module de gestion du contexte est modélisé par un seul cas

utilisation « gérer le contexte » qui implémente quatre opérations :

la

d’


- ajouter un paramètre du contexte - modifier un paramètre - supprimer un paramètre - afficher les paramètres

Figure 6.13 Diagramme de classes du paquetage contextManagement

ce graphique qui propose un

es du contexte, nous utilisons un document XML

Ces opérations sont gérées à travers une interfaécran pour chaque opération.

Pour stocker les paramètrcontext.xml qui est stocké dans un répertoire contextManagement qui est créé dans le répertoire knowledgeManagement. Ce même répertoire stocke également le document xml qui caractérise la situation contextuelle de l’utilisateur courant.

Nous utilisons le langage HTML pour concevoir les écrans de l’interface et le langage PHP pour développer le programme qui gère le contexte.

6.2.4 Gestion des Services

A l’image du module de gestion des profils, l’architecture de gestion des services s’organise en trois couches : (I) l’interface qui consiste à créer les services ainsi qu’à les mettre à jour, (II) le contrôle qui implémente l’ensemble des cas d’utilisation qui gère les services et (III) le stockage des services.

La figure 6.14 illustre le diagramme de cas d’utilisation. Ce diagramme propose trois cas d’utilisation : créer un service, associer un service à un profil et

. Le premier cas concerne la création des services. Lors de cette création, les

nis. Le second cas décrit l’association d’un service

mettre à jour d’un service

composants d’un service sont défi


à un profil. En effet, une fois qu’un service est créé, il doit être affecté à un

ilisation associer un service à un profil, nous observons les opérations suivantes :

l composant de ce profil (dimension ou attribut

omplexe)

Diagramme des cas d’utilisation La figure 6.15 présente le diagramme de paquetage de gestion des services.

gérant les ents des profils.

composant d’un profil. Ce composant peut être soit une dimension, soit un attribut complexe. Le troisième cas s’occupe de la mise à jour des services, à savoir la modification et la suppression des services.

A chaque cas d’utilisation correspond un ensemble d’opérations implantant le cas d’utilisation. Pour le cas d’utilisation créer un service, nous avons l’opération : - créer un service s ; - définir les paramètres d’entrée et de sortie liés au service s.

Pour le cas d’ut

- sélectionner profi - sélectionner un c - associer à un profil

Pour le cas d’utilisation mettre à jour d’un profil, nous distinguons les opérations suivantes :

- modifier un service ; - supprimer un service ; - afficher les services.

Figure 6.14

Ce paquetage regroupe une classe service qui contient les opérations services et leur association avec des élém


Figure 6.15 Digramme de paquetage des se

rvices

odule.

Ces trois cas sont gérés via une interface graphique. Chaque opération est figure 6.16 montre l’architecture des écrans de ce gérée par le biais d’un écran. La

m


Ecran 1 : gestion des services - création d’un service - mettre à jour des services

Ecran 2 : créer un service Ecran 3 : mettre à jour des services - Ecran 3a : af icher desservices - Ecran 3b : m unservice

f

odifier

Figure 6.16 Architecture d’écrans du module de gestion des services

Le stockage des services est effectué dans un répertoire serviceManagement l. Le premier fichier est

escription sur chaque service créé. Le second fichier concerne l’

Figure 6.17 Stockage des services dans la base de connaissances

qui contient deux fichiers : services.xml et associeProfil.xmconsidéré comme un registre qui contient une d

association entre les services et les profils. Le répertoire serviceManagement est créé dans le répertoire knowledgeManagement. La figure Figure 6.17 illustre le stockage de ce processus.

Ecran 4 : associer unservice à un profil

Ecran4 : definir les paramètresd’entrées et les paramètres desortie

Répertoire : KnowledgeManagement

Répertoire : serviceManagement

services.xml associeProfil.xml


Pour déployer le processus de gestion des services, nous utilisons le langage HTML pour créer les écrans, le langage PHP pour développer les opérations citées précédemment. Pour le développement des services, nous utilisons le langage java.

6.2.5 Mise en œuvre de la personnalisation

La mise en œuvre de la personnalisation a pour objectif de réaliser les tâches de la personnalisation décrites dans les services afin de proposer une information pertinente en tenant en compte des données définies dans les profils et de la situation contextuelle de l’utilisateur. Ce module se base sur l’utilisation des éléments définis lors des sections précédentes et en particulier les profils et les services.

Le processus de mise en œuvre de la personnalisation est réalisé en deux étapes : 1) la sélection des profils valides et 2) l’exploitation des services. Chaque étape est représentée par un cas d’utilisation comme illustré dans le diagramme de la Figure 6.18. Un acteur moral gestionnairePersonnalisation est impliqué dans la réalisation de ces cas d’utilisations.

Figure 6.18 Diagramme des cas d’utilisation

Le cas d’utilisation sélectionner des profils valides a pour objectif de fil valide qui

orrespo e tilisateur lorsqu

il faut avoir la situati

sélectionner parmi les profils de la base de connaissance le proc nd à la situation contextuelle d l’u ’il ouvre une session.

Le cas d’utilisation exploiter les services consiste à extraire les services qui sont associés aux composants du profil valide, à ordonner ces services puis à les exécuter.

Lorsque l’utilisateur envoie sa requête, le gestionnaire de la personnalisation déclenche le processus de personnalisation. Au préalable on


contextuelle stockée dans la base de connaissance. Ensuite il faut obtenir la liste des profils (désignant les structures) contenus dans la base de connaissance. Pour chaque profil, il vérifie si le sujet dépend du contexte. Dans ce cas, un sous-profil, dont le contenu de l’attribut proprietaire est égal au contenu du paramètre du contexte, est extrait du document xml qui correspond au profil.

La seconde étape de ce cas d’utilisation consiste à comparer les attributs complexes du sous-profil afin de ne garder que ceux qui contiennent des valeurs correspondants au contenu de la situation contextuelle. En final, le sous-profil sera inséré dans un document xml temporaire.

Figure 6

ent xml dédié à l’association entre les à ces éléments. La deuxième étape

de la phase auxquels ils appartiennent (phase 1

qui caractéri

classifier les services ; - ordonner les services ;

personnalisationManager contexte 1.getContext()

6.selectionProfilValide() 8.compareAttributContext() 9.deleteAttributNoValide() 10.insertProfilValide()

Attribut_complexe

7.isDependOnContext()

.19 Diagramme de collaboration décrivant la sélection des profils

Une fois le profil valide extrait, le gestionnaire de la personnalisation extrait les services qui sont associés aux composants du profil valide. Cette extraction est réalisée en extrayant les éléments désignant les dimensions et les attributs complexes

profil et en sélectionnant à partir du documdu services et les profils, les services associés consiste à classifier les services en fonction

et phase 2). Ensuite dans chaque classification, les services sont ordonnés en fonction de l’ordre déjà attribué à chaque service. Au final, les services sont invoqués dans chaque classification. Donc nous distinguons un ensemble d’opérations

sent le cas d’utilisation exploiter les services : - extraire les services ; -

profil

3.ListerP fils()

ro

2.[situation contextuelle]

4.[profils]

sujet

5. isDependOnContext()


- exécuter les services.

Figure 6.20 Diagramme de collaboration décrivant le scénario d’invocation des services

Le paquetage personnalisationManagement illustré dans la Figure 6.21 permet d’implémenter le processus de mise en œuvre de la personnalisation en proposant la classe personnalisationManager qui regroupe l’ensemble des opérations nécessaires à l’implémentation de ce processus.

Ce paquetage utilise les opérations de la classe profil du paquetage profilManagement et de la classe context du paquetage contextManagement ainsi que les opérations de la classe services.

personnalisationManager dimension

Attribut_complexe

2.getDimension()

1.getProfilValide() 6.classifyService() 7.ordonnerService() 8.invoquerService()

3.getAttributCompexe()

service

4.extractService()

5.[services]


Figure 6.21 Diagramme de classes du paquetage personnalisationManagement

6.2.6 Gestion de la base de connaissance

La base de connaissances contient les fichiers qui gèrent les profils, le contexte et les services. Ces fichiers sont stockés dans des documents xml. Cette unité a donc pour objectif de gérer ces fichiers ainsi que le contenu de ces fichiers, à savoir les métadonnées et les données. En effet, lors de la mise en œuvre de la personnalisation, la base de connaissance peut être sollicitée pour réaliser des actions sur les fichiers et leur contenu. Donc il est important de définir l’ensemble des opérations que la base de connaissance va subir. Ces opérations seront définies dans deux classes stockage et dataManagement qui sont organisées dans un paquetage stockageManagement illustré dans la Figure 6.22.


Figure 6.22 Diagramme des classes de paquetage stockageManagement

6.2.7 Conclusion

Dans les sections précédentes, nous avons pu proposer l’architecture logicielle de l’approche de la personnalisation. Cette architecture comporte deux parties : la gestion des éléments (profils, contexte et services) intervenant dans le processus de la personnalisation et la mise en œuvre de la personnalisation en utilisant les éléments déjà définis dans la première partie. Nous avons proposé l’ensemble de paquetages ui regroupent des opérations dans des classes. q

L’implémentation de cette architecture n’est pas finalisée. Pour tester le fonctionnement de cette architecture sur une application, nous proposons dans le section suivante une étude de cas afin d’illustrer l’utilisation de cette approche sur

une application manipulant des données médicales.

6.3 Scénario générique d’utilisation du système de personnalisation

Pour rales diff

ppeler la stratégie de la personnalisation, nous décrivons dans ce paragraphe érentes étapes nécessaires à l’exploitation du système de la personnalisation


que noapplication quelconque est effectuée en deux parties : 1 - défi

ls les profils sont

à l’exécution de la personnalisation.

t l’ajoute à la librairie. Une fois un service développé, il

2 – me définis : la mise enl’utilisaun ense ons :

le gestionnaire sélectionne, à partir des profils déjà définis dans la base de connaissances, le profil valide qui correspond au contenu de la situation contextuelle. 2.3 le gestionnaire sélectionne les services qui correspondent aux éléments du profil valide. Puis il les classe en deux groupes et invoque leur exécution.

us proposons. L’implémentation d’un scénario de personnalisation dans une

nir les éléments nécessaires à l’exploitation de la personnalisation : 1.1 définir les paramètres du contexte : la première étape consiste à définir à l’aide de l’interface les paramètres du contexte qui sont utilisés par le système. L’instanciation de ces paramètres définit la situation contextuelle de l’utilisateur. 1.2 définir les profils : le concepteur définit les besoins en terme de personnalisation. Il détermine les sujets pour lesqueproposés. Ensuite il modélise ces besoins et les représente dans un schéma XML pour ensuite être intégrés dans les profils. Une fois les structures des profils définies, les données peuvent être définies. Le concepteur, l’administrateur et l’utilisateur final peuvent être chargés de définir les données dans le cadre de leurs droits d’accès respectifs. 1.3 développer les services : le concepteur se charge d’identifier et de développer les services nécessaires Certaines fonctionnalités sont récupérées à partir de la librairie qui contient des fonctions déjà proposées pour d’autres applications. En cas du besoin d’une nouvelle fonctionnalité, le concepteur développe cette fonction à l’aide du langage JAVA eest associé à un élément d’un profil. ttre en œuvre de la personnalisation en utilisant les éléments déjà œuvre de la personnalisation est déclanchée lorsqu’une requête est lancée par teur. Cette action sollicite le gestionnaire de la personnalisation pour exécuter mble d’opérati2.1 le gestionnaire demande de connaître la situation contextuelle de l’utilisateur qui est stockée en principe dans un document XML. 2.2

6.4 Application au projet SGI2

Pour tester le fonctionnement de cette approche de personnalisation, nous comptons l’implémenter sur le projet SGI2 en cours d’élaboration. Ce projet a pour objectif rincipal de fournir une sémantique partagée (ontologie) entre les utilisateurs des stèmes d’informations médicales initialement hétérogènes. Il propose un médiateur

psy


(appelé Dossier Unifié Virtuel (DUV)) entre les producteurs d’information et les d’information et de présenter ces données selon une vue unique et

résente l’architecture du système de médiation sémantique. En implémentant le système de personnalisation sur le projet, le concepteur peut améliorer le fonctionnement de ce projet en gérant des nouvelles dimensions de

droit d’accès, les préférences et les compétences ce qui

utilisateurs chronologique.

Figure 6.23 Architecture du Middleware sémantique: SGI2

La Figure 6.23 p

personnalisation telles que lepermettra à l’utilisateur final d’accéder à des informations pertinentes de manière intuitive et transparent.

6.5 Conclusion

Ainsi dans ce chapitre, nous avons pu décrire la composition de l’architecture approche de la personnalisation. Nous avons proposé une étude de cas

illustrer l’implémentation de cette architecture. Le projet SGI2 est en cours de stème proposé sera intégré dans ce projet.

logicielle de l’pour réalisation. Le sy

Schéma unificateur :

Dossier Virtuel Unifié

(DVU)

Objet complexe

Objet simple

Classe d’objets

Point de vue communication

Objet

SI2 : Producteur D’information

SI1 : Producteur D’information

Utilisateur

March April May1 2 3130 1 2 3029 10

R P

V V

B H PR P

V V

B H P

Carte d’Informations Iconisées CI2

Base de documents

March April May1 2 3130 1 2 3029 10 Selon des

Politiques De droit

Implémentation del’approche de lapersonnalisation

Interface Utilisateur


Chapitre 7 Conclusion


7 Conclusion

Ce chapitre établit un bilan du travail effectué et pose les perspectives qui en découlent.

7.1 Bilan du travail réalisé

L’origine de ce travail de thèse partait d’un constat simple à savoir : La croissance considérable de volume des données ainsi que la diversité des besoins des utilisateurs rendaient l’accès à une information pertinente de plus en plus difficile. Nous avons vu qu’un utilisateur, en recherchant une information, est submergé par des données pas forcément toutes intelligibles. Donc il existait un réel

vasifs qui offrent aux utilisate

a été proposé dans ce mémoire dont les contributions s’articul

(v) mise en ouvre de la personna

t le système. La majorité des systèmes de perso

besoin de personnaliser l’information recherchée par l’utilisateur en fonction de ses attentes et ses préférences. Ce besoin de personnalisation a été accentué par le large développement des systèmes per

urs mobiles un accès à des informations quelque soit la localisation et le dispositif. Devant cet état de fait, il était nécessaire de proposer un système de personnalisation qui tenait en compte à la fois des besoins de l’utilisateur en terme de personnalisation et du contexte d’utilisation.

A partir de la problématique exposée ci-dessus, un système de personnalisation

ent autour de six axes de travail interconnectés : - La conception d’une architecture générique de personnalisation capable

d’offrir les moyens et les outils nécessaires pour réaliser l’ensemble des besoins en terme de personnalisation. Cette architecture est basé sur cinq modules : (i) gestion des profils, (ii) gestion du contexte, (iii) gestion des services, (vi) exploitation des profils dans le processus de personnalisation et

lisation. - La prise en considération du contexte d’utilisation qui a certainement de

l’influence sur l’interaction entre l’utilisateur ennalisation s’était focalisée sur l’utilisateur en négligeant le contexte de

l’utilisateur. Or avec l’avancée technologique des systèmes mobiles, des nouveaux défis sont apparus et en conséquence des nouvelles solutions devaient être proposées pour couvrir toutes les facettes de la personnalisation.

- La proposition d’une vision générique et évolutive du modèle du profil qui laisse la possibilité d’intégrer facilement des nouveaux besoins de personnalisation en tenant en compte du contexte de l’utilisateur.

- L’adoption du principe des services pour réaliser les objectifs de la personnalisation ce qui permet de renforcer la vision générique des profils. Les


services dans notre système sont développés de manière indépendante sous forme de programmes autonomes ce qui facilite leur maintenance et leur évolution.

- La définition d’une stratégie de personnalisation appliquée sur les données renvoyées pour répondre à la requête de l’utilisateur et sur la présentation de ces

endante du domaine de l’application sous forme d’une surcouche logicielle aussi bien sur une application existante que sur une nouvelle application. Dans ce travail, nous avons développé ce système pour personnaliser des

stème ouvre des nouvelles es d’application : services web, données multimédia,

7.2

données dans l’interface de l’utilisateur final. - Le développement et l’implémentation du système de personnalisation de

manière indép

données textuelles. Mais la vision générique de ce syperspectives à d’autres domaindomaine collaboratif, ressources. Ce système de personnalisation sera testé sur le projet SGI2 qui a pour objectif d’offrir une vue homogène des données réparties dans une interface intuitive et conviviale.

Perspectives

Nos prod’améliosystèmepersonna

1

utomatiques qui permettent de mettre à jour sont basées sur le principe

stème et d’exprimer ces stème consistent à réaliser

positions ouvrent plusieurs perspectives de recherche qui permettent rer en général la personnalisation de l’accès à l’information dans les

s d’information et en particulier le fonctionnement de notre approche de lisation :

) Mise à jour automatique des profils La mise à jour des profils est réalisée manuellement dans notre système de personnalisation. Or, il existe des techniques utilisant des méthodes d’apprentissage aautomatiquement les profils. Ces techniquesd’observation du comportement de l’utilisateur lorsqu’il utilise le système. Par ailleurs, des formulaires doivent être conçues et proposées aux utilisateurs pour qu’ils puissent définir leurs attentes en terme d’affichage des informations. Il est intéressant pour l’utilisateur qu’il puisse participer au fonctionnement du sypréférences. Les prochaines étapes de ce syces deux tâches.

2) Utilisation des techniques de services web Des techniques employées dans la mise en place des services web peuvent être adoptées pour améliorer l’implémentation des services proposés dans le système de personnalisation. Ainsi, l’utilisation de ces services peut être facilitée et déployée par différents plateformes


es utilisés dans ces profils. t des systèmes de

texte, organiser le ositionnement des objets de l’interface, la structure de l’interface, etc.).

Par ailleurs, les services qui gèrent la personnalisation sont développés e manière indépendante dès qu’un nouveau besoin apparaît. Donc, il ’existe pas un moyen de semi-automatiser le développement des services n proposant des fonctionnalités génériques à définir et intégrer dans les ervices. Cette tâche doit être réfléchie et prise en considération dans les rochains travaux de ce système de personnalisation.

3) Proposition d’une ontologie Il est important de proposer une ontologie générale aux profils. Ainsi lors de la définition des profils, les termes proposés sont choisis à partir du vocabulaire de cette ontologie. Elle permet également de rechercher des orrespondances sémantiques entre les termc

Jusqu’au présent, tous les travaux en général qui proposenpersonnalisation basés sur des profils emploient des termes propres en fonction de ses besoins. Cette diversité de modèles de profils rend leur application à d’autres domaines une tâche quasi-impossible. Donc, la proposition d’une ontologie répond à cette problématique et rend l’adoption d’une partie ou de la totalité d’un modèle de profil proposé par un système de personnalisation donné une tâche possible. 4) Amélioration de la personnalisation de la présentation La personnalisation de la présentation dans notre système dépend de la personnalisation du contenu. Cette personnalisation concerne essentiellement la présentation des informations personnalisées dans l’interface de navigation. Aucune adaptation, proprement dite, de l’interface n’est prévue dan ce système. Donc il est intéressant d’enrichir et d’approfondir cette personnalisation des outils qui permettent de ersonnaliser également l’interface (mise en forme du p

p

dnesp


Biblio aphie gr[AMA 99] g and

applications to digital libraries”, Proceedings of the 3rd

[AMO 03] ompositional Software Agents, in proceedings of

the international Conference on Web Engineering – ICWE

[ANL 05a]

On Human-Computer, Universal Access in Human-Computer Interaction, Las Vegas,

[ANL 05b] pes et architecture pour la personnalisation d'information en interaction homme-machine,

conference on Francophone sur l'Interaction Homme-Machine, September 2005

[BAR 00]

[BOU 04] Bouzeghoub M., personnalisation de l’information, AS98 /

[BOU 05] l’art et définition dun

modèle flexible de profils, Actes de la 2ème conférence en

[BRA 00] Bradley K., Rafter R., Smyth B., Case-Based User Profiling for

Amato G., Staraccia U., “User profile modellin

European Conference on Research and avanced technology for digital libraries, p. 184-187, 1999.

Amor M., Fuentes L., Troy J.M., Putting Together Web Services and c

2003, Oviedo, Spain, July 2003, LNCS 2722, pp 44-53

Anli, A., Grislin-Le Strugeon, E. and Abed, M. A Generic Personalization Tool based on a Multi-Agent Architecture. 11th International Conference

juillet, 2005.

Anli, A. Kolski C., Abed M., Princi

application à l'information transport Proceedings of the 17th international

Barra M., Distributed Systems for Group Adaptivity on the web. Proc. Conference on Adaptive Hypermedia and Adaptive Web-based Systems, Trento, 2000

RTP9, 2004

Bouzeghoub M., Kostadinov D., personnalisation de l’information : aperçu de l’état de

recherche d’informations et applications CORIA’2005, Grenoble, France, 2005

Content Personalisation, In: Proceedings of the International


Conference on Adaptive Hypermedia and Adaptive Web-based Systems, Trento, Italy, August 2000

[BRU 98] Brusilovsky P. Eklund L. Schwarz E. Web-based Education for

[BRU 01] Brusilovsky P. Adaptive Hypmedia. User modelling and User

[BRU 02]

[BUR 02b] Burke R., « Hybrid Recommender Systems: Survey and

[CAB 06] Julien, C. Validation sociale d’annotations collectives : argumentation

[CHA 04] Chaari T., Laforest F., Génération et adaptation automatiques

[CHA 05] Chaari, T., Laforest, F., Flory, A., « Adaptation des

mai – 3 juin 2005, Grenoble, France, pp. 111-118.

all: A tool for development adaptative courseware. In Seventh International World Wide Web Conference. 1998

Adapted Interaction, 2001. 11:p.87-110

Brusilovsky P., Mark T. Maybury. From adaptive hypermedia to the adaptive web. Communications of the ACM, vol. 45, no. 5 p.p. 30–33, 2002.

Experiments », Journal of Personalization Research, User Modeling and User-Adapted Interaction, vol. 12 (4), 2002.

Cabanac, G., Chevalier, M., Chrisment, C., et

bipolaire graduelle pour la théorie sociale de l’information. Dans INFORSID’06 : 24e congrès de l’INFormatique des Organisations et Systèmes d’Information et de Décision, pages 467–482. Éditions Inforsid.

[CAN 02] Canny J., « Collaborative filtering with privacy via factor analysis », Proceedings of the 25

th International Conference on

Research and Development in Information Retrieval (SIGIR’02), Aug 11-15, 2002, Tampere, Finland.

des interfaces utilisateurs pour des environnements multi-terminaux. Revue Ingénierie des Systèmes d'Information, n° spécial Systèmes d'information pervasifs, vol 2, 2004.

applications au contexte en utilisant les services Web », In : Coutaz, J., Lecomte, S.(Eds.), Actes des deuxièmes journées francophones : Mobilité et Ubiquité 2005 (UbiMob'05), 31


[CHA 07] Chaari, T., Ejigu, D., Laforest, F., Scuturici, V..M., 2007. A Comprehensive Approach to model and use Context for adapting Applications in Pervasive Environments. Int. Journal of Systems and Software, Elsevier.

003.

[COM 06] ta, Proceedings of the 2006 ACM symposium on Applied

[CON 02] Conlan O., Dagger D., Wade V. Towards a Standards-based

217, September 2002.

ide Web Conference, Fortec Seminars, 1999

[DOU 04] Dourish, P., « What we talk about when we talk about context

[CHE 03] Chevalier, M. et Julien, C. Interface adaptative et coopérative pour l’aide à la Recherche d’Information sur le Web. Information - Interaction - Intelligence, 3(2) :47–73, 2

[CHI 04] Chinnici R., Gudgin M., Moreau J.-J., Schlimmer J., Weerawarana S., “Web Services Description language (WSDL) Version 2.0 Part 1: Core Language”, W3C Working Draft, August 2004.

[CHO 02] Chomicki J., Querying with Intrinsic Preferences, In: Proceeding of the 8th International Conference on Extending Database Technology, Prague, Czech Republic, 2002

Combi C., Oliboni B., Conceptual modeling of XML da

computing, SESSION: Database theory, technology, and applications (DTTA), 467 - 473, 2006, Dijon, France

Approach to e-Learning Personalization using Reusable Learning Objects. In Proceedgins of the World Conference on E-Learning in Corporate, Government, Healthcare and Higher Education (E-Learn 2002), P.p. 210–

[DEA 99] Dean J. Henzinger, M.R. Finding related pages in the World Wide Web, In Proceeding of WWW-8, the Eight International World W

[DEY 00] Dey A.K., G. D. Abowd. Towards a Better Understanding of Context and Context-Awareness. CHI 2000 Workshop on the What, Who, Where, When, and How of Context-Awareness, The Hague, The Netherlands, 2000.

», Personal and Ubiquitous Computing, vol. 8, n° 1, 2004, pp. 19-30.


[ELK 03]

Based Access Control. IEEE 4th International Workshop on Policies for Distributed Systems and Networks

[FIN 00] sis of Commercial User Modeling Servers for Personalization on the World Wide

[FIN 02] tours, Artificial intelligence review, 18(1):33-74, September

[FRA 01] n

ion Systems (ADBIS 2001), LNCS 2151, Vilnius, Lithuania, September 25-28, 2001, pp. 323-337.

[FRA 02]

national Conference on Adaptive Hypermedia and Adaptive Web-Based

[GAL 03] s Systèmes de Filtrage Collaboratif

», Manifestation de Jeunes Chercheurs STIC (MAJESTIC’03),

[GAR 00] d Spatial Filtering in an Adaptive Information System, in Adaptive

2000.

A. Abou El Kalam, R. El Baida, P. Balbiani, S. Benferhat, F. Cuppens, Y. Deswarte, A. Miège, C. Saurel et G. Trouessin Organization

(Policy 2003), Lake Come, Italy, June 4-6, 2003.

Fink J. & Kobsa A., A Review and Analy

Web, International Journal of User Modeling and User-Adapted Interaction, 10, Kluwer Academic Publishers, 2000, pp. 209-249.

Josef Fink, A. Kosba, User modelling for personalized city

2002

Frasincar F., Houben G-J. & Vdovjak R., A RMM-Based Methodology for Hypermedia Presentation Design, Proceedings of the 5th East European Conference on Advances in Databases and Informat

Frasincar F. & Houben G-J, Hypermedia Presentation Adaptation on the Semantic Web, in de Bra P., Brusilovsky P. & Conejo R., (Eds.), Proceedings of the 2

nd Inter

Systems (AH 2002), Malaga, Spain, May 29 - 31, 2002, LNCS 2347, 2002, pp. 133-142.

Gallardo-Lopez L., Berrut C., Denos N., « Une approche pour le contrôle de la qualité de

Oct 29-31, 2003, Polytechnique de Marseille, France.

Garlatti, S. and S. Iksal, Concept Filtering an

Hypermedia and Adaptive Web-Based Systems, P. Brusilovsky, O. Stock, and C. Strapparava, Editors. 2000, Springer Verlag: Trento. p. 315-318,


[GOW 03] Gowan J.P, A multiple model approach to personalised information access, Thesis of Master in Computer Science, faculty of Science, University College Dublin, 2003

-Computing Interaction, vol. 16, n° 2-4, 2001, pp. 269-286.

[HAN 01]

[HAR 92] HARMAN D., Relevance feedback revisited, Proceedings of

[HAR 05]

ht, The Netherlands, July 25-29, 2005, ACM Press, p. 222-229.

[HEN 02]

S 2414 - First International Conference inPervasive Computing

ût2002, Springer-Verlag, pp. 167-180.

[HWA 02] y book recommendations ICADL 2002 : international

conference on Asian digital libraries No5, Singapore ,

[INF 04]

[GRU 01] Grudin, J., « Desituating action: digital representation of contexte », Human

Han B., Student Modelling and Adaptivity in web based Learning Systems. Master’s thesis, Massey University/New Zealand, 2001.

ACM SIGIR 1992

Harvey, T., Decker K., Carberry, S., « Multi-Agent Decision Support Via User Modeling ». In proceedings of the 4th Int. Conference on Autonomous Agent and Multi-Agent Systems AAMAS 2005, Utrec

Henricksen, K., Indulska, J., Rakotonirainy, A., « Modeling context information in pervasive computing systems », In : Mattern, F., Naghshineh, M., (Eds.), LNC

(Pervasive’2002), Zürich, Switzerland, ao

HWANG S-Y. ; LIM Ee-Peng ; A data mining approach to new librar

SINGAPOUR 2002, vol. 2555, pp. 229-240,

Info Quest http://www.Infoquest.com, 2004

Jain A. K., Murty M. N., Flynn P. J., « Dat[JAI 99] a Clustering: A Review », ACM Computing Surveys, vol. 31 (3), 1999, p.264-

[JER 01] à la recherche et `a l’interrogation de bases documentaires,

323.

Jeribi, L., Rumpler, B., et Pinon, J.-M. (2001). Système d’aide


fondé sur la réutilisation d’expériences. Dans INFORSID’01 : 19e congrès de l’INFormatique des Organisations et Systèmes d’Information et de Décision, pages 443–463.

[KAP 00]

ovember 13-16, 2000.

[KAS 05]

le de filtre détecteur de nouveauté » Actes de CORIA 2005,

[KAY 00] Modeling for Adaptation,P.p. 271–294. Human Factors Series. Lawrence

[KEI 04] Keidl M., Kemper A., Towards Context-Aware Adaptable web

[KIE 02] Kießling W., Foundations of Preferences in Database Systems, In

[KIM 02] im. Personalization: Definition, Status, and Challenges ahead. Journal of Object Technology, vol. 1, no. 1 p.p. 29–40,

[KIN 03] International Journal of

Information Systems in Education, vol. 1, no. 1 p.p. 22–31,

[KLY 04] Klyne G., Reynolds F., Woodrow C., Ohto H., Hjelm J., Butler

Kappel G., Retschitzegger W., & Schwinger W., Modeling Customizable Web Applications - A Requirement's Perspective, in Proceedings of the International Conference on Digital Libraries, (ICDL 2000), Kyoto, Japan, N

Kassab, R., Lamirel, J.C., Nauer, E., « Une nouvelle approche pour la modélisation du profil de l'utilisateur dans les systèmes de filtrage d'information basés sur le contenu : le modè

Grenoble, France, 9- 11 mars, 2005, p. 185-200.

Kay J., User Interfaces for All, chapter User

Erlbaum Associates, Inc.,2000. http://www.cs.usyd.edu.au/~judy/Homec/Pubs/ch18.pdf.

Services, In proceedings of the 13th World Wide Web Conference, New York, USA, May 17-22, 2004.

Proceedings of the 28th Conference on Very Large Data Bases, Hong Kong, China, 2002

Won K

2002.

Kinshuk and Taiyu L. User Exploration Based Adaptation in Adaptive Learning Systems.

2003.

M.H., Tran L., “Composite Capability/Preference Profiles


(CC/PP): Structure and Vocabulaires 1.0”, W3C Recommendation, January 2004.

[KOB 01] Kobsa A., Generic User Modeling Systems, User Modeling and

[KOC 00] Reference Model, Modelling Techniques and

Development Process, Ph.D Thesis, Fakultät der Mathematik

[KOI 04] Koutrika G., Ioannidis Y., Personalization of Queries in

[KOS 03] Kostadinov D, Personnalisation de l’information et gestion des

[LEM 04] ma T., « Architecture de négociation et d'adaptation de Services Multimédia dans des Environnements Hétérogènes »,

[MAR 00] Martin H. & Lozano R., Dynamic Generation of video

User-Adapted Interaction, v.11 n.1-2, p.49-63, 2001

Koch N., Software Engineering for Adaptative Hypermedia Systems –

und Informatik, Ludwig-Maximilians-Universität München, December 2000.

Database Systems, In: Proceedings of the 20th International Conference on Data Engineering, Boston, Massachusetts, USA, April, 2004

profiles utilisateurs, Mémoire de DEA, PRiSM, Versailles, 2003

Lemlou

Thèse de Doctorat, Institut National Polytechnique de Grenoble, Grenoble, France, avril 2004.

[LIE 95] Lieberman H., Letizia : An Agent that Assists Web Browsing . In Proceedings of International Joint Conference on Artificial Intelligence (IJCAI’95), pages 924–929, Morgan Kaufmann, 1995.

[MAL 02] Malik A., Building XML Schemas in an Object-Oriented Framework, IBM developer works, 2002.

abstracts using an object-oriented video DBMS, Networking and Information Systems Journal, Special Issue on Video Data 3(1), Hermes, 2000, pp. 53-75.


[MIL 04]

, (2004) 437-476,

ligence Review, vol. 19, 2003, Kluwer Publishers, p.285-330.

[MOS 04] puting: a guide for the pervasive computing

community », Proceedings of the IEEE/ACS International

[NIC 01] . 5, n° 2, pp. 18-26, 2001

rvices, in Jeckle M. & Zhang L-J (Eds.), Proceedings of the International Conference Web

[PAS 03] Pashtan A., Kollipara S., Pearce M., « Adapting Content for

[PAW 04] Pawlak Z., « Some Issues on Rough Sets », Transaction on

[PER 03]

[POO 03] POO D., Chang B., Goh J., A Hybrid Approach for User Profiling, 36 th Annual Hawaii International Conference on System Sciences (HICSS03)- Track 4, January 06-09, 2003

Miller, B. N., Konstan, J. A., and Riedl, J.: PocketLens: Toward a Personal Recommender System. ACM Transactions on Information Systems 22

[MON 03] Montaner M., López B., De La Rosa J. L., « A Taxonomy of ecommender Agents on the Internet », Artificial Intel

Mostéfaoui, K., Pasquier-Rocha, J., Brézillon, P., « Context-aware com

Conference on Pervasive Services (IPCS’04), IEEE Computer Society, 2004, pp. 39-48.

Z. Z. Nick, P. Themis, Web Search Using a Genetic Algorithm, IEEE Internet Computing, vol

[OZT 04] Ozturk M., Alexis T., Vincke P., Preference Modeling. Kluwer Academic, Dordrecht (2004). Also DIMACS technical report 34 (2003)

[PAQ 03] Paques H., Liu L., PU C., Adaptation Space : A design Framework for Adaptive Web Se

Services – ICWS-Europe 2003, Erfurt, Germany, September 2003, LNCS 2853, pp 49-63

Wireless Web Services », IEEE Internet Computing, Volume 7, Issue 5, Sept-Oct 2003, pp. 79-85

Rough Sets I, LNCS 3100, 2004.

Perugini S., Gonçalves M. A., Fox E. A., « A Connection-Centric Survey of Recommender Systems Research », Journal of

Intelligent Information Systems, vol. 23 (1), 2003.


[RAA 02] Raad H. & Causse B., Modelling of an Adaptive Hypermedia System Based on Active Rules, in Cerri S.A., Gouardères G. & Paraguaçu F. (Eds.), Proceedings

th of the 6 International

Conference on Intelligent Tutoring Systems (ITS 2002),

[RIC 99] 99 (Ré-édition

d’un article de 1981), pp. 323-338.

[ROL 00] s

International Forum cum Conference on Information

[ROU 02]

01, 2002, Melbourne, Victoria, Australia

e de positionnement universel ? », In : Coutaz, J., Lecomte, S.

[SAN 96] Sandhu R., Coyne E.J., Feinstein H.L., Role based access

[SCH 94] EEE Workshop

on Mobile Computing Systems and Applications, Santa Cruz,

[SHA 00] ing Their Normal Behaviour”. In

Proceedings of the 2000 International Conference on

Biarritz, France and San Sebastian, Spain, June 2-7, 2002, LNCS 2363, 2002, pp. 149-157.

Rich E., Users are individuals: individualizing user models, Int Journal on Human-Computer Studies, 51, 19

Rolland C., Information Systems and Web Information Systems: A Methodological Perspective, Proceeding

Technology and Communication at the Dawn of the New Millennium, Bangkok, Thailand, August 2000.

Routledge N., Bird L., Goodchild A., UML and XML schema, Proceedings of the 13th Australasian database conference, p.157-166, January

[SAM 05] Samama, N., Vervish-Picois, A., Fraçois, M., « La localisation en intérieur à l'aide de répéteurs GPS : vers un systèm

(Eds.), Actes des deuxièmes journées francophones : Mobilité et Ubiquité 2005 (UbiMob'05), 31mai – 3 juin 2005, Grenoble, France, pp. 21-28.

control models, IEEE Computer, 29, (2), pp.38-47, 1996.

Schilit, B.N., Adams, N., Want, R., « Context-Aware Computing Applications », Proceedings of the I

USA, décembre 1994, pp. 85-90.

Shavlik J., Goeks J., “Learning Users' Interests by Unobtrusively Observ

Intelligent User Interfaces, New Orleans 2000.


[SHA 03] aches, Databases in networked

Information Systems, 3rd International Workshop, 2822 5:15,

[SOL 04]

[STE 98a] C., Adaptable

and adaptive user interfaces for disabled users in AVANTI

Services, Antwerp, Belgium, 25-28 May 1998, LNCS 1430,

[STE 98b] is D. & Sfyrakis M., Self-Adapting Web-based Systems: Towards Universal

[TAM 06] imensionnel de l’utilisateur », Actes de CORIA 2006,

Lyon, France, 15-17 mars, 2006, p. 225-236

[TRO 99] ment à partir de cas pour l'aide à la navigation

dans un hypermédia , In proceedings of Hypertexte &

[TUR 01] tigny, Suisse, 29 Mai – 1 Juin, 2001,

pp. 281-299.

[TUR 02] independence of the methods from the schema, in proceedings

C.Schahabi, Y.S. Chen, Web Information Personalization : challenges and appro

Japan September 2003

Solworth J.A., Sloan R.H., Security Property Based Administrative Controls. In Proceedings of the 9th European Symposium on Research in Computer Security(ESORICS 2004), September 2004.

Stephanidis C., Paramythis A., Sfyrakis M., Stergiou A., Maou N., Leventis A., Paparoulis G. & Karagiandidis

Project, in Triglia S., Mullery A., Campolargo M., Vanderstraeten H. & Mampaey M. (Eds), Proceedings of the 5

th International Conference on Intelligence in Services and

Networks (IS&N’98), Technology for Ubiquitous Telecom

Springer-Verlag, Germany, 1998, pp. 153–166.

Stephanidis C., Paramythis A., Akoumianak

Accessibility, Proceeding of the 4th Workshop on User Interface For All, Stockholm, Sweden, 19-21 October, 1998.

Tamine, L., Bahsoun, W., « Définition d’un profil multid

Trousse B., Jaczynski M., Kanawati R., Une approche fondée sur le raisonne

Hypermedia : Products, Tools and Methods (H2PTM'99), Paris, 1999.

Turki S., Introduction aux hyperclasses, Actes du XIXe Congrès Inforsid, Mar

er

Turki S. & Léonard M., Hyperclasses: towards a new kind of


of the 4th

International Conference on Entreprise Information Systems (ICEIS'2002), Volume 2, Ciudad Real, Spain, April 3-6, 2002, pp. 788-794.

[VAS 03]

n Research 13, (2003) 179-210, DOI: 10.1023/A:1024072706526.

[VIL 02] de

l’accès progressive », Thèse, Institut National Polytechnique

[VIR 05a] or content adaptation in web-based information systems, In IFIP TC8

[VIR 05b] ontext-aware adaptive information system. In OTM

Workshop on Context-Aware Mobile Systems, 2005

[VRI 03] dimensional framework for user models, In Proceedings of the

[VRI 04] Vrieze P., Bommel P.V., Klok J., Weide T., adaptation in

[WEB 01] odelling, User Modeling and User-Adapted Interaction,

2001

[W3C 98]

C-CSS2 [denier accès le 15 janvier 2008]

[W3C 99] HTML Specification version 4.01, W3C Recommendation,

Vassileva, J., McCalla, G., and Greer, J.: Multi-Agent Multi-User Modeling in I-Help. User Modeling and User-Adapted Interaction: The Journal of Personalizatio

Villanova-Oliver, M., « Adaptabilité dans les systèmes d’information sur le Web : modélisation et mis en oeuvre

de Grenoble, Grenoble, Décembre 2002.

De Virgilio R., Torlone R., An extensible technique f

Working Conference on Mobile Information Systems, 2005

De Virgilio R., Torlone R., Management of heterogeneous profiles in c

Vrieze P., Bommel P.V., Klok J., Weide T., Towards a two-

MAWIS03 workshop attached to the OOIS03 conference, Geneva 03

multimedia systems, Multimedia Tools and Applications, 2004.

Webb I., Geoffrey M.J.P. and billsus D., Machine Learning and User M

World Wide Web Consortium, Cascading Style Sheets, level 2, CSS2 Specification, W3C Recommendation, May 12, 1998. http://www.w3.org/TR/RE

World Wide Web Consortium, HyperText Markup Language,


December 24, 1999. http://www.w3.org/TR/html4/ [dernier accès le 15 janvier 2008]

[W3C 01] World Wide Web Consortium, eXtensible Stylesheet Language, XSL Specification – version 1.0, W3C Recommendation, October 15, 2001. http://www.w3.org/TR/xsl/ [dernier accès le 15 janvier 2008]

W3C http://www.W3C.com (2004) [dernier accès le 15 janvier 2008]

[W3C 04]

[WEX 97] Wexelblat A. et Maes P., Footprints : Visualizing Histories for

Internet (RIAO’97), Centre des hautes études internationales

[WOO 95]

[YUD 05] Yudelson, M., Gavrilova, T., Brusilovsky, P., «Towards User

nedin, New Zealand, Pages: 23 - 23 , 2004

[WEI 03] Weibelzahl S., Evaluation of Adaptive Systems. PhD thesis, University of Trier, 2003. http://www.easy-hub.org:8000/stephan/ weibelzahl03-diss.pdf [dernier accès le 30 octobre 2007]

Web Browsing . In Actes de la 5ème conférence sur la Recherche d’Information Assistée par Ordinateur sur

d'Informatique, Montréal, pages 75–84, 1997.

Wooldridge M., Jennings N., “Intelligent Agents: Theories, Architectures, and Language ”. Springer-Verlag, 1995

Modeling Meta-ontology ». In proceedings of the 10th Int. Conference on User Modeling UM 2005, Edinburgh, Scotland, UK, July 24-29, 2005, LNCS 3538, Springer-Verlag, p. 448-452

[ZHA 04a] Zhang Y., On conceptual modelling and design of role-based access control systems, Proceedings of the first Asian-Pacific conference on Conceptual modelling - Volume 31, Du

[ZHA 04b] Zhang M., Yao J. T., « A Rough Sets Based Approach to Feature Selection », The 23rd Conference of the North American Fuzzy Information Processing Society, Canada, 2004.


http://www.easy-hub.org:8000/stephan/

[ZHU 05] Zhu T., Greiner R., Haubl G., Price B., Jewell K, Behavior-based recommender systems for web content. In IUI ’05: Proceedings of the 10th international conference on Intelligent user interfaces. Workshop: Beyond Personalization 2005, New York, NY, USA, 2005. ACM Press.

01] Zuckerman I., Predictive Statistical Models for user modelling, User Modeling and user-adapted interaction, 11: 5-18, 2001

[ZUG


système d’accès personnalisé à l’information :...

Documents