Oto - UQAM

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
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
2
1. Pourquoi automatiser
la
correction des travaux de
programmation?
Étapes typiques d’un TP
E
nseignant
et sesassistants
É
tudiants
1
C
om
poserT
P
2
D
istribuerT
P
3
FaireT
P
6
T
raiter
résultats
5
C
orrigerT
P
4
R
endreT
P
4
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.
5
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.
6
2. Quelques outils
de correction
existants
(Quelques sources d’inspiration)
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
8
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.
9
Autres outils semblables
• 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, 1997-1999)
– 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.
10
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.
11
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.
12
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.
13
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)?
14
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; }
}
15
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() );
}
16
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() );
}
}
17
Exemple JUnit : résultats d’exécution
There was 1 failure:
1) testTransfert(CompteTest)
junit.framework.AssertionFailedError:
expected:<100> but was:<200>
at CompteTest.testTransfert(CompteTest.java:19)
at CompteTest.main(CompteTest.java:27)
FAILURES!!!
Tests run: 2,
Failures: 1,
Errors: 0
18
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.
19
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.
20
3. Oto
Utilisation, scripts et modules
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.
22
Utilisation typique d’Oto
Script et
tests publics
1.
creer_boite
Enseignant
2.
activer_eval
--public
Rapport
Étudiant
3.
verifier_tp
TP
6.
detruire_boite
Script et
tests privés
7.
activer_eval
Rapport
8.
corriger_groupe
Les TP
9.
desact ive r_ eva l
10 .
desact ive r_ eval
--public
5.
prendre_tp
Délai
écoulé
4.
rendre_tp
23
3.1 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).
24
Scripts Oto : grammaire
• scriptOto ::= (declaration | assertion)* {sortie}
• declaration ::= {<<Description>>} {visibilite} declarationNue
• assertion
::= 'assurer' Expression 'sinon' Expression
• sortie
::= 'sortir' '{' ID (',' ID)+ '}‘
• visibilite ::= { '+' | '-' }
• declarationNue ::= variable | fichier | tache
• variable ::=
• fichier ::=
• tache
::=
ID
ID
ID
'=' Expression
'=?' Expression
'::' ID '{' {parametres} '}'
• parametres ::= variable (',' variable )+
25
Script Oto: exemple
tp =? Compte.java
test = CompteTest
compilation :: javac { fichiers = $tp }
<<Vérification du bon fonctionnement>>
+ verification :: junit { classe = $test }
<<Nombre d'erreurs>>
nbErreurs = $verification.nb_erreurs
sortir { nbErreurs }
26
Rapport de vérification
tp =? Compte.java
test = CompteTest
compilation :: javac { fichiers = $tp }
SORTIES
¯¯¯¯¯¯¯
Nombre d'erreurs = 1
<<Vérification du bon fonctionnement>>
+ verification :: junit { classe = $test }
<<Nombre d'erreurs>>
nbErreurs = $verification.nb_erreurs
ETAPES
¯¯¯¯¯¯
sortir { nbErreurs }
Vérification du bon fonctionnement:
Nombre
Nombre
Nombre
Nombre
de tests:
d'erreurs
d'erreurs
d'erreurs
2
au total: 1
assertives: 1
exceptionnelles: 0
Resultats detailles:
27
... ( Sortie textuelle de la commande JUnit )
3.2 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.
28
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.
29
Modules déjà existants
• Contexte initial d’utilisation = Cours d’introduction à 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.
30
3.3 Mise en œuvre : architecture
Oto et son environnement
Utilisateur
Interface
conviviale
Traducteur
Oto
Données
Programmes
externes
Principal Oto
Compilateur
Java
Script
Oto
Image
Oto
TP
JUnit
Classe
TP
Test
JUnit
Rapport
Oto
31
Mise en œuvre : architecture (suite)
P r in c ip a l O t o
N o ya u O to
C om m andes
C o n c e p ts
( a d m in is t r a t io n )
M o te u r
( in t e r p r é t e u r )
M o d u le s O t o
( e x t e n s io n s )
C o n te xte
d 'e x é c u t io n
U t ils
D onnées
P ro g ra m m e s
e xte rn e s
32
Mise en œuvre : déploiement
physique
Oto (Serveur Unix)
Terminal
SSH, SFTP
Plug-in Oto
pour BlueJ
Interface Web
(Projet en cours)
33
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).
34
4. Conclusion et travaux futurs
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
36
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)
37
Questions ?
• Pour plus d’informations
– Site web:
• http://www.info2.uqam.ca/~oto/
– Courriel:
• [email protected]
38