Chargement d'un chier

Des logs vers un format plus souple

Nous avons présenté les chiers log qui ont été récupérés après les bêta-tests du produit d'Océ (Tab. B.1). Ces chiers logs sont constitués de 6 attributs dont un de type Date. Nous allons dresser le tableau des types WEKA correspondants à ces attributs, ce qui nous servira à comprendre comment générer l'en-tête du chier ARFF correspondant à un chier de logs quelconque.

Les logs enregistrés sont le fruit d'un premier ltrage des évènements. Nous avons précisé plus haut que seuls les évènements ActionEvent, ItemEvent et WindowEvent ont été conservés. Les valeurs du champ Event ont donc un nombre de possibilités très réduit par rapport à ce qu'on peut obtenir. C'est typiquement un attribut de type nominal.

Transformation des logs vers un format hybride

Pour traiter les chiers de logs nous avons besoin du séparateur d'attributs. Dans nos logs ce séparateur n'est autre que le  ; . Nous avons donc toutes les informations pour décomposer chaque ligne de notre chier. Le premier traitement réalisé est une analyse sur un échantillon des lignes de logs, an de deviner le nombre d'attributs et leurs types.

l'at-yyyy-dd-MM HH :mm :ss HH :mm :ss yyyy-MM-dd yyyy-MM-dd HH :mm :ss HH :mm :ss yyyy-dd-MM MM-yyyy-dd HH :mm :ss HH :mm :ss MM-yyyy-dd dd-yyyy-MM HH :mm :ss HH :mm :ss dd-yyyy-MM MM-dd-yyyy HH :mm :ss HH :mm :ss MM-dd-yyyy dd-MM-yyyy HH :mm :ss HH :mm :ss dd-MM-yyyy Tab. B.2: Types de dates reconnues par le parseur

tribut j dans cette ligne. Jusqu'à présent nous avons stocké uniquement les données d'interaction contenues dans le chier. Il faut préparer le chier pour la génération et la modication éventuelle de son en-tête. Pendant le scan des lignes, nous avons stocké les valeurs distinctes de chaque attribut. Ceci dans le but d'orir à l'utilisa-teur la possibilité de changer le type de son attribut en type nominal. De plus cela permet de donner une prévision du type de chaque attribut. On va déterminer les types des champs d'un log, grâce à un parcours d'un nombre xe de lignes. Nous avons choisi de procéder à la vérication dans cette ordre : numeric, date, nominal et string. Le type string est le type par défaut d'un attribut, s'il n'a pas validé les premiers tests. La vérication d'un champ numérique est simple, il sut de regarder si la chaîne ne contient rien d'autre que des chires ou une virgule. Un type nomi-nal peut-être considéré comme un attribut ayant un nombre de valeurs distinctes assez faible (constante xée à 15 valeurs). Le type date impose une vérication plus rigoureuse que les autres types. En eet, nous tentons de reconnaître 12 formats de date référencés dans le tableau B.2.

Cependant il existe des cas où le format sélectionné n'est pas le bon. En eet, certains formats sont équivalents sur une période bien précise du mois. Par exemple, du 01 mai 2006 au 12 mai 2006, les deux formats suivants sont équivalents :  yyyy-dd-MM HH :mm :ss ,  yyyy-MM-dd HH :mm :ss . Mais arrivé le 13 Mai, seul l'un des deux reste valide. Le fait de déterminer le format sur un échantillon va mener à ce type de cas. Une des solutions possibles serait de tirer les lignes étudiées aléatoirement dans le chier. Mais il n'est pas garanti que ce cas de gure ne se reproduise pas. Reconnaître tous ces formats va nous permettre de manipuler une bonne partie de chiers de logs ayant un champ date. Cependant nous n'utiliserons par la suite qu'un seul format de date an de nous simplier la manipulation des données.

La détermination du type va permettre d'avoir un premier en-tête du chier qui va nous servir à repérer certaines erreurs du log. Ces erreurs seront stockées lors d'une seconde lecture du chier, après que l'en-tête soit déni. Pour le moment, on considère que les erreurs sont les indices des lignes contenant au moins un attribut

non valide, manquant ou supplémentaire.

Le contenu d'un chier de logs est maintenant :  Noms des attributs

 Nombre d'attributs  Un tableau de lignes  Le type des attributs

 L'ensemble des valeurs distinctes des attributs  Indices des lignes contenant des erreurs.

Cette structure ressemble à celle d'un chier ARFF ; elle permet de modier l'en-tête et de repérer les lignes erronées.

Le parseur ARFF ad hoc (raisons et mise en oeuvre)

Nous avons vu que l'application utilisait des chiers ARFF contenant encore des erreurs. Nous aurions pu utiliser le parseur ARFF fourni avec WEKA si celui-ci ne s'arrêtait pas à la première erreur. De plus, ce parseur ne conserve pas les valeurs distinctes de tous les attributs mais seulement celles de type  string  et  nominal . Nous avons implanté notre propre parseur ARFF capable de parcourir tout un chier malgré les erreurs qu'il contient et donnant la possibilité de changer l'en-tête. Le principe de ce parseur ne dière pas beaucoup de celui du parseur précédent. Cependant il doit prendre en compte la présence des commentaires, la signication du symbole  ? 2et la présence de la balise  @relation  qui est le nom de la base de données contenues dans le chier. Nous allons encore changer notre représentation du chier log pour y inclure cette balise. N'ayant pas cette information dans nos logs bruts, on considéra que la valeur par défaut est le nom du chier.

Les étapes du chargement

A cette étape, deux possibilités s'orent à l'utilisateur : soit le chier est un log quelconque, soit les données d'interaction sont exprimées au format ARFF (conte-nant des erreurs ou non). Dans le premier cas, l'utilisateur passe par un écran de saisie du caractère séparateur avant d'obtenir le panneau de correction. Dans le cas d'un chier au format ARFF, on accède directement au panel d'édition de l'entête et de correction après le chargement du chier (Fig. B.5).

2Symbole  ?  : le point d'interrogation dans le format ARFF exprime le fait que la valeur pour ce champs soit inconnue.

Fig. B.5: Chargement d'un chier de logs dans l'application

Fig. B.6: Sélection d'un type numérique