Rapport final du stage de Julien SIGNOLLES - limsi

RAPPORT DE STAGE |Nom de l'étudiant(e) |Signoles |
|Prénom de l'étudiant(e) |Julien |
|Niveau d'étude |Maîtrise (bac +4) |
|Titre du stage |Interaction Multimodale et Agents |
| |pour l'Enseignement Assisté par |
| |Ordinateur |
|Période |décembre 2000 - mai 2001 |
|Directeur de stage |Jean-Claude MARTIN |
| |(martin@limsi.fr) |
|Lieu du stage |LIMSI-CNRS |
|Projet |AMICAL |
| |Agents and Multimodal Interaction |
| |for Computer Aided Learning |
|Version du rapport |1.1 |
|Date du rapport |mercredi 23 mai 2001 |
Table des matières Introduction 3 Modélisation orientée objet 3 Notes concernant l'implémentation du modèle objet 3 Introduction 3 Modèle générique dynamique du cours 5
Présentation des éléments de base 5
Combinaisons dynamiques d'éléments de base 8
Schéma global des classes et interfaces du modèle dynamique 11 Classes interagissant avec le modèle dynamique 12 Modèle générique interactif du cours 13
Relation modèle dynamique - modèle interactif 13 Correspondance partie dynamique - partie interactive 14 Représentation graphique des éléments du cours 15 Vue et contrôleur AWT pour les composants du cours 16
Encapsulation des données 16
Relation modèle - vue 17 Développement Java 18 Intégration avec la partie multimodale 18
L'applet java de base 18
Choix de la grammaire vocale 18
Un exemple du programme 21 Perspectives 22 Bibliographie 24 Sites web 25 Annexe A : Etude de l'existant 26 Annexe B : Test d'Argo / UML 36 Annexe C : Premier exemple d'application 38 Annexe D : Le cours pris pour exemple 46 Annexe E : Complémentarité entre le médiateur VDL et le modèle objet 51 Annexe F : Compte-rendus des réunions sur AMICAL 52 Annexe G : Planning 59
Introduction Le but de ce stage est de mettre en ligne, sur une page web, un cours
permettant une interaction multimodale avec des étudiants.
Le stage consiste à effectuer une modélisation du cours et à en créer
une représentation graphique afin de pouvoir l'intégrer dans un système
multimodal. Une démo, sous forme d'applet java, doit, de plus, être
réalisée afin de tester la convivialité de l'application ainsi créée en
situation réelle. Modélisation orientée objet
Notes concernant l'implémentation du modèle objet
L'implémentation java ne correspond pas parfaitement au modèle
objet. Certains éléments du modèle n'ont pas été implémentés (comme cela a
d'ailleurs été déjà signalé) alors que de nouvelles méthodes ont pu être
introduites pour les besoins de l'implémentation. D'autres éléments ont pu
également être renommés pour une meilleure clarté et une meilleure
cohérence avec le reste de l'application. Cependant, la documentation html
fournie avec le code source permet d'identifier facilement les
modifications par rapport au modèle initial. Introduction
Le modèle proposé se décline en composantes Modèle-Vue-Contrôleur
(MVC) permettant de mieux séparer les parties applications et interface
graphique. La partie modèle comporte
. des éléments indépendants de l'interaction avec un étudiant
. des éléments complétant les éléments précédents par des
informations liés aux étudiants (réponses aux exercices, temps
passé...)
La partie Vue gérera la manière dont le modèle sera représenté à
l'écran. Il semble important de noter que certains éléments du modèle ne
seront pas forcément visibles à l'utilisateur (justifications pédagogiques,
compléments d'information ...).
La partie Contrôleur servira à générer la vue en fonction des données
stockées dans le modèle, et à modifier la partie dynamique du modèle en
fonction des interactions de l'étudiant sur la vue.
Ces parties se retrouvent dans la structure de "packages" (cf.
figure1). Figure 1 - package diagram [pic] Modèle générique dynamique du cours
Ce modèle est contenu dans le package java
course.model.generic.dynamic Tous les objets génériques d'un cours ne peuvent plus être modifiés
une fois créés. Ils correspondent aux éléments du cours tels qu'ils
pourraient être stockés dans une base de données. C'est la raison pour
laquelle, il n'existe, dans chaque classe, que des méthodes d'accès aux
données (get) et aucune méthode de modification (set). Le but de ce projet est de générer dynamiquement un cours en fonction
des interactions de l'utilisateur et de ses caractéristiques (son niveau,
sa filière...). Nous avons donc identifié les relations possibles entre les
éléments du cours :
- isALogicalPartOf : indique quelles sections sont inclues dans
un ensemble de sections. Par exemple, un exercice sur les boutons radios
devra être inclus de manière logique dans un chapitre sur les interfaces
graphiques et n'aurait pas sa place dans un chapitre sur les boucles for et
while. (cf. paragraphe sur la classe SectionSet)
- require : indique les éléments indispensables pour pouvoir
accéder à un autre (cf. paragraphe sur la classe Element).
- giveAccessTo : indique les éléments auxquels un autre élément
autorise l'accès. Cette relation est la relation réciproque de "require".
Si x require y alors y giveAcessTo x.
Nous avons distingué, dans notre modèle, des éléments de base et des
ensembles de sections dont l'organisation peut être établie dynamiquement. Présentation des éléments de base
. DynamicTextElement [pic] Un texte (Text) est composé de différentes phrases (sentences). Chaque
phrase est de type String. De plus, un texte possède un style qui dépend de
son type (texte standard, titre, introduction ou conclusion).
. DynamicArrayElement [pic] Une section de ce type permet d'agrémenter le cours de tableau (à deux
dimensions). Dans cette version, cette classe n'a pas été écrite. . DynamicStoredElement [pic] Ce type d'élément représente les éléments nécessitant le chargement
d'un fichier informatique (caractérisé par son nom filename) créé
indépendamment de l'application.
. DynamicGraphicElement (extends DynamicStoredElement) [pic] Une image (gif ou jpeg) possédant une certaine taille caractérisée par
sa hauteur (height) et sa largeur (width). Ce type permet d'illustrer le
cours de schémas ou de captures d'écran, par exemple. . DynamicAnimatedExemple (extends DynamicStoredElement) [pic] Les exemples animés (AnimatedExemple) permettent d'illustrer le cours
à l'aide de démonstrations visualisables par l'utilisateur. Ces exemples
sont basés sur des applets java (fichier .class) fournies à l'application.
Dans cette version, cette classe n'a pas été écrite.
. DynamicExercice
[pic]
Un exercice n'est qu'une interface. La seule caractéristique commune à
tous les exercices est de posséder un nombre de points (calculer
différemment selon les types d'exercice).
. DynamicAloneExercice (extends DynamicElement implements
DynamicExercice)
[pic]
Un exercice solitaire est un élément de base du cours ayant la
particularité d'être un exercice.
. DynamicMultipleChoicesQuestion (extends DynamicAloneExercice)
[pic]
Une question à choix multiples (MultipleChoicesQuestion) est un
exercice où l'utilisateur peut choisir plusieurs bonnes réponses
(goodResponses) à une question (question) parmi un ensemble de réponses
proposées (suggestedResponses). . DynamicLacunarExercice (extends DynamicAloneExercice)
[pic]
Un exercice lacunaire propose des phrases à trous à l'utilisateur que
ce dernier se doit de compléter.
Les différents morceaux de phrases séparés par des blancs sont
indiqués dans sentences. Les réponses à mettre dans les blancs sont
indiquées dans goodResponses. Chaque phrase est de type String. Chaque
réponse est un vecteur de String permettant d'indiquer plusieurs réponses
possibles (des synonymes par exemple) à mettre dans chaque blanc.
La présentation de l'exercice se fait dans l'ordre suivant :
- sentences[0]
- champ de texte de goodResponses[0]
- sentences[1]
...
- champ de texte de goodResponses[n-1]
- sentences[n]
. DynamicMatchingExercice (extends DynamicAloneExercice)
[pic] Un exercice assorti propose des mots (words) et leurs définitions
(definitions) à l'utilisateur. Chaque mot et chaque définition sont de type
String. L'utilisateur doit retrouver la défini