Détail des différentes couches de l’architecture de CPI-FOAD

Cette architecture fonctionne sur l’idée de l’utilisation de services existants, et le choix du bon service au bon moment, parmi un ensemble d’applications disponibles et connues du système.

Les applications externes sont déclarées auprès de l’entité chargée de les gérer, et décrivent les fonctionnalités qu’elles peuvent assumer. Le système associe donc à chaque fonctionnalité la liste des fournisseurs existants. On déclare ainsi des fonctionnalités telles que : tableau blanc partagé, travail de groupe, partage de fichier, navigation synchronisée, sondage, et ainsi de suite.

Lors de la création d’un cours, le système recense les fonctionnalités nécessaires pour l’exécuter, et choisit en conséquence les applications tierces à solliciter, le but étant de solliciter le plus petit nombre d’applications possibles, tout en répondant à toutes les exigences du cours.

Au-delà de permettre l’harmonisation des applications existantes, et la sélection automatique de l’association d’applications la plus pertinente face à une situation donnée, ce système permet égale-ment de faire face aux pannes et aux aléas divers. En effet, dans le cas où une application sollicitée n’est pas disponible, le système est en mesure de faire appel à une autre application fournissant le même service.

Un exemple illustrant l’alternance entre deux applications tierces fournissant un tableau blanc est donné en III.2.

Nous présentons ici une description sommaire des modules composants cette architecture. Interface :

Interface spectateur Cette interface se destine aux acteurs non impliqués dans l’interaction, typiquement un évaluateur exterieur.

106 CHAPITRE II.2. ARCHITECTURE DE L’ENVIRONNEMENT

Interactivité :

Cahier Virtuel L’espace de travail privé des apprenants. Le cahier virtuel se base sur une com-binaison de services.

Tableau Blanc Le tableau principal de la salle virtuelle.

Écran Maitre L’écran de contrôle du formateur, ou apparaissent les alertes visuelles entre autres.

Classe Virtuelle Une visualisation synthètique de la salle virtuelle. Système Auteur Système de création et de scénarisation de cours.

Assistant L’assistant est un conseiller personnel des utilisateurs, basé sur les profils.

Réalisateur Le réalisateur gère les situations. Il utilise le scénario de cours comme référence et appelle les services et ressources nécessaires.

Gestionnaire de connaissances Gère les connaissances globales. Présentation :

Scène Virtuelle La scène virtuelle gère l’interprétation des évènements pour le moteur d’adap-tation.

Adapteur L’adapteur traduit les requêtes de services en fonction des protocoles utilisées par les applications externes.

Scénariste Le scénariste utilise les observations du système pour proposer des évolutions au graphe de situations.

Commentateur Le commentateur interprète et explique les évènements principaux pour un évaluateur externe.

Observation :

Scripte Le scripte gère la cohérence au sein des situations.

Observateur L’observateur capture les évènements et états du système.

Interpréteur L’interpréteur analyse les observations et traces générées par le système et les formalise.

Modèle :

Gestionnaire de rôles Les rôles déterminent principalement les droits des acteurs. Gestionnaire de profils Gère l’évolution des profils.

Bibliothèque de situations La bibliothèque de situations fournit au système auteur et au scé-nariste des situations en fonction du contexte.

Données :

Gestionnaire de Ressources Gère l’accès aux ressources logicielles et matérielles. Accès Données Gère l’accès aux bases de données.

3. VERSIONS PAR ASPECTS ET MODULES 107

Cette architecture fonctionnelle a été partiellement mise en place au cours du développement des prototypes (voir III.2). Cependant, son exploitation et la mise en place de différents services ont rapi-dement mis en avant ses limites.

Principalement, l’intégration d’applications externes avec des technologies de type iframe3 ou bien le langage Flash imposé par OpenMeetings ne nous permet pas de mettre en place le dialogue nécessaire à l’étude de l’état des utilisateurs ou de leur activité. En effet, ces applications restent des boites noires du point de vue de notre système. Cela empêche également la mise en place d’une continuité entre les sessions. L’un des points forts de l’application OpenMeetings est la persistance des salles virtuelles : lors de la reprise d’un cours suite à une interruption, les utilisateurs retrouveront le contenu du tableau blanc et les documents partagés dans la salle. Le partage de ces informations de persistance n’est pas possible entre les différents services externes.

De plus, l’évolution des différents composants n’est pas facilitée par cette architecture. Au cours du développement des prototypes, il nous a fallu notamment mettre en place plusieurs versions des composants de gestion de narration, ce qui engendre des effets de bords non négligeables dans le reste de l’application.

Enfin sur un plan technique, cette solution est liée à des technologies à l’avenir incertain, notam-ment le langage OpenLaszlo.

Nous proposons donc une seconde architecture basée sur la modularité et la conception par as-pects.

3 Versions par aspects et modules

Cette architecture veut répondre aux limitations de la proposition précédente en proposant : – Une indépendance des différents composants du système ainsi que du module métier – Une simplification de la mise à jour des composants

– Une garantie des possibilités d’observation et d’analyse de l’état et de l’activité des acteurs – Un mode de déploiement compatible avec des technologies actuelles et soutenues, ouvrant vers

de nouveaux supports

La philosophie de cette architecture est de rapprocher la vision composants de la vision fonction-nelle, notamment via l’utilisation de modules. L’architecture est centrée autour d’un cœur métier, dont la fonction est de gérer les modèles et d’assurer la communication entre les modules. Cette architec-ture est illustrée par la figure II.2.19.

108 CHAPITRE II.2. ARCHITECTURE DE L’ENVIRONNEMENT