Oto Un outil générique et extensible pour corriger les travaux de programmation Guy Tremblay et Frédéric Guérin Département d’informatique, UQAM (Université du Québec à Montréal) ESILV, 13 décembre 2005

2 Plan de la présentation 1.Pourquoi automatiser la correction des travaux de programmation? 2.Quels sont quelques-uns des outils de correction existants? 3.L’outil Oto : 3.1 Comment l’utilise-t-on? 3.2 Comment peut-il être configuré et étendu? 3.3 Comment est-il mis en œuvre? 4.Conclusion et travaux futurs

1. Pourquoi automatiser la correction des travaux de programmation?

4 Étapes typiques d’un TP

5 Correction d’un TP Divers aspects doivent être traités et corrigés –Stylistiques : Bien présenté et bien indenté ? Commentaires présents et pertinents ? Identificateurs bien choisis ? –Structuraux : Cohésion forte? Couplage faible? Bonne dissimulation d’information? –Fonctionnels : Ça compile ? Ça marche correctement ? Imaginez 50, 100, 150 copies à corriger !!! Long, répétitif, ennuyant, résultats non-uniformes.

6 Remise des TP par les étudiants Dans certains cours, la remise des travaux se fait encore avec des disquettes (sic) Feedback limité ou venant tardivement –Le travail est corrigé par des auxiliaires d’enseignement, sans beaucoup d’expérience; –Le nombre élevé copies fait que le délai de correction est parfois long; –Si l’étudiant a mal compris l’énoncé, impossible pour lui de se reprendre.

2. Quelques outils de correction existants (Quelques sources d’inspiration)

8 Les trois principales fonctionnalités Gestion des travaux –Réception (électronique) des travaux –Calcul des notes –Transmission des résultats Évaluation de la justesse des résultats Évaluation de la « qualité » du code

9 TRY (Rochester Institute of Technology, 1989) Permet aux étudiants : –De faire vérifier de façon préliminaire leur travail. –De remettre leurs programmes électroniquement. Les vérifications se font deux façons possibles: –Par comparaison des résultats textuels produits par le programme (modulo les espaces blancs) avec les résultats attendus; –À l’aide de routines de sortie (définies par l’enseignant) que les programmes des étudiants doivent appeler.

10 Curator (Virginia Polytechnic Institute, 1997) –Support pour la soumission électronique. –Tests basés sur la comparaison des entrées-sorties textuelles. BOSS (Univ. of Warwick, ) –Soumission électronique. –Tests basés sur la comparaison des entrées-sorties textuelles. BOSS2 (Univ. of Warwick, 2000) –Soumission électronique. –Tests basés sur la comparaison d’objets (Java) produits par le programme. Autres outils semblables

11 ASSYST (University of Liverpool, 1997) Peut évaluer divers aspects, dont: –Temps d’exécution. –Complexité structurale (McCabe). Mais –Tests basés sur la comparaison des E/S textuelles: Les résultats attendus sont spécifiés par une grammaire. –Correction étoffée, mais figée. –Ensemble fixe de langages : Ada, C/C++ ou Java.

12 OCETJ (UQAM et Cégep du Vieux-Montréal, 2002) OCETJ = Outil de Correction et d‘Évaluation de Travaux Java. Objectifs clés = –Fournir du feedback aux étudiants avant la remise finale. –Éviter les tests basés sur la comparaison des E/S textuelles. Donc, OCETJ fournit du support pour: –Vérification préliminaire des travaux par les étudiants. –Remise électronique des travaux par les étudiants. –Correction par l’enseignant d’un ensemble de travaux.

13 JUnit Popularisé par XP (eXtreme Programming). Utilisé pour tester des programmes et des classes Java: –Au niveau des méthodes et des classes; –Pendant le développement du programme; –En utilisant des assertions.

14 Tests JUnit Les tests JUnits sont organisés de façon hiérarchique: –Classe de tests = collection de suites de tests; –Suite de tests = collection de méthodes de tests; –Méthode de test = une ou plusieurs assertions. Lorsqu’un test échoue, JUnit indique: –Quelles assertions ont échoué et dans quels tests ? –Pourquoi le test a échoué (si documenté par le testeur) ?

15 Exemple JUnit : classe pour Compte bancaire class Compte { private Client c; private int s; public Compte( Client cl, int soldeInit ) { c = cl; s = soldeInit; } public int solde() { return( s ); } public Client client() { return( c ); } public void deposer( int montant ) { s += montant; } public void retirer( int montant ) { s += montant; } }

16 Exemple JUnit : classe de tests public class CompteTest extends TestCase { public CompteTest( String nom ) { super(nom); } public void testSolde() { Compte c = new Compte( new Client("Joe"), 100 ); assertTrue( c.solde() == 100 ); } public void testTransfert() { Compte c = new Compte( new Customer("Joe"), 100 ); int soldeInit = c.solde(); c.deposer( 50 ); c.retirer( 50 ); assertEquals( soldeInit, c.solde() ); }

17 Exemple JUnit : classe de tests (suite) // Génération de la suite et de la classe de tests. public static Test suite() { return new TestSuite(CompteTest.class); } public static void main( String[] args ) { junit.textui.TestRunner.run( suite() ); }

18 Exemple JUnit : résultats d’exécution There was 1 failure: 1) testTransfert(CompteTest) junit.framework.AssertionFailedError: expected: but was: at CompteTest.testTransfert(CompteTest.java:19) at CompteTest.main(CompteTest.java:27) FAILURES!!! Tests run: 2, Failures: 1, Errors: 0

