Oto, un outil d'aide à la correction de programmes

Oto, un outil d'aide à la correction de programmes

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.

Oto: Guide de l'enseignant 2 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

Oto: Guide de l'enseignant 3

Oto: Guide de l'enseignant 4 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 . c r e e r _ b o ite 2 . a c tiv e r _ e v a l -- p u b lic 3 . v e rif ie r _ tp 4 .

r e n d r e _ tp 5 . p r e n d r e _ tp 8 . c o rr ig e r _ g ro u p e D é la i é c o u lé S c r ip te t te s tsp u b lic s T P L e sT P S c r ip te t te s tsp riv é s E n s e i g n a n t É t u d i a n t R a p p o r t R a p p o r t 7 . a c tiv e r_ e v a l 9 . d e s a c ti v e r _ e v a l 1 . d e s a c ti v e r _ e v a l --p u b l ic 6 . d e tru ir e _ b o ite 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.

Oto: Guide de l'enseignant 5 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: c r e e r _ b o i t e r e n d r e _ t p d e t r u i r e _ b o i t e p r e n d r e _ t p 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 où 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,

Oto: Guide de l'enseignant 6 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.

Oto: Guide de l'enseignant 7 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ù indique le nom d‟usager Unix de l‟enseignant : oto lister_boites ....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 où est le nom du compte Unix de l‟enseignant à qui il faut rendre le TP, est le nom de la boîte, est la «liste» des membres de l‟équipe qui rend ce TP, et 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

Oto: Guide de l'enseignant 8 ....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 où 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 où 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.

Oto: Guide de l'enseignant 9 2 Vérification préliminaire des travaux L‟objectif de l‟étape de vérification préliminaire est de guider l‟étudiant dans la réalisation du TP, de lui permettre de vérifier qu‟il est sur la bonne voie. La vérification joue donc un rôle de filtre, assurant qu‟un TP remis pour correction fonctionne minimalement, mais sans nécessairement révéler en quoi consistera la correction finale.

Avant que l‟étudiant puisse vérifier son travail, les modalités précises de cette vérification doivent d‟abord être spécifiées par l‟enseignant. Entre autres, il faut indiquer quels sont les tests à exécuter sur le travail étudiant.

Peut-être aussi faut-il compiler le travail au préalable? La séquence exacte des tâches à exécuter lors de la vérification est spécifiée dans un script Oto, spécifique au travail à vérifier. Ce script est généralement accompagné des tests (et possiblement de fichiers associés) qui doivent être exécutés par la même occasion. L‟ensemble script, tests et/ou fichiers auxiliaires est ce qui compose une évaluation. Nous reviendrons sur cette question dans une section ultérieure. Pour le moment, nous nous concentrons sur le processus de vérification, lequel est schématisé dans la figure suivante où verifier_tp est exécutée par les étudiants alors que les autres actions sont effectuées par l‟enseignant : a c t i v e r _ e v a l - - p u b l i c v e r i f i e r _ t p d e s a c t i v e r _ e v a l - - p u b l i c 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 où est le nom donné à cette évaluation, et 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

Oto: Guide de l'enseignant 10 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ù 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 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 ....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 où est le nom du compte Unix de l‟enseignant qui a publié l‟évaluation, est le nom de l‟évaluation, et 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.

Oto: Guide de l'enseignant 11 ....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 où est le nom de l‟évaluation à désactiver.

3 Correction des travaux Supposons que les étudiants ont remis leurs travaux ─ chacun à l‟aide de la commande rendre_tp ─ et que ces travaux sont maintenant disponibles dans un répertoire donné du compte Unix de l‟enseignant ─ qui les a obtenus à partir de la boîte de TPs à l‟aide de la commande prendre_tp (cf. Section 2.3). L‟enseignant peut maintenant procéder à la correction de ces divers travaux. Les étapes de la correction des travaux sont les suivantes: a c t i v e r _ e v a l - - p r i v e d e s a c t i v e r _ e v a l - - p r i v e c o r r i g e r _ g r o u p e L‟enseignant commence par activer l‟évaluation (i.e., le script et les tests) devant servir à la correction.

