Soutenance mémoire
TCAO : Concepts et classifications
Dans les années 80, l’utilisation de l’informatique pour gérer la coopération entre membres d’un groupe (travaillant ou pas en même temps, et ou non dans un même lieu) a constitué une révolution concernant le travail coopératif [Cosquer-99]. Cette révolution est à l’origine du domaine intitulé “Travail Coopératif Assisté par Ordinateur”, ou TCAO (de l’anglais Compurter Suported Cooperative Work, ou CSCW1). L’objet du TCAO est en substance d’adapter ces technologies aux besoins des utilisateurs impliqués dans des activités de groupe. Les systèmes informatiques, élaborés dans le cadre de la recherche en TCAO, permettant à des groupes d’utilisateurs de collaborer à des buts communs sont qualifiés en anglais de groupware. La traduction française couramment utilisée pour ce terme est “collecticiel” [Lévy-90]. En fait, la pluridisciplinarité du TCAO rend difficile la définition de ces systèmes. Une définition assez courante que nous devons à Ellis [Ellis-91] a été traduite par Karsenty [Karsenty-94] de la façon suivante : “Système informatique qui assiste un groupe de personnes engagées dans une tâche commune (ou but commun) et qui fournit une interface à un environnement partagé”. Collecticiel est également la traduction officielle adoptée par l’Association Française pour la Cybernétique Économique et Technique 1 (ASTI) [ASTI]. Mais très souvent, nous rencontrons également les termes “système collaboratif”, “système de TCAO” ou encore “application collaborative” pour désigner le groupware. Pour notre part, nous n’emploierons par la suite que les termes “collecticiel” ou “application collaborative” pour désigner ces systèmes informatiques. Le TCAO est un domaine multidisciplinaire qui concerne, entre autres, les systèmes répartis, l’interface homme-machine, l’automatisation du bureau, etc. Cette multidisciplinarité entraîne une grande diversité d’applications qui assistent des groupes d’individus à accomplir des tâches communes. Par conséquent, nous trouvons des divergences importantes parmi les concepts et classifications proposés dans la littérature au sujet des applications collaboratives.
La flexibilité, l’extensibilité et la malléabilité
Nous trouvons souvent deux autres propriétés associées à la flexibilité : (i) l’extensibilité, qui selon une définition générale, privilégie l’ajout de nouveaux comportements aux systèmes, soit par l’intégration de nouveaux modules ou composants, soit par l’extension des modules/composants existants dans l’application [terHofte-98] ; et (ii) le tailoring [Dourish-96], traduit en français par “malléabilité” [Bourguin-00], qui définit des notions d’adaptabilité et de flexibilité pour les utilisateurs finaux (ou à un responsable plus expérimenté, tel qu’un administrateur). Mørch [Mørch-97] distingue trois formes de malléabilité : le paramétrage, l’intégration et l’extension de l’application. Le paramétrage permet de sélectionner une ou plusieurs valeurs pour certains paramètres d’une application afin de la spécialiser. Quant à la distinction entre intégration et extension, Mørch insiste que l’extensibilité est associée à la possibilité d’étendre une application en modifiant des parties spécifiques de cette application, pour qu’elle puisse répondre à des besoins provenant de l’utilisateur ; l’intégration, quant à elle, se limite à l’ajout et à la composition de nouveaux modules ou composants à l’application. Nous avons décidé d’emprunter la notion d’extensibilité dans le sens plus général du terme (telle qu’elle est présentée dans [terHofte-98]). Ainsi, une application peut être également étendue par le biais de l’intégration de nouvelles fonctionnalités sous la forme de nouveaux composants, modules ou d’autres applications.
Développement s’appuyant sur des frameworks et des plates formes
De nombreux projets de recherche se fixent comme objectif de construire des frameworks ou des plates-formes pour le développement d’applications collaboratives. Il s’agit en général de solutions plus génériques que les boîtes à outils qui cherchent notamment à supporter des propriétés telles que la flexibilité et l’extensibilité. Les frameworks, couramment appelés en français “architectures cadre” ou “cadre d’application”, fournissent une structure réutilisable qui spécifie les fondements de l’application. Normalement, cette structure se présente sous la forme d’une architecture générique ou conceptuelle. Les frameworks peuvent également être associés à la notion de pattern (ou “patron”) qui décrivent des solutions reconnues pour une classe de problèmes (par exemple [Tarpin-Bernard-98]). Une plate-forme offre en général un support générique d’exécution et de développement de collecticiels en définissant une architecture et des briques logicielles implémentant des mécanismes de contrôle pour la collaboration. Certaines plates-formes sont développées en s’appuyant sur des frameworks (par exemple, [Barthelmess-05] et [Domingos-97]). Néanmoins, une distinction consensuelle entre frameworks et platesformes s’avère difficile, surtout quand nous trouvons le terme framework désignant des environnements fournissant un ensemble de bibliothèques ou briques logicielles pour permettre le développement d’applications (par exemple [.NET]). Nous allons ainsi employer ces termes selon les critères choisis par chaque auteur des travaux cités par la suite. Un framework ou une plate-forme peut être définie pour supporter la construction de nouvelles applications ou la transformation d’applications existantes en applications collaboratives. Dans cette dernière catégorie, nous avons par exemple la plate-forme XTV [Abdel-Wahab-91] et les frameworks Habanero [Jackson-99] et DISCIPLE [Li-99]. Ces systèmes permettent de partager entre plusieurs utilisateurs des applications originalement conçues pour un seul utilisateur. En particulier, Habanero et DISCIPLE offrent aux développeurs les outils nécessaires à la création de collecticiels implémentés en Java par l’intégration et le partage de différentes applications mono-utilisateur (l’intégration d’applications originalement collaboratives est également envisageable). Malgré cette flexibilité concernant la possibilité de combiner différentes applications dans un même environnement, il s’agit beaucoup plus d’une “cohabitation” que d’une réelle intégration, car il n’existe pas vraiment d’interactions entre ces applications. Dans la catégorie des frameworks et des plates-formes pour la construction de nouvelles applications collaboratives, une tendance actuelle des concepteurs de ces systèmes consiste à réaliser un développement modulaire en s’appuyant sur des composants. En effet, au cours de ces dernières années dans le domaine de l’ingénierie de systèmes, plusieurs travaux ont porté sur les approches orientées composants. Le développement à base de composants logiciels est devenu un facteur majeur pour rendre possible la composabilité, l’extensibilité et la malléabilité [Slagter-00]. Il existe plusieurs définitions du terme “composant logiciel”. En particulier la définition de Szyperski [Szyperski-02] est très souvent adoptée, notamment dans le domaine du TCAO. Szyperski définit un composant logiciel comme : “une unité de composition avec des interfaces contractuellement spécifiées et des dépendances explicites sur son contexte. Un composant logiciel peut être déployé indépendamment et il est sujet à des compositions par des tiers”. Différents auteurs considèrent que les collecticiels de demain seront davantage des assemblages de composants (par exemple [Farias-00b] et [Grundy-02]). Ils partent du principe que la plupart des fonctionnalités requises existeront déjà sous forme de composants développés par des tiers. En s’appuyant sur des assemblages de composants, les systèmes peuvent définir des environnements collaboratifs complètement intégrés. Ainsi, au contraire des boîtes à outils, un schéma d’interaction entre composants doit être défini afin de permettre l’intégration de différents composants dans une même plate-forme. TeamWave Workplace (TeamRooms à l’origine) [Roseman-97] par exemple propose une extension basée composants de GroupKit. Une architecture et un modèle de composant spécifique sont définis de manière simple afin d’encourager le développement de nouveaux composants par des tiers. Neem [Barthelmess-05] représente également une plate-forme définissant une infrastructure de composants réutilisables et extensibles. Mais dans les deux cas, la réutilisation des composants est limitée au système en question. Ainsi, le développeur est contraint d’utiliser les composants spécifiques au système. Afin de rendre possible l’intégration de composants développés sans avoir de système spécifique cible, la construction de collecticiels converge de plus en plus vers l’utilisation d’intergiciels (de l’anglais middleware [Geihs-01]) définissant des modèles généraux de composants). Des exemples répandus de modèles de composants sont CCM (CORBA Component Model [OMG-04]), EJB (Entreprise JavaBeans [EJB]) et .NET [.NET]. Ces modèles de composants offrent une séparation entre les fonctionnalités métier du composant et les fonctionnalités système (sécurité, répartition, cycle de vie, etc.). Cette séparation est réalisée suivant le paradigme composant/conteneur [Szyperski-02]. Ainsi, de nombreux systèmes pour le développement d’applications collaboratives ont été développés en s’appuyant sur ces modèles généraux de composants, notamment ceux définis par CORBA et JavaBeans [Slagter-00]. Nous avons par exemple les systèmes basés sur CORBA, tels que CoCoWare [Slagter-01], DARE [Bourguin-00] et la plate-forme décrite en [terHofte-96], et sur JavaBeans, tels que ACOST [Hummes-00], EVOLVE [Stiemerling-00], MAUI toolkit [Hill-04] et ANTS [Garcia-01]. L’intérêt de ces systèmes est ainsi d’assurer la propriété d’extensibilité par le biais de l’intégration de composants développés par des tiers 1 qui n’ont pas été a priori préconisés pour ces systèmes. La condition à respecter est que ces composants s’appuient sur le même modèle général de composants. Certains systèmes offrent des possibilités d’extensibilité encore plus élaborées permettant que de nouveaux composants soient intégrés aux collecticiels en temps d’exécution (par exemple [Hummes-00]). En outre, puisque les composants originellement disponibles dans ces systèmes (généralement des composants intégrant les mécanismes de base nécessaires à la coopération) ont été développés selon le modèle général de composant utilisé par le système, ils peuvent être réutilisés par des tiers, ou même intégrés dans un environnement de développement intégré (EDI 2 ) standard. Par exemple, les MAUI components (des composants offrant des fonctionnalités multi-utilisateurs fournis par MAUI toolkit1) peuvent être utilisés dans des EDIs Java tels que NetBeans [NetBeans] et JBuilder [JBuilder]. Ainsi, l’approche de développement s’appuyant sur des modèles généraux de composants définis par des intergiciels facilite l’intégration d’autres fonctionnalités coopératives sous la forme de composants logiciels. L’utilisation de telles technologies impose toutefois des contraintes vis-à-vis de l’environnement d’exécution. Autrement dit, cela reste difficile (voire impossible) d’intégrer aux collecticiels des composants, ou carrément d’autres applications collaboratives, qui n’ont pas été conçus en se reposant sur ces intergiciels. Même si les intergiciels viennent à l’aide du développeur en lui cachant plusieurs problèmes liés à la conception d’applications collaboratives, comme par exemple la distribution géographique des participants, ils deviennent de plus en plus complexes [Kordon-05]. Cette complexité est souvent liée au fait que les concepteurs des intergiciels cherchent à établir des systèmes répartis toujours plus sophistiqués [Colyer-03]. Cette tendance amène les développeurs à être confrontés au même ensemble de problèmes que les intergiciels étaient censés résoudre – les systèmes pour le développement de collecticiels, ainsi que les collecticiels développés, risquent de devenir trop complexes.
Les contraintes des CVEs conventionnels
Les CVEs constituent depuis quelques années un sujet de recherche en plein essor, et plusieurs technologies pour le développement d’environnements virtuels collaboratifs ont été décrites dans la littérature. Des systèmes comme COSMOS-2 [Darlagiannis-00], MASSIVE-3 [Greenhalgh-00] et NPSNET-V [Capps-00] proposent des cadres généraux et/ou des librairies applicatives pour faciliter le développement de mondes virtuels partagés en trois dimensions (3D). Ces différentes solutions traitent les problèmes importants spécifiques aux CVEs (propagation d’état, coordination, cohérence, etc.). Ces trois systèmes offrent des moyens pour étendre le CVE uniquement par le chargement dynamique de nouvelles entités 3D. Mais l’intégration d’autres fonctionnalités de collaboration/communication n’a pas été prévue (dans le cas de MASSIVE-3, des communications audio entre utilisateurs peuvent être supportées). Même si certains des systèmes décrits précédemment définissent leurs propres mécanismes d’extension, ils permettent uniquement d’intégrer des objets ou composantes 3D directement à l’intérieur du monde virtuel. Parmi les CVEs existants, seules quelques solutions proposent d’intégrer l’activité collaborative en cours au sein du monde virtuel avec d’autres applications. En particulier, quelques systèmes offrent des mécanismes d’interface avec le Web. En effet, étant donné que le Web devient aujourd’hui la plateforme de communication et de collaboration la plus importante, il est crucial d’aborder ce problème. Dans [Pekkola-00], par exemple, les auteurs proposent l’intégration de VIVA, qui est un CVE, à CRACK!, qui est un outil permettant à l’origine de rendre compte de la présence des autres utilisateurs visitant la même page WEB. L’idée consiste à associer à des pages Web des mondes virtuels. Un utilisateur visitant ces pages est ainsi au courant des autres utilisateurs visitant les mêmes pages ou de ceux qui sont connectés aux mondes virtuels associés. Celui qui est connecté à un monde virtuel peut également visualiser ceux qui naviguent sur le Web. Au delà de l’intégration avec le Web, VIVA intègre d’autres media permettant aux utilisateurs de communiquer entre eux dans d’autres contextes que celui de la réalité virtuelle, tels que l’audio, la vidéo et le chat. Un autre système qui supporte la collaboration au delà d’un monde virtuel est le CVE présenté dans [Frécon-98]. Ce CVE s’interface avec un éditeur de texte qui est associé à la représentation 3D d’un bloc-notes. Les utilisateurs peuvent sélectionner le bloc-notes pour lire ou éditer des textes. En plus de l’éditeur de texte, le monde virtuel dispose d’une métaphore d’un système de courrier électronique permettant aux utilisateurs de poster des documents encapsulés dans des enveloppes 3D à destination d’autres utilisateurs qui ne sont pas connectés à l’environnement. Blaxxun Platform [Blaxxun] définit un mécanisme de partage de documents intégré à un environnement virtuel. Ce mécanisme permet de présenter à l’intérieur du monde virtuel des documents de différents formats. Un outil de communication VoIP (Voice over IP) est également inclus pour permettre à des utilisateurs connectés de communiquer entre eux. Remarquons que, malgré le fait d’étendre des mondes virtuels en offrant d’autres moyens de collaboration (en dehors de celui de la réalité virtuelle), les systèmes présentés dans [Pekkola-00], [Frécon-98] et [Blaxxun] sont des systèmes figés et donc pas extensibles. De manière ad hoc, ces systèmes ont intégré des fonctionnalités de collaboration supplémentaires aux CVEs sans chercher à offrir des solutions générales d’intégration. L’environnement MOVE [García-02] semble constituer une solution plus générale pour intégrer des applications externes à un CVE. Il définit une infrastructure extensible (s’appuyant sur l’architecture ANTS) permettant à des développeurs de créer et d’insérer de nouveaux outils dans le système. Cependant, la limitation principale de cette approche est qu’elle ne permet que l’intégration d’applications conçues spécifiquement dans ce but. Comme nous l’avons souligné, le problème de l’intégration d’applications externes à des CVEs n’a pas jusqu’à maintenant été traité de manière satisfaisante, même si potentiellement cette intégration est très fortement souhaitable. Ainsi le développement de notre travail a été motivé au départ par la constatation du fossé existant entre la plupart des CVEs actuels et d’autres applications collaboratives. Partant de ce constat, nous avons eu comme but de définir un environnement qui soit le plus général possible pour l’intégration d’outils de collaboration externes à des CVEs, permettant ainsi d’enrichir des CVEs conventionnels.
E-learning
Le E-learning est le nom donné à l’utilisation des technologies de l’information et de la communication dans la formation initiale et/ou professionnelle. En bénéficiant des avantages des nouvelles technologies, on cherche à rendre plus efficaces les processus d’apprentissage et l’accès à la connaissance. Puisque les technologies de TCAO ont été conçues pour simplifier le partage d’information, favoriser la communication de groupe, améliorer la coordination des activités et motiver l’implication individuelle, le déploiement de ces technologies dans le E-learning permet de promouvoir un apprentissage coopératif 1 . Les étudiants communiquent en utilisant des formes d’interaction qui peuvent conduire à la stimulation de mécanismes d’apprentissage, tout en éliminant les inconvénients de la déshumanisation de la formation “à distance”. Ce raisonnement est un des principaux fondements des nouvelles théories pédagogiques telles que le constructivisme et la théorie de l’activité [Engeström-99] [Mwanza-01]. Le constructivisme représente l’approche selon laquelle le savoir est construit par chaque individu grâce à ses interactions avec un environnement social (i.e. d’autres individus et les objets). En complément, la théorie de l’activité propose que l’apprentissage des l’élèves se fasse à partir d’une activité conjointe réflexive qui est en constante construction (suite à différents phénomènes comme celui de la coopération). La “situation” n’est jamais donnée à l’avance, mais elle est le résultat d’interactions. Ainsi, l’impossibilité de réellement prédire les besoins nous incite à dépasser les limites d’une approche à priori des environnements collaboratifs et à adopter la conception de systèmes évolutifs permettant l’intégration dynamique de nouveaux outils de collaboration. Différentes applications collaboratives peuvent faire partie d’un tel environnement. Par exemple, les CVEs (Collaborative Virtual Environments) représentent une catégorie importante de systèmes collaboratifs pour le support au E-learning. La perception des activités dans les environnements scolaires ainsi que la reproduction des métaphores du monde réel, rendues possibles par la réalité virtuelle, peuvent être considérées comme des exigences pour l’apprentissage en groupe. Nous pouvons imaginer un scénario où un CVE est utilisé pour mettre en place un monde virtuel représentant le bâtiment d’une école, constitué : d’un hall d’entrée, de deux salles de cours virtuelles et d’une salle des enseignants. Trois types d’utilisateurs peuvent se connecter: “Professeur”, “Moniteur” et “Elève”. Un outil de messagerie instantanée est intégré au monde virtuel de façon à connecter tous les utilisateurs dont les avatars se trouvent dans le hall d’entrée. Les cours sont présentés à l’aide d’un outil de navigation Web coopérative comme CoLab et d’un outil d’audioconférence. Nous associons ainsi à chaque salle de cours une session CoLab et une autre session d’audioconférence. Pour suivre un cours, un élève doit quitter le hall d’entrée et entrer dans une des deux salles de cours, ce qui le connecte automatiquement aux outils de collaboration associés. La salle des enseignants sert à réaliser des réunions entre enseignants et moniteurs. Un tableau blanc partagé est employé en tant qu’outil de discussion et dès qu’un utilisateur (jouant un de ces deux rôles) entre dans la salle, il est connecté à la session de tableau blanc.
|
Table des matières
Chapitre I Introduction générale
I.1. Contexte général
I.2. Problématique abordée
I.3. Principales contributions de la thèse
I.4. Plan de thèse
Chapitre II État de l’art
II.1. Introduction
II.2. TCAO : Concepts et classifications
II.2.1. Quelques concepts fondamentaux
II.2.1.1. La coopération et la collaboration
II.2.1.2. La télé-présence
II.2.1.3. La session et les artéfacts de travail
II.2.2. Classification des applications collaboratives
II.2.2.1. La classification espace-temps
II.2.2.2. Les catégories fonctionnelles d’applications de TCAO
II.3. Développement de systèmes de TCAO
II.3.1. Quelques difficultés
II.3.1.1. La flexibilité, l’extensibilité et la malléabilité
II.3.2. Les approches de développement
II.3.2.1. Développement from scratch
II.3.2.2. Développement s’appuyant sur des boîtes à outils
II.3.2.3. Développement s’appuyant sur des frameworks et des plates-formes
II.4. Vers l’intégration d’applications collaboratives existantes
II.4.1. Motivations
II.4.2. Plates-formes et environnements généraux d’intégration
II.4.2.1. Les intergiciels conventionnels
a) CORBA
b) DCOM
c) Java RMI
II.4.2.2. Enterprise Application Integration
II.4.2.3. Les services Web
II.4.2.4. Bilan des solutions générales d’intégration
II.4.3. Plates-formes et environnements pour l’intégration d’applications collaboratives
II.4.4. Positionnement de notre proposition
Chapitre III L’Approche d’intégration initiale
III.1. Introduction
III.2. CIE : l’environnement d’intégration collaboratif
III.2.1. Les contraintes des CVEs conventionnels
III.2.2. Le cadre général d’intégration
III.2.3. L’architecture de base
III.3. Implémentation de l’environnement d’intégration collaboratif
III.3.1. Implémentation des modules de l’architecture
III.3.2. Le fichier d’initialisation
III.3.3. L’extensibilité de l’environnement
III.4. Conclusions
Chapitre IV L’environnement d’intégration : LEICA
IV.1. Introduction
IV.2. Approche générale d’intégration
IV.2.1. Scénarios d’intégration
IV.2.1.1. Outil de navigation coopérative enrichi d’un outil de messagerie instantanée (Chat)
IV.2.1.2. Réunions virtuelles
IV.2.1.3. E-learning
IV.2.2. Cadre général d’intégration
IV.3. Description d’une SuperSession
IV.3.1. Modèle de SuperSession
IV.3.1.1. Applications collaboratives
IV.3.1.2. Applications non collaboratives
IV.3.1.3. Rôles généraux
IV.3.1.4. Utilisateurs connectés
IV.3.1.5. Sessions spécifiques
IV.3.2. Illustration d’une SuperSession
IV.4. Création d’une SuperSession
IV.4.1. Configuration des informations de gestion
IV.4.1.1. GSMinfo
IV.4.1.2. IAinfo
IV.4.2. Spécification des politiques de collaboration
IV.4.2.1. Types de notification d’événement et de requêtes d’exécution d’action
IV.4.2.2. La définition des règles de collaboration : les policy widgets
IV.4.2.3. Exemples de règles
IV.4.2.4. Formalisation de la sémantique des règles politiques
IV.5. Conclusion
Chapitre V L’architecture de LEICA
V.1. Introduction
V.2. Architecture : de l’intégration des applications à l’exécution d’une SuperSession
V.2.1. Intégration d’une application collaborative à LEICA
V.2.1.1. Création dynamique d’un Wrapper
V.2.1.2. Couplage du Wrapper à l’application
V.2.1.3. Enregistrement d’une application
V.2.2. Configuration d’une SuperSession
V.2.2.1. Configuration du GSMinfo et découverte des applications intégrées à LEICA
V.2.2.2. Choix et configuration des applications collaboratives
V.2.2.3. Spécification de la politique de collaboration
V.2.3. Exécution d’une SuperSession
V.2.3.1. Démarrage d’une SuperSession
V.2.3.2. Connexion des utilisateurs à la SuperSession
LEICA: Un environnement faiblement couplé pour l’intégration d’applications collaboratives
V.2.3.3. Les notifications d’événement et l’exécution de la politique de collaboration
V.2.3.4. Gestion de l’état global d’une SuperSession
V.2.4. Les incohérences potentielles dues à la répartition
V.2.4.1. La gestion d’un état global cohérent et l’exécution repartie de la politique de collaboration
V.2.4.2. Les incohérences en présence de contraintes temporelles
V.2.4.3. Autres incohérences concernant l’exécution des règles politiques : la problématique des applications multiserveurs et P2P
V.3. Modélisation de LEICA en UML
V.3.1. Introduction à UML 2.0
V.3.2. Méthode de modélisation utilisée
V.3.3. Modélisation en UML de l’architecture de LEICA
V.3.3.1. L’analyse : les cas d’utilisation et les diagrammes de séquences de LEICA
V.3.3.2. La conception : les diagrammes de classes et de structures composites
V.3.3.3. Comparaison des scénarios engendrés par Tau G2 à ceux initialement proposés dans le cas des applications client/serveur
V.4. Conclusion
Chapitre VI Implémentation et déploiement de LEICA
VI.1. Introduction
VI.2. Les choix technologiques
VI.2.1. Les services Web
VI.2.2. Le paradigme publish/subscribe
VI.2.2.1. Pastry et Scribe
VI.3. Principaux modules du prototype
VI.3.1. APIFactory
VI.3.2. Server Wrapper
VI.3.2.1. La mise en place du système de notification d’événements
VI.3.2.2. Le PolicyManager et l’exécution de la politique de collaboration
VI.3.3. Session Configuration Service
VI.3.4. LClient
VI.4. L’intégration d’outils de collaboration et déploiement de LEICA
VI.4.1. CoLab
VI.4.2. Babylon Chat
VI.4.3. La SuperSession “CoLabPlusChat”
VI.4.4. L’environnement d’exécution
VI.4.5. Quelques considérations sur le prototype
a) L’intégration faiblement couplée
b) L’utilisation des technologies de services Web
c) Le système de notification d’événements
d) L’exécution de la politique de collaboration
VI.5. Conclusions
Chapitre VII Conclusion générale et perspectives
VII.1. Bilan des travaux réalisés
VII.2. Les perspectives de nos travaux
Télécharger le rapport complet
