Hubert Wassner

Professeur d'informatique

10 04 2009

Analyse anti-plagiat à grande échelle ... (avec Baldr)

+

Baldr est l'outil anti-plagiat que nous (prof' et étudiants de l'ESIEA) avons créé. J'ai donc l'habitude de l'utiliser à chaque rendu de Travaux Pratique (TP) en informatique, ce qui me permet en 1 minute de repérer les codes qui se ressemblent « trop ». Jusqu'à présent j'ai traité en même temps entre 30 et 40 fichiers à la fois... Là, pour la première fois j'ai plus de 250 codes à analyser! Ces codes sont issus du concours de programmation Wingineer...

Avant d'analyser les codes proposés par les candidats du concours Wingineer, regardons d'abord comment ça marche sur un exemple...

Baldr produit une mesure distance entre tous les codes analysés. Naturellement les codes ayant des distances proches sont ceux qui ont le plus de chances de contenir du plagiat.... Cette image montre l'histogramme des distances sur un rendu de TP :

Comment l'interpréter ? L'axe x représentante la distance, et l'axe y représente le nombre de paires de codes ayant cette distance entre eux.

  • La distance la plus probable entre 2 codes pris au hasard est environ 0.75 (le pic le plus haut). Cette distance est donc « normale », si on fait l'hypothèse que les fraudeur/plagiaires sont minoritaire.
  • La question est alors : en dessous de quelle distance est-ce inquiétant (=fraude potentielle) ?... En regardant l'histogramme ont voit que la courbe baisse au fur et à mesure qu'on se déplace vers la gauche (en partant du pic). Cela veux dire plus on s'intéresse aux paires de codes ayant une distance faible entre eux, moins il sont nombreux. On voit même que vers 0.5 il n'y en a plus du tout... Et vers 0,46 il y a à nouveau un tout petit pic, cette distance est à la fois la distance la plus faible de l'ensemble et en plus il n'y a pas d'autres valeurs de distances proches. Il s'agit donc la d'une distance « a-normale » entre deux codes, c'est une suspicions de fraude. (Qui sera avéré après analyse manuelle des codes en question).

Regardons maintenant le même type d'analyse mais maintenant sur les +250 codes des candidats au concours Wingineer.


Baldr va donc me permettre d'estimer le niveau de plagiat (copie) qu'il y a entre les candidats du concours Wingineer.

En applicant la même analyse que précédemment, on constate que :

  • le nombre de codes ayant une forte ressemblance entre eux est faible. En pratique il s'agit en fait des candidats qui n'ont fait que soumettre des codes d'exemples proposé sur le site du concours, (avec très peu de modifications). Il n'y a donc pas de plagiat/fraude à proprement parler.
  • La courbe est beaucoup plus étalée que ce que j'ai l'habitude de voir pour les rendus de TP, pourquoi ?
    • Le profils des candidats est beaucoup plus large que ce que on peut avoir dans une classe (dans les inscrit il y a des gens qui sont en classe de seconde et d'autres qui ont un doctorat !, dans une classe il n'y a pas autant d'écart de niveau).
    • la nature du problème autorise beaucoup plus de solutions différentes qu'un TP classique d'info' (c'est la raison pour laquelle, le concours peut à la fois intéresser un lycéen de seconde et quelqu'un qui a un doctorat en informatique)

Si on fait la même analyse uniquement sur les candidats en classe de terminale, voilà ce qu'on obtient.

On voit alors que l'histogramme est plus « étroit » (entre ~0.3 et ~0.9), c'est logique puisqu'alors on a à nouveau une population plus homogène en terme de compétences informatique (même si il reste des différences, la variabilité est moins importante que sur l'ensemble des candidats...)

Cela peut paraître futile mais ce qui est bluffant dans cette expérience c'est que j'ai pu extraire ces informations en 2 minutes !! Sans l'outil Balr, il aurait fallu analyser plus de 250 codes et faire plus de 30.000 comparaisons, bref un travail de titan...

Voyez cet article pour plus de détails sur le fonctionnement de Baldr...

Notez ce billet : 0 vote(s)

Vous avez trouvez intéréssant ce billet? Abonnez-vous au flux RSS pour être tenu informé des prochains!

Trackbacks

Aucun trackback.

Les trackbacks pour ce billet sont fermés.

Commentaires

Le lundi 4 mai 2009 à 20:42, par Alex.guillioud

Génial cet outil :) Il est capable d'analyser autre chose que du code ?

Le mardi 5 mai 2009 à 11:02, par Hubert WASSNER

Oui, déjà on peut analyser d'importe quel type de code (Java, C, netlogo, etc....) et même des executables.

Voir cet article d'introduction à la méthode il y a la fin toute un liste de domaines où c'est applicable, et je pense qu'il y en a bien d'autres encore...

Le vendredi 8 mai 2009 à 10:32, par twitter

-Un outil similaire permet de detecter les duplications de codes (+ Copeir /coller) Cet outil permet aussi de réaliser de la qualimétrie, métriques... sur le code logicielles produit : -> Démo :

http://nemo.sonar.codehaus.org/

++C'est l'outil est dailleurs utilisé par les frameworks openSource (dc pr gros volume de codes)++