Puis, il procède à la correction de l‟ensemble des travaux. Enfin, il désactive l‟évaluation. Notons que l‟évaluation pour fin de correction est privée et accessible de lui seul, contrairement à l‟évaluation pour fin de vérification préliminaire (section précédente) qui elle est mise à la disposition des étudiants pour les guider et assurer qu‟ils sont sur la bonne voie. Ces deux évaluations sont le plus souvent distinctes l‟une de l‟autre car la correction finale est généralement plus sévère et complète que la vérification préliminaire.

Il est possible qu‟il soit nécessaire, dans certains cas, de mieux examiner le comportement d‟un travail donné ou encore de corriger des travaux remis en retard. Dans ce cas, le processus de correction peut être affiné de la manière suivante: a c t iv e r _ e v a l - - p r iv e d e s a c ti v e r _ e v a l - - p r i v e c o r r ig e r _ g r o u p e v e r if i e r _ t p- - p r i v e

Oto: Guide de l'enseignant 12 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 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

Oto: Guide de l'enseignant 13 où est le nom de l‟évaluation (nécessairement privée) devant servir à corriger les travaux étudiants, et 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 ».

Oto: Guide de l'enseignant 14 ....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.

Oto: Guide de l'enseignant 15 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 . c r e e r _ b o ite 2 . a c tiv e r _ e v a l -- p u b lic 3 . v e rif ie r _ tp 4 . r e n d r e _ tp 5 . p r e n d r e _ tp 8 . c o rr ig e r _ g ro u p e D é la i é c o u lé S c r ip te t te s tsp u b lic s T P L e sT P S c r ip te t te s tsp riv é s E n s e i g n a n t É t u d i a n t R a p p o r t R a p p o r t 7 .

a c tiv e r_ e v a l 9 . d e s a c ti v e r _ e v a l 1 . d e s a c ti v e r _ e v a l --p u b l ic 6 . d e tru ir e _ b o ite 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

Oto: Guide de l'enseignant 16 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é.

Oto: Guide de l'enseignant 17 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

Oto: Guide de l'enseignant 18 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

Oto: Guide de l'enseignant 19 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 }

Oto: Guide de l'enseignant 20 ....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: tremblay.guy@uqam.ca RESULTATS: Compilation: OK Nb erreurs: 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.

Oto: Guide de l'enseignant 21 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 > 'Compte.java' } 21. tp['Compilation'] = if comp.reussi? then "OK" else "Erreurs!?" end 22. 23. 24. tests = tester_junit( tp ) { 25. :classe >> 'TestCompte' 26. } 27. nbErrs = tests[:nberreurs] 28. nbTests = tests[:nbtests] 29.

30. # Elements a inclure dans le rapport 31.

tp['Nb erreurs'] = nbErrs 32. tp['Note'] = 100 * ( nbTests - nbErrs ) / nbTests 33. tp['Details'] = simplifier( tests[:detail] ) 34. end 35. 36. stats = produire_statistiques( groupe ) { 37. :nom_variable >> 'Note' 38. } 39. 40. puts produire_rapport_complet( groupe, stats : tri >> :code_permanent } À la ligne 33, on obtient l‟ensemble des détails associés à l‟exécution des tests pour le travail en cours de traitement (tests[:details]), détails qu‟on associe au travail pour ensuite les inclure dans le rapport. Toutefois, il faut savoir que les détails générés par JUnit sont nombreux et détaillés (notamment, contenu de la pile d‟exécution au moment où une assertion de test n‟a pas été satisfaite).

