Prototype

La figure 3.4 montre l’aspect du prototype sur le poste instructeur, lorsque deux élèves sont présents. L’instructeur se sert de deux écrans sur la même station de travail, car l’ensemble des outils et des interfaces gestionnaires de la session (lanceur des applications) ne contiennent pas sur un seul écran. Pour les élèves, un seul écran suffit car la quantité d’information affichée par leurs interfaces gestionnaires a été réduite.

Vidéo locale Vidéos distantes Lanceur des applications Tableau blanc Tableau électronique partagé Application locale multimédia

Figure 3.4. Prototype TOPASE

La visualisation de tous les membres de la classe se fait au travers d’une visioconférence synchronisée appelée N-TSVS (N-Timestamp Synchronized Videoconference System), et développée dans le cadre de la thèse de P. Owezarski [VILL98], [OWEZ98]. Les modules de N-TSVS, un par participant, définissent, gèrent, et synchronisent les différents médias audio et vidéo transmis et reçus, en garantissant leur validité temporelle au niveau du groupe. Au niveau interface, les fenêtres vidéo affichent les images reçues des autres participants. Toute fenêtre vidéo entourée par un cadre rouge indique que son participant émet de l’audio. Ce signal visuel, très utile pour faciliter le suivi des conversations, permet aussi de faciliter la résolution des collisions audio, lorsque plusieurs participants parlent en même temps.

Le tableau électronique partagé, développé par V. Baudin, permet de visualiser et de piloter à distance des applications mises sous son contrôle. L’interface de chaque membre se compose d’une fenêtre vidéo. Un membre sélectionné place ses applications à partager dans la zone de son tableau électronique. Tout autre membre autorisé peut alors contrôler à distance les applications partagées. Le tableau supporte aussi un mécanisme d’annotation.

Le tableau blanc, développé par V. Baudin, permet à un membre sélectionné de diffuser des transparents au format GIF ou JPEG. Son interface utilisateur se compose d’une fenêtre graphique. Le tableau blanc supporte des annotations publiques faites par un membre sélectionné et autorise des annotations privées.

La fenêtre du lanceur des applications, développé par V. Baudin, affiche l’état courant de l’ensemble de la session. De façon plus précise, il montre l’état de l’ensemble des applications collecticiel utilisées et indique quelle est la configuration courante du groupe. Il participe à la mise en place de la fonctionnalité de conscience de groupe et facilite à l’instructeur le suivi du travail de groupe.

Au niveau technologique, l’ensemble des outils collecticiels et le lanceur des applications ont été réalisés en C, selon une architecture «multithreadee», où chaque thread a en charge une opération élémentaire sur un seul flux de donnée identifié. La synchronisation des

données utilise une technique à base d’estampilles temporelles. Les formats audio et vidéo manipulés sont propriétaires (car les développements ont été faits entre 1996 et 1998). Les échanges de données se font au-dessus d’IP multicast.

Le support matériel du prototype consiste en un ensemble de stations de travail SUN SOLARIS 2.5, équipées de cartes vidéo Parallax, et connectées au travers de deux réseaux Ethernet et ATM. Nos tests de l’environnement se sont déroulés en utilisant IP au-dessus d’Ethernet et d’ATM. Bien entendu, la bande passante d’Ethernet, de 10 Mb/s à l’époque, est rapidement atteinte avec seulement trois participants : ATM supporte plus d’utilisateurs.

L’ensemble des outils précédents (N-TSVS, tableau électronique partagé, tableau blanc) sont sous le contrôle du lanceur des applications, lui même connecté par l’intermédiaire du module Protocole de Coopération, au service de gestion de session. De ce fait, l’ensemble des flux de données manipulés au travers de ces outils, respectent et suivent la structure courante de la session, en accord avec la structure du diagramme de coordination qui modélise la session. De façon plus précise, le nombre d’affichages vidéo fait par le module N-TSVS de chaque utilisateur est en conformité avec la phase de la session et la position de chaque utilisateur. Par exemple, en phase de briefing, un utilisateur élève ne voit que l’image de son professeur, alors que ce dernier voit tous les élèves. En phase de question durant le briefing, la vidéo de l’élève qui pose une question apparaît automatiquement chez tous les élèves. De la même façon, les flux audio de N-TSVS respectent la structure de la session : par exemple, en phase de briefing, N-TSVS n’autorise que l’audio venant du professeur. En phase de debriefing, tout le monde peut discuter. Les outils tableau électronique partagé et tableau blanc ont un comportement similaire. En phase de briefing, seul le professeur peut partager ses applications et diffuser ses supports. En phase de debriefing, plus informelle, chaque membre peut diffuser et partager ses documents.

Ces comportements dynamiques et adaptables en session ont été autorisés grâce à la conception d’outils collecticiels ouverts et configurables au travers d’APIs, APIs que nous avons connectées au lanceur des applications. Le lanceur a ensuite eu pour charge de traduire les configurations de session, génériques et définies sous forme de graphes, en appels de méthodes spécifiques, pour chaque API d’outil.

3.4 Bilan

L’implantation en Estelle + C du service et du protocole V1 de gestion de session s’est révélée possible, sans grande difficulté, une fois la spécification mise au point et simulée. Le service et le protocole se sont avérés robustes vis-à-vis de déconnexions brutales des utilisateurs, avec reconfiguration automatique en mode dégradé de la session courante, et vis-à-vis de la prise en compte des outils.

Cette première contribution illustre l’utilisation de techniques de descriptions formelles et de leur apport pour faciliter la réalisation, et surtout l’implantation complète de services et de protocoles multi utilisateurs complexes.

Le premier gain s’exprime en terme de facilité de description. Il est beaucoup plus facile de décrire des comportements sous forme d’automates communicants que directement dans un langage.

Le deuxième gain (mis en œuvre dans ma thèse) est sur la qualité des comportements décrits lors de la conception et sur la confiance mise dans leur codage, comportements qui sont simulés et validés formellement, ceci pour en détecter les erreurs. Ces approches de

simulation et de validation aident grandement à détecter les erreurs, toujours difficiles à provoquer, à déterminer, à analyser et à reproduire dans les systèmes distribués.

Le dernier gain que nous avons illustré ici est l’énorme gain en temps de réalisation pour l’implantation du protocole. Aucune erreur supplémentaire n’est introduite car on ne procède à aucun recodage manuel des comportements. L’utilisation de moteurs d’implantation pré codés sous forme de librairies logicielles facilite l’activation automatique des comportements simulés et évite de perdre du temps à recoder leurs fonctionnalités. On effectue ainsi une retouche minimum du code, retouche toujours éventuellement source d’introduction de nouvelle erreur.

Une remarque tempère ces bénéfices : L’approche compilée utilisée par l’environnement de programmation et nécessaire pour lier Estelle avec C, introduit des difficultés d’interfaçage. Certaines variables doivent être mises en commun, il est nécessaire de mélanger des instructions C et Estelle. Ces difficultés proviennent du fait que deux langages différents sont utilisés pour l’implantation finale. Nous pensons que ces problèmes pourraient être levés par l’orientation suivante : utiliser une approche librairie de macro instructions pour la technique formelle initiale sur un langage unique.