Ce guide est destiné aux mainteneurs de l'outil en ligne de commande "Messi". Il permettra une bonne maintenance du logiciel, ainsi que des pistes d'évolution de ce dernier sur le moyen terme.
Organisation du programme :
• Le programme utilise plusieurs fichiers et un répertoire afin de fonctionner correctement. Il utilise les fichiers "caporalCli.js", "hashtag.js", "liste.js", "parser.js", "retweet.js", "tweet.js" et "user.js", mais aussi le répertoire "data".
• Le fichier qui lance l'appel de chaque fonction est le fichier "caporalCli.js". En effet, au sein de ce fichier, les fonctions sont bien organisées de manière à faciliter la maintenance et l'évolution du logiciel. Les appels aux fonctions sont séparés suivant les spécifications indiquées dans le cahier des charges, ce qui permet une visibilité et une clarté incomparable pour le mainteneur.
• L'utilisation d'un parser est un élément très important dans cet outil. Celui-ci a été représenté dans le fichier "parser.js", qui nous permet notamment d'extraire les informations des fichiers ".csv" et de faire les appels aux différentes classes que nous allons vous présenter par la suite.
• Durant la programmation de cet outil, ont été créées 4 classes à travers 4 fichiers différents :
Tweet qui est utilisée dans le parser. Cette classe recense l'intégralité des informations proscrites par un tweet. Ces informations vont être ensuite bien sélectionnées/triées (conserver celles qui nous intéresse selon la fonctionnalité demandée).ListeTweet qui est utilisée dans le fichier "caporalCli". Affectée à la SPEC1, elle permet de sélectionner les informations nécessaires demandées par le cahier des charges. Les informations conservées seront notamment insérées dans un fichier ".txt". Retweet qui est utilisée dans le code principal (fichier "caporalCli.js"). Celle-ci permet de stocker les informations nécessaires au bon fonctionnement de la SPEC1.1 et au respect du cahier des charges.User qui est utilisée de la même manière que la classe Retweet dans le code principal. Cette fois-ci, la classe permet de stocker les informations nécessaires au bon fonctionnement de la SPEC1.2 selon le cahier des charges. La maintenance de cette spécification suivra pleinement celle de la SPEC1.1.Hashtag qui est utilisée d'une manière différente dans le code principal. Effectivement, les informations stockées ne sont utilisées qu'à des fins d'affichage dans le terminal. Cette classe est utilisée doublement : dans la SPEC2 et la SPEC3.Perspectives d'évolution :
• Les différentes fonctionnalités introduites dans la version originale du programme ne nécessitant pas de chemin de répertoire particulier lors de la commande effectuée, les changements effectués sur le mode de fonctionnement de la fonction "createList" semblent inutiles. Ainsi, il pourrait être intéressant d'ajouter un argument obligatoire à la commande effectuée par l'utilisateur : le chemin du dossier/fichier à traiter pour la requête concernée. Exemple :
node caporalCli.js <Commande> <dirPath> [Arguments] [Options]
• De nouvelles fonctionnalités seraient intéressantes à introduire. Comme indiqué dans les tickets n°4 et n°6, en suivant l'évolution indiquée juste au-dessus, il pourrait être utile d'ajouter des fonctionnalités d'ajout et de suppression d'éléments au sein de fichiers ".txt". En effet, "createList" permettrait la création d'un fichier vide au nom propre ; "addList" permettrait l'ajout d'un tweet (et toutes ses informations) dans un fichier créé au préalable ; "supList" permettrait de supprimer un tweet (et toutes ses informations) dans un fichier existant déjà aussi. Voici des exemples de commandes possibles :
node caporalCli.js addList <dirPath> tweetConcern fichExist --> On pourrait imaginer utiliser des options particulières afin de sélectionner le bon tweet lors de l'ajout.
node caporalCli.js supList <dirPath> tweetConcern fichExist --> De même que la commande ci-dessus.
• Le suivi de la composition d'un fichier/liste de tweet pourrait être aussi intéressant. En effet, afin de rendre l'outil viable et quelque peu réaliste, cette fonctionnalité, "infoList", serait fondamentalement obligatoire. Cette fonctionnalité afficherait dans le terminal le contenu d'un fichier qui a été créé et respectant une certaine structure (un message d'erreur apparaîtrait dans le cas contraire). La commande entrée par l'utilisateur pourrait être la suivante :
node caporalCli.js infoList <dirPath> fichExist --> Une option permettant d'introduire des critères d'affichage pourrait être aussi ajoutée.
Remarque :
De nombreuses autres implémentations pourraient être potentiellement citées. Cependant, le but du livrable n°3 est de réfléchir sur le moyen terme. Ainsi, des implémentations plutôt basiques sont attendues.
De plus, pour rappel, le mode de fonctionnement de l'outil actuel ne correspond absolument pas avec les fonctionnalités/implémentations proposées plus haut. C'est pourquoi les perspectives d'évolution données dans l'espace dédié changerait totalement l'aspect général du logiciel (nous sortirions totalement du cadre du livrable n°3).