Vous êtes sur la page 1sur 74

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE

Faculté génie électrique et informatique


Département informatique

Université Mouloud MAMMERI de Tizi-Ouzou

Mémoire de licence

Présenté par
Mlle LADJIMI DJAMILA

Mlle HADJ AHMED DJOUHAR

Thème
Calcul d’indicateurs à base de trace
Pour l’adaptabilité

Proposé et encadré par :

Mme AIT ADDA SAMIA

Année Universitaire 2009/2010


Remerciements

Avant tout, nous tenons à remercier le Bon Dieu pour le courage, l’aide et la patience
qu’Il nous a donné pour mener ce projet à terme.

Nous remerciement vont aussi à nos très chers parents aux quel on doit beaucoup et
sans eux ce présent travail ne serait jamais abouti.

Que notre enseignante et promotrice Mlle Samia AIT ADDA trouve ici, l’expression
de notre large reconnaissance. Nous voudrons la remercier particulièrement de nous avoir fait
découvrir un domaine de recherche très intéressent que le« traçage des interactions utilisateur
système ». Nous la remercions aussi pour ces innombrables remarques, son aide et sa
gentillesse. Qu’elle sache que nous gardons d’elle vivace image d’une personne possédant un
large spectre de savoir duquel on a beaucoup appris. En toute sincérité nous a honorés.

Nous remercions très respectueusement les membres du jury d’avoir accepter


d’évaluer notre travail.

Enfin, que tous ceux qui ont contribué de prés ou de loin à l’accomplissement de ce
travail, trouvent ici l’expression de nos très profonds respects.

1
Dédicaces

Je dédie ce travail avec considération et respect


à tous ceux que j’aime et j’apprécie

A mes très chers parents

A la mémoire de mon cher et tendre frère

A mon frère et ma sœur

A ma copine Farida et à toute sa famille

A tous mes amis

A toute ma famille

Djamila.

2
Dédicaces

Je dédie ce travail avec considération et respect


à tous ceux que j’aime et j’apprécie

A mes très chers parents

A mes frères et mes sœurs

A mes très chers neveux Elyas, sara, Serine, Adem et


Agnes

A ma copine Djamila et à toute sa famille

A tous mes amis (Nassima, Naima, Razika…)

A toute ma famille

Djouhar.

3
Sommaire

Sommaire

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


Chapitre1 : Modélisation de l’utilisateur

1. Introduction ....................................................................................................................... 3
2. Définition de la modélisation d’un utilisateur ................................................................. 3
3. Pourquoi modéliser l’utilisateur ? ..................................................................................... 5
4. la personnalisation et l’adaptation .................................................................................... 5

4.1. Définition de la personnalisation .............................................................................. 5

4.2. Définition de l’adaptation .......................................................................................... 6

4.3. Différence entre Adaptation et Personnalisation ....................................................... 6

4.4. Méthodes et techniques d’adaptation ........................................................................ 6

1. Les méthodes et les techniques de présentation adaptative ..................................... 7


a) Méthodes ............................................................................................................. 7
b) Techniques ........................................................................................................... 7
2. Les méthodes de navigation adaptative .................................................................. 8

5. Quelques modèles utilisateur ............................................................................................ 9

5.1. Le modèle Munich ..................................................................................................... 9


5.2. Le modèle INT .......................................................................................................... 9
5.3. Le modèle AHAM ....................................................................................................... 9
5.4. Le modèle musette ................................................................................................. 10
6. Modélisation utilisateur et personnalisation ................................................................... 11
7. Conclusion ..................................................................................................................... 12

Chapitre 2 : Les traces et les fichiers logs

1. Introduction ..................................................................................................................... 13
2. Traces ............................................................................................................................. 13

4
Sommaire

2.1. A la recherche d’une définition .................................................................................. 1


2.2. Types de systèmes qui tracent les interactions utilisateur système .......................... 1
2.2.1. Systèmes utilisant l’histoire interactionnelle sans la présenter aux utilisateurs
.................................................................................................................................................. 15
2.2.2. Systèmes présentant une visualisation de l’histoire interactionnelle destinée à
l’analyste de la situation ........................................................................................................... 15
2.2.3. Systèmes présentant une visualisation de l’histoire interactionnelle destinée à
l’utilisateur et lui proposant la possibilité d’y naviguer .......................................................... 16
2.2.4. Systèmes présentant une visualisation de l’histoire interactionnelle pour
l’utilisateur et proposant la possibilité d’agir dessus .............................................................. 16
2.3. Métacognition et réflexivité .................................................................................... 17
2.3.1. Concept de métacognition .............................................................................. 17
2.3.2. La réflexivité .................................................................................................. 17
2.4. Raisonnement à partir de l’expérience tracée ......................................................... 18
2.4.1. De la nature des traces d’interaction : niveau d’abstraction des informations
tracées .................................................................................................................................... 18
2.4.2. Raisonner à partir de l’expérience tracée ....................................................... 19
2.4.2.1. Principe général du Raisonnement à partir de l’Expérience
Tracée (RàPET) ........................................................................................................................ 19
2.4.2.2. Liens avec le raisonnement à partir de cas ............................................... 20
2.5. Définition d’un indicateur ....................................................................................... 20
3. Fichier log ..................................................................................................................... 21
3.1. Définition ................................................................................................................ 21
3.2. Le contenu d’un fichier log .................................................................................... 21
3.2.1. Les logs de transferts .............................................................................................. 22

3.2.2. Les logs d’erreurs ................................................................................................... 22

3.2.3. Les logs référentiels ............................................................................................... 22

3.2.4. Les logs d’agent .............................................................................................................. 22


3.3. Utilité des fichiers logs .............................................................................................................. 22

3.4. Quelques formats de fichier log ..................................................................................... 23

3.4.1. Le format W3C Etendu (Word Wide Web Consortium) ................................... 24

3.4.2. Le format log commun .......................................................................................... 24

5
Sommaire

3.5.Les logiciels d'analyse de fichier log ...................................................................................... 24


3.6.Les problèmes liés aux fichiers logs ....................................................................................... 25

4. Conclusion ..................................................................................................................... 25
Chapitre3 : Etude conceptuelle du système

1. Introduction .................................................................................................................... 26
2. Présentation du projet ..................................................................................................... 26
3. L’architecture générale de la solution ........................................................................... 26
4. Identification des besoins ............................................................................................... 31
4.1. Identifier les acteurs ................................................................................................ 32
4.2. Les messages acteurs ............................................................................................... 32
4.3. Identification de cas d’utilisation ............................................................................ 32
4.4. Diagramme et description de cas d’utilisation ....................................................... 33
4.5. Diagramme de séquence système ........................................................................... 34
4.6. Elaboration du diagramme de classes ..................................................................... 35
5. Conclusion ..................................................................................................................... 36

Chapitre 4 : La réalisation
1. Introduction .................................................................................................................. 37
2. Description de l’environnement de développement ..................................................... 37
2.1 . Aspect matériel ....................................................................................................... 37
2.2. Aspect logiciel : ........................................................................................................ 37
2.2.1. Langage et outils de programmation .............................................................. 37

2.2.2. Système d’exploitation .................................................................................... 37

3. Présentation du logiciel LOG ANALYZER ........................................................................ 38

3.1. Interface de démarrage ............................................................................................. 38


3.2 . La boite de dialogue d’ouverture d’un fichier .................................................................. 39
3.3. Interface principale .................................................................................................. 40
3.4. Interface d’information sur l’internaute ................................................................. 41
3.5.Interface la liste des pages consultées ..................................................................... 43
3.6. Interface d’affichage de fichier log .......................................................................... 44
3.7. Interface la fréquence............................................................................................... 44
3.8. Interface heure durée .............................................................................................. 45

6
Sommaire

4.Conclusion ...................................................................................................................... 46

Conclusion générale ............................................................................................................... 47

Références bibliographiques ................................................................................................. 48

Annexes ................................................................................................................................... 52

7
Liste des figures

Liste des figures

Figure 1 : Positionnement de la personnalisation par rapport à l'adaptation ............................. 6


Figure 2: Modélisation utilisateur et mécanismes de personnalisation ................................... 11
Figure3: Le processus générale de gestion de trace .................................................................... 14
Figure 4 : Architecture générale du système ........................................................................... 27

Figure 5 : Mode de collecte de trace ............................................................................................ 28


Figure 6 : Extrait de fichier XML .................................................................................................... 30
Figure 7: Digramme de classe du Modèle d’indicateur ................................................................ 31
Figure 8: Diagramme principal de cas d’utilisation ................................................................. 33

Figure 9 : Diagramme de séquence pour le cas d’utilisation .................................................. 35

Figure 10 : Diagramme de classes ........................................................................................... 36


Figure 11 : Fenêtre De Démarrage ........................................................................................... 38
Figure 12: fenêtre de la boite d’ouverture d’un fichier log ...................................................... 39
Figure 13 : Fenêtre de la boite d’information .......................................................................... 40

Figure14 : Fenêtre principale .................................................................................................. 40

Figure15 : Fenêtre Information Sur L’internaute ................................................................... 42

Figure 16 : Fenêtre La liste Des Pages Consulter ................................................................... 43

Figure 17 : Fenêtre de La Fréquence d’utilisation des pages ................................................. 44


Figure 18 : Fenêtre Affichage ficher log .................................................................................. 45

Figure 19: Fenêtre heure durée de consultation des liens ........................................................ 46


Figure 20 : Extrait de fichier log ............................................................................................. 57

8
Liste des tableaux

Liste des tableaux

Tableau 1 : Tableau descriptif du fichier XML........................................................................ 30


Tableau2 : tableau descriptif de cas d’utilisation ................................................................... 3 3

9
Introduction générale

10
Introduction générale

Introduction générale
Utilisateur ou non d’Internet, chaque citoyen est aujourd’hui repérable par les données
qu’il laisse, ou que d’autres laissent sur lui, à travers quantité de dispositifs : page web, cartes
à puce, courriels, moteurs de recherche, etc. Ces traces emmagasinées par les réseaux
constituent un objet scientifique en même temps qu’un enjeu stratégique pour les États
comme pour les entreprises. Les sciences de la communication étudient l’usager à travers ses
pratiques, ses représentations et ses statistiques d’audience, et ceux, pour une éventuel
amélioration de outils manipulés et les services offerts.
Donc, l’objectif de notre travail, qui s’inscrit dans cadre générale, consiste en la
modélisation de l’interaction d’utilisateur du web à base de trace, en vue d’amélioration et une
préalable adaptation, qu’il soit du contenu, de navigation ou de présentation.
L’étude d’interaction se fait à l’aide d’une source de traçage, qui enregistre les traces
d’utilisations sous différentes formes la plus concrète, celle nommée « fichier log ».
Les fichiers logs sont en générale du texte brute difficile à comprendre et analyser par
n’importe quelle personne qu’elle soit novice en informatique ou non. Donc pour faciliter
leurs manipulations et interprétations, une analyse à l’aide d’un programme « logiciel
d’analyse des logs » est nécessaire, pour leur donner une sémantique selon le domaine
d’utilisation.
C’est dans ce cadre, que s’inscrit notre projet de licence, qui a pour thème « calcule
d’indicateur à base de trace pour l’adaptabilité ». Donc, grâce au langage java, nous allons
concevoir un produit portable avec une interface graphique conviviale, souple et simple,
permettant aux utilisateurs une manipulation facile de trace et ceci grâce aux calcule
d’indicateurs (chapitre 2).
Le présent document est un rapport traitant les différentes étapes de développement de
l’application. Il est structuré en trois parties principales:
La première, constituée des chapitres 1 et 2 donne un état de l’art sur la modélisation
de l’utilisateur en vue d’une adaptation, les traces de ce dernier et les fichiers logs.
Dans la seconde partie (chapitre 3), nous effectuerons une étude conceptuelle du
système à développer. Cela consiste entre autre en l'identification des acteurs et des
fonctionnalités à leur fournir et les choix de l'environnement de travail.
Enfin, la dernière partie (chapitre 4) est un rapport sur l'implémentation des besoins
identifiés durant l'étude conceptuelle. Des annexes ont été ajoutées afin d'apporter de plus
amples informations sur certains points décrits dans le rapport.

