Présentation de l'application

Réalisée en Java, l'application LogHandler permet de charger des données d'inter-action sous forme de logs quelconque, de les nettoyer et de les stocker dans une base de données (g. B.2). A partir de cet état, LogHandler permet d'exécuter diérentes analyses, comme le calcul de statistiques globales ou la recherche de séquences par-ticulières d'évènements. Les résultats des analyses sont présentés au format HTML. De plus, l'application permet de traduire les logs nettoyés dans le format ARFF1, les rendant compatibles avec l'application WEKA, une librairie JAVA open source, qui ore un ensemble de méthodes de fouille de données.

B.1.1 Interface principale de l'application

L'interface graphique est divisée en quatre sections qui correspondent aux étapes d'une première analyse d'un chier de logs. L'achage tente de partager les fonctions de chargement/correction d'un chier, de sélection des données, du paramétrage des analyses et de l'achage des résultats (g. B.3).

1ARFF (Attribute Relation File Format) : Format de chiers utilisé par la librairie WEKA consacrée au Data Mining (http ://www.cs.waikato.ac.nz/ml/weka/)

Source des Données Données ciblées Données prétraitées Données transformées Motif / Modèles Visualisation Collecter et Filtrer Prétraitements et nettoyage Transformation Analyse Traduction

Fig. B.1: Schéma général de la fouille de données

Les fonctions de chargement et de correction d'un chier de logs sont accessibles par l'option  Load File  du menu  File . Les autres fonctionnalités sont direc-tement visibles sur l'interface. La sélection des données se fait par l'intermédiaire d'un arbre dont la sélection a été redénie. L'utilisateur ne peut sélectionner que les chiers d'une seule interface à la fois car nous avons fait l'hypothèse que les chiers d'une même interface avaient tous le même format. Les onglets de résultats restant achés même après un changement de sélection, on peut comparer les résultats de deux interfaces.

Arbre de sélection

Nous avons vu dans la description de l'interface, la place importante qu'occupait l'arbre de sélection. En eet, c'est par le biais de ce composant que l'utilisateur va déterminer quels chiers seront analysés. Une sélection de tel ou tel chier dans l'arbre va par la suite aecter la saisie des paramètres des analyses (cette caracté-ristique est décrite en détail dans la suite). L'arbre compte en fait trois niveaux, le premier n'est autre que le n÷ud de la base de données. Le second niveau est celui des interfaces des applications étudiées. Nous avons choisi de considérer que chacun de ces n÷uds représente une version particulière d'une même interface (i.e. application). Le troisième niveau est celui des chiers issus de l'utilisation de ces

Fig. B.4: Exemple d'un chier de conguration et de sa DTD

interfaces. La sélection dans l'arbre est contrainte de la façon suivante : tous les n÷uds  chier  sélectionnés doivent avoir le même n÷ud parent, c'est-à-dire être issus de la même interface. Cette contrainte est due aux algorithmes d'analyses qui ne peuvent s'appliquer que sur un format de log à la fois.

B.1.2 Conguration de l'application

L'application LogHandler utilise un chier de conguration pour déterminer quelle base de données utiliser mais aussi quelles analyses proposer dans l'interface de l'utilisateur. Ce chier de conguration n'est lu qu'une seule fois à l'initialisation de l'application ; cela permet d'accéder aux données nécessaires à la mise en place de certains mécanismes de l'interface. Voici un exemple de chier de conguration avec sa DTD :

L'application réagira au fait qu'une base ne soit pas ou plus accessible, en eet une erreur sera générée au moment de la connexion (après le lancement de l'appli-cation) et les fonctionnalités de l'application ne seront pas disponibles. La mention No DataBase  sera précisée en haut de la zone de sélection.

Dans la dénition des analyses sont précisées toutes les analyses qui doivent être disponibles dans l'interface. Simplement le nom ou le chemin (des packages) amenant à la classe d'analyse est demandé pour ajouter une analyse. Si une analyse est marquée dans le chier alors qu'aucune classe n'y correspond, elle ne sera tout simplement pas proposée à l'utilisateur.

Ce mécanisme augmente l'évolutivité de l'application LogHandler, en permettant l'ajout de nouvelles méthodes d'analyse de manière simple.

B.1.3 Préparation des paramètres d'analyses

Une fois que les méthodes d'analyses présentes dans l'application sont détermi-nées et que l'arbre est construit, diérents mécanismes visant à faciliter la saisie des paramètres des analyses sont mis en ÷uvre. Durant l'initialisation, les en-têtes des chiers stockés dans la base sont chargés. Les valeurs distinctes des attributs de type  string  ou  nominal  sont également chargées, permettant ainsi de proposer une liste des noms des attributs et des valeurs de certains attributs. Grâce à cela, on peut utiliser des composants du type  JComboBox  ou  JList  plutôt qu'un champ de texte qui demanderai plus de travail à l'utilisateur de LogHandler.

Si le chargement d'un chier ne pose apparemment pas de problèmes, il est nécessaire de rappeler que la taille des chiers de logs est souvent conséquente (les 20 000 lignes sont en général dépassées). La mise en place de tous ces mécanismes de saisies entraîne donc un certain coût. C'est pour cela que nous avons décidé de charger les données nécessaires pendant la phase d'initialisation de l'application. En eet, réalisé au moment de la sélection, un chargement entraînerai un gel de l'interface pendant le temps du chargement. Pendant la phase d'initialisation, ce traitement est caché jusqu'à l'achage de l'interface.