Il peut donc être utile de filtrer les éléments inutiles et ainsi simplifier les informations, et c‟est ce qui est fait ici en appelant la fonction simplifier, fonction auxiliaire écrite en Ruby qui ne conserve que les éléments clés du contexte d‟exécution. Quant aux informations concernant les notes et leur distribution, moyenne, etc., elle sont produites (ligne 36) en utilisant le module collectif produire_statistiques, où on indique simplement le nom de la variable (de l‟attribut) que l‟on désire analyser et compiler, ici, Note. Finalement, l‟option indiquée à la ligne 40 permet de présenter les rapports en ordre croissant des codes permanents – les valeurs possibles pour l‟option :tri sont :deposeur, :equipe et :code_permanent, les deux dernières étant synonymes.

Oto: Guide de l'enseignant 22 ....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. 11. tests = tester_junit( tp ) { 12. :classe >> 'TestCompte' 13. } 14. nbErrs = tests[:nberreurs] 15. nbTests = tests[:nbtests] 16. 17. # Elements a inclure dans le rapport 18. tp['Nb erreurs'] = nbErrs 19. tp['Note'] = 100 * ( nbTests - nbErrs ) / nbTests 20. tp['Details'] = simplifier( tests[:detail] ) 21. else 22. # La compilation n‟a pas reussi: inutile d‟executer les tests 23. tp['Compilation'] = comp.message_erreur_echoue 24. end 25. end 26.

27. puts produire_rapport_complet( groupe )

Oto: Guide de l'enseignant 23 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. 13. puts produire_rapport_complet( groupe ) 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.

Oto: Guide de l'enseignant 24 ....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 25. tests = tester_junit( tp ) { 26. :classe >> 'TestCompte' 27. } 28. 29. nbErrs = tests[:nberreurs] 30. nbTests = tests[:nbtests] 31.

32. # Elements a inclure dans le rapport 33. tp['Nb erreurs'] = nbErrs 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.

Oto: Guide de l'enseignant 25 ....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. 13. puts produire_rapport_complet( groupe ) 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).

Oto: Guide de l'enseignant 26 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: tremblay.guy@uqam.ca 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“

Oto: Guide de l'enseignant 27 ....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.

Oto: Guide de l'enseignant 28 ....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 )

Oto: Guide de l'enseignant 29 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 [options] où est le nom de la commande Oto à invoquer, [options] est une liste facultative d‟options, et 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 Active une évaluation dont le nom sera et qui est composée des fichiers . 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 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 Produit la liste des fichiers remis au nom des étudiants dans la de . corriger_groupe --public --delai= --sortie_- maximum= Corrige le groupe de travaux à l‟aide de l‟évaluation Oto dont l‟identifiant est . 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).

Oto: Guide de l'enseignant 30 Commande Oto Options et arguments Description creer_boite --avec_co- de_permanent --echean- ce="()" Crée une nouvelle boîte à TP dont le nom sera . D‟autres options, mutuellement exclusives dans certains cas, peuvent aussi être spécifiées : voir Section 2.1. desactiver_eval --public Désactive et détruit les fichiers de l‟évaluation Oto identifié par . decrire_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 Décrit l‟interface du module de correction indiqué : rôle, descriptions des arguments et des résultats.

detruire_boite --detrui- re_travaux Détruit la boîte à TP dont le nom est . 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 Produit la liste les boîtes à TP créées par . 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 Produit la liste des évaluations publiques activées par . 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 Prend les TP dans la boîte identifiée par et les dépose dans le répertoire courant de l‟utilisateur.

Chaque travail est déposé dans son propre répertoire. rendre_tp Dépose un TP composé des fichiers dans la boîte à TP de l‟enseignant au nom des étudiants . On peut indiquer un répertoire, auquel cas tout son contenu est (récursivement) remis.