11
Chapitre1: Modélisation de l’utilisateur

12
Chapitre1 Modélisation de l’utilisateur

Chapitre1

Modélisation de l’utilisateur

1. Introduction :
Les informations fournies sur Internet sont présentées de la même manière pour tous
les utilisateurs même s’ils ne sont pas intéressés par les mêmes informations. Alors, il faut
trouver une solution pour fournir les informations adaptées aux besoins de l’utilisateur. Les
situations proposées permettent donc aux utilisateurs d’Internet d’accéder à l’information
pertinente, de naviguer dans un grand espace d’information sur Internet.
Le Web sémantique et les méthodes d’adaptation/personnalisation permettent de résoudre ces
problèmes, et donc nécessite de modéliser de l’utilisateur.
Dans ce chapitre nous présentons le principe de modélisation de l’utilisateur,
pourquoi modéliser ce dernier, en suite on va définir l’adaptation et la personnalisation et
pour finir on va citer quelques modèles existants.

2. Définition de la modélisation d’un utilisateur :


Pour arriver à définir la modélisation de l’utilisateur nous devons d’abord définir
quelques concepts :
2.1. Le modèle : un modèle est un synonyme de la théorie, mais avec une connotation
pratique, un modèle va nous servir à communiquer et échanger des points de vue afin d’avoir
une compréhension commune et précise d’un même problème.
2.2. La modélisation : Ce n’est donc rien d’autre que la pensée organisée en vue d’une
finalité pratique .La modélisation est une opération par laquelle on établit un modèle d’un
phénomène afin d’en proposé une représentation interprétable, reproductible et simulable.
Donc la modélisation de l’utilisateur est la description aussi complète et fidèle que possible
de tous les aspects relatifs aux comportements de l’utilisateur, d’où l’un des objectifs de cette
modélisation est de pouvoir personnaliser les réponses de système à cet utilisateur.

En 1983, Elaine RICH [14] distingue différentes manières de modéliser l’utilisateur :

13
Chapitre1 Modélisation de l’utilisateur

 modèle explicite / implicite ;


 modèle individuel / stéréotype / générique ;
 modèle à court terme / long terme / statique / dynamique ;
Les modèles implicitement codés sont les modèles utilisateurs types insérés par le
concepteur dans le système tandis que les modèles explicites codent les informations acquises
à propos de l’utilisateur dans un module séparé. Les modèles implicites se basent sur une
classification des utilisateurs. Il faut, alors, poser les bonnes questions à l'utilisateur ses
préférences et ses connaissances pour l'affecter à une des classes. Cependant, comme le
souligne Rich [15], les individus ne sont pas des sources fiables d’informations à propos
d’eux-mêmes. De plus, les modèles implicites sont difficiles à modifier quand une nouvelle
information sur l’utilisateur est mise en valeur comme étant une meilleure alternative.

Le modèle explicite de l’utilisateur où le comportement et les préférences de


l’utilisateur sont également représentés mais selon les spécifications de l’utilisateur. Par
exemple, lorsque l’utilisateur visualise un document, il faut qu’il indique son opinion sur le
degré de pertinence du document par rapport à sa requête.
Le modèle générique suppose une population homogène d’utilisateurs ; c’est-à-dire
que tous les utilisateurs d’une même classe générique sont traités de la même façon. Le
modèle individuel essaie de modéliser l’information spécifique à chaque utilisateur. Le
modèle stéréotype se situe entre ces deux modèles. Si le stéréotype est activé par des actions
de l’utilisateur, celui-ci sera activé dans son intégralité même si le déclencheur ne concerne
qu’un aspect particulier du stéréotype.

Les modèles à long terme gardent uniquement les caractéristiques stables de


l’utilisateur tandis que les modèles à court terme conservent le but courant de l’utilisateur.
Nous pouvons, aussi, distinguer les modèles statiques, qui resteront les mêmes durant toute
une session, des modèles dynamiques qui changent durant les sessions en fonction des actions
de l’utilisateur.

3. Pourquoi modéliser l’utilisateur ?


Les travaux de modélisation de l’utilisateur cherchent à découvrir des motifs
récurrents de navigation sur un site donné. Les applications sont essentiellement orientées
vers :

14
Chapitre1 Modélisation de l’utilisateur

 La conception pour l’amélioration de l’architecture et de l’ergonomie d’un site.


 L’analyse de la fréquentation des rubriques les plus visitées et la segmentation des
sessions par type de visite. Les sites à vocation commerciale souhaitent disposer de
données les plus précises possibles sur leur fréquentation, afin de savoir quelles pages
sont les plus visitées, comment les utilisateurs y arrivent, et comment les faire « rester
» plus longtemps sur le site.
 L’optimisation des serveurs et l’élaboration de contenus adaptatifs (prédiction,
proposition de liens et contenus personnalisés à la session).
 L’adaptation et la personnalisation des sites selon les profils utilisateurs.
 L’assistance et l’aide des utilisateurs.

4. la personnalisation et l’adaptation :

4.1. Définition de la personnalisation :


La personnalisation représente toute interaction avec un client, un groupe de client, un
utilisateur ou des partenaires, visant à ajuster le contenu, la présentation, la publicité ou les
services et les produits sur mesure. Cette interaction repose sur un ensemble de technologies
exploitant le maximum d'informations dont l'entreprise dispose, et pouvant offrir la possibilité
au destinataire d'intervenir dans le processus.

Suivant [3], avec l’énorme montant d’information disponible de nos jours, il est
nécessaire de rassembler et de distribuer uniquement les informations qui sont pertinentes
pour un individu ou un groupe d’individus dans un format et une disposition spécifiée et dans
un intervalle de temps spécifié par l’utilisateur.

4.2. Définition de l’adaptation :


D’après le dictionnaire le terme adaptative est définie comme : « adaptative
adj. :( technique) s'occuper du changement, être capable de changé quand c’est nécessaire
pour le but de s’y prendre avec toute les situations ».

L'adaptation est définie par H. Dietrich, U. Malinowski, T. Kühme et M. Shneider [14]


comme "une tentative de modifier le comportement interactif d'un système en considérant à la

15
Chapitre1 Modélisation de l’utilisateur

fois les besoins individuels des utilisateurs humains et les conditions propres à
l'environnement de l'application".

4.3. Différence entre Adaptation et Personnalisation :

La distinction entre les termes "personnalisation" et "adaptation" n'est pas évidente. Il


semble qu’il est utile de la préciser. Le principal élément différent entre la personnalisation
et l’adaptation est la prise en compte d'éléments propres à l'environnement de l'application.
Donc la personnalisation n'est pas un concept distinct de celui de l'adaptation, mais plutôt une
sous-catégorie de ce dernier (comme illustré dans la figure .I .1). Toute personnalisation est
donc de l'adaptation mais l'inverse n'est pas exact.

Personnalisatio Adaptation
n

Figure 1 : Positionnement de la personnalisation par rapport à l'adaptation [14]

4.4. Méthodes et techniques d’adaptation [6] :

Le processus d’adaptation doit suivre les méthodes d’adaptation. Ces méthodes


d’adaptation ont été classées en deux catégories :

 L'adaptation de la présentation (le contenue et présentation): Afin d’assurer que le


