Dans le cadre de diff\u00e9rents projets, on est amen\u00e9 \u00e0 r\u00e9cup\u00e9rer diff\u00e9rents codes provenant de diff\u00e9rents concepteurs d\u00e9pos\u00e9s sur github. Dans une certaine mesure, ces codes dispose d’une documentation limit\u00e9e et peu d\u00e9taill\u00e9e mais qui permet rapidement de prendre en mains ces codes pour une ex\u00e9cution et obtenir le r\u00e9sultat souhait\u00e9. Maintenant dans un contexte qui le permet o\u00f9 l’on souhaite faire \u00e9voluer le code pour rajouter ou modifier des instructions afin de l’adapter ou de le mettre \u00e0 jour, il est n\u00e9cessaire de se “plonger” de fa\u00e7on plus intense dans la compr\u00e9hension des \u00e9l\u00e9ments et d’\u00e9viter de le d\u00e9grader. <\/p>\n\n\n\n
Dans de dernier cas, plusieurs solutions ont \u00e9t\u00e9 explor\u00e9es comme Sphinx<\/span>, reverse ainsi que Visual Paradigm<\/span> mais rien de concluant et d’adapter pour nos objectifs. En effet, afin d’optimiser les d\u00e9veloppements et la r\u00e9utilisation, il nous semble opportun de constituer une biblioth\u00e8que de composants logiciels. Cette biblioth\u00e8que que l’on se propose de constituer permettra d’identifier \u00e0 partir de requ\u00eates de haut niveau les blocs instructions int\u00e9ressants et correspondants \u00e0 son besoin. Pour ce faire, il est important \u00e0 partir de fichiers sources d’un projet d’\u00eatre capable de reconstituer diff\u00e9rents sch\u00e9mas d’aide et d’analyse.<\/p>\n\n\n\n La solution que l’on souhaite mettre en oeuvre nomm\u00e9e ParsPy<\/strong> est de d\u00e9velopper un parser pour effectuer ces analyses et ainsi constituer notre base de connaissance. Cette solution va s’appuyer sur deux \u00e9l\u00e9ments de fondations une base de donn\u00e9es MongoDB<\/span> et une base de donn\u00e9es de type graphe Neo4J<\/span><\/span>