La nature des diffŽrentes applications

Il faut distinguer les applications, dites finales, que nous venons de voir, qui sont directement utilisŽes par les acteurs du syst•me, des applications qui sont implicitement utilisŽes par ces der-niers.

3.2.1. Les applications dites ÒfinalesÓ.

Parmis ces applications, il faut distinguer celles qui sont destinŽes aux enseignants et celles qui sont destinŽes aux apprenants. Les premi•res peuvent •tre utilisŽes au sein dÕun navigateur, mais ce nÕest pas obligatoire, alors que les secondes le sont obligatoirement.

Ainsi le gestionnaire du mod•le du domaine, et le crŽateur de QCME ont la particularitŽ dÕ•tre ˆ la fois des applets et des programmes indŽpendants Java, permettant alors aux enseignants rŽ-guliers dÕŽviter le quelque fois fastidieux tŽlŽchargement de lÕapplet.

Par contre le gestionnaire de cours ainsi que lÕŽvaluateur de QCME ne sont disponibles que sous forme dÕapplet car ces applications doivent •tre constamment en liaison avec un navigateur

Web.

3.2.2. Les applications ÒcachŽesÓ.

Les applications qui sont implicitements utilisŽes par les utilisateurs sont celles qui ont pour ob-jectifs de dŽterminer le type dÕutilisateur courant et de construire les cours ˆ proprement parler. Dans le premier cas, lÕapplication est invoquŽe ˆ chaque connexion dÕun utilisateur, et dans le deuxi•me cas, elles (car il y en a plusieurs) sont invoquŽes soit par le gestionnaire de cours lors-que lÕapprenant dŽsire visualiser un cours particulier, soit par les liens hypertextes intrins•lors-ques aux cours que visualise lÕapprenant (liens de prŽrequis, ou liens ÒprŽcŽdentÓ et ÒsuivantÓ que nous avons vu prŽcŽdemment).

Ces applications, toujours Žcrites en Java sont des servlets. Elles sont pour lÕinstant aux nombres de quatre.

¥ La premi•re qui se nomme Login dŽtermine le type dÕutilisateur et crŽe la page dÕac-c•s aux fonctions du syst•me.

¥ La seconde qui se nomme CoursesMaker est en charge de produire le code HTML permettant dÕafficher les deux frames qui composent un cours, cÕest-ˆ-dire le cadre de gauche qui va contenir le plan du cours, et le cadre de droite qui va contenir le cours ˆ proprement parler (Cf. figure 73).

¥ La troisi•me nommŽe CoursesMap crŽe justement le code HTML permettant ˆ lÕap-prenant de visualiser le plan du cours.

¥ Enfin, la quatri•me, nommŽe CoursesContent, crŽe le code HTML permettant ˆ lÕapprenant de visualiser le cours ˆ proprement parler.

Ainsi si on reprend la figure 42, on peut remplacer les mots gŽnŽriques servlets et applets par le nom des applications, telle que le prŽsente la figure 74.

Figure 73 - Les applications qui construisent les cours.

Produit par CoursesMaker Produit par CoursesMap

Chapitre VII - Expérimentation.

4. Conclusion.

Nous venons dÕŽtudier les diffŽrents outils mis ˆ disposition des enseignants et des apprenants, ainsi quÕun petit exemple de production de cours adaptŽ aux caractŽristiques de lÕapprenant. Cet exemple, qui nous en sommes conscients ne peut valider compl•tement les qualitŽs de notre syst•me, nous a tout de m•me permis de faire quelques constations.

Commen•ons tout dÕabord par les points positifs, cÕest-ˆ-dire principalement la validation de la modŽlisation et de lÕarchitecture logicielle que nous avons dŽcidŽe dÕadopter. En effet, ˆ notre connaissance, il nÕexiste aucun serveur dÕobjets distribuŽs qui distribue rŽellement les objets comme nous le faisons. Dans notre syst•me, les clients de ce serveur (dans notre cas les servlets et les applets) utilisent des objets distribuŽs comme ils les utiliseraient en local. Si un client ˆ besoin ˆ un instant t dÕun objet distant, il lÕinstancie naturellement. Cela permet donc de conce-voir des programmes clients de mani•re transparente, ce qui facilite grandement leur modŽlisa-tion et surtout leur implŽmentamodŽlisa-tion. Cette facilitŽ permettra dÕimplŽmenter rapidement les quelques applications qui manquent encore, cÕest-ˆ-dire un outil dÕadministration (pour crŽer et supprimer les comptes utilisateur) ainsi quÕun outil de gestion de canevas (qui sera certainement intŽgrŽ dans lÕapplication de gestion du mod•le du domaine).

Revers de la mŽdaille, le serveur dÕobjets peut •tre amenŽ, si le nombre de clients qui lÕutilisent augmente, ˆ crŽer ŽnormŽment dÕobjets distribuŽs. A priori on ne sait pas trop comment ce der-nier va se comporter si plusieurs dizaines voire centaines de clients se connectent en m•me temps. Durant nos tests, nous avons pu constater, quÕen moyenne, nos programmes avaient constamment environ une cinquantaine dÕobjets actifs. Or auparavant, nous avions validŽ la charge du serveur HORB (nous avions crŽŽ jusquÕˆ trois milles objets ÒsimplesÓ). On peut donc raisonnablement penser que notre syst•me devrait convenablement se comporter pour au moins une vingtaine dÕutilisateurs connectŽes au m•me moment.

Ensuite, cette expŽrimentation a confirmer une intuition que nous avions eu d•s le dŽbut, cÕest-ˆ-dire lÕimportance du nombre de briques diffŽrentes pour pouvoir prŽtendre avoir un syst•me qui sÕadapte rŽellement ˆ lÕutilisateur: une dizaine de briques par notion ou cours et par type

co-Figure 74 - Architecture logicielle de METADYNE: Qui fait quoi ?

SERVEUR HTTP CLIENT METADYNE NAVIGATEUR WEB SERVEUR METADYNE MATISSE SERVEUR DÕOBJETS DISTRIBUES HORB Login CoursesMaker ^CoursesMap CoursesContent Gestionnaire de cours Evaluateur de QCME Gestionnaire du mod•le du domaine CrŽateur de QCME

gnitif semble •tre un minimum. Or la production de brique ŽlŽmentaire nÕest pas des plus trivia-le, et cožte ŽnormŽment cher en temps et/ou en argent. DÕo• lÕintŽr•t et lÕimportance de serveurs tels que le serveur SEMUSDI que nous avons dŽjˆ vu, et dont nous allons Žtudier lÕarchitecture en annexe.

Bilan.