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
Séminaire du Département
d’informatique
Mercredi, 1er février 2006
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
rendre_tp/prendre_tp
(UQAM)
• rendre_tp permet aux étudiants … « de copier
un fichier dans un répertoire de «tp» d'un
professeur (à la CONDITION que celui-ci ait utilisé
la commande mkdir_tp). »
– Restriction: ne copie qu’un seul fichier à la fois
• prendre_tp permet aux enseignants « de
s'approprier tous les fichiers d'un répertoire de
«tp» créé préalablement avec la commande
«mkdir_tp». »
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
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.
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:<100> but was:<200>
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.
21
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.
23
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
24
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).
25
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 )+
26
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.nberreurs
sortir { nbErreurs }
27
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.nberreurs
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:
28
... ( 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, make, 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, shell script de test , 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
Les deux modules de base
• Contexte initial d’utilisation = Cours
d’introduction à la programmation Java (INF1120,
puis INF2120).
• Les deux modules initialement développés par
Frédéric Guérin (et décrits dans son mémoire):
– javac : Compilation d’un programme Java.
– junit : Exécution d’un test JUnit.
31
Deux autres modules développés
plus récemment
• tester_filtre (Frédéric G. et Guy T.):
– Exécution d’une série de tests fonctionnels (de niveau système)
appliqués à un exécutable de type « filtre textuel ».
– Filtre = programme qui lit sur stdin et qui écrit sur stdout.
– Comparaisons des résultats obtenus et des résultats attendus à
l’aide de diff – donc comparaisons textuelles.
– Exemple:
– oto activer_eval EvalTp1 scriptTp1.oto TestsTp1
• xunit_make (Guy T.):
– Exécution de tests unitaires (génériques) définis à l’aide d’un
makefile.
– Utilisable pour divers langages, en autant que le sommaire des
résultats respecte certaines conventions.
32
Exemple pour tester_filtre
# Fichier scriptTp1.oto
compilation :: javac { fichiers = CompterCaracteres.java }
verification :: tester_filtre
{
filtre = “java CompterCaracteres”
tests = Tests
}
nbErreurs = $verification.nberreurs
sortir { nbErreurs }
::::::::::::::
::::::::::::::
TestsTp1/test2.donnees
TestsTp1/test1.donnees
::::::::::::::
::::::::::::::
fd
10
fd
fd
10
::::::::::::::
fd
TestsTp1/test1.resultats
::::::::::::::
::::::::::::::
TestsTp1/test2.resultats
6
::::::::::::::
12
33
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
34
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
35
Mise en œuvre : déploiement
physique
Oto (Serveur Unix)
Terminal
SSH, SFTP
Plug-in Oto
pour BlueJ
Interface Web
(Projet en cours)
36
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).
37
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
39
Travaux en cours et futurs
• Tester Oto dans un cadre réel (en cours)
– Labos (notés) du premier cours de Java
– Travaux pratiques dans le cours INF5170
• 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 (en cours)
– Interface actuelle
• Enseignants = ligne de commande Unix
• Étudiants = plug-in BlueJ (outil pour l’apprentissage de Java)
40
Questions ?
• Pour plus d’informations
– Site web:
• http://www.info2.uqam.ca/~oto/
– Courriel:
• [email protected]
41