Oto, un outil d’aide à la correction de...

Oto: Guide de l'enseignant 1

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 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. 2 À 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.

http://oto.uqam.ca/

http://oto.uqam.ca/application-web/OtoLogin.jsp


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


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).

1.creer_boite

2.activer_eval

--public

3.verifier_tp

4.

rendre_tp

5.

prendre_tp

8.

corriger_groupeDélaiécoulé

Script ettests publics

TP

Les TP

Script ettests privés

Enseignant

Étudiant

Rapport

Rapport

7.activer_eval

9.

desactiver_eval

10.desactiver_eval

--public

6.detruire_boite

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.


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:

creer_boite rendre_tp

detruire_boite prendre_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,

http://oto.uqam.ca/


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_maxi-

mum 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.


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>


....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.


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 :

activer_eval--public

verifier_tp

desactiver_eval--public

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


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.


....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:

activer_eval--prive

desactiver_eval--prive

corriger_groupe

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:

activer_eval

--prive

desactiver_eval--prive

corriger_groupeverifier_tp --prive


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 dia-gramme, 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...>


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 ».


....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.


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).

1.creer_boite

2.activer_eval

--public

3.verifier_tp

4.

rendre_tp

5.

prendre_tp

8.

corriger_groupeDélaiécoulé

Script ettests publics

TP

Les TP

Script ettests privés

Enseignant

Étudiant

Rapport

Rapport

7.activer_eval

9.

desactiver_eval

10.desactiver_eval

--public

6.detruire_boite

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


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é.


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


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 compi-

ler_javac, comme son nom l‟indique, permet de compiler un programme Java. La liste des


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 }


....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: tremblay_gu+2010.05.15.18.29.46.137069+TREG12121212.tp_oto

Equipe: TREG12121212

Depot: 2010-05-15 a 18:29

Deposeur: tremblay_gu

Nom: Guy Tremblay

Courriel: [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.


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.

19. groupe.each do |tp|

20. comp = compiler_javac( tp ) {:fichier >> 'Compte.java' }

21. tp['Compilation'] = if comp.reussi? then "OK" else "Erreurs!?" end

22.

23.

24. tests = tester_junit( tp ) {


26. }



29.




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.


....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.

1. groupe.each do |tp| 2. comp = compiler_javac( tp ) { 3. :fichier >> 'Compte.java' 4. } 5. 6. if comp.reussi? then 7. # La compilation a reussi: on peut lancer les tests. 8. tp['Compilation'] = "OK" 9. 10.



13. }



16.




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.



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.

1. groupe.each do |tp| 2. comp = compiler_javac( tp ) { 3. :fichier >> 'Compte.java' 4. } 5. 6. assurer( comp.reussi?, 'Compilation echouee :\n' + comp.message_erreur_echoue )

7. 8. tests = tester_junit( tp ) { 9. :classe >> 'TestCompte' 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.


....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. 9. groupe.each do |tp| 10. # Compilation

11. comp = compiler_javac( tp ) {

12. :fichier >> 'Compte.java'

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. tp['Compilation'] = if comp.reussi? then "OK" else "Erreurs!?" end

22.

23.

24. # Execution des tests



27. }

28.



31.



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.


....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é.

1. groupe.each do |tp| 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 acces-sibles 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).


TRAVAIL: tremblay_gu+2010.05.15.18.29.46.137069+TREG06065801.tp_oto

Equipe: TREG06065801

Depot: 2010-05-15 a 18:29

Deposeur: tremblay_gu

Nom: Guy Tremblay

Courriel: [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 attri-

buts :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“


....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.


....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 )


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>

<boite>

<equipe>

Produit la liste des fichiers remis au nom des étudiants

<equipe> dans la <boite> de <enseign>.

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).



Description

creer_boite --avec_co-

de_permanent

--echean-

ce="(<date>)"

<boite>

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.

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 --detrui-

re_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.



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 auto-diagnostic (tests unitaires) du système.

verifier_tp --prive

--delai=<n>

-- sortie_-

maximum=<n>

<enseignant>

<eval>

<fichier+>

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.

version (aucun) Émet sur stdout le numéro de version d‟Oto.

....6.2 Liste des arguments

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.


....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=

"(....)"

Voir la commande creer_boite.

--avec_liste_-

minimum=

"(....)"


--avec_liste_-

maximum=

"(....)"


--avec_veri-

fication Voir la commande creer_boite.

--echean-

ce="(<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.


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.

--detrui-

re_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.


....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

tester_filtre --strict

<fichier>

<fichierTests>

<fichier+>

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_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.

http://oto.uqam.ca/documents/guide-labos.pdf


http://oto.uqam.ca/documents/manuel-oto-etudiant.pdf

http://oto.uqam.ca/documents/manuel-oto-etudiant.pdf


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 :

tests = tester_junit( tp ) {

:classe >> 'TestCompte'

}

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 :

nbTests = tests[:nbtests]

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].


....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 Description

stdout Sortie de la commande de compilation.


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.

*****************************


....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 :


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 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 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.


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.


....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 ».




Les paramètres et résultats sont détaillés dans les tableaux suivants :


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.


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”.


nbtests Nombre de tests exécutés au total.

nberreurs Nombre de tests qui ont échoué.



....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 :


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 :


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.



....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.


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 répertoire racine du travail étudiant. Ce répertoire est relatif au répertoire racine étudiant.

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.


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).


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 *.



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.

validation-

ListeFichiers 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.



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é.


....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é.



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.


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”.


nbtests Nombre de tests exécutés au total.

nberreurs Nombre de tests qui ont échoué.



....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.



programme obligatoire Nom du programme de test à exécuter (extension “.hs”).



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.


http://hunit.sourceforge.net/


....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:


nom_variable obligatoire 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


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 :


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.


Les paramètres sont détaillés dans le tableau suivant :


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.

Oto, un outil d’aide à la correction de...

Documents

Transcript of Oto, un outil d’aide à la correction de...