contenu d’une page Web contient l’information pertinente, le système présentera,
marquera les fragments conditionnels `a une page. Ceci a pour but de s’assurer le contenu
d’une page contient l’information appropriée pour l’utilisateur donné au temps donné.
 L'adaptation de la navigation: concernent plus particulièrement les liens :
Le modèle d’utilisateur classifie tous les nœuds (pages Web) dans plusieurs groupes
selon les connaissances actuelles de l’utilisateur et les intérêts ou les buts. Le système
utilise des liens dans des nœuds pour guider des utilisateurs vers les informations

16
Chapitre1 Modélisation de l’utilisateur

appropriées ou intéressées. Selon la classification du nœud auquel un lien mène, il


pourrait être particulièrement annoté ou enlevé.
1. Les méthodes et les techniques de présentation adaptative [5] :

a) Méthodes
L'explication additionnelle: Les parties du document ce qui est appropriée au niveau de
connaissance de l'utilisateur est présenté.
L'explication pré-requise : Le système évalue les pré-requise nécessaires à la compréhension
de la page présentée à l'utilisateur. Si ce dernier ne possède pas les connaissances suffisantes,
le système intègre des informations supplémentaires sur les concepts inconnus dans la page.
L'explication comparative : Le système va vérifier si l'utilisateur connaît un concept similaire
à celui présenté dans la page Web (concept qu'il ne connaît pas), alors le système va ajouter
des explications qui insistent sur les similarités et les différences entre les deux concepts.
Les explications variantes : Le système possède différentes versions des fragments. Il
sélectionne ceux qui correspondent le plus au profil de l'utilisateur.
Le tri : Les différents fragments d'information sont triés en fonction de leur pertinence pour
l'utilisateur.
b) Techniques :
Ces méthodes sont implémentées dans ces techniques :
Le texte conditionnel : Dans cette technique, on divise l'espace d'information en des fragments
et chaque fragment est associé avec des conditions sur le niveau de connaissance de
l'utilisateur. Le système va choisir les plus appropriés fragments.
Le stretchtext: Dans l'hyper-space traditionnelle, si on a besoins de détailler un concept ou un
mot clés, il y a un lien vers autre texte. Dans cette technique, on remplace directement ces
mots clés par un texte détaillé dans le document. Par exemple, dans un document au sujet de
la programmation de PHP, on a des mots « HTML ». Pour un utilisateur qui ne le connait pas,
on va ajouter la définition de HTML dans le document, sinon, seulement le mot « HTML ».
La réorganisation de fragments: Selon la préférence et l'objectif d'utilisateur, le système va
réorganiser les fragments pour donner des variantes représentations.
Les pages et fragments variants: Le but de cette technique est de pouvoir présenter les mêmes
informations de différentes façons. Une page ou un fragment ont des plusieurs versions
corresponds à chaque type d’utilisateur.
Les techniques à base de cadre (frame): Un concept est décris comme un cadre dans lequel il
y a des rainures. Chaque rainure est associée aux fragments variants, des liens vers d'autre

17
Chapitre1 Modélisation de l’utilisateur

cadre. Le système dispose aussi des règles de présentation permettant de sélectionner les
rainures et de les organiser en fonction des caractéristiques de l'utilisateur.
L'adaptation de modalité: On a plusieurs présentations d'une information, chacune
correspondant à un média différent. En fonction des préférences de l'utilisateur et du contexte
de consultation (support, logiciels disponibles), le système propose l'information sur l'un ou
l'autre des médias.
2. Les méthodes de navigation adaptative :
Dans [4], Peter Brusilovsky définit la navigation adaptative autour de cinq méthodes
qui peuvent être aussi considérées comme des buts à atteindre par les techniques de
navigation adaptative: Guidage global, Guidage local, Repère de navigation global, Repère
de navigation local et Vues personnalisées. Afin de réaliser ces méthodes et d'avoir
l'adaptation à l'objectif de l'utilisateur, en général on appliquer les techniques suivantes: [4].
Le guidage direct: Le système détermine à partir des objectifs et connaissances de l'utilisateur
le meilleur "prochain" nœud à visiter. Le lien vers ce nœud est représenté par un bouton
"suivant" ou "continuer".
Le tri: Le système donne à l'utilisateur une liste de liens triés pour l'aider à choisir la partie
suivante dans sa stratégie de lecture. Elle est très utilisée dans le système de recherche
d'information. Trois façons utilisées: le masquage de liens, la désactivation de liens, la
suppression de liens.
Le masquage: Le but de cette technique est de limiter l'espace d'information à l'utilisateur.
Les liens qui ne conviennent pas au niveau de connaissance ou à la préférence d'utilisateur
sont masqués.
L'annotation: Cette technique consiste à présenter les liens différemment en fonction de la
pertinence du nœud destination pour l'utilisateur [2]. On peut utiliser les couleurs, les
symboles pour aider l'utilisateur à classifier les liens, les textes selon le niveau de
connaissance et aussi la préférence.

5. Quelques modèles utilisateur:


Il existe plusieurs modèles pour modéliser l’utilisateur et on va se limiter à définir
quelques un :

5.1. Le modèle Munich [10] :


Le modèle Munich est composé d’une classe gestionnaire d’utilisateurs, qui est
composée d’un ou de plusieurs utilisateurs. Un utilisateur possède des attributs nom

18
Chapitre1 Modélisation de l’utilisateur

d’utilisateur et email. Il contient également d’autres attributs, potentiellement quelconques.


Les attributs sont divisés en deux, ceux qui dépendent du domaine, et ceux qui n’en dépendent
pas. Un attribut est constitué d’un nom et d’une valeur. L’identifiant est unique pour un
utilisateur dans toute l’application. Les attributs dépendant du domaine sont liés aux
composants du domaine. Ce modèle a une seule catégorie d’attributs indépendants du
domaine. Ce modèle ne permet pas de conserver la trace « qui sera l’objet de discussion de
prochain chapitre » des documents parcourus : il n’y a pas d’historique.

5.2. Le modèle INT [10]:


Le modèle de l’utilisateur est un triplet : UM=<learner, preference, knowledge>
learner est l’identifiant de l’utilisateur. Les préférences de l’utilisateur correspondent à sa
présentation préférée. Chaque élément de l’ensemble des préférences est représenté par une
paire<attribute, value>. Les connaissances de l’utilisateur sont représentées par des triplets de
la forme :< dommmain concept, role, educationnalState>. Là encore, les connaissances sont
séparées des attributs indépendants du domaine. Les attributs indépendants du domaine sont
représentés par une paire nom/valeur. Valeur (educational-state) et un rôle, correspondant au
type de la connaissance acquise (connaissance pratique, théorique, histoire du concept, etc).
5.3. Le modèle AHAM [10] :
Le modèle de l’utilisateur d’AHAM est relativement peu formalisé. Il reste très
général. Dans AHAM, le modèle de l’utilisateur est constitué d’attributs, qui correspondent le
plus souvent à la connaissance de concepts. Pour chaque entité, un certain nombre de paires
attribut-valeur sont stockées, comme, par exemple, le fait qu’un concept ait été lu ou le niveau
de connaissance d’un concept. Les données relatives aux utilisateurs sont stockées dans une
table. Cette table contient l’état des connaissances que l’utilisateur a du domaine, ainsi que ses
préférences si nécessaire. La façon dont les caractéristiques des utilisateurs sont mises en
relation avec les autres éléments du modèle est implicite. Il n’y a pas d’historique. Il n’y a pas
d’attributs prédéfinis.
5.4. Le modèle musette : [1]
Le modèle MUSETTE (Modéliser les Usages Et les Tâches pour Tracer l’Expérience)
sert à décrire les utilisations d’un système informatique. Le modélisateur doit tout d’abord
décider des limites du système à observer ; il peut alors recenser les objets lui permettant de
décrire le système et les opérations effectuées par l’utilisateur.

19
Chapitre1 Modélisation de l’utilisateur

Nous présentons le principe de modélisation de l’utilisation en introduisant les notions


de modèle d’utilisation (MU).
Modèle d’utilisation (MU): est l’ensemble des définitions et descriptions des éléments
d’interaction déterminés par le modélisateur, qui pourront être inscrits finalement dans la trace
nommés Objets d’Intérêt (OIs), ils sont de trois types :
Le premier est Les entités, qui sont des objets, des objets « présents » pour l’utilisateur dans
son interaction avec le système, le second est les évènements, qui sont des objets qui « ont
lieu », qui « se passent » durant cette même interaction, et enfin le troisième et le dernier type
les relations, qui sont binaires et peuvent lier indifféremment des entités et/ou des
évènements.
La séquence temporelle des objets et opérations mobilisés par l’utilisateur lorsqu’il utilise le
système est appelée trace d’utilisation.
Trace d’utilisation : La trace d’utilisation d’un système informatique est une séquence
alternée d’états et de transitions. Chaque état est décrit par des objets du modèle d’utilisation
du système, et chaque transition entre deux états est décrite par des opérations de ce modèle
d’utilisation (plus de détaille réf Chapitre 2).
Ces traces sont difficilement exploitables en tant que telles (c’est sur ce type de
matériau que sont généralement utilisées les techniques de fouille de données afin d’en
extraire des connaissances), d’où l’intérêt de les expliquer à l’aide de la notion de tâche.
Modèles de tâche : Tout modèle de tâche est une restriction du modèle d’utilisation décrivant
les propriétés de ses objets qui sont toujours vérifiées lors de la réalisation de la tâche en
question. Le modèle de tâche peut aussi être accompagné d’explications sur le rôle des
éléments du modèle d’utilisation impliqués dans cette tâche.
Ensemble de modèles de tâches définis a priori par le modélisateur constitue alors
une « grille de lecture » du modèle d’utilisation : ils nous permettent de repérer des parties de
la trace d’utilisation qui sont conformes à ces modèles, et donc de les expliquer. Ces parties
de la trace d’utilisation dites des cas d’utilisation.
Cas d’utilisation : On appelle ainsi tout partie de la trace d’utilisation qui instancie un modèle
de tâche.

6. Modélisation de l’utilisateur et la personnalisation [9]


Un système capable de fournir une interaction personnalisée nécessite un modèle
utilisateur. Ce modèle contient des informations sur les buts, les besoins, les préférences ou
les intentions des utilisateurs. Les modèles utilisateur plus avancés peuvent contenir des

20
Chapitre1 Modélisation de l’utilisateur

informations liées à l’état psychique, émotionnel, physique, le contexte dans lequel se trouve
l’utilisateur etc.

Modèle utilisateur

Actualis Actualise Accède


e
Editeur profil
utilisateur Technique de Mécanismes de
modélisateur personnalisation
Services intelligents

Donnée Donnée Services


Fournit
intelligents
Utilisateur

Figure 2: Modélisation utilisateur et mécanismes de personnalisation [9]

La figure 2 représente une forme simplifiée d’un système pour la modélisation des
utilisateurs. Ce système acquiert les données par l’intermédiaire d’un éditeur de profil
utilisateur (d’une façon explicite), ou en utilisant différentes techniques de modélisation
utilisateur. Les techniques de modélisation utilisateur et les mécanismes de personnalisation
constituent des services intelligents comme représenté dans la Figure 2.
L’interaction personnalisée nécessite plusieurs étapes parmi lesquelles:
· La définition du modèle utilisateur
· L’acquisition des données utilisateurs
· Le raisonnement et les inférences
· La génération de services personnalisés
Les mécanismes de personnalisation peuvent consister en des techniques adaptatives variées
ou être basées sur les interactions des agents. Un système adaptatif, flexible permet
l’adaptation de sa fonctionnalité et son contenu hypermédia selon les besoins et
caractéristiques des utilisateurs.

21
Chapitre1 Modélisation de l’utilisateur

7. Conclusion :
Nous avons vu dans ce chapitre l’utilité de modéliser l’utilisateur ainsi que les étapes
et méthodes qui contribuent à cette modélisation, et le but de ce chapitre était de présenter les
méthodes d’adaptation/personnalisation qui sont une solution qui permette aux utilisateurs du
web d’accéder à l’information pertinente.

Adapter aux préférences et aux besoins de l’utilisateur ne pourra être réalisé, comme nous
l’avons constaté par l’étude des modèles, sans avoir recours à des informations sur ce dernier
et qui sont ses différentes interactions avec le system qu’on appellera trace, ce qui sera
l’objet de discussion et d’étude dans le chapitre qui suit.

22
Chapitre2: Les traces et les fichiers logs

23
Chapitre2 Les traces et les fichiers logs

Chapitre 2
Les traces et les fichiers logs
1. Introduction :
Les expériences vécues par un individu constituent son histoire, elles sont un matériau
pour son futur. Ces expériences peuvent être mobilisées, après qu’elles aient eu lieu, dans,
d’autres situations. Nombre de recherches se sont intéressées à l’utilisation des expériences
passées, en particulier des recherches sur le processus de conception.

Comme notre application consiste à réutiliser l’expérience d’interaction de l’utilisateur


avec le système pour concevoir un outil qui permet l’utilisateur de visualiser toutes ces
navigations sur le web ce chapitre est réservé pour les traces et les fichiers logs. Pour cela
nous allons d’abord définir la trace et les systèmes qui tracent les interactions utilisateurs
système puis on va introduire le concept de métacognition et réflexivité, aussi nous allons
parler de raisonnement à partir de l’expérience tracée et définir c’est quoi un indicateur, et
pour terminer nous allons aborder la notion de fichier log.

2. Traces:
2.1. A la recherche d’une Définitions [11]:
Lorsque l'on aborde la question des traces, il faut tout d'abord pouvoir s'entendre sur
la définition que l'on associe au terme trace. En effet, il existe actuellement plusieurs points de
vue sur ce que pourrait être cette définition d'une trace.
D'après P. Jermann [14], une trace est une observation ou un enregistrement de l'interaction de
l'apprenant avec un système en vue d'une analyse. Dans le même sens, J-P. Pernin [15] définit
une trace comme un indice de l'activité des acteurs d'une situation d'apprentissage, qu'elle soit
ou non instrumentée. Il complète, par ailleurs, sa définition en précisant qu'il s'agit d'un
résultat obtenu au cours ou au terme d'une activité, d'un événement ou d'un ensemble
d'évènements relatifs au déroulement de la situation d'apprentissage. Dans une optique
légèrement différente, P-A. Champin[16] parle d'une séquence d'états et de transitions
représentant l'activité de l'utilisateur : «la séquence temporelle des objets et opérations
mobilisés par l’utilisateur lorsqu’il utilise le système est appelée trace d’utilisation ». Dans ces
trois « définitions », une trace est une trace d'activité, d'utilisation, d'interaction. On parle
alors de traces primaires, brutes, de base ou de « bas niveau ». Il ressort également de ces

24
Chapitre2 Les traces et les fichiers logs

définitions qu'une trace est temporellement marquée, plus particulièrement lorsque Champin
parle de séquence temporelle.
Ces traces brutes ne portant aucune interprétation, des traces de « plus haut niveau » sont
construites par agrégation ou structuration de traces de « bas niveau », ainsi que par
l’application d'opérations (par exemple : des données statistiques) sur celles-ci. Ces traces
sont porteuses d'une information plus complexe que les traces primaires. Jermann et Pernin
avancent alors le terme d'indicateurs pour désigner ces traces secondaires.
On y retrouve plusieurs définitions concernant les traces. Notamment, on y considère
qu'une trace est une donnée de base enregistrée par un système.
Les données obtenues en effectuant une opération (calcul, ajout de sémantique) sur une trace
ne sont pas considérées comme des traces, elles sont désignées sous le terme d’indicateurs.
En conception logicielle, l’enregistrement de l’expérience inscrite et « capitalisée »
dans des traces des interactions utilisateur-système est un domaine de recherche actif, à
l’origine du développement de systèmes qui tracent ces interactions. Nous présentons ci-
dessous différents types de systèmes « traçants ».

Figure3: Le processus général de gestion de trace [33]

2.2. Types de systèmes qui tracent les interactions utilisateur système [17] :
Dans le domaine de l’interaction homme-machine, le traçage des interactions
utilisateur système et l’utilisation des traces comme outils de recherche existent depuis

25
Chapitre2 Les traces et les fichiers logs

longtemps [18]. Ces traces sont des historiques, utilisés pour comprendre la situation
d’interaction ou pour assister l’utilisateur dans sa tâche.
Selon le fait que les situations d’utilisations des histoires interactionnelles sont ou non
présentées à l’utilisateur il y a quatre types de système qui traces les interactions utilisateur
système.

2.2.1. Systèmes utilisant l’histoire interactionnelle sans la présenter aux utilisateurs :


Le premier groupe de systèmes identifiés est celui des systèmes qui ne présentent pas
l’histoire interactionnelle aux utilisateurs bien qu’ils l’utilisent. Ces systèmes utilisent les
traces des interactions entre utilisateurs et système, mais ne les exploitent pas sous forme de
visualisation. Des calculs sont réalisés sur ces traces (fichiers logs), en vue de prévoir,
conformément à un modèle implicite, les actions futures des utilisateurs et ainsi modifier
l’interface pour qu’elle corresponde au comportement « prédit ». Les informations relatives
aux interactions sur lesquelles les calculs sont effectués correspondent aux informations de
types suivants : accès à des ressources, consultations des écrans, clics effectués, temps passés
aux opérations, choix effectués, réponses données aux éventuelles questions, etc. Ces
traitements sont automatiques et prévus par le programme. Les actions effectives de
l’utilisateur sont comparées à un modèle d’actions prévues. De tels systèmes s’intéressent
ainsi aux préférences des utilisateurs pour personnaliser l’interface. Certains de ces systèmes
proposent des interfaces qui « donnent et prennent conseils » [19] en interaction avec
l’utilisateur. Ces interfaces reflètent les calculs faits sur les interactions utilisateur-système
stockées en mémoire, en proposant à l’utilisateur des suggestions d’actions.

2.2.2. Systèmes présentant une visualisation de l’histoire interactionnelle destinée à


l’analyste de la situation :
Le deuxième groupe de systèmes est celui des systèmes proposant une visualisation
des traces d’interactions utilisateurs-système à un analyste de la situation, qui n’est pas
l’utilisateur du système. Dans le cadre d’analyses des usages en situations interactionnelles, il
peut être intéressant que l’analyste de la situation, par exemple le chercheur, ait accès aux
traces des interactions entre utilisateurs et système. Depuis longtemps, les traces
informatiques sont utilisées par les chercheurs pour « espionner » la manière dont les sujets se
comportent dans une situation donnée ou utilisent un système, qui peut précisément être le
système sur lequel est installé le logiciel étudié. Ce genre d’études a existé en ergonomie, en
sciences de l’éducation, en psychologie, et en communication. Pour une situation

26
Chapitre2 Les traces et les fichiers logs

d’apprentissage instrumenté, Després [20] a développé un système basé sur les traces
d’interactions, permettant au tuteur de percevoir l’état d’avancement du travail des
apprenants. En interaction homme-machine, un « espion » bien connu est PlayBack [21] Les
traces d’interactions enregistrées peuvent être à l’origine de comptages divers : temps passés,
fréquences d’utilisation, fonctionnalités utilisées ou inutilisées, erreurs, taux de réussite, etc.
[22] citent d’autres mesures plus spécifiques telles que le taux de répétition, le taux de
composition et la localité [23]. Pour classifier les traces, des méthodes issues des travaux sur
la reconnaissance de formes sont appliquées : réseaux de neurones et recherche de séquences
répétées.
Notre application se penche sur ce type du système.
2.2.3. Systèmes présentant une visualisation de l’histoire interactionnelle destinée à
l’utilisateur et lui proposant la possibilité d’y naviguer :
Le troisième groupe de systèmes offre une visualisation des traces d’interactions aux
utilisateurs, et leur permet de naviguer dans ces informations. Ces systèmes présentent
l’histoire interactionnelle aux utilisateurs en vue de supporter leur activité. Les possibilités des
utilisateurs d’interagir avec cet historique sont limitées à de la navigation et ne concernent pas
le déclenchement de nouvelles actions ni la saisie d’informations déclenchant des actions.
Certains systèmes concernent la navigation, d’autres sont destinés à des situations
d’apprentissage.

2.2.4. Systèmes présentant une visualisation de l’histoire interactionnelle pour


l’utilisateur et proposant la possibilité d’agir dessus :
Le quatrième groupe de systèmes concerne les systèmes qui présentent une
visualisation de l’histoire interactionnelle à l’utilisateur et qui lui offrent la possibilité d’agir
dessus. Ces systèmes utilisent l’histoire interactionnelle comme un outil pour les utilisateurs,
pour entrer des données ou des commandes.
Les chercheurs qui développent des systèmes présentant une visualisation de l’histoire
interactionnelle pour les utilisateurs font l’hypothèse que cette présentation va permettre aux
utilisateurs de prendre de la distance sur leur activité et susciter ainsi une activité sur
l’activité. Ceci les conduit à mobiliser le concept de métacognition que nous expliquant dans
le paragraphe ci-dessous.

27
Chapitre2 Les traces et les fichiers logs

2.3. Métacognition et réflexivité :


Bon nombre de travaux utilisant les traces informatiques pour les présenter aux
utilisateurs convoquent le concept de métacognition pour tantôt justifier leur proposition de
visualisation des traces, tantôt nommé les activités que la présentation des traces suscite.

2.3.1. Concept de métacognition :


La métacognition désigne la connaissance que le sujet a de ses propres processus de
pensée et de ceux d'autrui, ainsi que le contrôle qu'il exerce sur ses propres processus cognitifs
[24]. Depuis les premières études sur la métacognition, ce concept renvoie à deux types de
compétences bien distinctes : les connaissances déclaratives sur le système cognitif et sa
nature, et le contrôle et la régulation effective de ce système. Cette distinction
connaissance/contrôle est classiquement retrouvée dans les définitions de la métacognition.
Selon Flavell, la métacognition réfère aux connaissances que possède un sujet concernant ses
propres processus et produits cognitifs. Elle réfère au monitoring actif, à la régulation et à
l’orchestration de ces processus et produits, en général en relation avec un but ou un objectif.
La définition proposée par [25] attribue ainsi deux dimensions essentielles à la métacognition
: les connaissances métacognitives et les régulations métacognitives. Les connaissances
métacognitives d'un individu portent sur sa propre cognition et sur la Cognition en général.
Les régulations métacognitives réfèrent aux activités supportant le contrôle individuel de la
pensée ou de l'apprentissage [26].

2.3.2. La réflexivité :
Les systèmes présentés aux 2.2.3 et 2.2.4 sont des systèmes qui présentent une
visualisation de l’histoire interactionnelle pour les utilisateurs, en s’appuyant sur la
métacognition, ont pour objectif de favoriser la prise de conscience réflexive par les
utilisateurs de leur activité. Par activité réflexive, nous entendons davantage qu’une activité
réfléchie, c’est-à-dire tournée vers soi. Nous désignons une activité se prenant elle-même pour
objet. L’idée est que le système informatique peut servir de « miroir doté de mémoire » pour
l’utilisateur, par le biais de la présentation des traces informatiques, ces dernières suscitant
chez l’utilisateur une prise de distance par rapport à son activité à l’origine d’une prise de
conscience de nature meta. Une des méthodes réflexives utilisées en ergonomie consiste à
utiliser les traces de l’activité d’opérateurs (via des enregistrements vidéo) comme un outil de

28
Chapitre2 Les traces et les fichiers logs

construction de savoirs nouveaux [27], par la mise à distance temporelle et physique du sujet
face à son activité.
Nous présentons ci-dessous une approche informatique pour la conception et
l’évaluation « centrées utilisateur » de systèmes visant une réelle coopération entre la machine
et l’utilisateur, le raisonnement à partir de l’expérience tracée.

2.4. Raisonnement à partir de l’expérience tracée :


L’idée du raisonnement à partir de l’expérience est de concevoir des systèmes qui
s’enrichissent au fil de leurs utilisations, à partir du traçage des interactions avec les
utilisateurs. Le principe est d’utiliser ces traces comme explicitation des expériences entre
utilisateurs et système pour soutenir les utilisateurs dans leur activité. Dans cette partie, nous
exposons premièrement en quoi la question du niveau d’abstraction des informations tracées
est à prendre en compte. Nous présentons ensuite les fondements du raisonnement à partir de
l’expérience tracée, qui a pour objectif de modéliser l’utilisation d’un système par un (ou des)
utilisateur(s) pour pouvoir la tracer.

2.4.1. De la nature des traces d’interaction : niveau d’abstraction des informations


tracées :
Différents types de traces informatiques peuvent être utilisés comme soutien à
l’activité. En particulier, le niveau d’abstraction des informations recueillies peut varier. Dans
le cas où les traces sont utilisées par le système pour assister l’utilisateur, mais sans qu’elles
lui soient présentées, les calculs étant faits sur les fichiers logs, le système récupère les
informations issues des calculs pour agir sur les interfaces. Dans ce cas, la question du niveau
d’abstraction des traces ne se pose donc pas puisque ce n’est pas un humain qui les reçoit. Si
il existe un modèle de l’utilisateur, ou bien si il y a un moteur de raisonnement à partir de cas,
le système pourra prédire ce que l’utilisateur fera, soit pour avoir une session d’utilisation «
réussie », soit en fonction de ce qu’il a fait auparavant, ou bien encore selon ce que d’autres
utilisateurs avec un « profil » similaire ou dans une situation proche ont fait. Il pourra ensuite
lui faire des suggestions d’actions. En revanche, dans le cas où les traces sont présentées soit à
l’analyste de la situation ou bien à l’utilisateur, les questions de leur niveau d’interprétation,
de leur mise en forme puis de leur visualisation se posent. Dans le cas de traces présentées au
chercheur ou, de manière plus générale, à l’analyste de la situation, les traces d’interactions
peuvent être simplement reconstruites ou plus finement interprétées par le système, en

29
Chapitre2 Les traces et les fichiers logs

fonction des objectifs d’analyse. Si l’analyste a des hypothèses de recherche pré


expérimentales, il peut faire un modèle de traces en fonction de ses attentes et l’implémenter
afin que le système n’enregistre puis ne lui « sorte » que les informations qui l’intéressent,
filtrées, mises en forme voire directement annotées. Dans le cas où les traces sont adressées à
l’utilisateur, elles peuvent également être plus ou moins interprétées par le système en
fonction du type d’utilisateur (âge, expertise éventuelle, proximité culturelle avec la tâche,
etc.), en fonction de ce que l’on suppose que cela va susciter chez lui, et également en
fonction de l’approche théorique d’assistance que l’on adopte. Dans certains systèmes, on
trouve des traces interprétées qui sont des « profils ». Pour une application donnée, ces traces
contiennent des informations sur l’utilisateur, sur les dernières actions qu’il a effectué avec
l’application. L’idée des profils est que la présentation à l’utilisateur d’une trace interprétée de
son activité va le guider et susciter une prise de conscience de son activité. Les traces peuvent
aussi être présentées à l’utilisateur dans leur forme « brute ».
Ce paragraphe montre qu’il existe différents niveaux d’abstraction dans les traces
d’interactions qui sont utilisées dans les systèmes informatiques, et que ce niveau varie selon
l’usage qui est fait de ces traces.

2.4.2. Raisonner à partir de l’expérience tracée :


Nous allons présenter le principe du raisonnement à partir de l’expérience tracée, puis
exposer quels sont ses liens avec le raisonnement à partir de cas.

2.4.2.1. Principe général du Raisonnement à partir de l’Expérience Tracée :(RàPET)


L’objectif du raisonnement à partir de l’expérience tracée est de participer à la
conception de systèmes informatiques capables de fonctionner « en intelligence » avec
l'utilisateur [28]. L'idée principale est que le système « apprenne » progressivement à partir
des interactions de l'utilisateur médiées par l'environnement informatique. Il s'agit d'utiliser
les traces informatiques des interactions utilisateur(s)-système pour les assister dans leur(s)
activité(s) en profitant du fait que ces informations peuvent être familières aux utilisateurs
puisqu’elles sont constituées de leur(s) expériences(s). Dans la signification coutumière du
terme « expérience », Mille rappelle que « toute connaissance trouverait sa source de manière
plus ou moins directe dans l'expérience : raisonner consiste en effet à mobiliser des
connaissances préalablement établies pour produire un résultat satisfaisant un but particulier
». C’est le niveau d’explicitation de l’expérience qui permet de distinguer le RàPET d’un
autre type de processus de raisonnement. L'expérience ne peut être appréhendée que par les

30
Chapitre2 Les traces et les fichiers logs

traces laissées dans l'environnement en tant qu’inscriptions de connaissances émergées ou


mobilisées en cours d'expérience, celles-ci devenant sources d’émergence de nouvelles
connaissances. Dans le domaine de l’ingénierie des connaissances, l’inscription des «
connaissances » dans les systèmes informatiques constitue un champ de recherches à l’origine
de traçages de différents types d’informations interactionnelles. Ces informations appelées «
inscripteurs de connaissances » sont enregistrées dans un format exploitable par un
environnement informatique, c'est-à-dire sous une forme computationnelle dont on pourrait
extraire la sémantique des informations par des calculs. Les systèmes experts, les systèmes à
base de connaissances, les systèmes basés sur le paradigme du raisonnement à partir de cas
(RàPC) sont des systèmes visant l’inscription des connaissances pour assister les utilisateurs.

2.4.2.2. Liens avec le raisonnement à partir de cas :


Utilisé en intelligence artificielle depuis le début des années 1980, le raisonnement à
partir de cas (RàPC) est une des méthodes de raisonnement par analogies, inspirée de la
psychologie cognitive. Il a introduit l’idée de la réutilisation de l’expérience dans le domaine
de la résolution de problèmes en intelligence artificielle. Il permet de raisonner à partir de cas
ou d'expériences anciennes pour résoudre un problème, de critiquer des solutions, d’expliquer
des situations inattendues ou d’interpréter des situations nouvelles [29].
D’après tous ce qu’on a parlés sur les traces on peut dire qu’elles sont des indicateurs
qui peuvent subir des traitements pour obtenir des indicateurs de plus grande sémantique.

2.5. Définition d’un indicateur [13] :


Selon [30] un indicateur est une variable au sens mathématique à laquelle est attribuée
une série de caractéristiques. C’est une variable qui prend des valeurs représentées par une
forme numérique, alphanumérique ou même graphique.... La valeur possède un statut : elle
peut être brute (sans unité définie), calibrée ou interprétée. Le statut identifie une
caractéristique bien précise : celle du type d’assistance offert aux utilisateurs. Chaque
indicateur peut dépendre d’autres variables .comme le temps et, ou même d’autres
indicateurs.

Exemple d’indicateur dans les EIAH (environnement informatique d’apprentissage humain) :


Indicateur sur le pourcentage de participation (Participation per-centage PART) :

31
Chapitre2 Les traces et les fichiers logs

L’indicateur PART implémenté dans plateforme MODELLINGSPACE (Avouris et al., 2003)


représente le taux de participation des acteurs dans n’importe quel type d’activité. Cet
indicateur donne le pourcentage des agents qui ont agit dans l’intervalle de temps considéré.
La formule de calcul est la suivante: Par exemple, si PART=0,5 alors la moitié des agents ont
interagi dans l’ensemble des modules sur un intervalle de temps. Si PART = 0 alors aucun
acteur n’a agit dans le groupe.
 Les traces de l'utilisation d'un système informatique sont de deux types :
_ Le logiciel (tel quel ou après avoir été instrumenté) enregistre dans des fichiers (appelés
classiquement fichiers de log ou logs) des informations sur ce qu'a fait l'utilisateur.
_ Il est aussi envisageable de filmer l'utilisateur en train d'utiliser le système ; la trace se
présente alors sous la forme d'un vidéogramme.
Parce que l'utilisation de la deuxième technique est, en pratique, très contraignante et très
coûteuse en temps de traitement, les systèmes d'analyse de traces à partir de fichiers de log
sont les plus fréquemment mis en œuvre.

3. Fichier log :
3.1. Définition [31]:
Le terme « log » provient de la langue anglaise (journal de bord des navires). Il est
notamment employé en informatique pour désigner un historique d’événements et par
extension le fichier contenant cet historique.
Le terme « log » en tant que tel n’apparaît pas dans la réglementation française. Les
textes applicables, qu’il s’agisse de textes nationaux ou de directives communautaires,
retiennent les termes suivants :
– « données relatives au trafic »1 ;
– « données de nature à permettre l’identification »2 ;
– « données de connexion à des services de communications électroniques »3 ;
– « données de connexion »4 ;
– « fichiers de journalisation des connexions

3.2. Le contenu d’un fichier log [32] :


Les fichiers logs sont typologiquement sont en nombre de quatre, à savoir:

3.2.1. les logs de transferts :

32
Chapitre2 Les traces et les fichiers logs

Ils enregistrent tous les transferts de fichier résultant d’une requête d’un client à un
serveur, ils contiennent principalement le nom et le type ( image, vidéo…) du fichier demandé
ainsi que l’adresse de la machine hôte.

3.2.2. Les logs d’erreurs :

Ils conservent la trace incidente survenue lors d’une transaction entre le client et le
serveur. Principal intérêt de ces fichiers logs d’erreurs en terme de mesure d’audience d’un
site web, réside dans le fait qu’ils donnent la possibilité de savoir dans qu’elle fichier ou
téléchargement a été interrompue et donc repéré les pages sur les quelles les utilisateurs
quittent le site internet.

3.2.3. Les logs référentiels :

Ils facilitent l’identification à la fois du site depuis lequel le client est arrivé(par
exemple un moteur de recherche ou un site contenant un lien avec le site étudié) et de la page
du site étudié sur lequel le client est arrivé.

Par exemple, la ligne (“http://sitededépart.fr/lien->/accueil.html’’signifie que le client


est arrivé depuis page lien d’un site appelé sitededépart.fr sur la page appelée accueil de site
étudié.

L’analyse de ces fichiers permet donc d’analyser le parcours de navigation des


internautes.

3.2.4. Les logs d’agent :


Ils archivent notamment les informations portant sur l’équipement informatique et les
types des navigateurs utilisées par chaque client.

3.3 Utilité des fichiers logs :

Les fichiers logs tracent tous les événements qui arrivent pendant l’activité d’un
système. Ils peuvent contenir la preuve en détail de toute activité exceptionnelle, suspecte ou
non désirée. Les fichiers logs issus des différents composants d’un réseau peuvent indiquer
si la sécurité du réseau est compromise ou en voie de compromission. Par exemple l’utilité
d’un fichier log pour un serveur web est :

 Déterminer les pages (ou produits) les plus et moins populaires.


 Déterminer les types de clientèle (localisation, langue, etc. .).
33
Chapitre2 Les traces et les fichiers logs

 Suivre l’évolution de l’achalandage /implantation des nouvelles technologies.


 Déterminer comment les clients sont arrivés sur votre site web (mots clés dans les
moteurs de recherches, référencement par d’autres sites, etc. .).
 Déterminer le parcours des clients dans le site web.
 Identifier des problèmes techniques sur le site.
3.4. Quelques formats de fichier log :
L’analyse du contenu d’un fichier log exige une bonne compréhension du format et
une structure appropriée facilitant son analyse.

En effet, des formats standards ont été développés. Parmi les quels, on peut citer : le format
W3C Etendu et le format log commun

3.4.1. Le format W3C Etendu (Word Wide Web Consortium):

C’est un format ASCII adapté avec une variété de champs. L’utilisation de ce format
permet d’inclure des champs importants comme elle peut omettre des champs non désirés.
Les champs sont séparés par un espace, le temps est enregistré en GMT (Greenwich Mean
Time). Ce format est disponible pour les serveurs Web et les serveurs FTP.

Exemple d’une entrée

172.16.25.10 02-05-1998 17:42:15 GET /default.html 200 HTTP/1.0

Cette entrée signifie que le 02 mai 1998 à 17h 42 mn 15s (GMT), un utilisateur ayant
l’adresse IP 172.16.25.10 et en utilisant HTTP 1.0 a lancé une requête GET/default.html.
Cette requête signifie le téléchargement de la page Web default.html. La requête est exécutée
avec succès. La valeur 200 étant le code de l’état du service, cette valeur indique le succès de
la requête.

3.4.2. Le format log commun :

C’est un format ASCII fixé disponible uniquement pour les serveurs Web. Il a été
développé par NCSA (National Center for Supercomputing Applications) à l’université
d’Illinois à Urbana-Champaign. Chaque entrée contient les champs suivants :

• Le nom de l’hôte ou l’adresse IP de l’hôte

• Le nom de l’utilisateur

• La date de soumission de la requête

34
Chapitre2 Les traces et les fichiers logs

• Le temps de soumission de la requête

• Le contenu de la requête envoyée par le client

• Le code de l’état HTTP retourné à l’utilisateur : c’est le code de la réponse http envoyé par
le serveur au client.

• La taille en octets des informations envoyées par le serveur Les champs sont séparés par un
espace, le temps enregistré est le temps local.

Exemple d’une entrée:

172.21.13.45 FRED 08-04-1998 17 :39 :10 GET/scripts/iisadmin/ism.dll 200 3401

Cette entrée indique qu’un utilisateur appelé FRED utilisant une adresse IP 172.21.13.45 a
envoyé au serveur Web une requête en utilisant la commande HTTP qui est « GET » pour
télécharger le fichier scripts/iisadmin/ismi.dll. Cette requête a été soumise au serveur le 08
Avril 1998 à 17h39mn 10 s temps local et elle a été retournée avec succès (code d’état
HTTP= 200). Les données envoyées à l’utilisateur FRED ont une taille de 3401 octets.

Remarque :

La réponse d’un serveur à un client peut être faite avec succès ou échec. Le code de
l’état de la réponse peut renseigner sur ce résultat.

▪ Si le code d’état ∈ {200, 201, 202, 203, 204, 300, 301, 302, 303, 304}, Alors le serveur a
répondu au client avec succès.

▪ Si le code d’état ∈ {400, 401, 402, 403, 404, 500, 501, 502, 503}, Alors le serveur n’a pas
répondu à la requête, il y a eu un échec et par conséquent la taille des données transférées au
client est égale à 0.

3.5. Les logiciels d'analyse de fichier log :

Ces fichiers se présentent sous la forme de lignes de codes laissées sur les serveurs.
Pour bénéficier d'une présentation plus digeste, certains logiciels ont été conçus pour faire une
synthèse graphique des données.

• Emplacement: logiciel à installer sur le serveur ou sur votre ordinateur


• Prix : gratuit et jusqu'à plusieurs milliers de francs
• Exemple : Webtrends, Analog,

35
Chapitre2 Les traces et les fichiers logs

3.6. Les problèmes liés aux fichiers logs :

Malgré l’importance des fichiers logs, néanmoins certains problèmes demeurent posés.

Nous citons :

• Les fichiers logs consomment un espace disque très grand.

• Les fichiers logs contiennent beaucoup d’information, ils sont immenses et par conséquent
l’analyse de leurs contenus devient une tâche très difficile.

• Les fichiers logs menacent la vie privée (privacy) de l’utilisateur. Un utilisateur refuse l’idée
que toutes ses activités soient enregistrées.

• Les fichiers logs peuvent être menacés comme d’autres formes de données dans le réseau ou
dans un système. Un attaquant qualifié pénétrant dans un système peut effacer les fichiers logs
ou modifier leur contenu. Il peut même arrêter le mécanisme d’enregistrement.

4. Conclusion :

Nous avons vu dans ce chapitre c’est quoi une trace d’interaction, l’intérêt de tracer
l’utilisateur, Nous avons cité une classification des logiciels qui tracent les interactions
utilisateurs-système, selon l’usage qui est fait des traces dans ces systèmes. Certains de ces
systèmes proposent une visualisation des traces à l’utilisateur, en vue de leur permettre
d’avoir une activité meta sur leur activité, et font appel aux concepts de métacognition et de
réflexivité.

Nous avons vu que les traces informatiques peuvent avoir différents niveaux d’abstraction,
selon le niveau d’interprétation souhaité par le concepteur du logiciel. Comme on a vu le
Principe général du Raisonnement à partir de l’Expérience Tracée, et enfin, nous avons vu la
définition des fichiers logs, qui est le moyen le plus concret pour tracer.
Le chapitre suivant sera réservé pour la modélisation de notre solution à l’aide du langage de
modélisationUML.

36
Chapitre3: Etude conceptuelle du système

37
Chapitre3 Etude conceptuelle du système

Chapitre3
Etude conceptuelle du système

1. Introduction :
L’étude conceptuelle d’un système avant sa réalisation est une phase importante pour
son élaboration, c’est un moyen qui permet de mieux comprendre le fonctionnement du
système, ainsi que de bien maitriser sa complexité et d’assurer sa cohérence.

Le but de ce chapitre est de concevoir un outil qui permet d’analyser un type de trace
qui est le fichier log. Pour ce faire, le chapitre est subdivisé en deux sections distinctes.

• La première section : on y trouve le schéma général de la solution qui présente les


différentes étapes pour l’analyse du fichier log.
• La deuxième section : présente la conception, par la méthode UML, de la solution mise en
place.

2. Présentation du projet :

Rappelons que le logiciel que nous allons développer comportera une tâche qui consiste à
calculer des indicateurs a partir d’un fichier log c'est-à-dire la détermination du taux de
consultation de chaque pages dans un site.

Le système calcule le nombre d’accès aux pages d’un site et la fréquence d’utilisation des
pages et la durée de consultation…d’un site en question.

Dans le paragraphe suivant nous présentons l’architecture générale de notre solution.

3. L’architecture générale de la solution :

Notre travail s’inscrit dans le cadre de l’analyse des traces. Pour atteindre cet objectif,
nous proposons l’architecture générale représentée dans la figure 2.

38
Chapitre3 Etude conceptuelle du système

Trace première (log)

Collecte

Filtrage

Fichier
Visualisation Calcul d’indicateur
XML

Trace transformée

Figure 4 : Architecture générale du système

Dés que l’utilisateur active l’outil d’enregistrement des traces « mini key » (cf.
Annexe), toutes ces interactions avec le système seront enregistrées sous forme d’un fichier
log qu’on a nommé trace première.

Lorsque l’analyste de la situation active LOG ANALYZER ce fichier log sera analysé
et filtré pour créer un fichier XML suivant un modèle que nous avons proposé (), ce dernier
sera interrogé pour le calcul d’indicateurs qui seront affichés à l’écran en vue d’être visualisés.

Pour mieux comprendre le schéma on va détailler chaque module à part:

 La collecte: Pour réaliser cette phase de collecte de trace on a choisi d’utilisé le


logiciel mini key car il est un logiciel gratuit, il fait l’extraction de plusieurs
informations, aussi il a la possibilité de configurer le système, en désactivant quelques
options, tels que :

 Extraction du nom de l’utilisateur,


 Extraction du mot de passe.
La qualité et la nature des traces enregistrées sont étroitement liées aux outils
techniques utilisés afin d’assurer leurs collectes.

39
Chapitre3 Etude conceptuelle du système

Système (site web)

Figure5: Mode de collecte de trace [33]

Nous pouvons identifier trois principaux modes comme designer sur la figure 5 :

 Une collecte manuelle : qui est procédé par un observateur humain, acteur ou non dans la
situation d’apprentissage avec l’outil papier crayon et l’éventuelle aide de quelque
logicielle tel que Word, Excel …etc.
 Collecte audiovisuelle : exécutée par un outil capable de créer des enregistrements visuels
et audio de la situation d’apprentissage.
 Collecte numérique : menée en utilisant un environnement informatique sauvegardant
l’activité de l’apprenant, tel que les outils de traçage. Les résultats de la collecte
numérique sont une trace numérique.

 Le filtrage : comme ce fichier contient une masse quantité d’informations, il sera alors
analysé et filtré afin d’extraire seulement les données nécessaires pour le calcul
d’indicateurs et les structurer dans un fichier XML afin d’avoir un fichier qui a une
structure fixe, car si la source de traçage change la structure de fichier log change donc on
n’a pas a recalculé à chaque fois ces indicateurs. Donc au lieu de réécrire toutes les

40
Chapitre3 Etude conceptuelle du système

fonctions (le traitement) de calcul d’indicateurs on réécrit seulement la fonction qui fait le
filtrage du fichier log.
 Modèle trace
La racine du modèle est la trace. Nous avons choisi d’encapsuler tous les autres
composants, décrits par le modèle dans cet élément.

La trace est associée à un utilisateur qui est observé lors de ses interactions avec le
système, cet utilisateur est composé de deux éléments, utilisateur_info et pages, le premier
possède un nom et heure d’accès qui représente l’heure de début de traçage, et le deuxième
possède page.

Toute page est composée de plusieurs éléments : heure c’est l’heure d’accès à cette
page, date, titre_page représente le titre de la page, lien_consulter est l’adresse complète de
cette page.

Le tableau qui suit résume la structure de la trace que nous avons adoptée :

Balise Description Eléments

Utilisateur Racine du document XML internaute_ info


Pages

Internaute info L’heure d’accès et le nom de heure_acces


nom
l’utilisateur
pages Toutes les pages consultés page
par l’utilisateur

page La page consultée heure


date
titre_page
lien_consulter
Heure_acces L’heure de démarrage de
système.
nom informations qui concernent
l’utilisateur telles que son
nom.

41
Chapitre3 Etude conceptuelle du système

Lien_consulter Contient l’adresse de la page


consultée.
Titre_page Une balise qui contient le
titre de la page consultée.

Tableau 1 : Tableau descriptif du fichier XML


Voici un exemple d’un fichier XML suivant le modèle que nous avons proposé :

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>

- <users>
- <internaute_info>
<heure_acces>13:44:43</heure_acces>
<nom>post32</nom>
</internaute_info>
- <pages>
- <page>
<heure>14:08:11</heure>
<date>30/05/2010</date>
<titre_page>Créez vos jeux avec Game Maker</titre_page>
<lien_consulter>http://www.siteduzero.com/tutoriel-3-239451-creez-vos-jeux-
avec-game-maker.html</lien_consulter>
</page>
</pages>
</users>

Figure 6: Extrait de fichier XML

Une méthode de structuration de trace est nécessaire, Pour cela, nous avons développé
un modèle d’indicateur, structurant les traces en indicateur de haut niveau, et ceci grâce à des
méthodes et des processus de calcul. Ce modèle sera présenté dans la section qui suit.

 Calcul d’indicateurs: Le modèle d’indicateur que nous proposons dans la figure


34 s’inspire des modèles étudiés dans certains travaux.

42
Chapitre3 Etude conceptuelle du système

Figure7: Digramme de classe du Modèle d’indicateur [34], [35]

Un indicateur est une agrégation d’un ou de plusieurs autres indicateurs et traces. La


trace peut être une trace primitive.

Nous pouvons faire aussi une distinction des indicateurs à travers trois types :

Indicateur de haut niveau : celui qui a une interprétation significative. Il est construit par le
processus de calcul d’indicateur depuis des données brutes et d’autres indicateurs
intermédiaires.

Indicateur intermédiaire : sa valeur n’est pas finale mais sert d’intermédiaire pour
construire d’autres indicateurs.

Indicateur de bas niveau : ceux qui n’ont pas une interprétation autonome et qui sont
construits directement par des données brutes.

 Visualisation: la visualisation des indicateurs est déclenchée par l’analyste afin de


comprendre le comportement de l’utilisateur du système en vue d’amélioration et une
adaptation préalable. Dans notre cas, nous avons choisi la valeur numérique pour la
représentation des statistiques, rappelons qu’il existe plusieurs types de visualisation (graphe,
texte etc…).

Dans ce qui suit nous élaborons les différents diagrammes qui correspondent aux
différentes vues de notre système.

43
Chapitre3 Etude conceptuelle du système

4. Identification des besoins :

Vu le besoin de réaliser cet outil dont nous venons d’exposer ces principales
fonctionnalités, nous avons fait une étude conceptuelle, qui consiste à développer un logiciel
permettant d’offrir le service : Statistiques autrement dit indicateurs.

L’objectif final de l’analyse d’un fichier log est le calcul d’indicateurs suivant :

 Internaute info : Les informations qui concernent l’utilisateur telles que nom de
l’utilisateur et l’heure de démarrage de traçage.
 La liste des pages visitées : cet indicateur permet de voir les différents liens consultés, il
est calculé en utilisant une fonction qui fait le chargement du fichier log et fait l’affichage
des liens en faisant appel à une autre fonction qui vérifie à chaque fois si le lien est déjà
affiché pour éviter la redondance.
 La fréquence d’utilisation des pages : c’est le taux de consultation de chaque page, ce taux
est le nombre de fois que chaque lien est consulté, il est calculé à l’aide d’une fonction qui
fait le chargement du fichier log, et calcule le nombre de fois que le lien existe dans la
trace.
 La moyenne de consultation des pages : en terme de fréquence, représente la moyenne de
consultation de chaque page, pour le calculer on a utilisé la règle de calcul suivante : la
fréquence d’utilisation de la page/le nombre total des pages consultés.
 La durée de consultation des pages : en utilisant une fonction qui permet de calculé et
d’afficher la durée de consultation de chaque page, dans notre cas c’est la différence entre
l’heure de début de consultation de la page en question et l’heure de début de consultation
de la page suivante.
 Affichage de fichier log : cet indicateur permet d’afficher la trace première et ça à l’aide
d’une fonction qui fait le chargement du fichier log et affiche sur l’écran.

4.1. Identifier les acteurs :


Dans le langage de modélisation UML, le concept acteur représente l’abstraction
d’un rôle joué par des entités externe (utilisateur, dispositif matériel) qui interagissent avec
le système étudié.

En analysant le contexte du problème, nous avons conclu que le seul acteur qui interagit est le
suivant :

44
Chapitre3 Etude conceptuelle du système

L’analyste : est une entité externe au system en interaction avec ce dernier.

4.2. Les messages :

Un message représente la spécification d’une communication entre objets qui


transporte de l’information avec l’intention de déclencher une activité chez le récepteur.
La réception d’un message est considérée comme un événement. Cette notion de message
est applicable pour décrire les interactions de plus haut niveau entre les acteurs et le
système.

4.3. Identification de cas d’utilisation:

Le tableau ci-dessous établit le résultat de ce travail :

Cas d’utilisation Acteur principale Message (émis, reçue)


utilisateur Emet : obtenir les différentes
statistiques concernant les pages visitées
Reçoit : calculs statistiques déterminés

Tableau2 : tableau descriptif de cas d’utilisation

4.4. Diagramme et description de cas d’utilisation :

45
Chapitre3 Etude conceptuelle du système

Titre :
Statistique
Auteur principale : l’analyste du système

Intention :
obtenir les différentes statistiques concernant les pages visitées
Enchainement nominaux :
Enchainement: afficher les statistiques concernant les pages visitées
Besoin d’IHM :
Interfaces pour afficher les statistiques

Visualisation
Internaute info Include
Include
Liens consultés Règle de calcul
Statistique

Include
Heure durée

Transformation
Fréquence lien

Include
Afficher log

Collecte (fichier log)

Figure8: Diagramme principal de cas d’utilisation

L'interprète des traces d’utilisation du dispositif est «l’analyste du système ». Son objectif
est : La mise au point des scénarios.

Son rôle est décrit sur la figure 4, après avoir choisit le fichier log à analyser, l’analyste
visualise les indicateurs calculés a partir du fichier trace crée.

4.5. Diagramme de séquence système :


Vu le besoin de compléter et de bien éclairer la description de cas d’utilisation
précédent, nous allons ajouter le diagramme de séquence pour le cas d’utilisation, afin
d’illustrer les différents scenarios nominaux.

46
Chapitre3 Etude conceptuelle du système

Diagramme de séquence pour le cas d’utilisation :

Interface de la statistique
Interface principale
Interface des statistiques
Utilisateur (Accueil)

Importer le fichier log

Fichier XML créé


Afficher la liste des
statistiques

Choisir une statistique


Appel de procédure

Statistique affichée

Figure9: Diagramme de séquence pour le cas d’utilisation

47
Chapitre3 Etude conceptuelle du système

4.6. Elaboration du diagramme de classes :


Afin de compléter les différentes étapes et diagramme précédents, nous allons rajouter
le diagramme de classe qui représente l’aspect logique de notre système

Fichier log
1
•Chemin Liens consultés
*µ1.
Connaissances
.*
1..*
•Liens consultés Afficher
1..* •Internaute info
Extraction *
• Fréquence lien
• Heure durée 1
• Afficher log *
1 * * µ
* * 1
* 1. Internaute info
Fichier XML * 1 * *µ1.
Identifiant µ * µ .* Afficher
µ .*
1. µ 1. 1.
.* 1. .* .* 1
1..* .* Fréquence lien
Mettre *µ1.
Afficher
.*

1
1 Heure durée
Afficher *µ1.
XML traitement .*

•Importer données 1..*


•traitement *µ1. 1
Afficher log
.* *µ1.
Afficher
.*

Figure10 : Diagramme de classes

La classe fichier log permet de récupérer le chemin du fichier à analyser puis la classe
fichier XML fait l’extraction des données à partir du fichier choisit, et crée par la suite le
modèle de trace (fichier XML). La classe XML traitement possède deux fonctions, importer
les données et traitement, c'est-à-dire utiliser les données du fichier XML et faire le traitement
prédéterminer pour le calcule d’indicateur désiré. La classe connaissance présente l’interface

48
Chapitre3 Etude conceptuelle du système

principale qui englobe toutes les fonctions qui permet d’afficher séparément chaque
indicateur.

5. Conclusion :
Durant ce chapitre nous avons présenté le schéma général de notre solution ainsi que
l’architecture conceptuelle de notre application en utilisant l’approche objet, et cela en
utilisant des différents diagrammes de modélisation du langage UML, qui nous a permet une
conception en modulaire et réutilisable ce qui facilite la maitrise et la production du logiciels.

Pour ce qui est de l’implémentation de notre application, nous la présenterons en détail


dans le chapitre qui suit.

49
Chapitre4 : La réalisation

50
Chapitre4 La réalisation

Chapitre 4
La réalisation

1. Introduction
Il est bien évident qu’une conception bien faite facilite beaucoup la réalisation du
projet en tenant compte de ce qu’on a modélisé dans les étapes précédentes , nous allons dans
ce chapitre d’écrire le fonctionnement de notre application ainsi que quelques explications
nécessaires pour comprendre son fonctionnement à travers les différents interfaces qui la
compose .

2. Description de l’environnement de développement :

2.1. Aspect matériel :


Pour la réalisation de notre projet, nous avons utilisé un pc possédant les
caractéristiques suivantes :

•Microprocesseur AMD Sempon(tm) SI-42 2.10 GHZ

•3.00 GO de RAM(2.75 Go utilizable)

•116 GO de capacité du disque

2.2. Aspect logiciel :


2.2.1. Langage et outils de programmation :

Le choix du langage adéquat est une étape très délicate dans le développement des
logiciels, pour le développement de notre logiciel (log analyseur), nous avons choisi le
langage de programmation java qui est un langage très puissant pour le développement de très
nombreuses applications surtout dans le domaine des réseaux et internet.

2.2.2. Système d’exploitation

En utilisant le langage java qui offre une compatibilité totale d’exécution sur différents
systèmes d’exploitation, notre produit fonctionne sur n’importe quelle plateforme. Ce logiciel
est testé sur les systèmes d’exploitation suivants : Windows XP et windows7

51
Chapitre4 La réalisation

4. Présentation du logiciel LOG ANALYZER


Dans ce qui suit nous allons décrire brièvement l’interface du logiciel et les différentes
fenêtres d’utilisation :

4.1. Interface de démarrage


Dés que vous démarrez le logiciel, la fenêtre de l’interface de démarrage se présente
comme la montre la figure suivante :

1
2

Figure 11 : Fenêtre De Démarrage

Description de la fenêtre de démarrage :

Elle est composée d’une barre de menus et deux boutons.

 Un clic sur le bouton (1) permet de quitter l’application.


 Un clic sur le bouton (2) permet l’affichage d’une boite de dialogue permettant de
choisir un fichier log, une fois que le fichier est choisi, l’interface des statistiques
apparaît.
 La barre des menus fichier (3) qui fait les mêmes tâches que les boutons est
représentée par la figure suivante :

52
Chapitre4 La réalisation

3.2. La boite de dialogue d’ouverture d’un fichier :

Cette fenêtre permet à l’utilisateur de choisir le fichier log à analyser, elle est montrée
par la figure qui suit :

Figure 12: fenêtre de la boite d’ouverture d’un fichier log

Après le choix du fichier log, une boite d’information apparait pour avertir l’utilisateur
que le chargement et le traitement du fichier log peut prendre quelques secondes ou minutes
en dépend de la taille du fichier log utiliser. La figure suivante représente cette boite
d’information :

53
Chapitre4 La réalisation

Figure 13 : Fenêtre de la boite d’information

Un click sur le bouton (4) l’interface principale (figure 14) apparait.

3.3 . Interface principale :

La fenêtre de l’interface principale du logiciel se présente comme l’expose la figure ci


dessous :

Figure14 : Fenêtre principale

Description de la fenêtre principale :

Cette fenêtre est composée d’une barre de menus, du cinq boutons, est d’une table :

54
Chapitre4 La réalisation

 Un clic sur le bouton « Liens » (5) permet l’affichage d’une fenêtre permettant de voir
la liste des pages consultées.
 Un clic sur le bouton « Internaute » (6) permet l’affichage d’une fenêtre permettant de
voir des informations sur l’utilisateur.
 Un clic sur le bouton «Fréquences » (7) permet d’afficher une fenêtre permettant de
voir la fréquence d’utilisation et la durée de consultation de chaque page.
 Un clic sur le bouton « Heure_durée » (8) permet l’affichage d’une fenêtre permettant
de voir l’heure d’accès et la durée de consultation de chaque lien.
 Un clic sur le bouton « Fichier log » (9) permet d’afficher une fenêtre permettant de
présenter le fichier log.

La barre des menus statistique de la fenêtre principale regroupe les actions des buttons qu’on
vient de présenter.

3.4. Interface d’information sur l’internaute :

Cette interface permet à l’utilisateur de voir le nom de l’ordinateur et l’heure d’accès


et qui est représentée par la figure suivante :

55
Chapitre4 La réalisation

16
10
11
12
0
13
14
150
17

Figure15 : Fenêtre Information Sur L’internaute

Description de l’interface :

Elle se compose d’une barre de menus(16), de cinq boutons et une table (17) qui représente le
nom de l’ordinateur et l’heur d’accès.

 Le bouton (10) permet de revenir à la fenêtre du démarrage (figure11).


 Le bouton (11) permet de revenir à la fenêtre principale (figure 14).
 Le bouton (12) permet d’aller à la fenêtre d’affichage du fichier log (figure 18).
 Le bouton (13) permet d’aller à la fenêtre des fréquences (figure17).
 Le bouton (14) permet d’aller à la fenêtre heure durée de consultation de chaque lien
(figure 19).
 Le bouton (15) permet d’aller à la fenêtre des différents liens consultés (figure 16).

La barre des menus statistique regroupe toutes les fonctionnalités des boutons qu’on vient de
présenter.

56
Chapitre4 La réalisation

Un click sur un des choix une fenêtre qui corresponde à l’indicateur va apparaitre.

3.5. Interface la liste des pages consultées :

Cette interface permet à l’utilisateur de voir les différentes pages qui à visiter. La
fenêtre de cette interface est représentée par la figure suivante :

18

20
19

Figure 16 : Fenêtre La liste Des Pages Consultées

Description de l’interface :

Elle se compose d’une barre de menus(18), des boutons(19) et une table(20) qui contient la
liste des pages consultées. La barre des menus regroupe toutes les fonctionnalités de ces
buttons.

3.6. Interface la fréquence:


Dans cette interface, l’utilisateur peut voir la fréquence et la moyenne de consultation
de chaque page.

57
Chapitre4 La réalisation

21
0

22

23

Figure 17 : Fenêtre de La Fréquence d’utilisation des pages

Description de l’interface :

Elle se compose d’une barre de menus(21), de boutons (22) et une table(23) qui contient la
fréquence d’utilisation de chaque page. La barre des menus regroupe toutes les fonctionnalités
de ces buttons.

3.7. Interface d’affichage de fichier log:


Cette interface permet à l’utilisateur de visualiser toute la trace d’interaction et c’est
ce qui est présenté sur la figure ci-dessous.

58
Chapitre4 La réalisation

24

25

26

Figure 18 : Fenêtre Affichage ficher log

Description de l’interface :

Elle se compose d’une barre de menus (24), de boutons (25) et une table (26) qui présente le
contenu de fichier log. La barre des menus (24) regroupe toutes les fonctionnalités de ces
buttons.

3.8. Interface heure durée :


Dans cette interface, l’utilisateur peut voir heure d’accès et la durée de consultation de
chaque page. La fenêtre de cette interface est représentée par la figure suivante :

59
Chapitre4 La réalisation

27

28

29

Figure 19: Fenêtre heure durée de consultation des liens

Description de l’interface :

Elle se compose d’une barre des menus(27), des boutons (28) et une table(29) qui contient
l’heure et la durée de chaque page consultée. La barre des menus à travers laquelle nous
pouvons afficher n’importe quels indicateurs, et ouvrir un fichier log, aussi elle permet quitter
l’application.

4. Conclusion :
Dans ce chapitre nous avons présenté l’environnement du développement de
l’application réalisée. L’objectif principal de cette application est de calculer des indicateurs à
partir d’un modèle de trace que nous avons proposé lors de la conception, en se basant
principalement sur un fichier Log.

Nous avons présenté aussi les différentes interfaces de l’application qui regroupe les
fonctionnalités qu’offre cette dernière.

60
Conclusion générale

61
Conclusion générale

Conclusion générale
Le but principal de ce projet était d’apporter des éléments de compréhension
concernant l’utilisation des traces d’interactions et les processus cognitifs qui y sont associés
dans le cadre d’une activité conjointe, et médiée par un système numérique (site et portail web
à titre d’exemple). Pour cette étude, nous avons mobilisé plusieurs domaines de recherche, et
principalement celui de la trace.

Le domaine de l’utilisation des traces informatiques en interaction homme-machine


est venu nous apporter des connaissances sur les utilisations des traces d’interactions que
certains systèmes proposent aujourd’hui. Nous avons vu que les systèmes traçants pouvaient
être utilisés pour des activités et dans des contextes très différents, en particulier selon le fait
de présenter ou non aux utilisateurs les traces d’interactions.

Au cours de notre travail, guidée par le domaine de recherche mentionné ci-dessus,


nous nous sommes attachés à apporter des éléments de réponses à notre problématique,
concernant d’une part la compréhension du rôle et du statut de la trace dans les interactions
entre un utilisateur et un dispositif numérique et d’autre part de leur utilisation. Nous nous
sommes centrée en particulier sur la construction d’indicateur que nous avons appelé par
ailleurs statistique.

L’observation de l’utilisation des traces d’interactions que nous avons menées, et la


qualification des utilisations observées que nous avons réalisée, participent selon nous à une
meilleure compréhension du rôle des interactions entre utilisateur et système dans le
développement potentiel des utilisateurs, car ces utilisations sont des occasions d’interactions
à partir de l’expérience.

Et ce qui concerne les perspectives, vue la complexité de ce domaine, nous pensons


qu’il reste énormément de choses à faire, et que nous avons touché qu’a une partie de son
introduction. Cependant nous imaginons toujours d’autre améliorations, du coté calcule
d’indicateur (par enrichissement) et visualisation (graphes, histogrammes etc.).

62
Annexes

63
Annexes

Annexe1
UML « Unified Modeling Language »

1. Introduction:
Pour faire face à la complexité croissante de l’ingénierie du logiciel, de nouvelles
méthodes et outils ont été crées. La principale avancée des quinze dernières années réside
dans la programmation orientée objet(P.O.O).

Face à ce nouveau mode de programmation, les méthodes de modélisation classique


(telle MERISE) ont rapidement montré certaines limites et ont dû s’adapter.

De très nombreuses méthodes ont également vu le jour comme OOD, OMT …Dans ce
contexte et devant le foisonnement de nouvelles méthodes de conception « orienté objet »,
l’objet Management Group(OMG) a eu comme objectif de définir une notation standard
utilisable dans les développements informatiques basés sur l’objet. C’est ainsi qu’est apparu
UML (Unified Modeling Language « langage de modélisation objet unifié »), qui est issu de
la fusion des méthodes OOD (Object Oriented development), OMT (Object Modelling
Technique) et OOSE (Object Oriented Software Engineering).

Issu de terrain et fruit d’un travail d’experts reconnus, UML est le résultat d’un large
consensus. De très nombreux acteurs industriels de renom ont adopté UML et participent à
son developpement.En l’espace d’une poignée d’années seulement,UML est devenu un
standard incontournable auquel on donnera une brève présentation de ses quelques concepts.

2. Les concepts de l’approche objet


2.1. L’objet : [36]

Un objet est une représentation simplifiée d’une entité du monde réel, qu’il s’agisse
d’entité concrète (avec une « réalité physique ») ou conceptuelle (abstraite).Les trois
caractéristique fondamentales d’un objet sont l’état, le comportement et l’identité. L’état
correspond aux valeurs instantanées de tous les attributs(ou données membres) de l’objet. Le
comportement décrit les actions et les réactions d’un objet(ou ‘compétences ‘ d’un objet ) et se
matérialise sous la forme d’un ensemble d’opérations(ou méthodes ou fonctions
membres).L’identité permet de distinguer tout objet de façon non ambiguë, indépendamment
de son état (de ses attribut).

64
Annexes

2.2. La classe : [37]

Une classe est une description abstraite (condensée) d’un ensemble d’objet du domaine
(instance de la classe) de l’application : elle définit leur structure, leur comportement et leurs
relations.

a) L’association :

Une association décrit la connexion entre plusieurs classes. Les classes sont
indépendantes les une des autres, dans le sens ou l’existence d’une e instance de ces classe ne
dépend pas d’une autre.

b) L’encapsulation :

Un objet est comme une coquille cachant à l’utilisateur son contenu tant au point de
vue des données que des opérations. Seules les spécifications des opérations dites publiques
sont visibles des utilisateurs. Comme un objet peut contenir d’autres objet, l’encapsulation
permet de diminuer la complexité en limitant la connaissance de l’utilisateur aux seules
choses dont il a réellement besoin.

c) L’héritage :
L’héritage est un mécanisme de transmission des propriétés d’une classe (ses
attributs et méthodes) vers une sous classe.
d) La spécialisation/généralisation :
Le principe de généralisation,/spécialisation permet d’identifier parmi les objet
d’une classe(générique) des sous-ensemble d’objet(des classes spécialisées) ayant des
définitions spécifiques. La classe plus spécifique (appelée aussi classe fille, classe dérivée,
classe spécialisée, classe descendante…) est cohérente avec la classe plus générale (appelée
aussi classe mère, classe générale…) c’est-a-dire qu’elle contient par héritage tous les
attributs, les membres, les relations de la classe générale, et peut contenir d’autres.
e) Le polymorphisme :
Le polymorphisme représente la faculté d’une même opération de s’exécuter
différemment suivant le contexte de la classe où elle se trouve. Ainsi, une opération définie
dans une superclasse peut s’exécuter de façon différente selon la sous-classe ou elle est
héritée

F) L’agrégation :

65
Annexes

Il s’agit d’une relation entre deux classes, spécifiant que les objets d’une classe sont
des composants de l’autre classe. Une relation d’agrégation permet donc de définir des objets
composés d’autres objets. L’agrégation permet d’assembler des objets de base, afin de
construire des objets plus complexes.

2.3. Les diagrammes d’UML : [37]

Un diagramme est la représentation graphique d’un ensemble d’éléments que l’on


représente en générale par un graphe reliant les sommets (éléments) avec des arcs (relations).
Il donne ainsi à l’utilisateur les moyens de visualiser et de manipuler des éléments de
modélisation.

2.3.1. Les diagrammes statiques du système :

• diagramme de cas d’utilisation : (use cases)

Les use cases permettent de structurer les besoin des utilisateurs et les objectifs
correspondants d’un système. Ils centrent l’expression des exigences du système sur ses
utilisateurs : ils partent du principe que les objectifs du système sont tous motivés.

• diagramme de classe :

Le diagramme de classes exprime la structure statique du système en termes de


classes et de relations entre ces classes. L’intérêt du diagramme de classe est de modéliser les
entités du système d’information.

•diagramme d’objet :

Le diagramme d’objet permet de mettre en évidence des liens entre les objets. Les
objets, instances de classe, sont reliés par des liens, instance d’associations. A l’exception de la
multiplicité, qui est explicitement indiquer, le diagramme d’objets utilise les mêmes concepts
que le diagramme de classes. Ils sont essentiellement utilisés pour comprendre ou illustrer des
parties complexes d’un diagramme de classes.

•diagramme de composants :

Les diagrammes de composants décrivent les composants et leurs dépendances dans


l’environnement de réalisation. En général, ils ne sont utilisés pour des systèmes complexes.

•diagramme de déploiement :

66
Annexes

Les diagrammes de déploiement montrent la disposition physique des différents


matériels(les nœuds) qui entrent dans la composition d’un système et la répartition des
instances de composants, processus et objet qui « vivent » sur ces matériels. Les diagrammes
de déploiement sont donc très utiles pour modéliser l’architecture physique d’un système.

2.3.2. Les diagramme dynamique du système :

•diagramme de collaboration :

Le diagramme de collaboration permet de mettre en évidence les interactions entre les


différents objets du système. Dans le cadre de l’analyse, il sera utilisé :

-pour préciser le contexte dans lequel chaque objet évolue ;


-pour mettre en évidence les dépendances entre les différents objets impliqués dans
l’exécution d’un processus ou d’un cas d’utilisation.
•diagramme de séquence :
Le diagramme de séquence est une variante du diagramme de collaboration. Par
opposition aux diagrammes de collaboration, les diagrammes de séquence possèdent
intrinsèquement une dimension temporelle mais ne représente pas explicitement les liens
entre les objets.
• diagramme d’états-transitions :
Ils ont pour rôle de représenter les traitements (opérations) qui vont gérer le
domaine étudié. Ils définissent l’enchainement des états de classe et font donc apparaitre
l’ordonnancement des travaux.
• diagrammes d’activités :
Le diagramme d’activités est attaché à une catégorie de classe et décrit le déroulement des
activités de cette catégorie.

67
Annexes

Annexe2
XML (eXtensible Markup Language)

1. La syntaxe du XML
a) Un élément XML est délimité par deux balises de même nom
b) (<balise></balise>), il peut contenir du texte ou d'autres balises, cependant toute balise
ouverte doit être fermée (contrairement au HTML).
c) Les balises doivent être correctement imbriquées.
d) Les noms de balises peuvent contenir des chiffres, des lettres ou d'autres caractères.
e) Les noms ne peuvent commencer par un nombre ou un signe de ponctuation.
f) Les noms ne peuvent commencer par les lettres XML.
g) Le XML fait la différence entre majuscules et minuscules (ainsi <balise> est différente
de <BaliSe>)
h) Pour les caractères spéciaux il existe des entités prédéfinies :
 &lt ; pour le caractère < (plus petit que)
 &gt ; pour le caractère > (plus grand que)
 &amp ; pour le caractère & (et commercial)
 &apos ; pour le caractère ‘ (apostrophe)
 &quot ; pour le caractère " (guillemets)
i) XML tolère les caractères accentués pour cela il faut ajouter au fichier XML l'entête
suivant : <?xml version="1.0" encoding="ISO-8859-1"?>.
j) Une balise peut contenir un ou plusieurs attributs, dont les valeurs doivent être mises
entre guillemets.
Un fichier XML respectant les règles précédentes est dit « document XML bien formé», c'est-
à-dire qu'il respecte la syntaxe de XML.

2. La DTD « Document type definition » : interne au fichier XML, ou externe, dans ce cas il
faut ajouter l'entête suivant au fichier XML,

3. <!DOCTYPE élément SYSTEM "nom_DTD.dtd">, où élément est l'élément

68
Annexes

< ?xml version = ‘’1.0’’


standalone= ‘’yes’’ ?>

< !DOCTYPE racine [

< !ELEMENT racine(element1,element2)>

< !ELEMENT element1 (#PCDATA)>

< !ELEMENT element2 (#PCDATA)>

]>

<racine>
La DTD contient les règles que doit respecter le document XML. La DTD peut être
racine du fichier XML. Le code<element1>Premier
suivant représente une DTD interne :
élément</element1>

<element2>Deuxième élément</element2>
Première ligne : indique que le fichier est indépendant car il utilise une DTD interne
</racine>
« standalone= ''yes'' ».

Deuxième ligne : indique que le fichier XML à comme racine l'élément <racine>

Troisième ligne : indique que l'élément racine, contient deux éléments qui sont element1 et
element2.
Quatrième et cinquième ligne : indiquent que les deux éléments elemet1, element2
contiennent des chiffre ou des lettres.

a. Les éléments :

La définition d'un élément dans la DTD contient deux parties qui sont le nom de l'élément, et
ce qu'il peut contenir, pour indiquer le contenu d'un élément la notation est comme suit :

 '+' ce qui précède doit être présent une ou plusieurs fois.


 ' ?'ce qui précède doit être présent au plus une fois.
 '*' ce qui précède peut être présent plus d'une fois, comme il peut être absent
 A|B soit A soit B mais pas les deux.
 A,B A et B doivent être présent dans l'ordre indiqué.
 EMPTY Indique que l'élément ne peut rien contenir.
 #PCDATA : « Parsable Character Data », données pouvant contenir des
chiffres ou des lettres.
 ANY : L'élément peut contenir n'importe quel contenu.

69
Annexes

Exemple :

< !ELEMENT personne (nom,prenom,adresse+,tel*) >

b. Les Attributs :

Pour indiquer les attributs d'un élément on utilise la syntaxe suivante :

< !ATTLIST nom_element

Nom_att1 typevaleur

Nom_att2 typevaleur

….

>
Les valeurs d'un attribut peuvent être :

CDATA : La valeur de l'attribut est une séquence de caractères.

ID : La valeur de l'attribut doit être unique.

IDREF : La valeur de l'attribut est un symbole défini comme valeur de l'attribut ID d'un
autre élément.

IDREFS : Plusieurs valeurs, comme IDREF.

(liste) : Un élément parmi la liste.

Exemple :

< !ELEMENT personne (adresse+,tel*)

< !ATTLIST personne

nom CDATA
#REQUIRED

prenom CDATA
#REQUIRED

>

70
Annexes

2. Avantages liés à l'utilisation du XML


On peut néanmoins résumer les apports de son utilisation dans les points suivants :

 Le langage XML étant par définition extensible, nous avons pu définir nos propres
balises avec les attributs que nous avons jugés nécessaires. Cela permet d'avoir des structures
concises et claires. De plus, on peut facilement insérer de nouvelles balises (balise
<Animation> par exemple);
 Le langage XML étant devenu un standard, plusieurs technologies d'analyse et de
traitement ont été développées parmi lesquelles on citera SAX (Simple API for XML). Ces
développements rendent particulièrement aisée sa manipulation par programmes;
 La structure séquentielle et hiérarchique d'un document XML est particulièrement
adaptée à la modélisation des cours qui ont exactement cette structure

3. Les parseurs XML

Le parseur est l’élément de programmation le plus important, puisque c’est lui qui
réalise le travail d’analyse du document XML. Son rôle est de vérifier la cohérence du
document XML (en termes syntaxique et/ou par rapport à un schéma ou une DTD) et de
transmettre à l’application les informations utiles au traitement du document. Tous les
parseurs n’offrent pas la même puissance, certains étant non validant et d’autres validant. De
plus, certains supportent une API SAX ou bien DOM, qui permettent au parseur d’entrer en
communication avec l’application. Pour une application, un parseur fait partie d’une API ou
d’une bibliothèque : ce n’est pas un organe indépendant mais un bloc de traitement que l’on
peut contrôler, comme n’importe quelle méthode externe.
Le Document Objet Model est une norme du W3C. Elle spécifie un API permettent aux
programmeurs d’application d’écrire des fonctions de création, de modification et de
consultation des éléments constitutifs d’un document XML.

71
Annexes

Annexe3

Logiciel mini Key Log

Mini Key Log est un logiciel de surveillance secrète développé par bleu série. Mini
Key Log vous permet de surveiller et d'enregistrer des activités d'utilisateur de façon
inaperçues, mais aussi pour stocker ceci dans les fichiers journaux. Le processus de
surveillance est complètement invisible et facile à employer. Ce logiciel fonctionne avec
Windows XP et Windows Vista.
Exemples d’activités enregistrées par Mini Key Log : Frappes : entrées-Mot de passe, noms
de l'utilisateur, Actif, ouvert ou fermé la fenêtre. clique-souris : droit, gauche, milieu.
opérations-fichier : supprimer, renommer, ouvrir, sauvegarder, copier un fichier.
Exemple de fichier enregistré par Mini Key Log :

72
Annexes

Figure 20 : Extrait de fichier log

73

Vous aimerez peut-être aussi