Oto: Guide de l'enseignant 31 Commande Oto Options et arguments Description supprimer_doublons (aucun) Supprime du répertoire courant les remises multiples effectuées par un étudiant ou un groupe d‟étudiants, telles qu‟obtenues par l‟exécution de la commande prendre_tp. Les doublons ne sont toutefois pas supprimés complètement, puisqu‟ils sont conservés dans un répertoire nommé Doublons. tester_module (aucun) Commande administrative pour exécuter un auto- diagnostic (tests unitaires) du système.

verifier_tp --prive --delai= -- sortie_- maximum= Vérifie un TP composé des fichiers à l‟aide de l‟évaluation Oto de l‟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 Nom d‟une boîte à TP. Cet identificateur se compose possiblement de lettres, de chiffres, de tirets et de soulignements.

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. Nom donné à une évaluation Oto (script et fichiers associés) Oto. Cet identifiant est composé possiblement de lettres, chiffres, tirets et soulignements. Liste de fichiers et répertoires, séparés par un ou des espaces. La liste doit comprendre au moins un élément.

Nom d‟usager Unix de l‟enseignant concerné. Liste de répertoires, séparés des espaces. Doit comprendre au moins un élément.

Oto: Guide de l'enseignant 32 ....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= ) " Voir la commande creer_boite. --avec_liste_- maximum= ) " Voir la commande creer_boite. --avec_veri- fication Voir la commande creer_boite. --echean- ce="()" 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= 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.

Oto: Guide de l'enseignant 33 Option Description --sortie_- maximum= 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.

Oto: Guide de l'enseignant 34 ....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 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 ()des cas de tests, qui seront vérifiés par comparaisons textuelles.

tester_methodes 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 () des cas de tests qui seront vérifiés à l‟aide de JUnit. tester_classe 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 () des cas de tests qui seront vérifiés à l‟aide de JUnit.

Oto: Guide de l'enseignant 35 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].

Oto: Guide de l'enseignant 36 ....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.

Oto: Guide de l'enseignant 37 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. * *

Oto: Guide de l'enseignant 38 ....7.2 Le module tester_junit Le module tester_junit permet d‟exécuter un test JUnit.

Les paramètres et résultats sont détaillés dans les tableaux suivants : Paramètre Mode Description classe obligatoire Nom de la classe qui implémente le test JUnit (sans l‟extension “.class”). racine facultatif Répertoire où doit se produire l‟exécution du test, si différent du 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.

Résultat Description nbtests Nombre de tests exécutés au total (en nombre de méthodes et non en nombre d‟assertions).

nberreurs Nombre d‟erreurs trouvées, au total (prévues et imprévues). nberreurs_prevues Nombre d‟erreurs trouvées grâce aux assertions. nberreurs_imprevues Nombre d‟erreurs trouvées à cause des exceptions non traitées. detail Sortie de la commande.

Oto: Guide de l'enseignant 39 ....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 ».

Oto: Guide de l'enseignant 40 Les paramètres et résultats sont détaillés dans les tableaux suivants : Paramètre Mode Description filtre obligatoire Commande Unix à exécuter pour lancer le programme filtre de l‟étudiant, par exemple: “java ClasseDuTp”, “a.out”. tests obligatoire Répertoire où se trouvent les cas de tests pour le filtre. Ce répertoire est relatif au répertoire du script Oto. Par défaut, les tests doivent se trouver dans le même répertoire que le script Oto. Il est aussi possible d‟indiquer un unique fichier de spécification de tests à la place du répertoire.

racine facultatif 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. debut_cas_test facultatif Caractère à utiliser pour indiquer le début d‟un cas de test. Plus précisément, il faut que ce caractère apparaisse trois (3) fois consécutives (ou plus) en début de ligne pour indiquer le début d‟un nouveau cas de test. Valeur par défaut ” .

separateur facultatif Caractère à utiliser pour séparer les données et les résultats d‟un cas de test. Plus précisément, il faut que ce caractère apparaisse trois (3) fois consécutives (ou plus) en début de ligne pour indiquer la séparation entre les données et les résultats du cas de test. Valeur par défaut ” . interactif facultatif Caractère à utiliser indiquer le mode interactif de spécifications des données et des résultats (mode entrelacé). Une ligne de données est alors représentée par une ligne débutant par ce caractère. Valeur par défaut ” .