-Le mieux étant de coupler cela avec un ordonnanceur telle que Hudson permettant d'automatiser les builds des sources ainsi que la generation de rapport qualimétrie, builds (Java,Perl,Python...) ;) -Fixer les règles de qualimétries et de formatage de code ; je pense notamment a checktyle,PMD ,Jalopy ...

une fois ces outils mit en place on gagne bcp de temps en dev, en qualité, en integration .. @+

Le mardi 12 mai 2009 à 14:40, par twitter

Couple gestion config de SVN,CVS... avec Hudson. Hudson se charge d'executer le projet et d'executer ou non sonar .(via le plugin hudson)

Sonar fourni une vie synthetique des plugins de qualimétrie que l'on souhaite (ex : JavaNcss )



Pour optimiser encore plus le travail collaboratif utilise mvn site de Maven pour re-builder automatiquement le site de documentation sur webdav .

pour le deployement et auto install utiliser la commande maven :

mvn deploy en configurant bien les droits du serveur applicatif et du fichier pom.xml

Dans le cas d'un dev de projet "classique" type ant , une sous tache maven peut etre appelle, ce qui laisse une certaine flexibilité au dev;

Enfin pr conserver une coherence de librairies utilisé utilise un gestionnaire de lib comme Nexus ou Archiva . (gain en cache de dwl en terme via proxy interne) ;) Baldr peut encore developper ces axes d'automatisation de deployement sur serveur applicatif et de taux de couverture de test . Je pense que se serait un vrai plus pour outil.

Le mardi 12 mai 2009 à 22:15, par Hubert WASSNER

(@twitter) je ne connais pas cet outil, j'imagine que c'est une version très évolué de comparateur de code.... Ce n'est pas ce que fait Baldr... Le comparateur de code n'est pas prévu pour détecter du code maquillé, de plus il faudrait automatiser la comparaison croisé d'une liste de code, et ordonnancer les codes qui se ressemblent le plus, et il faudrait encore un outil (tel qu'un histogramme) sur les mesure de similarité, pour visualiser le seuil au délà duquel il y a probablement fraude... Bref recoder Baldr ...

Le mercredi 13 mai 2009 à 00:59, par twitter

Ce a quoi je pense est en faites + a une plateforme integration Continue, automatise le dev jusqu'au deploiement .

L'utilisation de ses outils presentent des avantages certains cote prof & eleves . Je pense que ces outils peuvent ajouter des fonctionnalités complémentaires à Baldr; Le prof peut ainsi fixer un seuil de qualité que les étudiants doivent fournir dans leur projet developpé. Cela apporte aux étudiant a dev un prj avec rigueur& qualité ...

=> Cote Eleve : Configuration de ordonnanceur via gestion composant (ex:CVS, SVN ,Google Code..)

(+) Autocompilation et deploiement sur serveurs applicatifs Tendance de son prj (compile ou pas) Vision de la qualité du code produit , amélioration de son propre code Travail collaboratif des étudiants

(-) Demande des connaissances lie soit a Ant,Maven

=> Cote Prof :

(+) -Centralisation libs a utiliser par les etudiants (Nexus ou archiva), evite ainsi les problemes d'incoherence de version librairies au moment du rendu. (ex "classique": difference de librairies utilisé par letudiant et le prof)

-Ajoute plus ou moins de contrainte de qualité au rendu du projet -Vérification du dernier build (compile ou pas au moment du rendu)

-Evaluation automatique de la qualité du code rendu par les élèves -Detection des Copier/coller , lignes dupliquée, taux participation effectives de chaque élève dans le projet rendu ...(CF : voir liste ci dessous) -Detection fraude (avec Baldr)

(-) Avoir initer les etudiants aux outils, connaissance minimum Gestions configurations (commit,checkout eventellement merge )

-> Liste de plugins qu'agrege Sonar : voir le site http://nemo.sonar.codehaus.org/projects

LayerGuard : analyse des relations inter couche dans une architecture multi couche

Covertura : Analyse des tests de couverture du code

Dev-activity: recupere une synthese des dernieres modifications sur le gestion composant (svn) ..interressant de savoir qui a vraimment "travaillé" & codé le projet !!!

JavaNcss : statistiques et métrique sur le code et % commentaire detecte le nombre de ligne dupliquer

Jdepend : analyse des dépendances de code

Checkstyle : vérification des normes de dev (code et formatage)

PMD & CPD : Vérifie la qualité du code (pattern,code morts ...)

Surefire : verifie les tests unitaires et test integrations notamment JWebunit HTTPunit

Il existe aussi un plugin detectant les Copier /coller. je retrouverai le nom demain ;)



Jalopy : autoformatage de code du prj

Il existe un autre outil CAST, mais la c vraimment bourrin :D @+

Le mercredi 13 mai 2009 à 10:02, par twitter

Pour la detection copier/coller est compris dans CPD report Find bug est aussi tres utile :) ++

Ajouter un commentaire

Accéder à la charte des blogs?

Ce blog permet une syntaxe wiki simplifiée dans les commentaires. Si votre navigateur est compatible, vous pouvez vous aider de la barre d´outils. les adresses internet seront converties automatiquement. De plus, vous pouvez maintenant prévisualiser en direct votre commentaire (ci-dessus)