Architecture globale basée sur les différents aspects du système

Les différents modules sont inscrits auprès du module métier, sous forme de contrats décrivant les fonctionnalités offertes, à la manière du gestionnaire de services décrit dans l’architecture par couches. Un adaptateur permet de communiquer selon diverses modalités : sockets, services web, JavaRPC...

3.1 Description des aspects

L’architecture du cœur métier se base sur la programmation orientée aspects. Cette méthode per-met de séparer chaque préoccupation métier de l’environnement dans un aspect indépendant, et de séparer également les préoccupations métiers des aspects techniques.

3.1.1 Aspects métiers

Les aspects métiers correspondent aux responsabilités du domaine d’application.

Aspect métier principal - Cycle de fonctionnement : L’aspect principal assure le cycle global de l’environnement.

Modèles : Gestion des modèles des éléments de narration. Cet aspect construit les modèles à partir de fichiers de configuration. Il gère notamment la liste des événements observables, la constitution des mots d’état, les types de situations... Il est garant des spécificités de chaque instance de l’environnement.

Traces : Cet aspect reçoit l’ensemble des informations d’exécution à partir du portail Web, et les redistribue vers les aspects concernés.

3.1.2 Aspects techniques

Les aspects techniques permettent le fonctionnement de l’application. Ils sont totalement décor-rellés du domaine d’application.

Authentification : Authentification dans l’environnement. Session : Gestion des sessions utilisateurs.

3. VERSIONS PAR ASPECTS ET MODULES 109

Persistance : Sauvegarde des données.

Synchronisation : Synchronisation entre les modules. Services : Gestion des accès aux services externes. Ressources : Accès aux documents, sites web, matériel...

3.2 Évolution de l’interface

La définition de cette nouvelle architecture accompagne le besoin de reprendre intégralement l’interface de l’environnement, héritée du projet CPI-FOAD et de l’application OpenMeetings. L’uti-lisation de cette interface implique en effet la gestion de technologies telles que Flash, que nous souhaitons abandonner pour des raisons de performance et d’accessibilité.

Cela nous permet de concentrer la communication entre l’interface et le système en un seul flux de données, et d’obtenir ainsi un meilleur contrôle notamment sur le contenu des outils de l’interface tels que le tableau blanc.

3.3 Présentation des modules

Le découpage des fonctionnalités et responsabilités de l’environnement en modules facilite la maintenance et l’évolution du système. Les modules peuvent ainsi évoluer sans affecter le reste de l’environnement. La seule contrainte que nous imposons est la mise en place d’une façade ou bien la description formelle de l’interface du module dans un format exploitable par un adaptateur.

Afin d’améliorer l’interopérabilité de l’environnement, nous travaillons à la mise en place d’une évolution du système de gestion des services proposés dans l’architecture par couches. Ce système utilise une ontologie commune pour décrire les services attendus par l’environnement, et chaque mo-dule propose un contrat décrivant son interface et le mode d’emploi associé à chaque service. Un état de l’art lié à cette proposition est en cours.

La partie III décrit la mise en place de cette architecture dans notre prototype et l’intégration de différents modules, en particulier l’architecture du module de narration.

C

HAPITRE

II.3

Gestion du distantiel

« N’acceptons aucune entrave à la liberté de créer, d’imaginer, d’apprendre, d’explorer ! » Maurice Bonnet.

Sommaire

1 Vue synthétique de la salle virtuelle . . . 112 2 Espaces collaboratifs . . . 113 2.1 Travaux de groupes . . . 113 2.2 Autorégulation de la salle . . . 113 3 Le Commentateur . . . 114 3.1 Contexte . . . 114 3.2 Propositions . . . 114 3.3 Interface graphique pour le commentateur . . . 114 4 Prise de notes . . . 115 5 Intégration d’aspects sociaux : le voisinage . . . 115 6 Gamification . . . 116 6.1 Badges « compétitifs » . . . 117 6.2 Badges « honorifiques » . . . 118

C

Echapitre présente les modalités et les outils associés que nous proposons pour gérer les interac-tions à distance et réduire la distance transactionnelle dans notre environnement.

Il est important de préciser à nouveau le contexte d’utilisation que nous envisageons pour notre environnement. Il s’agit de gérer des sessions de formations synchrones prenant la forme de salles virtuelles. Ces sessions peuvent être mises en place dans différents contextes : enrichissement d’une session de formation présentielle classique grâce aux fonctionnalités multimédia notamment, mise en place d’une session de formation pour des acteurs géographiquement dispersés, ou bien réunion d’utilisateurs en partie dispersés.

Les apprenants utilisent un ordinateur classique disposant d’une connexion à Internet, et idéa-lement d’une webcam et d’un micro. Ils peuvent égaidéa-lement disposer d’une interface tactile sur leur machine ou bien utiliser une tablette connectée. Le formateur peut envisager plusieurs modalités d’utilisation. Une machine personnelle connectée est suffisante, tenant compte que la présence d’une webcam et d’un micro est fortement recommandée pour le formateur. Il peut également envisager l’utilisation d’un vidéo-projecteur diffusant son interface, et filmer l’ensemble à destination des apprenants. Une troisième possibilité, celle que nous mettons en place pour les tests et démonstrations de notre environnement, consiste à utiliser un TBI comme support de projection. Cela permet au formateur d’interagir directement sur celui-ci, évitant ainsi les aller-retours vers un clavier/souris à proximité. Cela lui permet également de disposer sur un second écran de différents outils de contrôle et de gestion de la salle, parmi ceux que nous proposons ici par exemple.

112 CHAPITRE II.3. GESTION DU DISTANTIEL

Dans ce chapitre, nous discutons dans un premier temps des interactions concernant la phase synchrone « pendant », puis des modalités ayant une portée plus grande que les sessions de cours.

1 Vue synthétique de la salle virtuelle

La principale source d’information d’un formateur dans une salle de classe à propos de l’état ou du niveau d’attention des apprenants est le regard. Nous proposons donc d’offrir au formateur une visualisation claire et simple de l’ensemble des participants à une session, qui lui permette d’identifier rapidement l’état et l’activité de ces derniers.

Cette proposition se base sur une extension de la « liste des utilisateurs » existant dans pratique-ment n’importe quel environnepratique-ment de visioconférence ou de FOAD. Elle se place égalepratique-ment comme une alternative aux miniatures affichant le flux vidéo des participants, qui peuvent alourdir l’inter-face sans forcément apporter d’information supplémentaire, et entraîner également une surcharge du réseau, comme l’illustre la figure II.3.1 : la liste des utilisateurs et la zone d’affichage des minia-tures occupent une part considérable de l’affichage du formateur, et la multiplication des flux vidéos entraine un ralentissement dans la transmission des données.

Dans le document Architecture pour le contrôle des interactions et le pilotage d’une application interactive multi-utilisateurs à exécution adaptative : application à un environnement de FOAD (Page 131-135)