avec_details facultatif Si présent, alors lorsqu‟un test échoue, les détails du test sont produits : données utilisées, résultats attendus, résultats obtenust.

La seule valeur possible est true. options_diff facultatif Options de diff à utiliser pour la comparaison des résultats. Un (unique) tiret “-” doit être spécifié pour l‟ensemble des options, par exemple “-ci”. Par défaut, la comparaison se fait de façon indulgente, i.e., les options utilisées si cet argument n‟est pas spécifié sont “-ctibw”.

Résultat Description nbtests Nombre de tests exécutés au total. nberreurs Nombre de tests qui ont échoué. detail Sortie de la commande.

Oto: Guide de l'enseignant 41 ....7.4 Les modules tester_methodes et tester_classe Ces modules de test de haut niveau permettent de tester respectivement des méthodes statiques (classe définissant une « bibliothèque » de méthodes) ou des méthodes d‟instance (classe définissant des objets simples) d‟une classe Java, et ce grâce à un unique fichier de spécification de tests. Ces tests sont exprimés plus simplement que des tests JUnit correspondants.

Ils ont aussi l‟avantage de tester, de façon indépendante des tests fonctionnels eux-mêmes, les signatures des méthodes afin d‟assurer que ces signatures sont conformes à ce qui est attendu.

Les entrées de ces modules sont les suivantes : Paramètre Mode Description programme obligatoire Classe Java à tester, par exemple: “TpJava1.java”. specifications obligatoire Fichier de spécification de tests à utiliser conjointement avec le programme. debut_cas_test facultatif Caractère à utiliser pour indiquer le début d‟un cas de test. Plus précisément, il faut que ce caractère apparaisse trois (3) fois consécutives (ou plus) en début de ligne pour indiquer le début d‟un nouveau cas de test. Valeur par défaut ” .

separateur facultatif Caractère à utiliser pour séparer les données et les résultats d‟un cas de test.

Plus précisément, il faut que ce caractère apparaisse trois (3) fois consécutives (ou plus) en début de ligne pour indiquer la séparation entre les données et les résultats du cas de test. Valeur par défaut ” . debut_instances facultatif Valide pour tester_classe seulement. Caractère à utiliser pour indiquer le début de la spécification des instances de test. Il faut que ce caractère apparaisse trois (3) fois consécutives (ou plus) en début de ligne pour indiquer le début d‟un nouveau cas de test. Valeur par défaut ” . Les sorties sont les mêmes que pour le module tester_junit, à savoir : Résultat Description nbtests Nombre de tests exécutés au total (en nombre de méthodes et non en nombre d‟assertions).

nberreurs Nombre d‟erreurs trouvées, au total (prévues et imprévues). nberreurs_prevues Nombre d‟erreurs trouvées grâce aux assertions. nberreurs_imprevues Nombre d‟erreurs trouvées à cause des exceptions non traitées. detail Sortie de la commande.

Oto: Guide de l'enseignant 42 ....7.5 Le module compiler_c Le module compiler_c permet de compiler un programme C. La tâche échoue si la compilation échoue, qu‟il s‟agisse d‟erreurs ou d‟avertissements. Les paramètres et résultats sont les suivants. Paramètre Mode Description fichiers obligatoire Liste des fichiers à compiler, séparés par des espaces.

On peut aussi utiliser le mot-clé :fichier. racine facultatif Répertoire où doit se produire la compilation, si différent du 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. Résultat Description stdout Sortie de la commande de compilation. Signalons que l‟utilisation de ce module n‟est recommandée que lorsqu‟un nombre (relativement) limité de fichiers doit être compilé. Dans le cas où plusieurs fichiers sont requis, l‟utilisation d‟un makefile est préférable. Signalons aussi que le nom de l‟exécutable peut être indiqué, si désiré, à l‟aide du paramètre options.

