SETIT 2007 4 th International Conference: Sciences of Electronic, Technologies of Information and Telecommunications March 25-29, 2007 TUNISIA Continuum de Collaboration Augmentée dans un nouveau modèle de TCAO Nabil ELMARZOUQI, Eric GARCIA et Jean-Christophe LAPAYRE LIFC - Laboratoire d Informatique de Franche-Comté 16, Route de Gray, 25030 Besançon Cedex, France [elmarzouqi,garcia,lapayre]@lifc.univ-fcomte.fr Abstract: Avec l'avènement du travail distribué collaboratif, il est nécessaire d'étudier et d'adapter les modèles "classiques" de ces nouvelles plateformes. Différents modèles de conception et d'architecture ont été mis en place mais l'efficacité d'une plateforme collaborative réside dans la capacité qu'elle aura à rendre le travail réellement collaboratif c'est-à-dire à placer les acteurs dans une situation la plus proche possible d'une salle d'examen virtuelle : on parle de prise de conscience des humains coopérants ou awareness. Nous proposons le Continuum de Collaboration comme étant une continuité de l'espace de travail collaboratif qui se décline en trois niveaux allant de la coordination à la collaboration en passant par la coopération. Cette continuité est augmentée par un "Trèfle" qui regroupe plusieurs espaces qui déterminent les dimensions fonctionnelles du travail collaboratif. Ce nouveau modèle a été appliqué dans le projet Européen nommé TeNeCi (Télé-neurologie coopérative). Key words: Collecticiel, Travail Collaboratif, Plateforme Distribuée, Interface Homme/Machine, Interactions, Prise de conscience (Awareness). INTRODUCTION Depuis les années 2000, le travail collaboratif distribué a pris son essor. Les plateformes dédiées à ce type de travail doivent fournir non seulement le support permettant les échanges, mais aussi les outils qui rendront ce travail réellement collaboratif : outils de partage, et surtout outils de prise de conscience du groupe (Awareness). Ces nouvelles plateformes sont en charge non seulement des aspects Machine/Machine, mais aussi Homme/Machine pour finalement favoriser les échanges Homme/Homme. Le but de ce papier est de présenter un nouveau modèle dit de collaboration augmentée. Pour cela, nous présentons tout d'abord les modèles de conception de ces architectures pour la collaboration. La section deux expose les interfaces Homme/Machine distribuées qui peuvent être représentées par le désormais bien connu modèle du trèfle auxquels nous contribuons en ajoutant la dimension régulation. Dans la troisième section, nous définissons notre nouvelle architecture "Modèle Continuum de Collaboration Augmentée - ACCM". Enfin la dernière partie expose l'application de notre modèle dans le projet Européen TeNeCi. 1. Modèles de conception des architectures et interactions pour les environnements collaboratifs Afin de montrer le rôle important des interactions homme/machine dans un environnement collaboratif, nous avons mené une étude sur deux échelles, en débutant par une analyse portant sur les modèles conceptuels pour les interfaces homme/machine puis sur les modèles d'architectures plus évolués. Les modèles de conceptions étudiés : Model View Controller, modèle d'arch et le modèle Pac-Amodeus incarnent dans leurs préceptes, des mécanismes pour modéliser et visualiser les collecticiels. 1.1. Le MVC : Model View Controller Le modèle multi-agents MVC consiste à séparer la partie interface utilisateur de la partie modélisation applicative. L'ontologie présentée par le MVC se présente en trois composants [LAY 04] [VEI 03] : modèles de données, de vue et de contrôleur. - Modèle : il s'agit du composant qui représente une abstraction des entités du domaine spécifique sans rapport avec la représentation dans l'environnement graphique (GUI), - Vue : La représentation graphique est spécifiée par ce composant qui se charge de visualiser les données qui sont retournées par le modèle. Donc il s'agit de la visualisation des données pour l'utilisateur final. Il faut noter que chaque vue peut avoir un ou - 1 -
plusieurs contrôleurs, - Contrôleur : Ce composant se charge de manipuler toutes les actions qui sont définies afin de les interpréter. Cette séparation entre le modèle de données et la visualisation graphique est indispensable surtout si le système doit se présenter sur plusieurs plateformes : web, PDA, téléphone cellulaire, application réseau... Ainsi l'interface utilisateur est adaptable suivant les plateformes d'implémentation en gardant le même noyau fonctionnel. Comme exemple applicatif, une solution est proposée [LAY 04] pour la transformation du schéma XML de spécification vers différents environnements graphiques (GUI) en utilisant plusieurs niveaux de style XSLT. Par exemple, pour Java Swing GUI, trois arbres de composants sont créés : - Arbre XML DOM pour le contenu, - Arbre d'éléments swing, - Arbre de contrôleurs sous forme d'objets Java. 1.2. Le modèle Arch Il s'agit d'une décomposition canonique des principaux composants d'un système interactif. La séparation entre l'interface Homme/Machine et le contenu fonctionnel (ou appelé aussi logique applicative), est le plus important aspect exploité par ce modèle. Cette séparation se fait au niveau architecture, car d'après ce modèle, la conception applicative de l'interface ne doit avoir aucun rapport avec les fonctionnalités présentées par le système afin de favoriser la réutilisabilité, la modification et l'adaptabilité de point de vue logiciel. Pour cela, le modèle présente cinq composants : Domain-specific component, Domain adaptor Component, Dialog Component, Presentation Component et Interaction Toolkit Component. - Domain-Specific Component (Noyau Fonctionnel) Il s'agit de la partie fonctionnelle qui présente tous les aspects de contrôle, manipulation et recouvrement des objets du domaine manipulé par la structure du système tout en restant indépendant de la présentation et de la projection des structures applicatives auprès de l'utilisateur, - Interaction Toolkit Component (Composant physique d'interaction) : c'est le composant qui implémente les interactions logicielles et matérielles vis-à-vis de l'utilisateur (widget). Il permet de générer les périphériques d'interaction logicielles et les outils permettant la manipulation des structures de données présentées par le système : les menus, les boutons, les boîtes de dialogue, les icônes, les boîtes à outils... - Domain Adaptor Component (Adaptateur du noyau fonctionnel) : c'est le composant médiateur entre le noyau fonctionnel (Domain-Specific Component) et le contrôleur de dialogue (Dialog Component). Tous les échanges entre le noyau fonctionnel et l'utilisateur sont exportés vers l'utilisateur via ce composant. L'organisation des données, la détection des erreurs sémantiques et l'initialisation du dialogue sont gérées à ce niveau, - Presentation Component (Composant de Présentation) : c'est le composant médiateur entre le noyau fonctionnel (Domain-Specific Component) et le composant physique d'interaction (Interaction Toolkit Component). Il s'agit d'une boîte à outils indépendante des objets du système, utilisable par le composant de dialogue, - Dialog component (Le Contrôleur de Dialogue) : il s'agit du composant principal qui lie les deux composants Presentation component et Domain Adaptor Component. Il se charge de manipuler tous les objets conceptuels, les présentations, l'enchaînement des tâches et surtout l'affectation des objets conceptuels aux objets de représentation. 1.3. Le modèle PAC-Amodeus Ce modèle présente une décomposition suivant les cinq composants fonctionnels du modèle d'arch présenté [LAC 02] [NIG 02]. Des agents PAC sont utilisés pour structurer la partie contrôleur [DUV 06]. L'ontologie présentée par l'agent PAC se compose de trois parties : - Présentation : qui s'occupe de l'interface utilisateur et des interactions homme/machine, - Abstraction : qui représente les compétences gérées dans le domaine, et leurs représentations au niveau système sans les lier aux interfaces homme/machine, - Contrôle : qui est le médiateur entre la présentation et l'abstraction. C'est le composant intermédiaire entre plusieurs agents PAC qui constituent une hiérarchie multi-agents. Il s'occupe de toutes les communications inter-agents ainsi que des communications intra-agent entre les facettes "Présentation" et "Abstraction" d'un même agent. Le modèle PAC-Amodeus présente alors une fusion des deux modèles : ARCH et MVC en s'appuyant sur l'ontologie des agents pour améliorer le contrôleur de dialogue et le présenter sous forme d'un modèle hybride multi-agents. Le point essentiel qui a été apporté par ce modèle est la malléabilité en ajoutant et retranchant des composants au niveau du contrôleur de dialogue grâce à cette structure - 2 -
modulaire. Plusieurs modèles d'architecture sont proposés pour les collecticiels afin de modéliser le travail collaboratif et d'introduire plusieurs mécanismes pour la mise en place des activités des collaborateurs dans l'environnement de travail collaboratif. 1.4. Principe de base des modèles d architecture des collecticiels L'aspect de base des collecticiels consiste en l'activité du groupe. L'étude du comportement des acteurs est très importante à ce niveau ainsi que la tâche produite et l'environnement qui englobe l'activité des différents acteurs. La compréhension des comportements produits est favorisée par l'environnement de coordination ce qui rend l'étude des collecticiels différente de celle des systèmes mono-utilisateur car elle englobe non seulement la particularité des comportements de chaque utilisateur, mais aussi la contribution des activités interutilisateurs. L'étude de l'ensemble des tâches réalisées par les acteurs et leurs pratiques, consiste à analyser le cadre de l'interaction, les règles qui la régissent au sein du groupe de travail, les événements qui agissent sur l'interaction ainsi que les différentes types de vue de l'espace de travail multi-utilisateurs. La modélisation des interactions est définie pour agir sur tous les niveaux d'abstraction de l'espace de collaboration. 1.5. Panorama des modèles d'architecture pour les collecticiels Selon plusieurs réflexions menées sur le comportement des collaborateurs dans leur environnement d'échange, plusieurs modèles sont proposés afin de spécifier l'espace de travail. Nous vous présentons un état de l'art des modèles qui ont marqué le développement des collecticiels. 1.5.1. Modèle Zipper Selon la notion d'états partagés [CAL 97], un collecticiel est décomposé suivant quatre niveaux d'abstraction : - Etat de l écran : qui représente l'état des périphériques utilisés en entrée et en sortie, - Etat de la vue : qui est l'état de la représentation des données manipulées et de l'organisation de l'interface utilisateur, - Etat du modèle : le modèle ici signifie le traitement représenté par les processus fonctionnels mis en place et leurs interactions avec les objets du domaine d'application, - Etat du fichier : qui engendre la persistance du modèle. Il y a trois modes d instance pour cette combinaison d'états : partagé, synchronisé et répliqué. 1.5.2. Méta-Modèle de Dewan: généralisation du modèle de Zipper et d'arch Les niveaux d'abstraction sont généralisés afin d'engendrer plusieurs couches représentant une multitude de niveaux d'abstraction pour la construction des collecticiels [LAU 02]. Ces couches sont déterminées selon deux niveaux [DEW 01] : - Niveau sémantique : qui représente le noyau fonctionnel et qui est déterminé par des couches partagées formant la racine du modèle, - Niveau physique : qui définit les différents composants d'interactions et qui sont organisés sous forme d'arborescence de branches pour définir les couches répliquées et qui sont reliées à la racine via un point d'embranchement. 1.5.3. Modèle ALV ALV ou Abstraction-Link-View est une architecture à base d'agents qui est organisée selon trois niveaux [CAL 97] : - Abstraction partagée : pour la gestion des objets du domaine qui sont partagés par tous les utilisateurs de l'espace de travail, - Vue répliquée : qui gère tous les événements réalisés par l'utilisateur qui sont traités par des fonctionnalités mises en place localement afin d'interpréter les interactions approuvées, - Lien : pour assurer la liaison entre la vue et les objets partagés de l'espace de travail. La conformité des données manipulées est nécessaire et doit être certifiée à ce niveau pour garder la cohérence des données partagées. 1.5.4. Modèle Clock et DragonFly Le modèle d'architecture Clock est similaire au modèle MVC et est représenté par un agent constitué de trois facettes [GRA 96] [LAU 02] : - Modèle : qui gère les données de l'espace de travail, - Contrôleur : pour interpréter les interactions des utilisateurs, - Vue pour projeter des informations sur l'interface utilisateur. La communication entre la "vue" et le "contrôleur" n'existe pas, tandis que l'échange est monodirectionnel entre le "contrôleur" et le "modèle" pour lui indiquer les changements apportés par l'utilisateur sur les données. La "vue" se contente de toutes les notifications de changement depuis le modèle. 1.5.5. Modèle CoPac Le modèle CoPac est une extension du modèle PAC-Amodeus. Il s'agit d'un agent PAC (Présentation, Abstraction, Contrôle) augmenté par la facette communication pour permettre l'échange de communication entre les utilisateurs de l'espace de - 3 -
travail collaboratif [SAL 95a]. Au niveau du contrôle, tous les messages sont distribués vers la facette "communication" en provenance de "l'abstraction" et de "la présentation". 1.5.6. Modèle Pac* Le modèle PAC* introduit un découpage fonctionnel au niveau de l'agent PAC suivant les trois dimensions de base du modèle de trèfle [LAU 02]. Un agent PAC* est composé alors de trois agents qui s'occupent respectivement du contrôle, de la production, de la communication et de la coordination. La communication entre ces agents reste dépendante de l'architecture utilisée : hybride, centralisée ou répartie. 1.6. Discussion Les modèles de conception et d'architecture présentés favorisent vivement la séparation de l'interface utilisateur et de la logique applicative des systèmes modélisés. Pour les collecticiels, les exigences sont encore plus évoluées puisque la nature des environnements de travail collaboratif présente plusieurs niveaux de congruence entre les tâches présentées et les approches fonctionnelles nécessaires pour l'environnement collaboratif. Le tableau Table 1 démontre l'absence de la dualité : "décomposition fonctionnelle/espace de travail" dans les modèles étudiés. Un collecticiel doit présenter plusieurs fonctionnalités aux différents intervenants afin de les aider à mener un travail de groupe selon les objectifs définis. Il est alors nécessaire d'avoir un espace de travail partagé sans pour autant abandonner l'idée d'un espace privé (espace dans lequel, de manière libre, l'acteur peut travailler seul). Modèle Décomposition Espace Espace Fonctionnelle Privée Public MVC... ARCH... PAC- AMODEUS... ZIPPER... DEWAN. ALV... CLOCK. COPAC.. PAC*.. Table 1. Synthèse des Modèles : présent,. : absent La collaboration implique aussi plusieurs niveaux de participations des collaborateurs en allant d'un simple partage de ressources jusqu'à l'accomplissement d'une tâche du processus de collaboration. Un espace de travail dédié aux collecticiels doit prendre en compte plusieurs concepts qui sont indispensables de part la nature de l'environnement comme étant un espace de travail : - qui prends en compte plusieurs intervenants, - qui donne la possibilité de communication entre les collaborateurs, - qui gère plusieurs niveaux de collaborations assurés par les intervenants, - qui présente plusieurs fonctionnalités pour aider à l'accomplissement du travail collaboratif, - tout en donnant plus de facilités à l'achèvement du travail assuré par les collaborateurs. 2. Les interfaces Homme/Machine distribuées : DHCI Les modèles d'architecture des collecticiels étant présentés, il s'agit dans cette section de présenter l'ontologie des interfaces homme/machine et leurs utilités dans la contribution et l'évaluation des interactions du groupe dans les collecticiels. L'environnement de collaboration préconise une approche plus évoluée du point de vue présentation de l'information, interfaçage avec l'espace de travail, interférence au sein du collecticiel et aspect fonctionnel (déterminé par la logique applicative du travail collaboratif). Il y a beaucoup de différences entre les interfaces de groupe et celles mono-utilisateur : non seulement car elles représentent les actions d'un groupe, mais aussi car elles sont contrôlées par les utilisateurs du groupe. Néanmoins, elles doivent gérer les problèmes de concurrence mais aussi et surtout diminuer les perturbations inhérentes aux manipulations des autres membres du groupe, et ceci plus spécialement pour les logiciels de visioconférence [GRE 95]. 2.1. Première approche L'approche de construction d'interface de groupe la plus utilisée est connue sous le nom de WYSIWIS : What You See Is What I See. Ce concept, assez ancien [STE 87], garantit que l'environnement apparaîtra de manière identique chez tous les membres du groupe. Cependant, ce mode est très contraignant du point de vue de sa mise en place : - Les utilisateurs souhaitent avoir une certaine indépendance, - Une interface WYSIWIS stricte implique des opérations permanentes de multidiffusion : chacun des sites émet vers tous les autres car toutes les actions doivent être vues. D'où la notion de WYSIWIS relaxé qui peut être appliquée dans quatre dimensions : - Espace : chaque participant a la possibilité de personnaliser la disposition des fenêtres sur son écran et d'ouvrir de nouvelles fenêtres communes, - 4 -
- Temps : en WYSIWIS Stricte, les actions sont synchronisées. Le temps permet de définir le grain de la coopération. Un grain variable permet des moments privés durant lesquels aucune des actions de l'utilisateur n'est connue du reste du groupe, - Population : une opération coopérative peut être restreinte à un sous groupe. Une gestion dynamique permet de tenir compte du fait qu'un sous-groupe ne se forme souvent que pour le temps d'une tâche transitoire. Ce groupe disparaît dès que la tâche commune est terminée, - La congruence des vues : les vues des participants peuvent différer, c'est-à-dire que l'information affichée n'est pas la même sur chaque écran. Ceci permet à chaque participant de sélectionner la vue du document la mieux adaptée à son travail. 2.2. Les modes d affichage Dans le travail coopératif, l'information peut être affichée de différentes manières pour mettre en avant les caractéristiques importantes, comme l'appartenance d'un objet, son âge,... Dans cette étude, nous nous focalisons sur cinq modes : - Le mode simple : pour une fenêtre de groupe, le changement de vues sur le document est uniquement local, c'est le WYSIWIS relaxé (mode de consultation du document par excellence). Toutes les modifications des utilisateurs du groupe sont prises en compte immédiatement et aucune information particulière au groupe n'est affichée, - Le mode identification : ce mode de représentation met en évidence l'identité de l'acteur qui réalise une modification sur l'espace partagé [HIN 99]. Différentes techniques peuvent être utilisées pour représenter ce mode : l'attribution de couleur à un participant, l'identification par une icône qui peut être, par exemple, la photographie ou un symbole de la fonction du participant, - Le mode localisation : ce mode permet de déterminer les vues des différents participants sur le document. Il est alors facile de connaître les zones de travail communes, - Le mode âge : ce mode permet de repérer plus aisément les zones d'activités du document en mettant en évidence les parties récemment modifiées, - Le mode histoire : ce mode permet de retracer l'évolution du document. Si un participant quitte la session, il peut désirer, lors de son retour, connaître les modifications intervenues depuis son départ. Ainsi différents degrés d'évolution pourront être utilisés comme dans PREP editor de l'université Carnegie Mellon de Pittsburgh [NEU 00]. 2.3. Trois espaces de base du modèle Trèfle Afin de pouvoir comparer différents collecticiels, Ellis définit dans [ELL 94] un modèle conceptuel formé de trois dimensions fonctionnelles. Le système collecticiel est basé sur l'interactivité entre les différents utilisateurs. Il favorise toutes les interactions entres les acteurs du système et offre l'opportunité des échanges mutuels entre les utilisateurs. Chaque échange est influencé par les activités des autres, par les possibilités d'interactions, par la production de messages. D'où les trois espaces fonctionnels de base du modèle de trèfle : la production, la coordination et la communication. - L'espace de production : identifie tout objet résultant de l'espace d'activité du système collecticiel ainsi que les fonctionnalités de production d'objets partagés. La gestion des accès aux objets produits est assurée à ce niveau. Cet espace offre une vision statique du système, Figure 1. Modèle de TREFLE - L'espace de coordination : représente tous les moyens de coordination dans l'espace de travail, qui se basent principalement sur les tâches et les activités, les acteurs et leurs habilités de modérer leur production. L'affectation des tâches et des rôles aux différents acteurs dans l'espace collaboratif permet la coordination des différents acteurs pour réaliser une oeuvre commune. Cet espace offre une vision dynamique du système, - L'espace de communication : englobe toutes les fonctionnalités qui assurent l'échange d'informations entre les acteurs du collecticiel. Ce qui permet de définir la communication Homme/Homme médiatisée (par ailleurs, il existe plusieurs types de communications : par exemple Homme/Machine, Machine/Homme,...). Les systèmes de visioconférence, la vidéo, - 5 -
la téléphonie sur IP, le textuel et la gestuelle, sont les modes de communication les plus utilisés. 2.4. Evolution du modèle conceptuel de trèfle Ce modèle a tout d'abord été repris et affiné dans [SAL 95b] pour définir le modèle des trois C : la Coproduction, la Coordination et la Communication. B. David ajoute dans [DAV 01] un quatrième espace, celui de la Conversation. Nous définissons un nouvel espace, celui de la Régulation comme orthogonal aux autres. Il permet de définir des lois d'interactions concernant les différents espaces. Le terme régulation signifie un ensemble de mécanismes qui permettent aux participants de s'organiser dans un environnement partagé. Nous ajoutons à cette définition la notion de flexibilité. Le service régulation permet en cours d'exécution la modification de l'organisation des participants, mais aussi du grain de l'application, et des mécanismes de gestion de la concurrence. - Trois espaces fonctionnels : Co-production, Communication et la Conversation, - L'espace de régulation qui est orthogonal, - L'espace de prise de conscience du groupe awareness qui est centré, - Le continuum de collaboration qui s'étale de la coordination à la collaboration en passant par la coopération. L'approche de conception WYSIWIS appliquée aux collecticiels, nécessite la congruence des vues de l'environnement de travail pour tous les collaborateurs et selon un mode d'affichage dédié aux spécificités de l'espace de travail. La particularité du modèle du trèfle réside dans le fait d'introduire les aspects fonctionnels liés au travail collaboratif, qui sont traités par l'espace de travail comme étant une nécessité de l'espace collaboratif. Ceci afin d'assurer un fonctionnement du groupe en impliquant tous les membres collaborateurs. 3. Le nouveau modèle de Continuum de Collaboration Augmentée, ACCM D'après notre étude réalisée sur les différents modèles existants, nous distinguons comme la montre la table de synthèse des modèles (cf. Table 1) l'absence de la dualité : {Espace Privé/Public} / {Décomposition Fonctionnelle} 3.1. Définition du modèle Le modèle du trèfle a été défini pour les interfaces Homme/Machine, nous proposons de réutiliser ce paradigme au niveau du modèle d'architecture, en l'injectant dans le Continuum de Collaboration. Nous définissons le Continuum de Collaboration comme étant une continuité de l'espace de travail collaboratif qui s'étale sur 3 dimensions allant de la Coordination à la Collaboration en passant par la Coopération. Cette continuité est augmentée par un trèfle fonctionnel qui regroupe plusieurs espaces qui définissent les dimensions composant le travail collaboratif. Ce qui détermine le Modèle Continuum de Collaboration Augmentée, ACCM (Augmented Continuum of Collaboration Model). Notre modèle d'architecture de base pour les groupes de travail est composé de (cf. Figure 2) : Figure 2. Modèle Continuum de Collaboration Augmentée, ACCM 3.2. Espaces abstraits : coordination, coopération et collaboration Nous devons distinguer trois espaces pour les collecticiels afin de décrire le continuum de collaboration : coordination, coopération et collaboration (cf. Figure 2) Plusieurs approches existent pour ces trois espaces abstraits [HOO 95] [GOD 01] [KVA 00] [HAN 03] qui caractérisent la collaboration par la réalisation d'un travail en équipe selon un objectif commun qui implique plusieurs acteurs suivant des relations mutuelles durables et proches. Tandis que la coopération est distinguée par des relations informelles et sans structure définie. Nous distinguons quelques spécificités pour chaque espace : - Espace de coordination : Pour l'espace de travail des collecticiels, cette dimension regroupe tous les objets partagés ainsi que les objectifs communs qui font la matière principale du regroupement des différents acteurs. Le travail personnel est le plus présent dans l'espace de coordination. Chaque acteur peut évaluer le résultat du travail de coordination afin d'aboutir à l'objectivité du travail collaboratif. Cet espace est destiné à être utilisé par un simple système et ne nécessite pas une capacité complexe pour établir la coordination fonctionnelle du travail collaboratif. Le travail en groupe est toujours guidé par des objectifs partagés, ce qui nécessite en phase de coordination plusieurs mécanismes pour la - 6 -
réalisation des tâches communes : divisions des tâches, ordonnancement, temporisation des contributions,... En coordination, c'est extrêmement important de spécifier toutes les tâches réalisées ainsi que l'affectation de chaque tâche aux acteurs appropriés comme le montre la figure 3. Chaque acteur suit des règles définies pour contribuer selon les actions déterminées par la communauté et qui définissent son profil fonctionnel, ou selon les actions ajustées par l'acteur lors de sa contribution et qui s'adaptent au problème traité selon ses initiatives. Figure 4. Modèle ACCM Coopération Figure 3. Modèle ACCM - Coordination - Espace de Coopération : Il s'agit d'un espace intermédiaire entre l'espace de coordination et l'espace de collaboration. La coordination peut mener à une coopération si le besoin d'échanger le champ de travail ou l'oeuvre de travail à travers les différents acteurs de l'espace de travail est capital afin d'améliorer ou d'apporter des retouches aux travaux réalisés. Nous pouvons alors spécifier la notion de groupe de coopération dans le sens de l'organisation du champ de travail selon les compétences métiers exigées. L'échange entre les participants est très demandé en coopération et il est assuré par plusieurs outils comme la messagerie instantanée, les outils audio-visuels (cf. Figure 4)... L'analyse commune est un aspect très exigé par la coopération. Il introduit une perception de toutes les données relatives aux buts communs ainsi que les méthodes appropriées pour la résolution du problème traité par le groupware. - Espace de Collaboration : La coopération s'élève à une collaboration si l'on introduit la notion du "Processus métier d'échange pour le travail collaboratif". La communication à ce niveau est complémentaire à l'échange du "champ de travail de coordination" entre les différents acteurs. Le sens d'engagement des acteurs caractérise le travail collaboratif et qui est concrétisé par des relations durables et continues entre les participants. L'accomplissement des travaux de collaboration ne peut avoir lieu que si l'on est un membre actif du groupe. La réalisation est très importante au niveau de la collaboration ainsi que le partage d'une vision commune pour la mise en place d'une solution. En collaboration, le groupe de travail cherche une meilleure solution pour son problème (cf. Figure 5). Le sens d'urgence est présent si le groupe de travail cherche une solution immédiate surtout lorsqu'on traite des applications en Télémédecine par exemple. Plusieurs outils sont mis en place pour la collaboration comme le brainstorming, les questionnaires... Figure 5. Modèle ACCM Collaboration - 7 -
Le continuum assure une continuité dans le travail collaboratif qui est exprimée par ces trois niveaux en commençant par la coordination qui est implicite dans l'espace de coopération, ce qui est encore implicite dans une collaboration. Le passage d'un niveau à un autre est assuré par les nécessités du travail collaboratif et qui se caractérise par la participation des membres du groupe de travail durant toutes les phases de traitement du problème soulevé. 3.3. L espace d Awareness : centre du trèfle du modèle Continuum de Collaboration augmentée Par définition, un collecticiel se présente comme étant un système multiutilisateurs qui supporte les actions du groupe d'utilisateurs, et notamment la conscience des autres participants [GUT 04]. Il s'agit d'un environnement qui préconise la collaboration pour la réalisation des tâches et la manipulation des composants afin d'achever un processus collaboratif. La prise de conscience (ou Awareness) prend en charge quatre facteurs principaux : - Le temps : comme étant un facteur majeur pour la réalisation des tâches collaboratives, - L'espace : qui représente la manipulation des informations visualisées et traitées dans l'espace de travail, - La population : qui regroupe tous les utilisateurs de l'environnement de travail et qui détermine qui est en relation avec l'autre, - La tâche : comme étant une unité importante du travail collaboratif au sein du collecticiel et qui implique l'activité de chaque membre participant. L'efficacité de la prise de conscience découle de la capacité de perception et de cognition dans l'environnement de travail collaboratif. Elle est indépendante de la capacité à comprendre mais surtout à concevoir, impressionner, distinguer et percevoir dans un espace multiutilisateurs. Plusieurs approches traitent la prise de conscience comme étant une conception liée au groupe de travail [ADA 95] [YOU 01] [GUT 04] donc on parle souvent de la prise de conscience des collègues (Awareness of co-workers) ou encore de la prise de conscience de l'espace de travail (Workspace Awareness). Dans notre approche nous relevons les points suivants : - La connaissance des données manipulées dans l'espace de travail ainsi que la conscience des autres utilisateurs collaborant, - L activité comme résultat du travail de coordination de chaque utilisateur en tenant compte de l'aspect connaissance pour définir : qui fait quoi?, dans quel but? et selon quel mode (asynchrone ou synchrone)? - Le contexte qui précise le champ de travail pour chaque activité réalisée par les participants au travail collaboratif en tenant compte des différentes options prédéfinies pour chaque activité, - La participation qui définit le niveau d'implication de chaque utilisateur dans l'espace de travail ainsi que les différents états de disponibilité dans l'environnement collaboratif. 4. Application à la Télémédecine : Le modèle ACCM appliqué au système TeNeCi 4.1. Présentation du système TeNeCi TeNeCi (Télé-Neurologie Coopérative) est un système d'aide à la décision dédié au domaine de la neurologie et plus particulièrement aux urgences neurologiques. Les VCD (Vascular Cerebral Disease) : maladies cérébrales vasculaires sont une des principales causes de mort aux urgences. Le CHU de Besançon (France) et le CHU Vaudois de Lausanne (Suisse) avaient alors l'initiative de créer ce projet européen dans le but de fournir un outil efficace et effectif aux médecins pour pouvoir établir un diagnostic collaboratif à distance. La plateforme TeNeCi offre les outils nécessaires pour rendre la réunion de plusieurs médecins possible pour qu'ils accèdent en temps réel à des informations extrêmement pertinentes, surtout lors de la prise de décision ou l'assistance présentée par le système devient nécessaire. Le système TeNeCi propose deux modes de coopération : asynchrone et synchrone. Toutes les informations nécessaires au diagnostic qui doit être réalisé par les experts sont regroupées dans un dossier, ce qui fait l'objet principal du mode asynchrone. En mode synchrone, plusieurs mécanismes sont mis en place pour faciliter la réunion des experts, afin de réaliser un diagnostic en ligne dans une salle virtuelle de réunion. Ce mode consiste à gérer les différents avis des intervenants et à diffuser leurs interventions en temps réel à tous les participants. Un grand nombre de traitements sont réalisés sur les images traitées en utilisant plusieurs outils comme le zoom, la gestion de contraste... Ce qui rend l'ordre des tâches et des accès concurrents très important et nécessite la mise en place de protocoles spécifiques [GAR 99] [GAR 01] [GAR 04] [GUY 01] [GUY 97]. 4.2. Fonctionnalités de base du système TeNeCi Plusieurs fonctionnalités sont présentées par le système TeNeCi et sont principalement dédiées aux groupware afin d'assurer un travail de groupe dans la salle d'examen virtuelle [GAR 05a] [GAR 05b] [DRO 05] : - Explorateur DICOM : permet l'exploration, la recherche et le téléchargement des différentes images qui proviennent des équipements médicaux supportés par le système (CT scan, MRI, PET), - 8 -
- Boîtes à Outils : Ce sont les outils utilisés pour retoucher les images médicales (zoom, dessins,...) et pour les commenter (ajouter des annotations...), - Messagerie électronique : utilisée pour l'échange des packages du diagnostic (dossier patient par exemple), - Visioconférence : pour une communication en vision entre les acteurs du système, - Audioconférence : pour une communication audio entre les acteurs du système, - Tableau blanc partagé : dans lequel les acteurs peuvent partager des dessins, textes, photos,... d'une façon interactive, - Observateur des actions : pour visualiser les actions réalisées dans l'espace de travail par les différents acteurs, - Messagerie instantanée : pour l'échange des messages textes entres les acteurs en ligne, - Régulation du son, de la vidéo et de l'espace de travail : chaque participant peut activer et désactiver le son et la vidéo, comme il peut spécialiser son espace de travail de point de vue IHM (disposition des fenêtres par exemple), - Transfert de fichier : pour diffuser des fichiers, utilisé lors du transfert d'une vidéo d'un patient par exemple, - Télépointeur : permet de visualiser le pointeur de chaque acteur ainsi que ses actions. Par exemple, lorsqu'un utilisateur sélectionne des régions sur une image traitée ou des formes sur une même image et par plusieurs acteurs, tous les autres acteurs visualisent ses actions en temps réel, - Télé-annotation : pouvoir inscrire des annotations sur les images traitées sous forme de texte ou dessin, - Télé-réglage : pour modifier les images par différents traitements (zoom, rotations, contraste, luminosité, détection de contour,...) et les diffuser à tous les membres acteurs, - Télé-édition du diagnostic : outil qui permet de remplir un questionnaire pendant la phase d'observation des réactions du patient. A la fin de l'observation, un rapport est généré contenant une comparaison de toutes les évaluations présentées par les experts, - Alerte de diagnostic : il s'agit d'un outil qui permet de préciser des alertes concernant l'élaboration de diagnostic en cas d'urgence ou en cas d'un besoin extrême par les acteurs du système. 4.3. Le modèle ACCM appliqué à TeNeCi Une répartition des fonctionnalités de base du système TeNeCi selon les composants du continuum de collaboration (cf. Table 2) montre les trois niveaux de collaboration et les outils proposés pour chaque espace afin d'assurer les tâches convenables. L'espace coordination regroupe tous les outils de traitements d'image DICOM ainsi que les moyens délivrés par le système pour transférer le dossier de diagnostic et les documents nécessaire au patient traité. L'espace coopération favorise en plus les outils de conversation : vision et audio conférence, tableau blanc et la messagerie instantanée ainsi que les mécanismes reliés à la prise de conscience (awareness) de l'espace de travail qui est une nécessité pour le travail de groupware et surtout pour la mise en place des réunions virtuelles des médecins dans les salles d'examen virtuelles (on trouve le télé-pointeur et l'observateur des actions réalisées). Fonctionnalités TeNeCi Explorateur DICOM Boîtes à outils Messagerie électronique Transfert de fichier Gestion de versions de dossier de diagnostic Gestion des profils Conscience des Modification apportées au dossier de diagnostic Visioconférence Audioconférence Tableau blanc partagé Messagerie instantanée Régularisation du son, de la vidéo et de l espace de travail Observateur des actions Télépointeur Présence d un médecin Télé-annotation Télé-réglage Télé-édition du diagnostic Alertes de diagnostic Verrouillage des diagnostics en cours de traitement Actions en cours d un médecin Composant ACCM Co-production Communication Régulation Awareness Conversation Régulation Awareness Co-Production Co-production Régulation Awareness Niveau de Collaboration Coordination Coopération Collaboration Table 2. Décomposition des fonctionnalités de base de TeNeCi selon le modèle ACCM L'espace de collaboration regroupe tous les outils pour la réalisation d'un diagnostic collaboratif à distance : on trouve le télédiagnostic qui implique plusieurs médecins en ligne et qui remplissent un questionnaire relatif aux réactions du patient traité. Le résultat du brainstorming des différents rapports est très favorable pour l'avis des médecins. La prise de conscience des médecins est exigée aussi surtout pour joindre un neurologue afin qu'il participe à l'examen - 9 -
dans la salle virtuelle. 4.4. Contribution collaborative par passage d'un niveau de collaboration vers un autre Le continuum de collaboration assure le passage d'un niveau de collaboration vers un autre selon les exigences du système collaboratif. Pour bien assimiler ces transitions, nous présentons un scénario qui se compose de trois phases de réalisations : en commençant par une coordination des participants jusqu'à l'aboutissement à un travail collaboratif. - Une phase de coordination : représentée par le transfert du dossier de diagnostic par le participant 1 aux participants 2 et 3 (cf. Figure 6), Figure 6. Système TeNeCi - Coordination : Transfert du dossier de diagnostic - Une phase de coopération : représentée par une vidéoconférence entre les participants 1, 2 et 3 et une audio conférence entre les participants 1 et 2. Ces outils de conférence assurent des liens de conversations entre les trois médecins pour analyser le dossier de diagnostic traité. Suite à l'analyse réalisée, le participant 2 ajoute des annotations sur une image visualisée (cf. Figure 7), Figure 7. Système TeNeCi - Coopération : Visio et Audio conférence, Ajout des annotations - Une phase de collaboration : représentée par une enquête réalisée par les trois participants selon les actions du patient en ligne, afin d'assurer un avis commun suite aux analyses du dossier de diagnostic étudié (cf. Figure 8). Figure 8. Système TeNeCi - Collaboration : Télédiagnostic CONCLUSION Dans ce papier, nous avons présenté les modèles de conception et d'architecture qui ont été mis en place avec l'avènement d'un nouveau type d'applications : les applications distribuées collaboratives. Puis nous avons étudié les modèles d'interfaces Homme/Machine distribuées. Mais l'efficacité d'une plate-forme collaborative réside dans la capacité qu'elle aura à rendre le travail réellement collaboratif c'est-à-dire à placer les acteurs dans une situation la plus proche possible d'une salle d'examen virtuelle. La prise de conscience des humains coopérants (awareness) est primordiale. C'est pourquoi, nous nous proposons, en portant le modèle dit du trèfle de définir le Continuum de Collaboration comme étant une continuité de l'espace de travail collaboratif qui s'étale sur 3 dimensions allant d'une Coordination à une Collaboration en passant par la Coopération. Cette continuité est augmentée par un trèfle fonctionnel qui regroupe plusieurs espaces qui déterminent des dimensions indispensables pour le travail collaboratif. Ce qui détermine le Modèle Continuum de Collaboration Augmentée, ACCM. Actuellement, une plateforme élaborée à l'aide de ce modèle est mise en place. Il s'agit de TeNeCi (Téléneurologie Coopérative) qui a été financée dans le cadre d'un projet européen InterregIII. L'idée étant de donner au médecin en cours de diagnostic les outils permettant de travailler en collaboration ainsi que la prise de conscience de son confrère et de son patient. Les résultats des tests de la plateforme in situ des praticiens hospitaliers, et les premiers retours d'expérience sont très convaincants. REMERCIEMENTS Les auteurs remercient l'institut des Sciences et Technologies de l'information (ISTI de Besançon) ainsi que la communauté Européenne (par le projet TeNeCi INTERREGIII), qui ont permis les financements de ce travail. - 10 -
RÉFÉRENCES [ADA 95] Tenney Y. Pew R. Adams, M. Situation awareness and the cognitive management of complex systems. Human Factors, 37(1):85 104, 1995. [CAL 97] Joëlle Coutaz Gaëlle Calvary and Laurence Nigay. From singleuser architectural design to pac*: a generic software architecture model for cscw. Conference on Human factors in computing systems, Atlanta, Georgia, United States, pages 242 249, 1997. [DAV 01] B. David. Ihm pour les collecticiels. Revue Réseaux et Systèmes Répartis, Calculateurs Parallèles, 13-2(3), 2001. [DEW 01] Dewan P. An integrated approach to designing and evaluating collaborative applications and infrastructures. CSCW, 10:75 111, 2001. [DRO 04] J.L. Haberbusch L. Droz-Bartholet, E. Garcia. Collaborative teleneurology for remote diagnosis conformance statement for teneci dicom explorer. Technical report, Laboratoire d Informatique de Franche Comté-LIFC, 2005. [DUV 06] Thierry Duval and Jean-Claude Tarby. Améliorer la conception des applications interactives par l utilisation conjointe du modèle pac et des patrons de conception. Proceedings of the 18th international conference on Association Francophone d Interaction Homme-Machine, Montreal, Canada, 133:225 232, 2006. [ELL 94] Clarence Ellis and Jacques Wainer. A conceptual model of groupware. Proceedings of the 1994 ACM conference on Computer supported cooperative work, pages 79 88, 1994. [GAR 99] Lapayre JC Garcia E, Guyennet H. Group support in cooperative work applications. Int. Conf. on Parallel and Distributed Processing Techniques and Applications, PDPTA 99, Las Vegas, USA, 6:2802 2807, July 1999. [GAR 01] Renard F., Ba T., Garcia E., Lapayre J-C. Calif multimédia : une plate-forme à objets pour le développement de télé-applications multimédia: Réseaux et systèmes répartis. Calculateurs Parallèles, 3:295 318, 2001. [GAR 04] J-C. Lapayre E. Garcia, H. Guyennet. Group partitionning over corba for cooperative work. Journal of Cluster Computing, 2004. [GAR 05a] J.C Lapayre S. Ramadass R. Budiarto N. Kassim M. Bouhlel E. Garcia, H. Guyennet. Collaborative telemedicine components integration in a multimedia conferencing system. 20th APAN Meeting: Advanced Network Conference, Taipei, pages 59 67, August 2005. [GAR 05b] V. Bonnans L. Cammoun S. Chatelain L. Droz Bartholet G. Devuyst H. Guyennet JL. Haberbush JC. Lapayre T. Moulin JP. Thiran E. Garcia, J. Bogousslavsky. Collaborative tele-neurology for remote diagnosis. 3rd International Conference: Sciences of Electronic, Technologies of Information and Telecommunications, SETIT, 2005. [GOD 01] J. C. Bignon C. Bouthier O. Malcurat P. Molli C. Godart, G. Halin. Implicit or explicit coordination of virtual teams in building design. conférence CAADRIA 2001 (Computer-Aided Architectural Design Research in Asia), Sydney, Australia, pages 429 434, 2001. [GRA 96] Nejabi R. Graham T.C.N., Urnes T. Efficient distributed implementat ion of semi-replicated synchronous groupware. UIST 96, pages 1 10, 1996. [GRE 95] Chris Greenhalgh and Steven Benford. Massive: a collaborative virtual environment for teleconferencing. ACM Transactions on Computer-Human Interaction (TOCHI), 2:239 261, 1995. [GUT 04] Carl Gutwin and Saul Greenberg. A descriptive framework of workspace awareness for real-time groupware. Computer Supported Cooperative Work (CSCW), Computer Science and Humanities, Social Sciences and Law, 11(34):411 446, November 2004. [GUY 97] Tréhel M Guyennet H, Lapayre JC. The pilgrim : A new consistency protocol for distributed shared memory. The IEEE Third Int. Conf. on Algorithms and Architectures for Parallel Processing, Melbourne, Australia, pages 253 264, December 1997. [GUY 01] Lapayre J-C, Guyennet H. The group approach in distributed system. Progress in Computer Research, Franck Columbus, 2:171 186, 2001. [HAN 03] Damien HANSER. Proposition d un modèle d auto coordination en situation de conception, application au domaine du bâtiment. PhD thesis, Institut National Polytechnique De Lorraine, October 2003. [HIN 99] Ken Hinckley and Mike Sinclair. Touch-sensing input devices. Conference on Human Factors in Computing Systems archive,proceedings of the SIGCHI conference on Human factors in computing systems, CHI 99, pages 223 230, 1999. [HOO 95] F. Hoogstoel. Une approche organisationnelle du travail coopératif assisté par ordinateur. Application au projet Co-Learn. PhD thesis, Université de Lille, November 1995. [KVA 00] T. Kvan. Collaborative design : what is it? Automation in construction, 9:409 415, 2000. [LAC 02] Coutaz J. Lachenal Ch. introspac : un outil pour enseigner et comprendre pac-amodeus. IHM 2003, Caen France, pages 212 215, 2002. [LAU 02] Yann Laurillau and Laurence Nigay. Clover architecture for groupware. 14th French-speaking conference on Human-computer interaction, 32:113 120, 2002. [LAY 04] Patrick Lay and Stefan Lüttringhaus-Kappel. Transforming XML schemas into Java Swing GUIs. In Peter Dadam and Manfred Reichert, editors, GI Jahrestagung (1), INFORMATIK 2004 -Informatik verbindet, Band 1, Beiträge der 34. Jahrestagung der Gesellschaft für Informatik e.v. (GI), 20. September - 24.September 2004 in Ulm, volume P-50 of LNI, pages 271 276.GI, 2004. [NEU 00] Ravinder Chandhok Christine M. Neuwirth, David S. Kaufer and James H. Morris. Computer supported collaborative writing: A coordination science perspective. Coordination Theory and Collaboration Technology, in the computers, cognition and work Series, May 2000. - 11 -
[NIG 02] Phil Gray Laurence Nigay. Architecture logicielle conceptuelle pour la capture de contexte. Proceedings of the 14th Frenchspeaking conference on Humancomputer interaction (Conférence Francophone sur l Interaction Homme-Machine), pages 211 214, 2002. [SAL 95a] Salber Daniel. De l interaction individuelle aux systèmes multiutilisateurs. L exemple de la communication Homme-Homme médiatisée. Thèse de doctorat informatique, Université Joseph Fourier, Grenoble, France, 1995. [SAL 95b] Daniel Salber, Joëlle Coutaz, and et al. De l observabilité et de l honnêteté: le cas du contrôle d accès dans la communication homme-homme médiatisée. Journée IHM 95, Cépaduès,Toulouse, 1995. [STE 87] G. Foster S. Lanning M. Stefik, D. G. Bobrow and D. Tatar. Wysiwis revised: early experiences with multiuser interfaces. ACM Transactions on Information Systems (TOIS),5:147 167, 1987. [VEI 03] Matthias Veit and Stephan Herrmann. Model-view controller and object teams: a perfect match of paradigms. pages 140 149. ACM Press, 2003. [YOU 01] Pekkola S. You, Y. Meeting others supporting situation awareness on the www. Decision Support Systems, (32):71 82. - 12 -