Guide Maintenance

• Node version v8.11.1
• Npm version v6.0.0

---

1. Organisation du programme

Contenu du programme

Le contenu du dossier de l’outil et l’utilisation du logiciel sont détaillés dans le Readme.md à la racine de l’exécutable.

Lancement du programme

• Le point d’entrée du programme est le fichier Launcher.js à la racine du dossier.
• Il importe la librairie readline, qui permet de créer une interface en ligne de commande, et les différents modules, qui correspondent chacune à une des spécifications décrite dans le cahier des charges.
• A l’exécution du programme, une fonction d’initialisation init s’exécute et appelle la fonction du choix d’un collaborateur choixCollab, qui retourne son nom s’il existe
• Une fois le collaborateur choisit, le menu de l’outil s’affiche dans le terminal grâce à la fonction afficherMenu.
• La fonction choixFonction récupère une valeur entrée de l’utilisateur qui est mis en argument de la fonction launchFunction. Selon la valeur en entrée, l’outil exécute le module correspond, affiche une erreur ou quitte le logiciel.

La version 1.27 de l’outil contient 7 spécifications.

Parse des données

Chacune de ces spécifications utilise le module mailParser.

• Ce module contient une unique fonction nommée parse. La fonction prend en entrée le contenu d’un mail et le parse selon des règles définies dans la fonction. Les différents contenus du mail sont récupérés et utilisés pour instancier un nouvel objet Mail. Cet objet Mail est une instance de la classe mail, qui est définie par dans module Mail.
• Le module mailParser est exécuté par une fonction récursive lireFichier de lecture de tous les fichiers présents dans le dossier contenant tous les mails. Cette fonction se trouve dans un module utils pour toutes les spécifications, excepté la spec1 où elle se trouve directement dans le module de la spécification. La fonction retourne un tableau tableauMails contenant tous les mails triés.

Principaux composants et fonctions

Spec1 : Extraire les contacts

Le module spec1 est une unique fonction qui parcours les fichiers du collaborateur, les lis et en extrait les coordonnées. Elle est similaire à la fonction lireFichier, cependant le nom du dossier est aussi nécessaire c’est pourquoi la fonction se trouve au sein du module.

Spec2 : Extraire liste des mails

Le module spec2 exécute et récupère le résultat du parse des mails puis affiche les dix derniers mails reçus ou envoyés. Un sous menu apparaît avec la méthode choisir et selon la valeur entrée par l’utilisateur exécute une des fonctions présentes dans le module : previousMail, export10, ou exporttotalite. Elle peut aussi afficher une erreur ou retourner au menu principal.

Remarque : Les modules des spécifications 3 à 5 et 7 s’organisent un peu différemment. Dans la fonction init de chacune d’elles on retrouve seulement des appels de fonctions contenues dans le module. Le code de traitement de la spécification n’est écrit plus directement dans la fonction init.

Spec3 : Quantité de mail échangés selon une période

Le module spec3 se présente de la même manière que spec2 au niveau de l’initialisation. Dedans, la fonction choix1 est exécutée. On retrouve trois appels de fonction :

• La fonction choix_periode qui permet de définir la période.
• On compare la date de tous les mails avec la fonction verification_date qui prend entrée la période et on ne garde que ceux qui correspondent. Ils sont ajoutés dans une variable globale du module.
• La fonction choisir permet d’afficher un sous menu comme dans la spec2.

Le résultat sera utilisé lors de l’export avec la fonction choix2.

Remarque : Le résultat du parse est passé en argument de la fonction qui exécute la spécification pour les spécifications 4 à 7.

Spec4 : Extraire les BuzzyDays

Le module de la spec4 récupère la liste des mails d’un collaborateur choisi (utils.lireFichier) et détermine à partir de leur date ceux qui entrent la catégorie buzzy days avec la fonction buzzydays. Elle affiche ensuite cette liste et il est proposé à l’utilisateur via la méthode choix de l’exporter ou de revenir au menu principal.

Spec5 : Termes les plus employés dans les objets

Le module spec5 récupère la liste des mails, qui est stockée dans un tableau tableauMails. Ce tableau est mis en argument de la fonction TopMotsObjet, qui range dans un tableau les différents termes employés dans les objets des mails ainsi que leur nombre d’apparitions. Les dix premiers termes de ce tableau sont ensuite affichés, et il est proposé à l’utilisateur via la méthode choisir de l’exporter ou de revenir au menu principal.

Spec6 : Utilisateurs les plus proches

La fonction topInterloculteur du module spec6 fait un dictionnaire avec le nom du destinataire et le nombre de mails envoyés. Il est stocké dans une variable globale interlocuteurs du module. Les valeurs sont triées dans la fonction init selon le nombre de mails envoyés et un nouveau dictionnaire est créé dans la variable top10interlocuteurs. La liste s’affiche et il est proposé à l’utilisateur de l’exporter ou de revenir au menu principal avec la méthode choisir.

Spec7 : Graphique des échanges

La fonction choisirGraphique redirige avec un sous-menu qui permet à l’utilisateur d’exporter un graphique, de revenir en arrière ou d’afficher une erreur. L’export du graphique est exécuté avec la fonction exportGraphByDay qui récupèrent les mails triés. Ils sont ensuite triés par date et ajouté dans une variable globale datesArray. Pour chaque date, on compte le nombre d'occurrence des mails pour un collaborateur donné. Lorsque l'occurrence est positive, elle est stockée dans un objet avec la date correspondante. L’ensemble des objets est dans un tableau datesOccurencesArray qui est passé en valeur un objet VegaArray avant d’être converti en graphique grâce à la librairie VegaLite.

---

2. Pistes d'évolution à long terme

À long terme, il faudrait refactoriser le code pour permettre au logiciel de pouvoir accepter n’importe quel set de données. Actuellement, le nom des collaborateurs est écrit en dur avec des conditions dans le code.

Il faudrait également faire en sorte que tous les modules soient organisés de la même manière. Certains modules contiennent des lignes de codes dans leur fonction init permettant le traitement de la spécification. Il serait plus judicieux de les encapsuler dans des fonctions avec des noms clairs et de faire seulement un appel de ces dernières. Le nom des variables et des fonctions doivent rester identiques d'un module à l'autre si elles ont la même utilité. La syntaxe doit être cohérente partout (séparer les mots par des _ ou camelcase par exemple). Une organisation homogène du code permettrait de le simplifier et le rendre plus lisible. La reprise du logiciel par un autre développeur, sa maintenance et son évolution seraient plus aisées.