....7.6 Le module detecter_plagiat Le module detecter_plagiat permet de comparer entre eux des travaux remis avec Oto, et ce pour en calculer la similarité entre eux.

Si celle-ci s‟avère importante, il pourrait alors s‟agir de cas de plagiat. Le module retourne alors le nom des dossiers et fichiers concernés pour que l‟enseignant puisse les examiner plus attentivement. Dans sa version actuelle, le module permet de détecter les similarités entre fichiers et ce même si des modifications simples et «naïves» ont été effectuées, par exemple, changement de noms de variables, modification des indentation, etc. – l‟outil utilisé, sim, utilise un algorithme d‟alignement de séquences de lexèmes pour calculer la similarité (approximate string matching).

Paramètre Mode Description langage facultatif Langage de programmation des fichiers des répertoires comparés : Java, C, MPD, OCL/USE. Par défaut Java. fichiers facultatif Nom complet relatif de chacun des fichiers devant être contenus dans les répertoires à comparer, séparés par des virgules, ou „*‟ pour comparer tous les fichiers, par exemple „fichier1, fichier2‟. Utile pour valider l‟existence d‟une liste précise de fichiers dans les répertoires à comparer. Par défaut *.

Oto: Guide de l'enseignant 43 Paramètre Mode Description repertoireBase facultatif Chemin absolu du répertoire où sont contenus les répertoires devant être comparés au répertoire traité par la commande utilisant le module (verifier_tp ou corriger_groupe).

Ce paramètre permet à l‟enseignant de comparer des travaux d‟étudiants avec des travaux situés dans d‟autres répertoires pour, par exemple, comparer chacun des travaux d‟un groupe avec ceux d‟un autre groupe, (y compris des travaux de sessions précédentes). Par défaut le répertoire courant. discriminant facultatif Discriminant de ligne de commande Unix permettant de choisir les répertoires à comparer à partir du répertoire de base. Par défaut *.tp_oto.

exclure facultatif Liste de fichiers devant être exclus de la comparaison. Utile si la liste de fichiers du paramètre „fichiers‟ est *. Les fichiers mentionnés dans cette liste ne doivent pas forcément exister dans les répertoires comparés, aucune validation n‟étant faite à ce niveau. Ce paramètre peut être utile pour exclure de la comparaison un fichier remis par l‟enseignant et que l‟étudiant n‟aurait pas dû rendre avec son TP. Par défaut, aucun fichier n‟est exclu.

plancher facultatif Pourcentage minimal de similarité entre les fichiers pour que leur comparaison soit considérée comme un cas de plagiat potentiel.

Valeur comprise entre 0 et 100. Lorsqu‟une comparaison retourne une similarité supérieure ou égale à ce plancher, le cas est mentionné dans le rapport. Pour spécifier cette valeur pour l‟ensemble des fichiers, on indique „*=70‟, le pourcentage étant alors de 70%. On peut également la spécifier pour chaque fichier, sous la forme „fichier1=60,fichier2=55‟, en autant que les fichiers mentionnés soient déclarés au paramètre „fichiers‟. Par défaut, le plancher est de 60% pour tous les fichiers.

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.

Oto: Guide de l'enseignant 44 Résultat Description nbCasTrouves Nombre de répertoires contenant au moins un fichier semblable à l‟un de ceux du répertoire traité. rapport Liste des noms de fichiers et des répertoires de chacun des fichiers considérés comme suspects, avec le pourcentage de similarité.

Oto: Guide de l'enseignant 45 ....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é. Les paramètres et résultats sont détaillés dans les tableaux suivants : Paramètre Mode Description programme obligatoire Le nom du fichier fourni par l‟étudiant, par exemple: “TP1.pep”. tests obligatoire Répertoire où se trouvent les cas de tests. Ce répertoire est relatif au répertoire du script Oto. Par défaut, les tests sont dans le même répertoire que le script Oto.

