f (find_min) V = 43 g (exchange) V = 24 h, k (sort) V = 86 g (exchange) V = 24 0
h, k (sort) V = 86 46 24
l, o (sort2) V = 103 46 24 80
Fig. 7.6 – Matrice des volumes partagés par les fonctions de tri
Ces volumes partagés peuvent ensuite être mis en rapport avec le volume des fonctions feuilles atteignables depuis l’une des fonctions comparées ou bien par rapport au volume de l’union des fonctions feuilles atteignables depuis les deux fonctions originelles comparées. Ces méthodes de normalisation seront décrites plus en détails ultérieurement en 12.3.2.
7.8 Étude expérimentale de projets d’étudiants
Nous souhaitons étudier les similarités d’un jeu de projets d’étudiants en factorisant leurs graphes d’appels. Nous nous intéressons à des projets en langage C dont la résolution de liens d’appels de fonctions peut être réalisée sans ambiguïté (en faisant abstraction de l’usage de pointeurs de fonction). La série de mini-projets étudiés a été réalisée au cours de travaux- dirigés par différents groupes d’étudiants sur quatre années, certains énoncés de projet ayant été traités par plusieurs promotions. Nous cherchons à quantifier les plagiats réalisés entre étudiants d’une même promotion sur un énoncé donné de projets, au sein d’une même pro- motion ainsi qu’entre différentes promotions. Nous nous intéressons également au phénomène d’auto-plagiat où un étudiant réutilise son propre code d’un projet précédent : cette approche est encouragée dans le cadre d’un développement modulaire et générique.
Projet Composantes Nombre de projets
2007 2008 2009 2010
Jeu de serpent File 17 15 16 15
Calculatrice RPN Pile 14 15 13 14
Compresseur Move To Front Liste chaînée, bibliothèque de codage d’entier
11 12 11 15
Arbre d’expression Pile 10
Autres projets (Huffman, réussites, calculatrice modulaire)
Pile, liste... 3 10 6
Fig. 7.7 – Jeu de projets d’étudiants étudié
7.8.1 Étude des feuilles et calcul de la similarité des projets
Les projets étudiés ainsi que l’effectif des promotions l’ayant traité sont indiqués en fi- gure 7.7. L’ensemble des projets rendus sont lexemisés afin de générer pour chacun un graphe de séquences d’appel ; ces graphes étant factorisés ensuite par la recherche de facteurs de lexèmes exactement égaux (moyennant une abstration des identificateurs et types) selon la méthode décrite précédemment au cours de ce chapitre. Le seuil de report de correspondances est fixé à t = 10 lexèmes. Nous recherchons pour chaque paire de projets le volume additionné des l’intersection des différentes fonctions feuilles que leurs fonctions initiales atteignent. Sur
les 199 projets initiaux et 19 701 paires correspondantes, 19 181 partagent au moins une fonc- tion feuille de volume d’au moins 10 lexèmes.
Il est probable que certaines fonctions feuilles sont issues de factorisation de code courant. Du tel code peut être lié à des formes idiomatiques de séquences de lexèmes ou alors à l’inclusion dans le projet rendu de bibliothèques fournies en énoncé (e.g. une bibliothèque graphique pour le jeu de serpent). À cet effet, nous introduisons une métrique de multiplicité sur les fonctions. Une fonction possédant pour fonctions racines dans le graphe d’appel factorisé des fonctions extraites de m projets distincts est de multiplicité m. Le graphe factorisé comporte 34 498 fonctions feuilles dont 2 391 issues de correspondances relevées (feuilles non-intersticielles). Nous classons ces dernières selon leur multiplicité (figure 7.8) :
Multiplicité 1 2 3..4 5..9 10..19 20..49 50..99 100..150
Nombre de feuilles 559 686 493 389 152 85 24 3
Fig. 7.8 – Répartition des fonctions feuilles par multiplicité
On choisit par la suite d’exclure les feuilles de multiplicité d’au moins M projets. Ce seuil ne doit pas être inférieur au plus grand groupe de projets similaires sans toutefois être trop élevé en permettant la prise en compte de similarité commune. Nous choisissons M = 50 projets. Ce choix élimine environ 20 % de paires de projets ne possédant en commun que des feuilles de multiplicité supérieure ou égale à 50.
Les paires de projets de similarité supérieure à 7
10 (similarité simmin normalisée par rapport
au volume des feuilles du plus petit projet) sont examinées manuellement. On en dénombre 19 dont 9 présentant une très forte similarité (supérieure à 9
10). Trois types de paires de projet
similaires se distinguent :
1. Les paires concernant un même projet copié au sein d’une même promotion (12 paires). Sans surprise, ces paires fortement similaires de projet plagié ont déjà pu être identifiées par le correcteur sans faire appel à un outil.
2. Les paires de projet copié entre différentes promotions (4 paires). Ces paires sont in- decelables par un correcteur humain qui ne peut avoir une mémoire globale de projets rendus sur différentes années2
3. Les paires de projet auto-plagiées où certains modules communs sont réutilisés (3 paires). Les frontières entre ces familles sont cependant floues : un projet rendu peut en effet em- prunter du code de plusieurs projets rendus, inter- ou intra-promotion, eux-mêmes ayant fait l’objet d’auto-plagiat et ainsi induire par transitivité de nouvelles relations de similarité indi- recte. On notera que la similarité étant considérée symétrique, nous ne pouvons déterminer automatiquement l’auteur originel d’un morceau de code3.
2
Un seul cas a pu être observé manuellement : l’étudiant avait rendu par mégarde la copie conforme d’un projet d’un étudiant d’une année antérieure disponible publiquement sur le web au lieu de son propre projet. Cette copie comportait toujours le nom de l’auteur original dans sa documentation. Ce même projet a également été repris par un autre étudiant mais en y introduisant des modifications.
3
7.8. Étude expérimentale de projets d’étudiants 124
Types de paires Normalisation Effectif total ]108..1] ]105..108] ]102..105] ]101..102] ]0..101]
Jeu de serpent simmin 2 016 2 11 53 379 1 062
Calculatrice simmin 1 540 4 2 27 150 511
Calculatrice 2007
Arbre d’expression 2007 simmin 238 1 4 7 13 55
Jeu de serpent
Compresseur simmax 3 087 0 0 0 1 1 301
Tous projets
Projet externe simmax 198 0 0 0 0 62
Fig. 7.9 – Étude des valeurs de similarité entre paires de projets sur différents sous-ensembles de paires
Utiliser différentes méthodes de normalisation (telles que discutées en 12.3.2) permet un meilleur aperçu des formes d’emprunt de code. Si la normalisation par rapport au plus petit projet (simmin) est une métrique intéressante pour quantifier le plagiat, les volumes respectifs
des feuilles atteintes par chaque projet comparé (V(p1) et V(p2)) permet d’affiner le scénario
de copie. Si V(p1) << V(p2), simmin >> simmax. En supposant simminélevé, nous pouvons en-
visager l’hypothèse, comme exprimé au chapitre 4 consacré à l’obfuscation, que le plagiaire ait copié le projet original en y ajoutant du code inutile. En pratique le code rajouté n’est jamais trivialement inutile : dans le cas contraire, son caractère serait rapidement mis en évidence par le correcteur. Plusieurs scénarios sont envisageables : soit l’ajout de fonctionnalités sup- plémentaires originales à partir d’une base plagiée, soit au contraire la copie uniquement des fonctionnalités essentielles abandonnant ainsi l’usage de code présent dans le projet original.
Nous étudions plus finement les paires similaires en considérant quelques sous-ensembles. Les premiers concernent des paires concernant un même projet, les seconds des projets différents comportant plus ou moins de modules pouvant faire l’objet d’un partage par auto-plagiat. Nous ignorons les feuilles de multiplicité strictement supérieure à 20. Le résultat est présenté en figure 7.9.
Les paires de forte similarité ont déjà été examinées précedemment : il est intéressant de considérer les paires de similarité moyenne (simmin∈ [102..108]). Elles sont proportionnellement
plus nombreuses pour le jeu de serpent que pour la calculatrice. Une analyse humaine confirme les emprunts de code entre les différents projets ; plus ou moins importants. Dans quelques cas, on pourrait subjectivement considérer la valeur de similarité sous-évaluée liée à des opérations répétées de réécriture d’expression (telles que var++ réécrit en var = var + 1 ou tab[i] en *(tab+i)...). La lexémisation d’un arbre de syntaxe abstrayant les petites expressions auraient probablement amélioré le rappel. Un exemple de graphe d’appels entre deux rendus de projet calculatrice en promotion 2007 (simmin∼ 0, 69, simmax∼ 0, 59) est présenté en figure 7.10.
En ce qui concerne les rendus de projet du jeu de serpent, nous exposons en figure 7.11 une carte de similarité (représentation graphique présentée ultérieurement en sous-section 14.2.2) permettant d’avoir un meilleur aperçu global des relations de similarité entre rendus : chaque rectangle modélise une paire de projets rendus, les côtés étant de longueur proportionnelle aux volumes globaux des projets et leur luminosité une fonction affine de leur similarité (en utilisant une normalisation par rapport au volume de l’union des feuilles). Étant donnée la méthode de normalisation, cette représentation est symétrique. Les projets y étant ordonnés
1::Evaluation
1::Depiler 1::Est vide pile
1::main 2::eval 2::inipile 2::main 2::estvide 2::estop 2::empiler 2::depiler 1::Empiler 1::Initialiser pile 1::Est operateur
7.8. Étude expérimentale de projets d’étudiants 126
Fig. 7.11 – Carte de similarité des rendus de projets de jeu de serpent
selon leur chronologie de rendu, la distance d’une paire par rapport à la diagonale permet de déduire la proximité temporelle des rendus et ainsi repérer des similarités au sein ou entre promotions comme pour le 3e rendu présentant une similarité importante avec deux rendus
de la même promotion et deux autres rendus d’une promotion différente.
Des paires composées de projets différents ont également été comparées. Les rendus de projet de calculatrice de la promotion 2007 ont été confrontés à ceux de l’arbre syntaxique d’expres- sion de la même promotion. Les fortes valeurs de similarité s’expliquent par l’utilisation d’une même structure de pile générique au sein des deux projets. Dans certains cas les étudiants ont choisi de réimplanter une nouvelle variante de pile. Contrairement à ces deux projets, le jeu de serpent et le compresseur ne disposent pas a priori de composantes pouvant être réutilisées. Les valeurs de similarité normalisées par rapport au projet le plus volumineux (généralement le compresseur) sont majoritairement inférieures à 3%. Lorsque nous comparons tous les projets étudiés à un autre projet externe quelconque (sans possibilité de modularisation de compo- sante commune), les valeurs de similarité suivent la même répartition. Les quelques feuilles partagées sont de poids faible et représentent du code assez commun mais n’étant toutefois pas éliminé par le seuil de multiplicité maximale adopté (un exemple est présenté en figure 7.12). On notera que l’on ne s’est pas intéressé ici à la similarité intra-projet qui pourrait également être utile afin d’évaluer des projets d’étudiants. Ceux-ci pourraient utiliser eux-mêmes un outil de recherche de similarité dans l’optique d’une amélioration de la modularité et généricité de leur code. Un tel service pourrait être intégré à une plate-forme de rendu de projets [136].
56 if((chemin=(char ∗) malloc(sizeof(char)∗j))==NULL) { libereArbreLexicographique(&dico);
return3;
(a) Projet externe
64 if(NULL==(plugin=(char ∗)malloc(sizeof(char)∗MAX))){ 65 perror("erreur␣malloc␣plugin\n");
exit(EXIT_FAILURE);
(b) Rendu de calculatrice modulaire
Fig. 7.12 – Un exemple de clone commun (de multiplicité 5) partagé entre le projet externe et un rendu de la calculatrice modulaire
Itération 1 2 3 4 5 6 7
Nombre de feuilles (longueur ≥ t) 8 877 17 589 8 494 4 915 4 171 3 999 3 969 Longueur cumulée des feuilles 493 590 340 321 123 829 60 282 48 436 45 942 45 548
Longueur du LCP maximal 535 147 96 96 21 13 11
Nombre de correspondances reportées 19 311 15 565 4 776 995 211 34 3 Longueur moyenne des correspondances 21,9 16,7 14,4 13,1 12,0 10,7 10,3 Temps d’exécution (en UAa
) 20,6 7,34 2,50 1,27 0,931 0,902 0,896
Fig.7.13 – Caractéristiques d’itérations de factorisation
a
Une UA équivaut à 1 seconde en mono-fil avec le JRE Sun 1.6 64 bits sur un CPU Intel P8600 2,4 Ghz (cache : 3 Mio, RAM : 4 Gio, ∼4787 bogomips).
7.8.2 Étude expérimentale de la factorisation et du graphe d’appel factorisé résultant
L’exécution de plusieurs itérations de factorisation permet la recherche de facteurs imbri- qués. Le processus de factorisation s’achève lorsque le plus long facteur partagé sur les feuilles est de longueur inférieure au seuil de report t. Nous nous intéressons ici aux feuilles du graphe factorisé à l’issue de chaque itération. On rappelle que la mise en évidence à l’itération k d’une correspondance sur une feuille présente à la fin de l’itération k − 1 conduit à la création d’une nouvelle feuille pour le sous-facteur correspondant ssi ce sous-facteur n’est pas une feuille en- tière : cette opération n’a pas d’incidence sur la longueur cumulée des feuilles. En revanche l’identification à une feuille entière permet de supprimer un exemplaire de cette feuille dans la fonction en cours de factorisation. Au cours des itérations, la longueur cumulée des feuilles diminue. Le graphe final ne comprend, parmi les feuilles de longueur d’au moins le seuil de report, aucune duplication de longueur au moins t. On notera que la taille du graphe rend son exploitation par visualisation globale ardue : toutefois, comme illustré en figure 7.10, le filtrage des nœuds atteints uniquement par quelques projets, lorsqu’ils sont de taille raisonnable, reste envisageable. D’autre part, même si le seuil de report t adopté est faible, on pourra choisir a posteriori d’ignorer des nœuds du graphe représentant des correspondances trop courtes.