Guide d`utilisation à l`intention des enseignants et des - Oto

Transcription

Oto, un outil d’aide à la correction de
programmes :
Guide d’utilisation à l'intention des enseignants
et des auxiliaires d'enseignement
F. Guérin, G. Tremblay, P. Lessard et A. Demange
Départment d’informatique, UQAM
Octobre 2014
Oto 2
Aperçu
Oto est un logiciel qui assiste enseignants et étudiants dans le cadre des travaux pratiques de
programmation. Oto permet aux étudiants de remettre leurs travaux en ligne et, en plus, de faire vérifier
(de façon préliminaire) leurs travaux avant de les remettre. Oto permet ensuite aux enseignants de
corriger les travaux remis. Nous aborderons successivement ces trois points, puis nous présenterons un
exemple concret d‟utilisation d‟Oto. Nous présenterons aussi des exemples de script de correction.
Enfin, à titre de référence, nous fournirons la liste des commandes et des modules Oto.
Ce guide se veut une introduction à l‟utilisation de l‟outil Oto. Pour des informations additionnelles, on
peut aussi consulter le mémoire de maîtrise de F. Guérin (Dép. d‟informatique, UQAM, octobre 2005)
et, pour le nouveau langage de script de correction, le mémoire de P. Lessard (Dép. d‟informatique,
UQAM, février 2010), tous deux disponibles sur le site Web d‟Oto : http://oto.uqam.ca.1
Soulignons que ce guide d‟utilisation présente les diverses commandes du noyau d’Oto, qui est une
application fonctionnant sous Unix en mode ligne de commandes.2 Une application Web permettant,
tant aux étudiants qu‟aux enseignants, d‟utiliser Oto à l‟aide d‟une interface graphique est aussi
disponible : http://oto.uqam.ca/application-web, Toutefois, nous ne décrirons pas cette application
dans le présent document, son utilisation étant relativement facile lorsqu‟on connaît les principales
commandes d‟Oto.
1
2
Signalons que certains noms de commandes ont été modifiés par rapport à la version décrite dans le mémoire de
maîtrise de Frédéric Guérin. Le présent document décrit la version courante du logiciel.
À l‟UQAM, oto fonctionne, de façon transparente entre les machines, sous les machines
{zeta,oto}.labunix.uqam.ca. Pour cela, il faut toutefois utiliser un code usager de style « code MS » (par ex.,
tremblay_gu), et non un ancien code usager de la machine arabica. De plus, pour qu‟oto fonctionne correctement,
le niveau supérieur de répertoire de l‟enseignant doit être mis en mode exécution (0711) pour les usagers du groupe et
les autres usagers.
Oto: Guide de l'enseignant
1
Table des matières
Contenu
Vue d‟ensemble du processus d‟utilisation d‟Oto................................................................................................4
1
Remise des travaux ......................................................................................................................................5
....1.1
Création d‟une boîte de remise de travaux ............................................................................5
....1.2
Affichage des boîtes de remise disponibles ...........................................................................7
....1.3
Remise d‟un travail par un étudiant .......................................................................................7
....1.4
Confirmation de la remise d‟un travail par un étudiant .........................................................7
....1.5
Réception des travaux par l‟enseignant .................................................................................8
....1.6
Destruction d‟une boite de remise de travaux .......................................................................8
2
Vérification préliminaire des travaux ..........................................................................................................9
....2.1
Activation d‟une évaluation ...................................................................................................9
....2.2
Affichage des évaluations disponibles .................................................................................10
....2.3
Vérification préliminaire d‟un TP........................................................................................10
....2.4
Désactivation d‟une évaluation ............................................................................................11
3
Correction des travaux ...............................................................................................................................11
....3.1
Affichage des évaluations privées .......................................................................................12
....3.2
Correction d‟un groupe de travaux ......................................................................................12
....3.3
Correction directe d‟un groupe de travaux ..........................................................................14
4
Exemple illustrant le processus typique d‟utilisation d‟Oto ......................................................................15
5
Exemples de scripts Oto ............................................................................................................................18
....5.1
Un script simple sans détails et sans statistiques .................................................................18
....5.2
Un script avec détails des tests et des statistiques, trié selon les codes permanents ............20
....5.3
Un script avec traitement des erreurs de compilation ..........................................................22
....5.4
Un script avec pénalité de retard..........................................................................................24
....5.5
Un script pour détection du plagiat ......................................................................................25
....5.6
Un script avec utilisation de commandes Unix ...................................................................25
....5.7
Un script de remise conditionnelle au résultat d‟une vérification préliminaire ...................27
....5.8
Arguments de la méthode each de l‟objet groupe .............................................................28
6
Les commandes Oto ..................................................................................................................................29
....6.1
Liste des commandes ...........................................................................................................29
....6.2
Liste des arguments .............................................................................................................31
....6.3
Liste des options ..................................................................................................................32
....6.4
Commandes pour cas d‟utilisation particuliers ....................................................................34
7
Les modules de correction Oto ..................................................................................................................35
....7.1
Le module compiler_javac..........................................................................................36
....7.2
Le module tester_junit ............................................................................................38x
....7.3
Le module tester_filtre ............................................................................................39
....7.4
Les modules tester_methodes et tester_classe ................................................41
....7.5
Le module compiler_c ...................................................................................................42
....7.6
Le module detecter_plagiat .....................................................................................42
....7.7
Le module tester_pep8 .................................................................................................45
....7.8
Le module tester_hunit ..............................................................................................46
....7.9
Le module produire_statistiques .........................................................................47
8
Les modules de rapports Oto .....................................................................................................................48
....8.1
Module produire_rapport_complet ......................................................................48
....8.2
Module envoyer_rapports_courriel ....................................................................48
2
3
Vue d’ensemble du processus d’utilisation d’Oto
La figure suivante illustre, à l‟aide d‟un diagramme d‟activités UML, une séquence typique
d‟utilisation d‟Oto. Plus précisément, il s‟agit d‟un scénario où l‟enseignant ne permet pas que des
travaux soient remis après qu‟il ait débuté la correction (i.e., il rend impossible toute remise dès que la
date limite est atteinte en supprimant aussitôt la boîte de remise).
Script et
testspublics
1.
creer_boite
Enseignant
Script et
testsprivés
7.
activer_eval
R
apport
8.
corriger_groupe
LesTP
9.
desactiver_eval
10.
desactiver_eval
--public
2.
activer_eval
--public
6.
detruire_boite
5.
prendre_tp
R
apport
Étudiant
3.
verifier_tp
TP
D
élai
écoulé
4.
rendre_tp
Une évaluation, qu‟il s‟agisse d‟une vérification préliminaire publique accessible aux étudiants ou
d‟une évaluation privée utilisée par l‟enseignant pour effectuer la correction finale, est généralement
composée d‟un script (écrit en Ruby étendu : voir section 5) et d‟un ensemble de jeux d‟essais (par
exemple, des jeux de tests spécifiés à l‟aide de JUnit). Bien qu‟une même évaluation puisse être utilisée
à la fois pour les vérifications préliminaires et pour la correction finale, règle générale on utilisera
plutôt deux évaluations distinctes, et ce de façon à garder privés les détails de la correction finale. En
pratique, il arrivera souvent que les jeux de tests utilisés pour les vérifications préliminaires formeront
simplement un sous-ensemble de ceux utilisés pour la correction finale, le script étant adapté en
conséquence. Règle générale, le script pour la correction finale contiendra aussi certaines instructions
permettant d‟attribuer une note au travail corrigé, ce qui ne sera pas nécessairement le cas pour une
vérification préliminaire.
Dans les sections qui suivent, nous discutons plus en détail de ces différents aspects et des différentes
commandes Oto.
4
1 Remise des travaux
Un étudiant peut utiliser Oto pour remettre un travail de programmation à un enseignant. Ce travail
peut comprendre un seul fichier, plusieurs fichiers, un seul répertoire ou une combinaison de fichiers et
de répertoires. Lorsqu‟un répertoire est remis, c‟est tout son contenu qui est copié et remis par la même
occasion.
Avant qu‟un étudiant puisse déposer un travail, l‟enseignant doit tout d‟abord avoir créé une boîte à TP
virtuelle ─ i.e., une boîte de remise de travaux. Une telle boîte de remise sert à recevoir les fichiers des
étudiants. Elle est analogue à une boîte de remise des travaux comme celle que l‟on retrouve dans
plusieurs départements d‟informatique et qui sert à recevoir les travaux et rapports des étudiants.
L‟ensemble du processus de remise peut se détailler comme suit, l‟action rendre_tp étant effectuée
par des étudiants alors que les autres actions le sont par l‟enseignant:
cre
e
r_bo
ite
re
ndre
_tp
de
truire
_bo
ite
pre
ndre
_tp
L‟enseignant commence par créer une boîte à TP. Puis les étudiants rendent leurs TPs. À n‟importe
quel moment, l‟enseignant peut prendre possession des TPs qui sont dans la boîte. Les étudiants
peuvent continuer à déposer de nouveaux TPs, et l‟enseignant pourra à nouveau prendre possession de
ces TPs, et ainsi de suite. Finalement, une fois la date limite de remise atteinte, l‟enseignant détruit la
boîte. La boîte peut être recréée au besoin plus tard, si nécessaire. Nous abordons tour à tour ces
différentes étapes.
....1.1
Création d’une boîte de remise de travaux
Oto, à la base, fonctionne sous Unix en mode ligne de commandes. C‟est donc sous cette forme que,
dans ce qui suit, nous décrirons les commandes Oto – tel que mentionné précédemment, il existe
toutefois une interface Web pour l‟utilisation d‟Oto, que nous ne décrivons pas ici (décrite dans un
autre document : voir http://oto.uqam.ca). La commande Unix pour créer une boîte à TP est la suivante:
oto creer_boite <id_boite>
où <id_boite> est le nom que l‟enseignant a choisi de donner à la nouvelle boîte. Nous suggérons de
donner à la boîte un nom composé du sigle du cours suivi du nom du TP, par exemple INF1000-TP1.
Pour éviter toute ambiguïté, on peut ajouter le nom du groupe et le nom de la session, par exemple
A05-INF1000-10-TP1. Notez que Unix, et donc Oto, fait la distinction entre les majuscules et les
minuscules. Notez aussi que le nom de la boîte est strictement unique à l‟enseignant, plus précisément,
5
unique à l‟identité du compte Unix sur lequel la boîte est créée. Deux enseignants avec des comptes
Unix différents peuvent donc sans problème utiliser un même nom de boîte de remise.
Diverses options peuvent être spécifiées lors de la création d‟une boîte de remise :

--avec_code_permanent : Lors de la remise d‟un travail (voir section 2.3), chaque membre de
l‟équipe doit être identifié à l‟aide d‟un identifiant. Cette option impose que l‟identifiant utilisé soit
un code permanent valide, donc en gros de la forme NOMPJJMMAA99.3

--avec_liste_exacte : Cette option est utilisée pour spécifier la liste exacte des fichiers qui
peuvent et doivent être remis dans la boîte. Les noms des divers fichiers sont spécifiés à la suite de
l‟option (avec guillemets et parenthèses). Par exemple, la commande suivante permet de créer une
boîte B1 dans laquelle un étudiant ne pourra effectuer une remise que s‟il fournit les deux fichiers
indiqués (f1.h et f1.c) :
oto creer_boite --avec_liste_exacte="(f1.h f1.c)" B1
 --avec_liste_minimum : Cette option est semblable à la précédente, à la différence qu‟un
étudiant doit remettre au moins les fichiers indiqués, mais il peut aussi remettre des fichiers
additionnels.
 --avec_liste_maximum : Cette option est semblable à la précédente, à la différence qu‟un
étudiant doit remettre au plus les fichiers indiqués, donc il peut ne remettre qu‟un sous-ensemble
(non-vide) des fichiers indiqués.

--echeance="(JJ,MM,AAAA,HH,MM)" : Cette option permet de spécifier une date limite de
remise. Un travail remis après cette date ne sera pas déposé dans la boîte.

--max_remises=n : Cette option permet de spécifier le nombre maximal de remises (n, un
nombre entier positif) que peut faire un même étudiant dans la boîte, l‟étudiant étant identifié par
son nom d‟utilisateur Unix. Elle n‟empêche cependant pas l‟étudiant d‟effectuer d‟autres remises à
l‟aide d‟un autre compte (par exemple, dans le cadre d‟un travail d‟équipe).
 --avec_verification : Cette option permet d‟associer à une boîte de remise un script de
vérification de remise. Le nom du script est spécifié après le nom de la boîte. Par exemple,
supposons un script verif_compil.oto (voir Section 5 pour les scripts Oto) qui permet de
vérifier qu‟une remise effectuée par un étudiant consiste en un unique fichier Tp1.java, lequel
fichier compile correctement. La commande suivante permettrait alors de n‟accepter dans la boîte
B1 que les fichiers Tp1.java qui compilent sans erreur :
oto creer_boite --avec_verification B1 verif-compil.oto
Signalons que les options avec_liste_exacte , avec_liste_minimum ou avec_liste_maximum ne peuvent pas être utilisées conjointement.
3
Plus précisément, certaines vérifications lexicales sont effectuées, par exemple, le premier J doit être 0, 1, 2 ou 3, le
premier M doit être 0, 1, 5 ou 6, le deuxième M doit être 0, 1 ou 2, etc. Toutefois, l‟analyse exacte (sémantique) de la date
n‟est pas effectuée.
6
Finalement, signalons aussi qu‟une fois la boîte créée, ses divers attributs peuvent être obtenus (par le
créateur de la boîte seulement) à l‟aide de la commande decrire_boite, qui affichera aussi la liste des
travaux ayant été remis et qui sont encore présents dans la boîte.
....1.2
Affichage des boîtes de remise disponibles
Pour obtenir la liste des boîtes de remise de travaux créés par un enseignant, la commande suivante
peut être utilisée, et ce par n‟importe quel usager, où <enseignant> indique le nom d‟usager Unix
de l‟enseignant :
oto lister_boites <enseignant>
....1.3
Remise d’un travail par un étudiant
Pour rendre son TP, l‟étudiant ou son mandataire (par exemple, une application Web : cf. plus bas) doit
utiliser la commande Oto suivante, et ce à partir d‟un compte Unix valide sur la machine où réside Oto:
oto rendre_tp <enseignant> <id_boite> <membres-equipe> <fichiers...>
où <enseignant> est le nom du compte Unix de l‟enseignant à qui il faut rendre le TP, <id_boite>
est le nom de la boîte, <membres-equipe> est la «liste» des membres de l‟équipe qui rend ce TP, et
<fichiers...> est la liste de fichiers ou répertoires qui composent le TP. Notez que la liste des
membres de l‟équipe ne doit comporter aucun espace ; les identifiants des membres sont plutôt séparés
par des virgules. Nous suggérons d‟employer les codes permanents ou la combinaison NomPrénom
pour désigner les membres, par exemple, TROL12127602,GUIR12556502. Signalons qu‟un même
étudiant peut remettre plusieurs copies de son travail. Dans ce cas, toutes les copies sont conservées
dans la boîte à TP, chacune étant horodatée.
Il est important de souligner qu‟une application Web est aussi disponible pour la remise des TP. Plus
précisément, cette application Web permet à un étudiant, à partir d‟une machine sur laquelle un fureteur
standard (Internet Explorer, Firefox) est installé, de remettre un travail avec Oto. Une restriction
importante est que l‟étudiant doit posséder un compte usager valide sur la machine où réside Oto,
puisque c‟est via le nom d‟usager et le mot de passe de ce compte étudiant que la connexion à Oto via
ssh pourra s‟effectuer et que la remise avec la commande rendre_tp pourra se faire. Signalons que
tous les étudiants d‟informatique ont maintenant un tel compte usager, qui leur permet d‟accéder à
toutes les machines, tant Windows qu‟Unix et Linux.
....1.4
Confirmation de la remise d’un travail par un étudiant
Un étudiant peut vérifier que la remise a été effectuée correctement en utilisant la commande suivante –
plusieurs résultats seront affichés si plusieurs remises ont été effectuées sans que l‟enseignant ait retiré
les travaux remis de la boîte de remise :
oto confirmer_remise <enseignant> <id_boite> <membres-equipe>
7
....1.5
Réception des travaux par l’enseignant
Pour prendre les TP déposés par les étudiants, l‟enseignant doit préalablement se positionner dans le
répertoire où il veut recevoir les TP, puis utiliser la commande Oto suivante:
oto prendre_tp <id_boite>
où <id_boite> est le nom de la boîte. Les TP seront transférés dans le répertoire courant, chaque TP
étant déposé dans un sous-répertoire qui lui est propre. Chacun de ces sous-répertoires possède un nom
aggloméré, et peu lisible, qui indique notamment le nom d‟usager de l‟étudiant qui a déposé le travail
(plus précisément, son code usager Unix), la date du dépôt et le nom des membres de l‟équipe à qui
appartient le travail. Normalement, l‟enseignant n‟a pas à décoder toutes ces informations car c‟est le
rapport de correction d‟Oto qui s‟en charge (voir la commande corriger_groupe).
Tel que mentionné précédemment, la commande rendre_tp permet à un étudiant ou à un groupe
d‟étudiants d‟effectuer plusieurs remises dans une boîte donnée. Lorsque la boîte contient plusieurs
remises pour un même nom d‟usager Unix, la commande prendre_tp récupérera simplement toutes
les remises ayant été effectuées. Toutefois, l‟enseignant ne voudra généralement conserver que la
remise la plus récente. Pour ce faire, n‟importe quand après avoir exécuté la commande prendre_tp,
l‟enseigner peut exécuter la commande suivante, et ce à partir du répertoire où ont été transférés les
travaux :
oto supprimer_doublons
L‟exécution de cette commande aura pour effet de créer un répertoire nommé Doublons où seront
conservées toutes les remises multiples, sauf la plus récente (telle que déterminée par la date de remise
encodée dans le répertoire créée pour le travail) – des exécutions répétées de cette commande
préserveront les fichiers déjà présents dans le répertoire Doublons.
....1.6
Destruction d’une boite de remise de travaux
Pour détruire une boîte, l‟enseignant doit utiliser la commande Oto suivante:
oto detruire_boire <id_boite>
où <id_boite> est le nom de la boîte. Une boîte qui contient des travaux ne peut pas être détruite. Il
faut d‟abord prendre les travaux qu‟elle contient.4 Mentionnons que tant et aussi longtemps qu‟une
boîte n‟est pas détruite, un étudiant peut y déposer des travaux, à moins qu‟une date d‟échéance n‟ait
été spécifiée lors de la création de la boîte avec l‟option « --echeance ».
4
Toutefois, il existe une option «--detruire_travaux » qui permet d‟indiquer que la boîte doit être détruite même si
elle contient encore des travaux.
8
2 Vérification préliminaire des travaux
L‟objectif de l‟étape de vérification préliminaire est de guider l‟étudiant dans la réalisation du TP, de
lui permettre de vérifier qu‟il est sur la bonne voie. La vérification joue donc un rôle de filtre, assurant
qu‟un TP remis pour correction fonctionne minimalement, mais sans nécessairement révéler en quoi
consistera la correction finale.
Avant que l‟étudiant puisse vérifier son travail, les modalités précises de cette vérification doivent
d‟abord être spécifiées par l‟enseignant. Entre autres, il faut indiquer quels sont les tests à exécuter sur
le travail étudiant. Peut-être aussi faut-il compiler le travail au préalable? La séquence exacte des tâches
à exécuter lors de la vérification est spécifiée dans un script Oto, spécifique au travail à vérifier. Ce
script est généralement accompagné des tests (et possiblement de fichiers associés) qui doivent être
exécutés par la même occasion. L‟ensemble script, tests et/ou fichiers auxiliaires est ce qui compose
une évaluation. Nous reviendrons sur cette question dans une section ultérieure. Pour le moment, nous
nous concentrons sur le processus de vérification, lequel est schématisé dans la figure suivante où
verifier_tp est exécutée par les étudiants alors que les autres actions sont effectuées par
l‟enseignant :
a
c
tiv
e
r_
e
v
a
l
--p
u
b
lic
v
e
rifie
r
_
tp
d
e
s
a
c
tiv
e
r_
e
v
a
l
-p
u
b
lic
Dans un premier temps, l‟enseignant active l‟évaluation (le script) en mode public, de façon à ce qu‟il
soit accessible aux étudiants. Ensuite, les étudiants procèdent à la vérification de leur travail autant de
fois qu‟ils le désirent. Enfin, l‟évaluation (i.e., le script plus les tests) est retirée de la circulation, donc
désactivée. Si une évaluation doit être modifiée, il faut tout d‟abord la désactiver puis activer la
nouvelle version. Dans les sections suivantes, nous aborderons successivement chacune de ces étapes.
....2.1
Activation d’une évaluation
Pour publier une évaluation qui sera utilisée par les étudiants pour des vérifications préliminaires de
leurs TPs, l‟enseignant doit utiliser la commande Oto suivante (toujours sur la machine Unix où réside
Oto):
oto activer_eval --public <id_eval> <fichiers...>
où <id_eval> est le nom donné à cette évaluation, et <fichiers...> est la liste de fichiers et
répertoires qui composent l‟évaluation. Au minimum, cette liste comprend un script Oto – dénoté par
un nom de fichier avec l‟extension « .oto ». En outre, elle inclut en général des fichiers pour tester les
programmes étudiants, par exemple des tests JUnit dans le cas d‟un TP en Java – soulignons que ces
9
fichiers doivent déjà être compilés, puisque le script Oto ne fera qu‟utiliser directement les fichiers
fournis – à moins que le script n‟effectue explicitement leur compilation.
Ici, l‟utilisation de l‟option « --public » est nécessaire, autrement l‟évaluation ne serait pas accessible
aux étudiants. En guise de nom pour l‟évaluation, nous recommandons, même si ce n‟est pas
strictement nécessaire, d‟utiliser le même nom que la boîte à TP qui devra servir à recevoir les travaux.
Il est également possible de spécifier l‟option « --delai=N » où N représente le nombre de secondes
d‟exécution maximal. Dans le cas où un délai est également mentionné au moment de la correction,
cette dernière valeur a préséance. Cette option est expliquée plus en détails à la section 3.2 sur la
correction des travaux.
....2.2
Affichage des évaluations disponibles
Un étudiant qui désire obtenir la liste des évaluations publiées par un enseignant peut utiliser la
commande suivante, où <enseignant> indique le nom d‟usager Unix de l‟enseignant (donc seules
les évaluations activées avec l‟option public seront indiquées) :
oto lister_evaluations <enseignant>
Dans le cas d‟une évaluation activée avec l‟option public, l‟étudiant peut également afficher
l‟ensemble des fichiers composant une évaluation publiée par un enseignant, ce qui inclut le fichier de
script Oto ainsi les autres fichiers la composant :
oto afficher_evaluation <enseignant> <évaluation>
....2.3
Vérification préliminaire d’un TP
Pour faire vérifier son TP, de façon à obtenir du feedback avant de continuer, l‟étudiant ou son
mandataire (par exemple, une application Web : cf. plus bas) doit utiliser la commande Oto suivante, et
ce à partir d‟un compte Unix valide sur la même machine où réside Oto:
oto verifier_tp <enseignant> <id_eval> <fichiers...>
où <enseignant> est le nom du compte Unix de l‟enseignant qui a publié l‟évaluation, <id_eval>
est le nom de l‟évaluation, et <fichiers...> est la liste de fichiers et répertoires qui composent
le TP. Cette commande a pour effet d‟exécuter le script Oto associé à l‟évaluation concernée, ainsi que
les tests associés. Elle fournit ensuite à l‟étudiant un compte-rendu de cette exécution avec, le cas
échéant, les erreurs détectées. Le script est exécuté dans le compte usager de l‟étudiant sur la machine
où réside Oto, et ce avec l‟identité de l‟étudiant sur cette machine. S‟il y avait des dégâts pour une
raison ou une autre, c‟est donc l‟étudiant qui devrait en assumer la responsabilité.
Encore une fois, il faut souligner qu‟une application Web est disponible pour l‟utilisation d‟Oto. Cette
application Web permet à un étudiant, à partir d‟une machine munie d‟un fureteur, de faire vérifier un
travail. Une restriction est que l‟étudiant doit posséder un compte usager valide sur la machine où
réside Oto, puisque c‟est via le nom d‟usager et le mot de passe de ce compte que la connexion à Oto
via ssh pourra s‟effectuer et que la vérification par l‟intermédiaire de la commande verifier_tp se
fait.
10
....2.4
Désactivation d’une évaluation
Pour désactiver une évaluation préliminaire qui a été publiée et la rendre inaccessible aux étudiants,
l‟enseignant doit utiliser la commande Oto suivante:
oto desactiver_eval --public <id_eval>
où <id_eval> est le nom de l‟évaluation à désactiver.
3 Correction des travaux
Supposons que les étudiants ont remis leurs travaux ─ chacun à l‟aide de la commande rendre_tp ─
et que ces travaux sont maintenant disponibles dans un répertoire donné du compte Unix de
l‟enseignant ─ qui les a obtenus à partir de la boîte de TPs à l‟aide de la commande prendre_tp (cf.
Section 2.3). L‟enseignant peut maintenant procéder à la correction de ces divers travaux. Les étapes de
la correction des travaux sont les suivantes:
a
c
t
i
v
e
r
_
e
v
a
l
p
r
i
v
e
c
o
r
r
i
g
e
r
_
g
r
o
u
p
e
d
e
s
a
c
t
i
v
e
r
_
e
v
a
l
p
r
i
v
e
L‟enseignant commence par activer l‟évaluation (i.e., le script et les tests) devant servir à la correction.
Puis, il procède à la correction de l‟ensemble des travaux. Enfin, il désactive l‟évaluation. Notons que
l‟évaluation pour fin de correction est privée et accessible de lui seul, contrairement à l‟évaluation pour
fin de vérification préliminaire (section précédente) qui elle est mise à la disposition des étudiants pour
les guider et assurer qu‟ils sont sur la bonne voie. Ces deux évaluations sont le plus souvent distinctes
l‟une de l‟autre car la correction finale est généralement plus sévère et complète que la vérification
préliminaire.
Il est possible qu‟il soit nécessaire, dans certains cas, de mieux examiner le comportement d‟un travail
donné ou encore de corriger des travaux remis en retard. Dans ce cas, le processus de correction peut
être affiné de la manière suivante:
a
ctiver_eval
--prive
corriger_groupe
verifier_tp--prive
desactiver_eval
--prive
11
L‟enseignant commence par activer l‟évaluation. Puis, il procède à la correction du groupe. Peut-être
qu‟un peu plus tard des travaux remis en retard s‟ajouteront à l‟ensemble des travaux disponibles.
L‟enseignant pourra alors procéder à une nouvelle correction de groupe, mais cibler cette fois
uniquement les nouveaux travaux, ou bien il pourra procéder à une correction individuelle des
nouveaux travaux, un à la fois, à l‟aide de la commande de vérification, la même que celle qui est
utilisée par les étudiants, mais en utilisant plutôt le script privé de correction. Autre cas de figure :
l‟enseignant désire modifier le script ou les tests, auquel cas il devra désactiver l‟évaluation et la
réactiver de nouveau, puis recorriger l‟ensemble du groupe. Comme l‟indique implicitement le diagramme, les cas de figure sont multiples.
La plupart des étapes de ce processus (activer_eval, verifier_tp, desactiver_eval) ont
été détaillées à la section précédente dans leur forme publique, i.e., vérification préliminaire de travaux
par les étudiants. La seule différence entre les formes publiques et privées d‟activation d‟une évaluation
(commande activer_eval) est simplement l‟utilisation de l‟option correspondante (--public ou,
par défaut, privé). Dans les sections qui suivent, nous ne détaillons donc que les éléments qui diffèrent,
à savoir obtenir la liste des évaluations privées et effectuer la correction d‟un groupe.
....3.1
Affichage des évaluations privées
Une différence à souligner entre les évaluations publiques (accessibles par les étudiants) et celles
privées (utilisées par l‟enseignant) concerne la commande lister_evaluations. Un enseignant qui
désire obtenir la liste des évaluations privées qu‟il a activées peut utiliser la commande suivante – dans
ce cas, le nom de l‟enseignant n‟a pas besoin d‟être (et ne doit pas être) indiqué, le nom utilisé étant
alors implicitement le nom d‟usager Unix de l‟enseignant :
oto lister_evaluations --prive
Pour obtenir les évaluations publiques, l‟enseignant peut évidemment utiliser la même commande que
les étudiants, à savoir :
oto lister_evaluations <enseignant>
Finalement, un enseignant qui a associé un ou des scripts de vérification de remise à une ou plusieurs
boîtes peut obtenir la liste de ces évaluations à l‟aide de la commande suivante :
oto lister_evaluations --verif_remise
Signalons toutefois que ces évaluations pour vérification de remise ne peuvent pas être manipulées
(activées ou désactivées) comme les autres évaluations : la création/destruction d‟une telle évaluation
de vérification de remise est strictement liée à la création/destruction de la boîte correspondante.
....3.2
Correction d’un groupe de travaux
Pour corriger un groupe de travaux, l‟enseignant doit utiliser la commande suivante:
oto corriger_groupe <id_eval> <repertoires...>
12
où <id_eval> est le nom de l‟évaluation (nécessairement privée) devant servir à corriger les travaux
étudiants, et <répertoires...> est un ensemble de répertoires, chacun de ces répertoires contenant
un TP étudiant. Cette commande a pour effet d‟exécuter le script Oto associé sur chacun des TPs puis
de produire un rapport global relatant le détail de chacune de ces exécutions. Ce rapport étant généré
sur la sortie standard (stdout, par défaut l‟écran), on utilisera donc habituellement une redirection de
fichiers pour conserver le résultat, par exemple :
oto corriger_groupe tp2 TP2_recus/*.tp_oto > rapport_tp2.txt
Pour chacun des travaux ainsi corrigés, le rapport indiquera l‟identité des membres l‟équipe ayant
produit ce travail, le nom d‟usager Unix et le nom de famille de l‟étudiant ayant effectué la remise,
ainsi que les détails de la correction du travail.
Il faut souligner que, par défaut, la correction d‟un groupe de travaux se fait sans qu‟aucun feedback
immédiat ne soit généré. Lorsque le nombre de copies à corriger est élevé, le temps d‟exécution peut
donc être relativement long (plusieurs minutes). Pour voir la progression dans l‟exécution du script de
correction, on peut alors activer l‟option « ++TRACE »5, qui permet de générer (sur stderr) une trace
d‟exécution.
Une autre option utile est l‟option « --delai=N » – où N est un entier – qui permet de spécifier le
temps CPU maximum alloué pour l‟exécution de chacun des travaux, ce qui peut être utile pour avorter
l‟exécution d‟un programme en cas de boucle infinie. Par défaut, la valeur de cette option est de 2
secondes. Un exemple d‟exécution combinant ces deux options pourrait être le suivant, où un
maximum de 4 secondes CPU par travail est alloué :
oto ++TRACE corriger_groupe --delai=4 tp2 TP2_recus/*.tp_oto > rapport_tp2.txt
Une autre option du même style est l‟option « --sortie_maximum=N », qui permet de spécifier la
taille maximum des fichiers et de la sortie (stdout) générés par un programme. Cette option peut être
utile pour faire avorter l‟exécution d‟un programme contenant une boucle infinie d‟écriture. Par défaut,
la valeur de cette option est de 512 blocs (de 512 K octets).
Finalement, signalons que si les rapports produits pour chacun des travaux contiennent certains
résultats particuliers, signalés à l‟aide d‟un mot-clé approprié, alors il est aussi possible d‟obtenir, dans
le sommaire de correction du groupe, la distribution des résultats obtenus pour les divers travaux. Pour
ce faire, il suffit d‟utiliser le module (collectif) produire_statistiques : voir plus loin pour un exemple
(section 5.2).
La section 4 présente un exemple illustrant le processus complet d‟utilisation de commandes Oto, alors
que la section 5 présente divers exemples de script de correction.
5
Option qui peut aussi être utilisée dans sa forme abrégée « ++T ».
13
....3.3
Correction directe d’un groupe de travaux
Il est possible de corriger un ensemble de travaux sans travailler avec une évaluation explicite – donc
sans passer par le processus consistant à activer une évaluation (privée), à faire un appel à
corriger_groupe, puis à désactiver l‟évaluation.
Pour utiliser ce processus simplifié de correction, il suffit simplement de donner comme premier
argument à Oto le nom d’un script Oto plutôt que le nom d’une commande. Par exemple :
oto script-plagiat.oto *.tp_oto > rapport-plagiat.txt
Dans ce cas, les divers travaux contenus dans les répertoires *.tp_oto seront traités à l‟aide du script
indiqué (lequel ici effectue une détection de plagiat : voir section 5.5) et le rapport de correction sera
mis dans le fichier rapport-plagiat.txt. Signalons que si l‟évaluation requiert l‟utilisation de
certains fichiers auxiliaires (par exemple, un programme de tests), il suffit simplement d‟indiquer ces
fichiers comme arguments sur la ligne de commande, après le nom du script.
14
4 Exemple illustrant le processus typique d’utilisation d’Oto
La figure suivante illustre une séquence typique d‟utilisation des commandes Oto dans le cas où
l‟enseignant ne permet pas que des travaux soient remis après qu‟il ait débuté la correction (i.e., il rend
impossible toute remise dès que la date limite est atteinte).
Script et
testspublics
1.
creer_boite
Enseignant
Script et
testsprivés
7.
activer_eval
R
apport
8.
corriger_groupe
LesTP
9.
desactiver_eval
10.
desactiver_eval
--public
2.
activer_eval
--public
6.
detruire_boite
5.
prendre_tp
R
apport
Étudiant
3.
verifier_tp
TP
D
élai
écoulé
4.
rendre_tp
L‟enseignant commence par créer une boîte à TP, puis il active le script public devant servir aux
vérifications préliminaires par les étudiants. Ensuite, les étudiants vérifient leurs TPs respectifs,
plusieurs fois s‟il y a lieu, et enfin remettent ces TPs. Une fois écoulé le délai prévu pour la remise,
l‟enseignant prend possession des TPs et détruit la boîte à TPs pour empêcher de nouveaux dépôts. Il
peut aussi attendre à plus tard pour détruire la boîte si les retards sont acceptés. Enfin, l‟enseignant
active le script privé pour son usage personnel, procède à la correction de l‟ensemble des travaux remis,
et finalement retire les évaluations publique et privée de la circulation.
Les commandes Oto et Unix associées à cette séquence typique d‟actions sont indiquées et commentées
ci-après. On suppose dans cet exemple que les étudiants doivent réaliser une classe Tp.java dans le
cadre de la séance de laboratoire numéro 3. L‟étape K est numérotée par KEns si elle est exécutée par
l‟enseignant, alors qu‟elle est numérotée par KÉtud si elle est exécutée par un étudiant.
1Ens. oto creer_boite --avec_code_permanent --avec_liste_exacte="(Tp.java)" labo3
L‟enseignant crée d‟abord la boîte à TP à laquelle on donne le nom de labo3.
2Ens. oto activer_eval --public labo3 script_public.oto TestTpPublic.class
15
L‟enseignant active ensuite une évaluation publique. On lui donne aussi le nom de labo3. Cette
évaluation comprend un script Oto et une classe de test JUnit (déjà compilée).
3Étud. oto verifier_tp tremblay labo3 Tp.java
Un étudiant effectue ici une vérification. On suppose ici que le nom d‟usager de l‟enseignant qui a
publié l‟évaluation est tremblay.
4Étud. oto rendre_tp tremblay labo3 DURN27518401,DAVA26116702 Tp.java
Un étudiant rend son travail. Plus précisément, on suppose ici que les étudiants travaillent en équipe.
Cette équipe est ici formée de deux acolytes, avec les codes permanents indiqués.
5aEns. mkdir labo3_recus ; cd labo3_recus
Avant de prendre les TPs, l‟enseignant crée un répertoire pour recevoir les travaux.
5bEns. oto prendre_tp labo3
Puis, l‟enseignant prend les travaux. Après l‟exécution de cette commande, le répertoire courant
contient un ensemble de sous-répertoires, plus précisément, un sous-répertoire par travail remis (pour
chaque exécution de la commande rendre_tp qui a été effectuée). Chacun des ces répertoires
possède l‟extension «.tp_oto» (cf. plus bas).
6Ens. oto supprimer_doublons
L‟enseignant ne désire corriger qu‟une copie par étudiant, donc il supprime les doublons, i.e., les
remises multiples – elles sont toutefois conservées dans le répertoire Doublons.
7Ens. oto detruire_boite labo3
L‟enseignant détruit la boîte – il n‟accepte plus aucun travail après qu‟il a débuté la correction.
8Ens. oto activer_eval labo3 script_prive.oto TestTpPrive.class
L‟enseignant active l‟évaluation privée devant servir à la correction, en fournissant le script de
correction et la classe de tests (déjà compilée). Ici, on donne à cette évaluation le même nom que
l‟évaluation publique correspondante. Les espaces de noms pour les évaluations publiques et privées
étant indépendants, les deux évaluations sont parfaitement distinctes.
9Ens. oto corriger_groupe labo3 *.tp_oto > rapport_labo3.txt
L‟enseignant corrige l‟ensemble des travaux reçus. Comme les TP récupérés sont déposés dans des
sous-répertoires qui ont l‟extension « .tp_oto », il est possible d‟utiliser une notation compacte
pour spécifier l‟ensemble des TP à corriger. Le rapport produit est plutôt long et il est souhaitable
d‟utiliser la redirection de fichiers pour récupérer ce rapport (produit sur stdout) dans un fichier texte
qui pourra ensuite être imprimé.
16
10Ens. oto desactiver_eval labo3
L‟enseignant désactive l‟évaluation privée.
11Ens. oto desactiver_eval --public labo3
L‟enseignant désactive l‟évaluation publique.
Pour les actions 9 à 11, l‟enseignant aurait aussi pu simplement exécuter la commande suivante, donc
sans passer par l‟activation explicite d‟une évaluation puis sa désactivation, mais en utilisant plutôt le
mode implicite décrit à la section 3.3 :
9’Ens. oto script_prive.oto TestTpPrive.class *.tp_oto > rapport_labo3.txt
17
5 Exemples de scripts Oto
Écrire un script Oto, c‟est dans un premier temps déterminer la séquence des opérations à effectuer
pour une évaluation préliminaire ou pour une correction de TP, par exemple, tout d‟abord compiler le
programme de l‟étudiant, puis le tester avec certains jeux d‟essai. Toutefois, ce n‟est pas le seul aspect
à définir, puisque l‟exécution du script peut aussi produire un rapport. Il faut donc spécifier, dans le
script Oto associé à une évaluation, divers éléments de ce rapport. Nous aborderons ces divers aspects
dans les exemples qui suivent.
Avant d‟examiner un premier exemple, signalons que pour comprendre les scripts Oto, il faut savoir
qu‟un script Oto est essentiellement un programme Ruby, défini via un « langage spécifique au
domaine» (plus précisément, un internal DSL = internal Domain Specific Language). En d‟autres
mots, un script Oto est un script Ruby, mais avec des instructions additionnelles propres à Oto.
....5.1
Un script simple sans détails et sans statistiques
Le listing suivant illustre un script Oto typique. Les numéros de ligne ne font pas partie du script et sont
indiquées ici simplement pour pouvoir se référer à la ligne correspondante dans le texte explicatif. On
suppose, dans le cadre de cet exemple, que les étudiants doivent remettre un fichier Compte.java.
1. groupe.each do |tp|
2.
# Compilation
3.
comp = compiler_javac( tp ) {
4.
:fichier >> 'Compte.java'
5.
}
6.
tp['Compilation'] = if comp.reussi? then "OK" else "Erreurs!?" end
7.
8.
9.
# Execution des tests
10.
tests = tester_junit( tp ) {
11.
:classe >> 'TestCompte'
12.
}
13.
nbErrs = tests[:nberreurs]
14.
nbTests = tests[:nbtests]
15.
16.
# Elements a inclure dans le rapport
17.
tp['Nb erreurs'] = nbErrs
18.
tp['Note']
= 100 * ( nbTests - nbErrs ) / nbTests
19. end
20.
21. puts produire_rapport_complet( groupe )
À la ligne 1, on retrouve la construction qui permet de traiter les divers travaux d‟un groupe : dans
un script Oto, la variable prédéfinie groupe représente une collection contenant l‟ensemble des
travaux à traiter. Cette collection possède un itérateur each – standard en Ruby pour les collections
– qui va retourner les divers éléments de cette collection. Ici (ligne 1), chaque travail ainsi obtenu
via l‟itérateur sera associé à la variable tp dans le corps de l‟instruction do. À la ligne 2, on retrouve
un commentaire – qui débute par le dièse (#) et se poursuit jusqu‟à la fin de la ligne. Aux lignes 3
à 5, on fait appel au module Oto compiler_javac pour traiter le travail tp. Le module compiler_javac, comme son nom l‟indique, permet de compiler un programme Java. La liste des
18
fichiers à compiler est fournie en argument, associée au mot-clé :fichier – ici, il y a un seul
fichier à compiler, mais on peut en spécifier plusieurs, séparés par des virgules (“,”), auquel cas on
peut aussi utiliser le mot-clé :fichiers. De façon générale, dans un script Oto, les arguments pour
les appels de modules de correction sont indiqués avec la notation :arg >> val.
Lorsqu‟on fait appel à un module de correction, le module va généralement retourner divers
résultats. Pour conserver ces résultats de façon à pouvoir ensuite y référer, il suffit, comme à la
ligne 3, d‟associer l‟appel du module à une variable, ici la variable comp.
Parmi les résultats associés à un appel de module, on retrouve toujours l‟attribut reussi?, qui
détermine si l‟objectif du module a été réussi pour le travail corrigé, dans le cas présent, est-ce que
le travail a été compilé sans erreur. Toutefois, alors que certains résultats sont communs à tous les
modules, par ex., reussi?, d‟autres sont spécifiques à un module particulier, par ex., le module
compiler_javac produit un résultat stdout qui indique les détails de la compilation du travail.
(Pour plus de détails sur les divers modules et leurs résultats, voir section 8.) Alors que les résultats
du premier type sont obtenus via des attributs, par exemple, comp.reussi? (ligne 6), les résultats
de l‟autre type sont obtenus à l‟aide de l‟opérateur d‟indexation, par exemple, comp[:stdout]. 6
Lorsqu‟on corrige un travail, on peut aussi vouloir conserver certaines informations spécifiques au
traitement de ce travail, pour utilisation ultérieure dans un rapport de correction. Pour ce faire, il
suffit d‟utiliser implicitement l‟objet tp comme un hash Ruby, , comme à la ligne 6 où l‟attribut
Compilation pour l‟objet tp est associé à une chaine ("OK" ou "Erreurs!?") qui indique si la
compilation a réussi correctement ou non, et ce en fonction de l‟attribut reussi? du résultat de
cette compilation.
Aux lignes 9 à 12, on fait ensuite appel au module tester_junit. Ce module reçoit en entrée le
nom de la classe qui servira à tester le code étudiant (TestCompte). Ici, la tâche est nommée
tests, ce qui nous permet ensuite d‟accéder aux résultats associés à l‟exécution de ces tests plus
loin dans le script (lignes 13 et 14).
À la ligne 18, on calcule la note de l‟étudiant, sur 100, associée à l‟objet tp via l‟attribut Note. Pour
effectuer ce calcul, on utilise les deux variables auxiliaires introduites aux lignes 13 et 14.
À la sortie de la boucle do (ligne 20), l‟ensemble des travaux du groupe ont été traités. On indique
alors, à la ligne 21, que l‟on désire générer un rapport complet pour le groupe, qui incluera chacun
des rapports individuels des divers TPs, eux-mêmes étant constitués des divers attribués définis
durant l‟exécution du script. Il est aussi possible de n‟inclure que certains éléments dans le rapport:
pour plus de détails, voir le mémoire de Paul Lessard (2010). L‟appel à la commande
produire_rapport_complet retournant une chaîne, on l‟émet ici sur la sortie standard à l‟aide
de l‟instruction puts.7
6
Ces résultats sont en fait conservés sous forme d‟un hash Ruby, d‟où la notation. Et d‟où le fait que tous les modules
retournent un attribut resultats, qui est ce hash Ruby.
7
Si on désire inclure, dans le rapport, le contenu du script oto utilisé pour effectuer la correction et produire le rapport,
on peut l‟obtenir en spécifiant l‟option suivante :
{ :avec_script >> true }
19
....5.2
Un script avec détails des tests et des statistiques, trié selon
les codes permanents
Si on exécute le script Oto de la section précédente, on obtiendra un rapport individuel, donc pour
un travail spécifique d‟un étudiant (ou d‟une équipe), qui ressemblerait à ce qui suit:
TRAVAIL:
Equipe:
Depot:
Deposeur:
Nom:
Courriel:
tremblay_gu+2010.05.15.18.29.46.137069+TREG12121212.tp_oto
TREG12121212
2010-05-15 a 18:29
tremblay_gu
Guy Tremblay
[email protected]
RESULTATS:
Compilation:
OK
Nb erreurs:
0
Note:
100
Si on ne s‟intéresse qu‟à la note, le rapport qui précède fournit tout ce qu‟il faut savoir. Toutefois, en
général, l‟enseignant peut aussi vouloir connaître la nature des erreurs détectées par les tests, ne
serait-ce que pour connaître les erreurs commises par les étudiants afin de savoir quels sont les
concepts qui ont été mal compris. Il peut aussi vouloir produire des statistiques sur les notes des
étudiants. Finalement, il faut savoir que l‟ordre par défaut de présentation des rapports individuels au
sein du rapport global est fondé sur le nom usager du déposeur. Or, puisque ce seront généralement les
codes permanents qui seront utilisés pour les noms des équipes, il peut être préférable d‟ordonner les
rapports individuels selon les codes permanents. Ceci est possible comme l‟illustre le script suivant.
20
1. def simplifier( results )
2.
res = []
3.
results.each { |l|
4.
if l !~ /JUnit version 4.5/ and
5.
l !~ /^\s*(\.([EI])?)+\s*$/ and
6.
l !~ /Time:/ and
7.
l !~ /at andg.junit/ and
8.
l !~ /at sun.reflect/ and
9.
l !~ /at java.lang.reflect/ and
10.
l !~ /at java.lang.reflect/ and
11.
l !~ /at \w+.\w+/
12.
then
13.
res << l
14.
end
15.
}
16.
res.join
17. end
18.
20.
comp = compiler_javac( tp ) {:fichier >> 'Compte.java' }
21.
22.
23.
24.
25.
26.
}
27.
28.
29.
30.
31.
32.
tp['Note'] = 100 * ( nbTests - nbErrs ) / nbTests
33.
tp['Details'] = simplifier( tests[:detail] )
34. end
35.
36. stats = produire_statistiques( groupe ) {
37.
:nom_variable >> 'Note'
38. }
39.
40. puts produire_rapport_complet( groupe, stats ) { :tri >> :code_permanent }
À la ligne 33, on obtient l‟ensemble des détails associés à l‟exécution des tests pour le travail en
cours de traitement (tests[:details]), détails qu‟on associe au travail pour ensuite les inclure
dans le rapport. Toutefois, il faut savoir que les détails générés par JUnit sont nombreux et détaillés
(notamment, contenu de la pile d‟exécution au moment où une assertion de test n‟a pas été
satisfaite). Il peut donc être utile de filtrer les éléments inutiles et ainsi simplifier les informations,
et c‟est ce qui est fait ici en appelant la fonction simplifier, fonction auxiliaire écrite en Ruby qui
ne conserve que les éléments clés du contexte d‟exécution. Quant aux informations concernant les
notes et leur distribution, moyenne, etc., elle sont produites (ligne 36) en utilisant le module collectif
produire_statistiques, où on indique simplement le nom de la variable (de l‟attribut) que l‟on
désire analyser et compiler, ici, Note. Finalement, l‟option indiquée à la ligne 40 permet de
présenter les rapports en ordre croissant des codes permanents – les valeurs possibles pour l‟option
:tri sont :deposeur, :equipe et :code_permanent, les deux dernières étant synonymes.
21
....5.3
Un script avec traitement des erreurs de compilation
Dans l‟exemple qui précède, si le programme de l‟étudiant contient des erreurs de compilation, un
simple message “Erreurs!?” est indiqué pour la compilation et le reste du script se poursuit. Or,
le script lance ensuite l‟exécution des tests. Si le programme à tester n‟a pas compilé correctement,
aucun des tests ne fonctionnera – en fait, en l‟absence d‟un programme compilé, les tests ne
pourront même pas être lancés et l‟exécution du module de test échouera, sans résultat.
Le script qui suit illustre une première façon d‟éviter d‟exécuter les tests en cas d‟erreur de
compilation, et ce tout en affichant des informations plus précises quant à ces erreurs. Plus
spécifiquement, à la ligne 23, on utilise la méthode prédéfinie message_erreur_echoue sur
l‟objet comp pour obtenir les informations générées par le compilateur. De façon plus générale, cette
méthode s‟applique à tout objet associé au résultat d‟un appel de module, et permet d‟obtenir les
informations générées par ce module en cas d‟échec de l‟atteinte de l‟objectif du module.
2.
3.
4.
}
5.
6.
if comp.reussi? then
7.
# La compilation a reussi: on peut lancer les tests.
8.
tp['Compilation'] = "OK"
9.
10.
11.
12.
13.
}
14.
15.
16.
17.
18.
19.
tp['Note'] = 100 * ( nbTests - nbErrs ) / nbTests
20.
tp['Details'] = simplifier( tests[:detail] )
21.
else
22.
# La compilation n‟a pas reussi: inutile d‟executer les tests
23.
tp['Compilation'] = comp.message_erreur_echoue
24.
end
25. end
26.
22
Une autre façon de traiter un programme contenant une ou des erreurs de compilation est présentée
dans le script suivant, où l‟on termine l‟exécution du script pour le travail courant en cas d‟erreur de
compilation. Ainsi, à la ligne 6, la méthode assurer représente une assertion. Si l‟expression
indiquée comme premier argument (comp.reussi?) est vraie, alors l‟exécution du script se
poursuit normalement. Par contre, si l‟expression indiquée est fausse, ce qui serait le cas pour un
programme contenant des erreurs de compilation, alors l‟exécution du script se terminerait aussitôt
en signalant une assertion non satisfaite et en émettant les informations spécifiées par le deuxième
argument (une chaîne de caractères) – ici, une chaîne à laquelle sont concaténés les détails des
erreurs de compilation, soit la chaîne comp.message_erreur_echoue.
2. comp = compiler_javac( tp ) {
3.
4. }
5.
6.
assurer( comp.reussi?, 'Compilation echouee :\n' + comp.message_erreur_echoue )
7.
8.
9.
10. }
11. end
12.
Soulignons que si une telle assertion non satisfaite est rencontrée à l’extérieur de la boucle de
traitement des travaux (donc à l‟extérieur du corps du groupe.each), ce sera alors le script dans
son ensemble dont l‟exécution sera terminée, et non uniquement le traitement du travail courant.
23
....5.4
Un script avec pénalité de retard
Lorsqu‟un travail est remis par un étudiant, des informations sur la date du dépôt sont disponibles et,
comme l‟illustre l‟exemple qui suit, peuvent être utilisées pour calculer une pénalité de retard.
1. def nbMinutesDeRetard( depot, limite )
2.
if (depot <=> limite) < 0 then
3.
0
# Aucun retard
4.
else
5.
( ( depot - limite ) / 60 ).floor
# Retard!
6.
end
7. end
8.
10.
# Compilation
11.
12.
13.
}
14.
15.
tp['Date du depot'] = tp.moment_depot
16.
limite = Time.local(2010, "May", 15, 18, 00)
17.
tp['Date limite'] = limite
18.
nbMins = nbMinutesDeRetard( tp.moment_depot, limite )
19.
tp['Nombre de minutes de retard'] = nbMins
20.
21.
22.
23.
24.
# Execution des tests
25.
26.
27.
}
28.
29.
30.
31.
32.
33.
34.
note = ( 100.0 * ( nbTests - nbErrs ) / nbTests ) - nbMins / 144.0
35.
note = (10.0 * note).floor / 10.0
36.
tp['Note'] = note
37. end
38.
39. stats = produire_statistiques( groupe ) {
40.
:nom_variable >> 'Note'
41. }
42.
43. puts produire_rapport_complet( groupe, stats )
À la ligne 15, on détermine le moment où le travail a été remis, alors qu‟à la ligne 16 on définit la
date limite de remise, donc à partir de laquelle un travail est considéré en retard. La fonction
nbMinutesDeRetard détermine alors, à partir de ces deux informations, le nombre de minutes de
retard. Ce nombre de minutes est ensuite utilisé, à la ligne 34, pour déterminer une pénalité de
retard (nbMins/144) déduite de la note, pénalité qui correspond à 10% par jour.
24
....5.5
Un script pour détection du plagiat
La plupart des modules de correction utilisés dans un script Oto sont des modules dits individuels,
i.e., le module effectue un traitement sur un unique travail à la fois – compilation, exécution des jeux
de tests, etc. Toutefois, un module de correction peut aussi être un module collectif, i.e., permettre
de traiter un ensemble de travaux. Nous avons déjà vu un premier exemple d‟un tel module collectif,
soit le module produire_statistiques. Nous verrons maintenant un autre exemple, soit le
module detecter_plagiat qui, comme son nom l‟indique, permet de détecter le plagiat.
1. pl = detecter_plagiat( groupe ) {
2. :langage >> 'Java'
3. :fichiers >> 'Compte.java'
4. :plancher >> 'Compte.java=70'
5. }
6.
7. puts produire_rapport_complet( groupe, pl )
La détection du plagiat permise par ce module repose sur l‟utilisation de l‟outil sim, un outil de
détection de similarité lexicale. Actuellement, des instances de sim utilisables par Oto existent pour
les langages suivants: C, Java, OCL/USE et MPD.
L‟argument :fichiers spécifie les fichiers (séparés par “,”) qui doivent être comparés entre eux.
L‟argument :plancher permet de spécifier le niveau de similarité (en pourcentage) à partir duquel
des travaux qui semblent similaires seront signalés dans le rapport. La valeur par défaut est 60.
Soulignons qu‟une valeur trop petite peut conduire à un très (trop!?) grand nombre de signalements,
alors qu‟une valeur trop grande peut conduire à omettre des cas potentiels de plagiat.
....5.6
Un script avec utilisation de commandes Unix
Le prochain exemple présente un script Oto contenant des instructions qui sont des appels à des
commandes Unix, générant des résultats conservés dans les informations associées au travail traité.
2.
tp['ls avant'] = `ls`
3.
4.
copier_fichiers_auxiliaires tp
5.
6.
tp['ls apres'] = `ls`
7.
8.
res_make = `make TestCompte`
9.
10. tp['Resultats'] = res_make
11. end
12.
La ligne 2 indique un appel à la commande Unix ls, commande qui liste les divers fichiers accessibles dans le répertoire dans lequel s‟exécute le script sur le travail en cours de traitement. Le
résultat illustré dans la figure qui suit montre que seul le fichier remis par l‟étudiant, Compte.java,
est disponible. Or, pour traiter le travail, on veut ici utiliser un makefile, fourni par l‟enseignant.
Il faut donc explicitement obtenir ce makefile, ce qui est fait à la ligne 4 avec l‟instruction
copier_fichiers_auxiliaires tp. On voit alors, toujours dans la figure ci-dessous, que les
fichiers appropriés ont bien été copiés. On peut donc lancer l‟exécution de la commande make
(ligne 8).
25
TRAVAIL:
Equipe:
Depot:
Deposeur:
Nom:
Courriel:
tremblay_gu+2010.05.15.18.29.46.137069+TREG06065801.tp_oto
TREG06065801
2010-05-15 a 18:29
tremblay_gu
Guy Tremblay
[email protected]
RESULTATS:
ls avant:
Compte.java
ls apres:
Compte.java
makefile
script.oto
TestCompte.java
Resultats:
/usr/jdk/latest/bin/javac -classpath /usr/local/opt/junit/junit.jar:.
TestCompte.java
/usr/jdk/latest/bin/java -classpath /usr/local/opt/junit/junit.jar:.
org.junit.runner.JUnitCore TestCompte
JUnit version 4.5
....
Time: 0,029
OK (4 tests)
Lorsqu‟on utilise la forme indiquée plus haut (avec backquotes), le résultat émis sur la sortie
standard (stdout) est celui produit par l‟exécution de la commande et est retourné sous forme
d‟une simple chaîne de caractères. Si on désire capturer la sortie émise sur le canal d‟erreurs
(stderr), on peut le faire en redirigeant ce dernier flux vers le flux de sortie standard, par exemple :
res_make = `make TestCompte 2>&1`
Il existe aussi deux autres formes d‟utilisation de commandes Unix : soit en utilisant explicitement
la commande bash (avec un argument chaine), soit en utilisant un nom de commande non reconnue
comme un module Oto. L‟avantage de tels appels est qu‟on a alors accès aux attributs :STDOUT, :STDERR et :STATUS. L‟appel précédent à make pourrait donc être indiqué comme
suit, les expressions res_make[:STDOUT], res_make[:STDERR] et res_make[:STATUS] pouvant
alors être utilisées pour accéder aux informations appropriées :
res_make = make 'TestCompte'
ou
res_make = bash “make TestCompte“
26
....5.7
Un script de remise conditionnelle au résultat d’une
vérification préliminaire
Le prochain exemple présente un script Oto qui permet, à la remise d‟un travail, de vérifier que le
programme remis par un étudiant, par exemple Tp1.java, compile correctement pour que la remise
s‟effectue.
verifier_remise do |tp|
compilation = compiler_javac( tp ) {
:fichiers >> "Tp1.java"
}
if !compilation.reussi?
msg_erreur = compilation.message_erreur_echoue
end
msg_erreur
end
Ce script, contenu dans le fichier verif.oto, serait activé comme suit :
$ oto creer_boite --avec_code_permanent \
--avec_liste_exacte=‟(Tp1.java)‟ --avec_verification BoiteTp1 verif.oto
Lors de la remise du fichier Tp1.java dans BoiteTp1 par un étudiant, si la compilation réussit, alors
le fichier sera déposé dans la boite. Par contre, si une ou des erreurs de compilation sont signalées,
alors la remise ne sera pas effectuée.
Dans un tel script de vérification, utilisant verifier_remise, la remise sera effectuée uniquement si
la valeur retournée comme résultat du script est nil (valeur de retour implicite, comme dans
l‟exemple, ou valeur de retour explicite avec return.) Toute autre valeur de retour sera interprétée
comme un message d‟erreur, et dans ce cas la remise ne sera pas effectuée.
27
....5.8
Arguments de la méthode each de l’objet groupe
Lors d‟un appel à la méthode each de l‟objet groupe, il est possible d‟indiquer certaines
options, spécifiées par l‟intermédiaire d‟un dictionnaire (hash) Ruby. Les options présentement
supportées sont les suivantes:

:tri : Permet de spécifier l‟ordre dans lequel les travaux du groupe seront traités. Les
valeurs possibles sont les suivantes : :deposeur, :equipe et :code_permanent.
(Les deux dernières valeurs sont synonymes.) La valeur par défaut est :deposeur, i.e.,
les travaux sont traités dans l‟ordre du nom d‟usager (LAMISS) de l‟étudiant ayant
effectué le dépôt du travail.

:fichier_auxiliaires : Permet d‟indiquer si les fichiers auxiliaires fournis par
l‟enseignant doivent, ou non, être automatiquement copiés dans l‟espace de correction
avant de corriger le travail de l‟étudiant. La copie est effectuée si et seulement si la valeur
spécifiée est :copier.
L‟extrait de code qui suit illustre l‟utilisation combinée de ces deux options, script dont le
comportement sera semblable à celui vu à la section précédente, où le fichier makefile de
l‟enseignant devait être utilisé pour traiter le programme de l‟étudiant.
groupe.each( :tri => :equipe, :fichiers_auxiliaires => :copier ) do |tp|
tp['Resultats'] = bash( “make TestCompte” )
end
puts produire_rapport_complet( groupe )
28
6 Les commandes Oto
Une commande Oto est invoquée à l‟aide de la commande Unix oto. Le format générique de
l‟appel est le suivant:
oto <commande> [options] <arguments>
où <commande> est le nom de la commande Oto à invoquer, [options] est une liste facultative
d‟options, et <arguments> est la liste des arguments de la commande. Les options peuvent
apparaître dans n‟importe quel ordre, mais doivent apparaître avant les arguments de la commande.
Une option commence toujours par une paire de tirets. Les arguments, quant à eux, sont
généralement positionnels, ce qui veut dire qu‟ils doivent apparaître dans un ordre précis.
....6.1
Liste des commandes
Le tableau suivant présente la liste des commandes Oto. La deuxième colonne présente la liste des
options et arguments. Les arguments sont présentés dans l‟ordre, c‟est-à-dire que l‟ordre vertical des
arguments dans le tableau correspond à l‟ordre horizontal des arguments sur la ligne de commande.
Les options et les arguments sont décrits plus en détail dans les sections suivantes.
Commande Oto
Options et
arguments
Description
activer_eval
--public
--ecraser
<eval>
<fichier+>
Active une évaluation dont le nom sera <eval> et qui est
composée des fichiers <fichier+>. Par défaut,
l‟évaluation est activée en mode privé. Pour qu‟elle soit
accessible aux étudiants, il faut utiliser l‟option --public.
Un script, dénoté par une extension « .Otto », doit être
présent. Si l‟option --ecraser est indiquée et qu‟une
évaluation du même nom existe déjà, elle sera écrasée par
la nouvelle.
afficher_evaluation
--script_seul
<enseignant>
<eval>
Affiche le contenu d'une évaluation activée par un
enseignant, en autant que celle-ci ait été activée en mode
public. Par défaut, la commande affiche tous les fichiers
composant l'évaluation.
confirmer_remise
<enseignant>
Produit la liste des fichiers remis au nom des étudiants
<equipe> dans la <boite> de <enseign>.
<boite>
<equipe>
corriger_groupe
--public
--delai=<n>
--sortie_maximum=<n>
<eval>
<rep+>
Corrige le groupe de travaux <rep+> à l‟aide de
l‟évaluation Oto dont l‟identifiant est <eval>. Chaque
travail est situé dans son propre répertoire. Le rapport de
correction sort sur sdtout, et la progression de la
commande sur stderr (si l‟option ++TRACE est
activée).
29
Commande Oto
creer_boite
Options et
arguments
--avec_code_permanent
--echeance="(<date>)"
Description
Crée une nouvelle boîte à TP dont le nom sera <boite>.
D‟autres options, mutuellement exclusives dans certains
cas, peuvent aussi être spécifiées : voir Section 2.1.
<boite>
desactiver_eval
--public
<eval>
Désactive et détruit les fichiers de l‟évaluation Oto
identifié par <eval>.
decrire_boite
<boite>
Affiche les propriétés de la boîte de remise (spécifiées lors
de sa création), ainsi que son contenu, i.e., la liste des
travaux remis.
decrire_module
<nomModule>
Décrit l‟interface du module de correction indiqué : rôle,
descriptions des arguments et des résultats.
detruire_boite
--detruire_travaux
<boite>
Détruit la boîte à TP dont le nom est <boite>. Une boîte
qui contient encore des travaux ne peut pas être détruite
sauf si on utilise l‟option appropriée.
detruire_espace
(aucun)
Détruit entièrement et inconditionnellement l‟espace Oto
de l‟utilisateur. À utiliser avec précaution!
lister_boites
<enseignant>
Produit la liste les boîtes à TP créées par <enseignant>.
lister_commandes
(aucun)
Produit la liste des commandes reconnues par Oto. C‟est
la commande par défaut lorsqu‟aucune commande n‟est
spécifiée.
lister_evaluations
<enseignant>
Produit la liste des évaluations publiques activées par
<enseignant>.
lister_evaluations
--prive
Produit la liste des évaluations privées activées par
l‟usager.
lister_evaluations
--verif_remise
Produit la liste des évaluations de vérification de remise
associées à des boîtes créées par l‟usager.
lister_modules
Produit la liste des divers modules de correction
disponibles.
prendre_tp
<boite>
Prend les TP dans la boîte identifiée par <boite> et les
dépose dans le répertoire courant de l‟utilisateur. Chaque
travail est déposé dans son propre répertoire.
rendre_tp
<enseign>
<boite>
<equipe>
<fichier+>
Dépose un TP composé des fichiers <fichier+> dans la
boîte à TP <boite> de l‟enseignant <enseign> au nom
des étudiants <equipe>. On peut indiquer un répertoire,
auquel cas tout son contenu est (récursivement) remis.
30
Commande Oto
Options et
arguments
Description
supprimer_doublons
(aucun)
Supprime du répertoire courant les remises multiples
effectuées par un étudiant ou un groupe d‟étudiants, telles
qu‟obtenues par l‟exécution de la commande
prendre_tp. Les doublons ne sont toutefois pas
supprimés complètement, puisqu‟ils sont conservés dans
un répertoire nommé Doublons.
tester_module
(aucun)
Commande administrative pour exécuter un autodiagnostic (tests unitaires) du système.
verifier_tp
--prive
--delai=<n>
-- sortie_-
Vérifie un TP composé des fichiers <fichier+> à l‟aide
de l‟évaluation Oto <eval> de l‟enseignant
<enseignant>. Le rapport d‟évaluation sort sur
stdout.
maximum=<n>
<enseignant>
<eval>
<fichier+>
version
(aucun)
....6.2
Liste des arguments
Émet sur stdout le numéro de version d‟Oto.
Le tableau suivant décrit les arguments des commandes Oto. Notons qu‟il n‟y a pas de limites fixées a
priori sur le nombre de caractères permis pour les identificateurs.
Arguments
Descriptions
<boite>
Nom d‟une boîte à TP. Cet identificateur se compose possiblement de lettres, de
chiffres, de tirets et de soulignements.
<equipe>
Noms des membres de l‟équipe, séparés par des virgules, sans espace. Chaque nom
est un identifiant composé possiblement de lettres, chiffres, tirets et soulignements;
par exemple un code permanent ou une juxtaposition nom_prenom.
<eval>
Nom donné à une évaluation Oto (script et fichiers associés) Oto. Cet identifiant est
composé possiblement de lettres, chiffres, tirets et soulignements.
<fichier+>
Liste de fichiers et répertoires, séparés par un ou des espaces. La liste doit
comprendre au moins un élément.
<enseignant>
Nom d‟usager Unix de l‟enseignant concerné.
<rep+>
Liste de répertoires, séparés des espaces. Doit comprendre au moins un élément.
31
....6.3
Liste des options
Le tableau suivant décrit les options des commandes Oto. Les options ne sont pas nécessairement
disponibles pour chacune des commandes. Veuillez vous référer à la liste des commandes pour savoir
quelles options s‟appliquent à quelles commandes.
Option
Description
++TRACE
Commande s‟appliquant à Oto dans son ensemble (donc l‟option doit être spécifiée
avant le nom de la commande Oto à exécuter) et permettant de générer une trace
d‟exécution (sur stderr) montrant la progression dans l‟exécution d‟un script de
correction. Existe aussi sous la forme abrégée « ++T ».
--avec_code_permanent
Voir la commande creer_boite.
--avec_liste_exacte=
"(....)"
--avec_liste_minimum=
"(....)"
--avec_liste_maximum=
"(....)"
--avec_verification
--echeance="(<date>)"
Voir la commande creer_boite. Il ne doit pas y avoir d‟espace dans la
spécification de la date, ni avant ou après le signe d‟égalité, et les guillemets sont
obligatoires.
--detruire_travaux
Voir la commande detruire_boite.
--delai=<n>
Un délai (temps d‟exécution CPU) est accordé à chaque tâche pour s‟exécuter et
retourner ses résultats. Si une tâche ne se complète pas dans le délai prescrit,
l‟exécution du script est sabordée. Par défaut, ce délai est de 2 secondes. Cette
option peut être utilisée pour modifier ce délai. Il ne doit pas y avoir d‟espace entre
le signe d‟égalité, ce qui le précède et ce qui le suit.
Exemple: --delai=6, pour amener le délai à six secondes.
Conseil: s‟il est prévu qu‟une tâche est particulièrement longue, il peut être utile
d‟augmenter ce délai pour éviter qu‟Oto ne saborde un script qui se déroule en fait
normalement. À l‟opposé, un étudiant qui a une boucle infinie dans son code doit
attendre la fin du délai pour savoir ce qui se passe. Il peut raccourcir ce délai
d‟attente en abaissant le délai à une seconde, pour réduire la durée du cycle itératif
de correction/vérification.
32
Option
Description
--sortie_maximum=<n>
Une taille maximale de fichiers/sortie est accordée à chaque tâche pour s‟exécuter et
retourner ses résultats. Si une tâche dépasse cette limite, l‟exécution du script est
sabordée. Par défaut, cette taille limite est de 512 blocs (de 512K). Cette option peut
être utilisée pour modifier cette taille limite. Il ne doit pas y avoir d‟espace entre le
signe d‟égalité, ce qui le précède et ce qui le suit.
--detruire_travaux
Voir la commande detruire_boite.
--prive
Par défaut, certaines commandes Oto utilisent une évaluation publique. Pour utiliser
l‟évaluation privée du même nom à la place, il faut utiliser cette option.
--public
Par défaut, certaines commandes Oto utilisent une évaluation privée. Pour utiliser
l‟évaluation publique du même nom à la place, il faut utiliser cette option.
33
....6.4
Commandes pour cas d’utilisation particuliers
De façon à faciliter l‟utilisation d‟Oto pour certains types particuliers de programmes – programmes
filtres, bibliothèques de routines et classes simples –, certaines commandes de haut niveau ont été
définies. Ces commandes sont expliquées plus en détail soit dans le « Guide pratique pour la
conception et la correction de travaux de laboratoires », soit dans le « Guide d‟utilisation destiné aux
étudiants »
Commande Oto
Options et arguments
Description
Vérifie un programme filtre – qui lit sur l‟entrée
standard et écrit sur la sortie standard – et ce à
partir d‟une description textuelle simple
(<fichierTests>)des cas de tests, qui seront
vérifiés par comparaisons textuelles.
tester_filtre
--strict
tester_methodes
<fichier>
<fichierTests>
<fichier+>
Vérifie un programme Java définissant une
bibliothèque de méthodes – exportant uniquement
des méthodes static et public – et ce à partir
d‟une description textuelle simple
(<fichierTests>) des cas de tests qui seront
vérifiés à l‟aide de JUnit.
tester_classe
<fichier>
<fichierTests>
<fichier+>
Vérifie un programme Java définissant une classe
d‟objets simples – méthodes d‟instance
uniquement, pas de méthodes static – et ce à
partir d‟une description textuelle simple
(<fichierTests>) des cas de tests qui seront
vérifiés à l‟aide de JUnit.
<fichier>
<fichierTests>
<fichier+>
34
7 Les modules de correction Oto
Les sous-sections suivantes décrivent les modules actuellement disponibles avec Oto. Dans chaque cas,
on indique quels sont les paramètres d‟entrée et les valeurs de sortie retournées. Les paramètres
d‟entrée sont spécifiés sous forme d‟arguments, par exemple :
}
Quant aux résultats, ils sont accessibles avec l‟opérateur « [] », puisque l‟ensemble des résultats est
retourné sous forme d‟un hash Ruby, par exemple :
nbErreurs = tests[:nberreurs]
detailExecution = tests[:detail]
De plus, chaque exécution d‟un module retourne aussi certains attributs décrivant l‟exécution, attributs
au sens des objets, donc accessible avec une notation telle tests.reussi? ou tests.resultats :
Quelques-uns de ces attributs sont les suivants – pour plus de détails, voir le mémoire de maîtrise de
Paul Lessard (appendice E) :

execute? : Est-ce que le module s‟est exécuté sans problème ?

reussi? : Est-ce que l‟objectif du module a été réussi pour le travail corrigé, par exemple,
a-t-il été compilé sans erreur, exécuté sans erreur au niveau des tests, etc.?

resultats : Les divers résultats produits par l‟exécution (sous forme d‟un hash). Donc,
tests[:nberreurs] = tests.resultats[:nberreurs].
35
....7.1
Le module compiler_javac
Le module compiler_javac permet de compiler un programme Java. Les paramètres et résultats sont
détaillés dans les deux tableaux suivants.
Paramètre
Mode
Description
fichiers
obligatoire
Liste des fichiers à compiler, séparés par des espaces. En général, le
fichier racine du projet suffit.
On peut aussi utiliser le mot-clé :fichier.
racine
facultatif
Répertoire où doit se produire la compilation, si différent du
répertoire racine du travail étudiant. Ce répertoire est relatif au
répertoire racine étudiant.
classpath
facultatif et
global
Liste des répertoires qui doivent être ajoutés au classpath pour la
compilation, sans espaces, séparés par des deux-points. Le répertoire
racine étudiant et le répertoire racine du script font automatiquement
partie du classpath.
options
facultatif
Liste facultative d‟options, avec ou sans espaces, à transmettre
directement au compilateur javac.
Résultat
stdout
Description
Sortie de la commande de compilation.
36
Soulignons que la commande Oto decrire_module peut être utilisée pour obtenir les informations
décrivant un module donné. Par exemple, pour le module compiler_javac, l‟exécution de la
commande decrire_module générerait (sur stdout) les informations suivantes :
******************************
*** Extension
= compiler_javac
*** Descripteur = Compilation java
*** Type
= Individuel
*** Role
=
Invoque javac, le compilateur java.
*** Arguments ***
-- classpath
(Opt.) String ::
Path additionnel pour chercher les classes, en sus du classpath systeme, de la racine
du projet, et de l'emplacement du script.
Separateur: ':'.
-- fichiers
(Obl.) String ::
Liste de fichiers a compiler, separes par des espaces.
Peut inclure des wildcards.
Chemin donne par rapport au repertoire racine du projet.
-- options
(Opt.) String ::
Autres options de compilation.
Nul par defaut.
-- racine
(Opt.) String ::
Chemin relatif de la racine du projet (relativement au repertoire racine du tp).
Defaut: racine du tp.
La commande javac est executee a partir de ce repertoire.
*** Resultats ***
++ stdout
String ::
sortie de la commande de compilation.
*****************************
37
....7.2
Le module tester_junit
Le module tester_junit permet d‟exécuter un test JUnit. Les paramètres et résultats sont détaillés
dans les tableaux suivants :
Paramètre
Mode
Description
classe
obligatoire
Nom de la classe qui implémente le test JUnit (sans l‟extension
“.class”).
racine
facultatif
Répertoire où doit se produire l‟exécution du test, si différent du
classpath
facultatif et
global
Liste des répertoires qui doivent être ajoutés au classpath pour
l‟exécution du test, sans espaces, séparés par des deux-points. Le
répertoire racine étudiant et le répertoire racine du script font
automatiquement partie du classpath.
version
facultatif
Deux valeurs possibles, soit 3 ou 4, selon que les tests sont en format
JUnit 3.0 ou JUnit 4.0 (avec annotations). Valeur par défaut = 4.
options
facultatif
Liste facultative d‟options, avec ou sans espaces, à transmettre
directement à la commande java.
Résultat
Description
nbtests
Nombre de tests exécutés au total (en nombre de méthodes et non en
nombre d‟assertions).
nberreurs
Nombre d‟erreurs trouvées, au total (prévues et imprévues).
nberreurs_prevues
Nombre d‟erreurs trouvées grâce aux assertions.
nberreurs_imprevues
Nombre d‟erreurs trouvées à cause des exceptions non traitées.
detail
Sortie de la commande.
38
....7.3
Le module tester_filtre
Le module tester_filtre permet de tester un programme au niveau des entrées et sorties textuelles
standards. Le programme est exécuté en lui passant des entrées sur stdin et les résultats de cette
exécution sont repris sur stdout. Ces résultats sont ensuite comparés aux résultats attendus. Les
chaînes de caractères retournées pour les résultats doivent être identiques, ou presque, aux chaînes de
retour prévues, sinon le test échoue ; par défaut, les différences au niveau des espaces blancs et de la
casse (minuscule/majuscule) sont ignorées dans cette comparaison, ainsi “ a+ B” et “a+b” sont
considérés équivalents – il est toutefois possible, à l‟aide d‟une option appropriée, de spécifier que ces
différences sont significatives (comparaison stricte).
Le test dans son ensemble s‟effectue au moyen d‟une série de cas de test. Pour chaque cas de test, on
doit avoir au minimum deux (2) fichiers. Le premier spécifie les données qui seront fournies au
programme sur stdin ; le nom de ce fichier doit débuter par “test” et se terminer par l‟extension
“.donnees”. Le deuxième fichier indique les résultats attendus (sur stdout) en fonction des données
reçues (sur stdin) ; il doit avoir le même nom que le premier mais avec une extension
“.resultats”. Finalement, il est aussi possible (mais pas obligatoire) de spécifier un troisième
fichier qui indique les arguments qui doivent être fournis au programme au moment de son appel
(argv) ; encore une fois, le nom du fichier doit être le même que les deux précédents, sauf pour
l‟extension qui doit être “.arguments”. Tous ces fichiers doivent se retrouver dans un même
répertoire, typiquement dans un sous-répertoire du répertoire où se trouve le script Oto associé.
Il est aussi possible de spécifier l‟ensemble des tests en utilisant un unique fichier de spécification des
tests. Le fichier de spécification doit comporter les séparateurs (entrée/sortie, début de cas de test et fin
de fichier) à utiliser. Ci-dessous un exemple de spécification :
===
49
--7
Ici le seul test spécifié indique une entrée « 49 » et une sortie « 7 ». Pour plus de détails sur
l‟utilisation d‟un tel fichier de tests et les différentes options, notamment le mode interactif de
spécification des données, voir le « Guide pratique pour la conception et la correction de travaux de
laboratoires ».
39
Les paramètres et résultats sont détaillés dans les tableaux suivants :
Paramètre
Mode
Description
filtre
obligatoire
Commande Unix à exécuter pour lancer le programme filtre de
l‟étudiant, par exemple: “java ClasseDuTp”, “a.out”.
tests
obligatoire
Répertoire où se trouvent les cas de tests pour le filtre. Ce répertoire
est relatif au répertoire du script Oto. Par défaut, les tests doivent se
trouver dans le même répertoire que le script Oto. Il est aussi possible
d‟indiquer un unique fichier de spécification de tests à la place du
répertoire.
racine
facultatif
debut_cas_test
facultatif
Caractère à utiliser pour indiquer le début d‟un cas de test. Plus
précisément, il faut que ce caractère apparaisse trois (3) fois
consécutives (ou plus) en début de ligne pour indiquer le début d‟un
nouveau cas de test. Valeur par défaut = “=”.
separateur
facultatif
Caractère à utiliser pour séparer les données et les résultats d‟un cas
de test. Plus précisément, il faut que ce caractère apparaisse trois (3)
fois consécutives (ou plus) en début de ligne pour indiquer la
séparation entre les données et les résultats du cas de test. Valeur par
défaut = “-”.
interactif
facultatif
Caractère à utiliser indiquer le mode interactif de spécifications des
données et des résultats (mode entrelacé). Une ligne de données est
alors représentée par une ligne débutant par ce caractère. Valeur par
défaut = “#”.
avec_details
facultatif
Si présent, alors lorsqu‟un test échoue, les détails du test sont
produits : données utilisées, résultats attendus, résultats obtenust. La
seule valeur possible est true.
options_diff
facultatif
Options de diff à utiliser pour la comparaison des résultats. Un
(unique) tiret “-” doit être spécifié pour l‟ensemble des options, par
exemple “-ci”. Par défaut, la comparaison se fait de façon
indulgente, i.e., les options utilisées si cet argument n‟est pas spécifié
sont “-ctibw”.
Résultat
Description
nbtests
Nombre de tests exécutés au total.
nberreurs
Nombre de tests qui ont échoué.
detail
40
....7.4
Les modules tester_methodes et tester_classe
Ces modules de test de haut niveau permettent de tester respectivement des méthodes statiques (classe
définissant une « bibliothèque » de méthodes) ou des méthodes d‟instance (classe définissant des objets
simples) d‟une classe Java, et ce grâce à un unique fichier de spécification de tests. Ces tests sont
exprimés plus simplement que des tests JUnit correspondants. Ils ont aussi l‟avantage de tester, de
façon indépendante des tests fonctionnels eux-mêmes, les signatures des méthodes afin d‟assurer que
ces signatures sont conformes à ce qui est attendu.
Les entrées de ces modules sont les suivantes :
Paramètre
Mode
Description
programme
obligatoire
Classe Java à tester, par exemple: “TpJava1.java”.
specifications
obligatoire
Fichier de spécification de tests à utiliser conjointement avec le
programme.
debut_cas_test
facultatif
Caractère à utiliser pour indiquer le début d‟un cas de test. Plus précisément,
il faut que ce caractère apparaisse trois (3) fois consécutives (ou plus) en
début de ligne pour indiquer le début d‟un nouveau cas de test. Valeur par
défaut = “=”.
separateur
facultatif
Caractère à utiliser pour séparer les données et les résultats d‟un cas de test.
Plus précisément, il faut que ce caractère apparaisse trois (3) fois
consécutives (ou plus) en début de ligne pour indiquer la séparation entre les
données et les résultats du cas de test. Valeur par défaut = “-”.
debut_instances
facultatif
Valide pour tester_classe seulement. Caractère à utiliser pour
indiquer le début de la spécification des instances de test. Il faut que ce
caractère apparaisse trois (3) fois consécutives (ou plus) en début de ligne
pour indiquer le début d‟un nouveau cas de test. Valeur par défaut = “@”.
Les sorties sont les mêmes que pour le module tester_junit, à savoir :
Résultat
Description
nbtests
Nombre de tests exécutés au total (en nombre de méthodes et non en
nombre d‟assertions).
nberreurs
Nombre d‟erreurs trouvées, au total (prévues et imprévues).
nberreurs_prevues
Nombre d‟erreurs trouvées grâce aux assertions.
nberreurs_imprevues
Nombre d‟erreurs trouvées à cause des exceptions non traitées.
detail
41
....7.5
Le module compiler_c
Le module compiler_c permet de compiler un programme C. La tâche échoue si la compilation
échoue, qu‟il s‟agisse d‟erreurs ou d‟avertissements. Les paramètres et résultats sont les suivants.
Paramètre
Mode
Description
fichiers
obligatoire
Liste des fichiers à compiler, séparés par des espaces.
On peut aussi utiliser le mot-clé :fichier.
racine
facultatif
Répertoire où doit se produire la compilation, si différent du
options
facultatif
Liste facultative d‟options, avec ou sans espaces, à transmettre au
compilateur.
compilateur
facultatif
Compilateur C à utiliser; par défaut, utilise le compilateur gcc.
Résultat
Description
stdout
Sortie de la commande de compilation.
Signalons que l‟utilisation de ce module n‟est recommandée que lorsqu‟un nombre (relativement)
limité de fichiers doit être compilé. Dans le cas où plusieurs fichiers sont requis, l‟utilisation d‟un
makefile est préférable. Signalons aussi que le nom de l‟exécutable peut être indiqué, si désiré, à
l‟aide du paramètre options.
....7.6
Le module detecter_plagiat
Le module detecter_plagiat permet de comparer entre eux des travaux remis avec Oto, et ce pour
en calculer la similarité entre eux. Si celle-ci s‟avère importante, il pourrait alors s‟agir de cas de
plagiat. Le module retourne alors le nom des dossiers et fichiers concernés pour que l‟enseignant puisse
les examiner plus attentivement. Dans sa version actuelle, le module permet de détecter les similarités
entre fichiers et ce même si des modifications simples et «naïves» ont été effectuées, par exemple,
changement de noms de variables, modification des indentation, etc. – l‟outil utilisé, sim, utilise un
algorithme d‟alignement de séquences de lexèmes pour calculer la similarité (approximate string
matching).
Paramètre
Mode
Description
langage
facultatif
Langage de programmation des fichiers des répertoires comparés :
Java, C, MPD, OCL/USE. Par défaut Java.
fichiers
facultatif
Nom complet relatif de chacun des fichiers devant être contenus dans
les répertoires à comparer, séparés par des virgules, ou „*‟ pour
comparer tous les fichiers, par exemple „fichier1, fichier2‟. Utile pour
valider l‟existence d‟une liste précise de fichiers dans les répertoires à
comparer. Par défaut *.
42
Paramètre
Mode
Description
repertoireBase
facultatif
Chemin absolu du répertoire où sont contenus les répertoires devant
être comparés au répertoire traité par la commande utilisant le module
(verifier_tp ou corriger_groupe). Ce paramètre permet à
l‟enseignant de comparer des travaux d‟étudiants avec des travaux
situés dans d‟autres répertoires pour, par exemple, comparer chacun
des travaux d‟un groupe avec ceux d‟un autre groupe, (y compris des
travaux de sessions précédentes). Par défaut le répertoire courant.
discriminant
facultatif
Discriminant de ligne de commande Unix permettant de choisir les
répertoires à comparer à partir du répertoire de base. Par défaut
*.tp_oto.
exclure
facultatif
Liste de fichiers devant être exclus de la comparaison. Utile si la liste
de fichiers du paramètre „fichiers‟ est *. Les fichiers mentionnés
dans cette liste ne doivent pas forcément exister dans les répertoires
comparés, aucune validation n‟étant faite à ce niveau. Ce paramètre
peut être utile pour exclure de la comparaison un fichier remis par
l‟enseignant et que l‟étudiant n‟aurait pas dû rendre avec son TP. Par
défaut, aucun fichier n‟est exclu.
plancher
facultatif
Pourcentage minimal de similarité entre les fichiers pour que leur
comparaison soit considérée comme un cas de plagiat potentiel.
Valeur comprise entre 0 et 100. Lorsqu‟une comparaison retourne une
similarité supérieure ou égale à ce plancher, le cas est mentionné dans
le rapport. Pour spécifier cette valeur pour l‟ensemble des fichiers, on
indique „*=70‟, le pourcentage étant alors de 70%. On peut
également la spécifier pour chaque fichier, sous la forme
„fichier1=60,fichier2=55‟, en autant que les fichiers mentionnés
soient déclarés au paramètre „fichiers‟. Par défaut, le plancher est
de 60% pour tous les fichiers.
validationListeFichiers
facultatif
Permet ou interdit la présence d‟autres fichiers dans les répertoires
lorsque le paramètre „fichiers‟ n‟est pas „*‟, de manière stricte
(„strict‟) ou indulgente („indulgent‟) – par défaut indulgente.
L‟option „strict‟ avorte l‟exécution du module si des fichiers
superflus sont trouvés dans un répertoire, alors que „indulgent‟ les
tolère. Si un fichier non déclaré est présent dans le répertoire, il est
utilisé aux fins de comparaison.
squelettes
facultatif
Permet d‟ignorer la partie commune d‟un fichier fourni par
l‟enseignant aux étudiants (squelette de programme à être complété).
Le chemin du „squelette‟, indiquant le fichier à compléter, doit être
relatif au paramètre du répertoire de base (ou le répertoire courant, si
le répertoire de base n‟est pas déclaré). Oto retire alors la partie
commune et ne compare que les modifications faites par les étudiants.
43
Résultat
Description
nbCasTrouves
Nombre de répertoires contenant au moins un fichier semblable à l‟un
de ceux du répertoire traité.
rapport
Liste des noms de fichiers et des répertoires de chacun des fichiers
considérés comme suspects, avec le pourcentage de similarité.
44
....7.7
Le module tester_pep8
Le module tester_pep8 permet de tester un programme assembleur asem8/pep8 (utilisé dans le
cours INF2170), et ce à l‟aide de tests au niveau des entrées/sorties standards – donc comme
tester_filtre. Le programme est tout d‟abord assemblé (avec asem8), puis le fichier objet est
exécuté (avec pep8), en le traitant comme un programme filtre (lecture des entrées sur stdin et
émission des résultats sur stdout). Les résultats produits sont comparés aux résultats attendus. Les
chaînes de caractères retournées pour les résultats doivent être identiques, ou presque, aux chaînes
prévues, sinon le test échoue ; par défaut, les différences au niveau des espaces et de la casse
(minuscule/majuscule) sont ignorées, ainsi “ a+ B” et “a+b” sont considérés équivalents – mais il est
possible, à l‟aide d‟une option, de spécifier que ces différences sont significatives (comparaison
stricte).
Les tests s‟effectuent au moyen d‟une série de cas de test. Pour chaque cas de test, on doit avoir
deux (2) fichiers. Le premier spécifie les données qui seront fournies au programme sur stdin ; le
nom de ce fichier doit débuter par “test” et doit se terminer par l‟extension “.donnees”. Le
deuxième indique les résultats attendus (sur stdout) en fonction des données reçues (sur stdin) ; il
doit avoir le même nom que le premier mais une extension “.resultats”. Il est aussi possible (mais
pas obligatoire) de spécifier un troisième fichier qui indique les arguments fournis au programme à son
appel (argv) ; encore une fois, le nom du fichier doit être le même que les deux précédents, sauf pour
l‟extension qui doit être “.arguments”. Tous ces fichiers doivent se trouver dans un même répertoire,
typiquement dans un sous-répertoire du répertoire où se trouve le script Oto associé.
Paramètre
Mode
Description
programme
obligatoire
Le nom du fichier fourni par l‟étudiant, par exemple: “TP1.pep”.
tests
obligatoire
Répertoire où se trouvent les cas de tests. Ce répertoire est relatif au
répertoire du script Oto. Par défaut, les tests sont dans le même
répertoire que le script Oto.
racine
facultatif
options_diff
facultatif
Options de diff à utiliser pour la comparaison des résultats. Un
(unique) tiret “-” doit être spécifié pour l‟ensemble des options, par
exemple “-ci”. Par défaut, la comparaison se fait de façon
indulgente, i.e., les options utilisées si cet argument n‟est pas spécifié
sont “-ctibw”.
Résultat
Description
nbtests
Nombre de tests exécutés au total.
nberreurs
Nombre de tests qui ont échoué.
detail
45
....7.8
Le module tester_hunit
Le module tester_hunit permet d‟exécuter un programme de tests HUnit, donc des tests unitaires
pour des programmes Haskell : voir http://hunit.sourceforge.net pour plus de détails.
Paramètre
Mode
Description
programme
obligatoire
Nom du programme de test à exécuter (extension “.hs”).
racine
facultatif
Résultat
Description
erreursDeCompilation
Nombre d‟erreurs de compilation – si non nul, alors les tests ne sont
pas exécutés.
nbtests
Nombre de tests exécutés (en nombre de méthodes et non en nombre
d‟assertions).
nberreurs
Nombre d‟erreurs.
detail
46
....7.9
Le module produire_statistiques
Le module produire_statistiques permet de produire certaines statistiques suite à la correction
d‟un groupe de travaux. L‟appel du module retourne un String, qu‟on peut ensuite utiliser, par
exemple, en l‟affichant sur la sortie standard.
Un seul paramètre est requis:
Paramètre
nom_variable
Mode
obligatoire
Description
Nom de la variable (résultat associé à chaque TP) à prendre en
considération pour les statistiques.
Voir la section 5.2 pour un exemple de script. La figure suivante illustre un résultat produit par un tel
rapport avec statistiques, pour un « groupe » de deux travaux où le nom de la variable à analyser et
compiler est Note.
**********************************************************************
RESULTAT COLLECTIF: Statistiques sur les travaux
Nombre de travaux consideres: 2
Nombre de travaux dont le resultat 'Note' n'etait pas defini: 0
Pour le resultat 'Note':
Moyenne: 75.0
Mediane: 75.0
Ecart type: 35.355
Resultat minimum: 50.0
Resultat maximum: 100.0
Distribution des resultats:
100.0 => 1
50.0 => 1
47
8 Les modules de rapports Oto
Outre des modules de correction, Oto comporte aussi des modules qui permettent de produire des
rapports de correction. Deux modules sont actuellement disponibles.
....8.1
Module produire_rapport_complet
Ce module permet de produire un rapport complet qui comprend toutes les informations de chacun des
rapports individuels, de même que les rapports de statistiques. Le résultat de l‟exécution est une chaîne
de caractères comportement l‟ensemble des informations.
Les paramètres sont détaillés dans le tableau suivant :
Paramètre
Mode
Description
tri
facultatif
Permet d‟indiquer dans quel ordre les différents rapports individuels
seront combinés dans le rapport complet.
Les valeurs possibles sont les suivantes : :deposeur, :equipe et
:code_permanent. (Les deux dernières valeurs sont synonymes.)
La valeur par défaut est :deposeur, i.e., ordonnés en fonction du
nom d‟usager (LAMISS) de l‟étudiant ayant effectué le dépôt du
travail.
avec_script
facultatif
Si présent, alors le script de correction est inclus dans le rapport. La
seule valeur possible est true.
rapports_
individuels
facultatif
Si présent, alors en plus du rapport collectif, un fichier indépendant
est créé pour chaque travail. Ces divers fichiers sont mis dans le
répertoire spécifié (chaine de caractères) par rapports_
individuels. Ce répertoire peut être spécifié de façon relative ou
absolue. Une erreur est signalée si le répertoire n‟existe pas.
....8.2
Module envoyer_rapports_courriel
Ce module permet d‟envoyer par courriel chacun des rapports individuels. Son exécution a donc pour
effet de transmettre un ensemble courriels, alors que la commande retourne simplement une chaîne de
caractères qui informe de l‟envoi de ces courriels.
Note: Actuellement, cette instruction ne peut être utilisée que sur la machine oto.labunix.uqam.ca,
puisque c‟est uniquement sur cette machine que l‟information appropriée (adresses de courriel) est
disponible.
48
Les paramètres sont détaillés dans le tableau suivant :
Paramètre
Mode
Description
sujet
facultatif
Le sujet (subject) qui sera indiqué pour le courriel.
entete
facultatif
L‟entête (chaîne arbitraire de caractères, possiblement multilignes)
qui sera indiqué au début du corps du message, avant le rapport de
correction lui-même.
49

Guide d`utilisation à l`intention des enseignants et des - Oto

Transcription

Documents pareils

FEV/MARS 11

Made in Design rafle un prix Designer`s

chez vaness - S2H Communication

Untitled - Grand Hôtel du Lac Vevey

lire - HapsatouSy

Visualiser notre plaquette - OTO

câline - Cinq Mondes

Ces livres qui peuvent chan

Juillet-Septembre 2013

OOPS - Les Sens de Marrakech