racine facultatif 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. options_diff facultatif Options de diff à utiliser pour la comparaison des résultats. Un (unique) tiret “-” doit être spécifié pour l‟ensemble des options, par exemple “-ci”. Par défaut, la comparaison se fait de façon indulgente, i.e., les options utilisées si cet argument n‟est pas spécifié sont “-ctibw”.

Résultat Description nbtests Nombre de tests exécutés au total. nberreurs Nombre de tests qui ont échoué.

detail Sortie de la commande.

Oto: Guide de l'enseignant 46 ....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. Les paramètres et résultats sont détaillés dans les tableaux suivants : Paramètre Mode Description programme obligatoire Nom du programme de test à exécuter (extension “.hs”). 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.

Résultat Description erreursDeCompilation Nombre d‟erreurs de compilation – si non nul, alors les tests ne sont pas exécutés.

nbtests Nombre de tests exécutés (en nombre de méthodes et non en nombre d‟assertions). nberreurs Nombre d‟erreurs. detail Sortie de la commande.

Oto: Guide de l'enseignant 47 ....7.9 Le module produire_statistiques Le module produire_statistiques permet de produire certaines statistiques suite à la correction d‟un groupe de travaux. L‟appel du module retourne un String, qu‟on peut ensuite utiliser, par exemple, en l‟affichant sur la sortie standard. Un seul paramètre est requis: Paramètre Mode Description 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

Oto: Guide de l'enseignant 48 8 Les modules de rapports Oto Outre des modules de correction, Oto comporte aussi des modules qui permettent de produire des rapports de correction. Deux modules sont actuellement disponibles. ....8.1 Module produire_rapport_complet Ce module permet de produire un rapport complet qui comprend toutes les informations de chacun des rapports individuels, de même que les rapports de statistiques. Le résultat de l‟exécution est une chaîne de caractères comportement l‟ensemble des informations.

Les paramètres sont détaillés dans le tableau suivant : Paramètre Mode Description tri facultatif Permet d‟indiquer dans quel ordre les différents rapports individuels seront combinés dans le rapport complet.

Les valeurs possibles sont les suivantes : :deposeur, :equipe et :code_permanent. (Les deux dernières valeurs sont synonymes.) La valeur par défaut est :deposeur, i.e., ordonnés en fonction du nom d‟usager (LAMISS) de l‟étudiant ayant effectué le dépôt du travail.

avec_script facultatif Si présent, alors le script de correction est inclus dans le rapport. La seule valeur possible est true. rapports_ individuels facultatif Si présent, alors en plus du rapport collectif, un fichier indépendant est créé pour chaque travail. Ces divers fichiers sont mis dans le répertoire spécifié (chaine de caractères) par rapports_ individuels. Ce répertoire peut être spécifié de façon relative ou absolue. Une erreur est signalée si le répertoire n‟existe pas. ....8.2 Module envoyer_rapports_courriel Ce module permet d‟envoyer par courriel chacun des rapports individuels.

Son exécution a donc pour effet de transmettre un ensemble courriels, alors que la commande retourne simplement une chaîne de caractères qui informe de l‟envoi de ces courriels.

Note: Actuellement, cette instruction ne peut être utilisée que sur la machine oto.labunix.uqam.ca, puisque c‟est uniquement sur cette machine que l‟information appropriée (adresses de courriel) est disponible.

Oto: Guide de l'enseignant 49 Les paramètres sont détaillés dans le tableau suivant : Paramètre Mode Description sujet facultatif Le sujet (subject) qui sera indiqué pour le courriel. entete facultatif L‟entête (chaîne arbitraire de caractères, possiblement multilignes) qui sera indiqué au début du corps du message, avant le rapport de correction lui-même.

Vous pouvez aussi lire