Guide Maintenance modified by Nathalie Zhang

Nathalie Zhang — Mon, 07 Jan 2019 15:03:44 -0000

--- v2
+++ v3
@@ -1,5 +1,7 @@
 * Node version v8.11.1
 * Npm version v6.0.0
+
+-----

 # 1. Organisation du programme
 ## Contenu du programme
@@ -27,9 +29,11 @@
 **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.
@@ -41,7 +45,12 @@
 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.

Guide Maintenance modified by Nathalie Zhang

Nathalie Zhang — Mon, 07 Jan 2019 15:01:47 -0000

--- v1
+++ v2
@@ -1,7 +1,48 @@
-**1. Organisation du programme**
-*Organisation général puis détaillé si nécessaire par exemple si  le code d'une spec appel celui d'une autre spec*
+* 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.

-**2. Pistes d'évolution**
+## 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.

Guide Maintenance modified by Chloé Chamaillard

Chloé Chamaillard — Sun, 30 Dec 2018 15:38:28 -0000

1. Organisation du programme
Organisation général puis détaillé si nécessaire par exemple si le code d'une spec appel celui d'une autre spec

2. Pistes d'évolution

Recent changes to Guide Maintenance

Guide Maintenance modified by Nathalie Zhang

Guide Maintenance modified by Nathalie Zhang

Guide Maintenance modified by Chloé Chamaillard