19 Relations entre OCETJ et JUnit Chaque TP est associé à une paire de tests JUnit: –Un test public, utilisé par les étudiants : vérification préliminaire (sommaire) d’un travail (feedback avant remise). –Un test privé, utilisé par l’enseignant : correction finale (détaillée) des travaux remis.

20 Faiblesses d’OCETJ Support pour un unique langage : Java Processus fixe de correction : 1.Compilation avec javac. 2.Vérification et correction avec junit. Mise en œuvre liée au contexte spécifique du Cégep du Vieux-Montréal: –Réseau (Novell) privé pour dossiers de remise.

3. Oto Utilisation, scripts et modules

22 Oto (UQAM, 2005) « Successeur » d’OCETJ Caractéristiques clés : –Correction sur mesure (programmable, adaptable); –Indépendant du langage (adaptable à divers langages); –Peut être étendu pour traiter des aspects variés: Qualités stylistiques, structurelles, fonctionnelles, etc. Deux mécanismes de configuration et extension : –3.1 Scripts de correction. –3.2 Modules d’extension.

23 Utilisation typique d’Oto

Scripts Oto Rôle = Décrire les différentes tâches requises pour évaluer un travail. Semblable à un shell script ou makefile : –Déclarations de constantes et fichiers. –Déclarations de tâches à effectuer. –Annotations décrivant le contenu du rapport de vérification. –Expressions pour calculs divers (en Ruby).

25 Scripts Oto : grammaire scriptOto ::= (declaration | assertion)* {sortie} declaration ::= { >} {visibilite} declarationNue assertion ::= 'assurer' Expression 'sinon' Expression sortie ::= 'sortir' '{' ID (',' ID )+ '}‘ visibilite ::= { '+' | '-' } declarationNue ::= variable | fichier | tache variable ::= ID '=' Expression fichier ::= ID '=?' Expression tache ::= ID '::' ID '{' {parametres} '}' parametres ::= variable (',' variable )+

26 Script Oto: exemple tp =? Compte.java test = CompteTest compilation :: javac { fichiers = $tp } > + verification :: junit { classe = $test } > nbErreurs = $verification.nb_erreurs sortir { nbErreurs }

27 Rapport de vérification SORTIES ¯¯¯¯¯¯¯ Nombre d'erreurs = 1 ETAPES ¯¯¯¯¯¯ Vérification du bon fonctionnement: Nombre de tests: 2 Nombre d'erreurs au total: 1 Nombre d'erreurs assertives: 1 Nombre d'erreurs exceptionnelles: 0 Resultats detailles:... ( Sortie textuelle de la commande JUnit ) tp =? Compte.java test = CompteTest compilation :: javac { fichiers = $tp } > + verification :: junit { classe = $test } > nbErreurs = $verification.nb_erreurs sortir { nbErreurs }

Modules d’extension Une tâche dans un script = module d’extension. Un module joue un rôle de proxy entre Oto et un programme externe –java, javac, JUnit, gcc, etc. Un module est décrit par une interface: –Entrées requises; –Sorties produites. Les modules (et Oto) sont écrits en Ruby.

29 Modules possibles Pour traiter divers langages : Java, C/C++, etc. –Compilation : javac, gcc, etc. –Vérification : JUnit, CUnit, etc. Pour traiter divers aspects: –Commentaires, dénominations, indentations, etc. –Normes de programmation, public vs privé, etc. –Complexité : McCabe, temps, mémoire, etc. –Détection de plagiat. –Etc.

30 Modules déjà existants Contexte initial d’utilisation = Cours d’intro- duction à la programmation Java (1 ère année). Modules déjà disponibles: –javac : Compilation d’un programme Java. –junit : Exécution d’un test JUnit. –tester_filtre : Exécution d’un test système (basé sur diff, donc E/S textuelles) appliqué à main. Module en cours de développement: –javaStyle : Vérification du style de programmation.

Mise en œuvre : architecture

32 Mise en œuvre : architecture (suite)

33 Mise en œuvre : déploiement physique

34 Mise en œuvre : principales difficultés Mise en œuvre en Ruby sous Unix (Solaris). Principales difficultés: –Intégrité et confidentialité des données; –Chargement des modules d’extension; –Tests du système (avec Test/Unit en Ruby); –Traitement des erreurs (plusieurs niveaux).

4. Conclusion et travaux futurs

36 Contributions Oto est un outil de correction qui est –Générique et configurable Par l’enseignant Grâce aux scripts Oto –Pour une correction sur mesure –Extensible Par l’enseignant ou l’expert Grâce aux modules d’extension –À de nouveaux langages –À de nouveaux aspects de correction

37 Travaux en cours et futurs Tester Oto dans un cadre réel –Labos (notés) du premier cours de Java Développer de nouveaux modules –Métriques de « qualité » (structure, style) –Autres langages (par ex. assembleur) –Détection de plagiat Développer une interface Web conviviale –Interface actuelle Enseignants = ligne de commande Unix Étudiants = plug-in BlueJ (outil pour l’apprentissage de Java)

38 Questions ? Pour plus d’informations –Site web: –Courriel: