(PDF) Groupware : architectural and control issues

Construction de collecticiels : ´ etude d’architectures logicielles et de fonctions de contrˆole Rushed Kanawati To cite this version: Rushed Kanawati. Construction de collecticiels : ´etude d’architectures logicielles et de fonctions de contrˆole. Networking and Internet Architecture [cs.NI]. Institut National Polytechnique de Grenoble - INPG, 1997. French. <tel-00010633> HAL Id: tel-00010633 https://tel.archives-ouvertes.fr/tel-00010633 Submitted on 14 Oct 2005 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destin´ee au d´epˆot et `a la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publi´es ou non, lished or not. The documents may come from ´emanant des ´etablissements d’enseignement et de teaching and research institutions in France or recherche fran¸cais ou ´etrangers, des laboratoires abroad, or from public or private research centers. publics ou priv´es. THESE Presentee par Rushed Kanawati Pour obtenir Le Titre de Docteur de l'INPG (Arr^ete ministriel du 30 mars 1992) Specialite : INFORMATIQUE Construction de collecticiels : etude d'architectures logicielles et de fonctions de contr^ole These soutenue le 24 Novembre 1997 devant le jury compose de : MM. : MAZARE Guy President DERYCKE Alain Rapporteurs TRE HEL Michel MOSSIE RE Jacques Examinateurs RIVEILL Michel These preparee au sein du projet SIRAC (IMAG-INRIA) A l'etoile ::: Au soleil et a la lune aux planetes de Joseph encore et pour toujours Remerciments : Le temps est venu pour remercier tous ceux qu'ont participe directement ou indirectement a l'aboutissement de cette these. Je remercie en particulier : Messieurs Michel Trehel et Alain Derycke pour avoir accepte d'^etre rapporteurs de cette these. Monsieur Guy Mazare qui m'a honnore en acceptant de presider le jury d'eva- luation de ce travail. Messieurs Jacques Mossiere et Michel Riveill qui ont dirigie ce travail Monsieur Roland Balter qui m'a accueilli dans son equipe de recherche. Les membres de l'equipe Sirac et les amis de l'Inria Rh^one-Alpes. Les membres du groupe du travail Scoop. Mes amis grenoblois et syriens expatries. Mes parents et mes freres et sures. Un grand merci a part a Maria, ma femme qui a su m'encourager aux moments diciles. Resume : Nous nous interessons dans ce travail a la problematique du developpement des applications pour le travail cooperatif, dites aussi collecticiels. Un collecticiel est a la fois une application multi-utilisateurs, repartie et interactive. La somme des trois proprietes precedentes rend le developpement de ce type d'applications particulierement dicile. Une approche souvent empruntee pour la construction des collecticiels consiste a developper une plate-forme qui fournit les services re- quis pour la cooperation. Dans ce rapport nous identions les principaux services demandes a une telle plate-forme et nous decrivons et nous comparons les die- rentes approches possibles pour realiser ces services. Nous proposons ensuite un nouvel environnement de cooperation appele Colt (pour Collaboration Terrain). Une premiere qualite de Colt est l'integration des deux modes de travail : individuel et en groupe. Les utilisateurs partagent un espace d'information ou chacun a le droit de voir et de se mouvoir selon des r^oles qui lui sont attribues. Une deuxieme qualite importante est l'adaptabilite fonctionnelle et structurelle. Selon l'axe structurel Colt permet de denir et de reajuster dynamiquement les r^oles des utilisateurs, de denir autant d'activites cooperatives que l'on souhaite et d'utiliser dans ces dierentes activites les outils dont on a besoin. Sur l'axe fonctionnel, les utilisateurs peuvent denir et changer dynamiquement la conguration des activites. Une attention particuliere est faite en vue de doter l'environnement de stra- tegies variees pour contr^oler les acces concurrents des utilisateurs aux donnees partagees. L'environnement Colt propose une famille de protocoles de tour de r^oles et integre un protocole original, appele LICRA. L'algorithme LICRA est un algorithme optimiste fonde sur la detection de dependances et la resolution auto- matique des con its en utilisant un mecanisme de transformation d'operations. Un premier prototype de l'environnement Colt est aujourd'hui disponible pour une plate-forme UNIX. Le prototype est implante en utilisant l'environnement de developpement TCL-TK. Abstract : The focus of this dissertation is the study of groupware or CSCW-applications development. One major approach for groupware development consist of construc- ting a platform that provide the dierent services required for supporting collabo- ration. In this work we start by out-lighting the main requirements for a CSCW platform. Then we describe and compare the dierent possible approaches for implementing these requirements. The results of the above mentioned study are used to feed the conception and the implementation of a new CSCW platform that we call : Colt (for Collaboration Terrain). Main features of the proposed platform are : 1) Easy transition between individual and collaborative work and 2) High functional and structural exibility. Colt users share a common information space. Each has his own role that denes his view on the shared space. The exibility of the environment allows the users to dene a wide variety of collaborative activities and to dynamically adjust and recongure existing ones. A special attention is paid to provide the environment with various strate- gies for concurrency control. In this goal, an original protocol, called LICRA (for Lock-free Interactive Concurrency Resolution Algorithm) is integrated in the environment. LICRA implements an optimistic strategy based on the use of operation transformation mechanism. A rst prototype of Colt, developed in TCL-TK, is now available for a Unix- platform. Table des matieres 1 Introduction 13 1.1 Le contexte general du travail : : : : : : : : : : : : : : : : : : : : 13 1.2 Objectifs: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 14 1.3 Cadre du travail : : : : : : : : : : : : : : : : : : : : : : : : : : : : 15 1.4 Demarche suivie : : : : : : : : : : : : : : : : : : : : : : : : : : : : 16 1.5 Contributions : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 16 1.6 Organisation de la suite du rapport : : : : : : : : : : : : : : : : : 17 2 Le TCAO, problematique et solutions 19 2.1 Introduction : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 19 2.2 Denitions et classications : : : : : : : : : : : : : : : : : : : : : 20 2.2.1 Denitions par analyse de fonctions : : : : : : : : : : : : : 21 2.2.2 Denitions par analyse de composants : : : : : : : : : : : 21 2.2.3 Denition par analyse de la communication : : : : : : : : 23 2.2.4 Synthese : : : : : : : : : : : : : : : : : : : : : : : : : : : : 24 2.3 Criteres d'etudes : fonctions de contr^ole : : : : : : : : : : : : : : : 26 2.3.1 La participation a une activite cooperative : : : : : : : : : 26 2.3.2 La coordination : : : : : : : : : : : : : : : : : : : : : : : : 29 2.3.3 Synthese : : : : : : : : : : : : : : : : : : : : : : : : : : : : 33 2.4 Classication de plates-formes pour le TCAO : : : : : : : : : : : 34 2.4.1 Niveau du support : : : : : : : : : : : : : : : : : : : : : : 34 2.4.2 Schema de mise en uvre : : : : : : : : : : : : : : : : : : 36 2.4.3 Nature des applications supportees : : : : : : : : : : : : : 38 2.5 Exemples : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 42 2.5.1 XTV : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 43 2.5.2 La plate-forme SOL : : : : : : : : : : : : : : : : : : : : : 44 2.5.3 GroupKit : : : : : : : : : : : : : : : : : : : : : : : : : : : 46 2.5.4 CoopScan : : : : : : : : : : : : : : : : : : : : : : : : : : : 46 2.5.5 La plate-forme MEAD : : : : : : : : : : : : : : : : : : : : 48 2.5.6 GroupDesign : : : : : : : : : : : : : : : : : : : : : : : : : 48 2.5.7 ActiveMail : : : : : : : : : : : : : : : : : : : : : : : : : : 50 2.6 Synthese et discussion : : : : : : : : : : : : : : : : : : : : : : : : 50 2.7 Conclusion : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 52 6 TABLE DES MATIE RES 3 Colt, un environnement de cooperation 55 3.1 Introduction : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 55 3.2 Objectifs : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 56 3.3 Choix de construction : : : : : : : : : : : : : : : : : : : : : : : : 57 3.3.1 Strategie de mise en uvre : : : : : : : : : : : : : : : : : : 57 3.3.2 Choix de metaphores : : : : : : : : : : : : : : : : : : : : : 58 3.4 Colt : presentation informelle : : : : : : : : : : : : : : : : : : : : : 61 3.5 Architecture generale : : : : : : : : : : : : : : : : : : : : : : : : : 65 3.5.1 Le Terrain : : : : : : : : : : : : : : : : : : : : : : : : : : : 65 3.5.2 L'agent-colt (AgC) : : : : : : : : : : : : : : : : : : : : : : 79 3.6 Realisation: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 83 3.6.1 L'environnement de developpement : : : : : : : : : : : : : 83 3.6.2 Mise en uvre : : : : : : : : : : : : : : : : : : : : : : : : : 83 3.7 Discussion et comparaison : : : : : : : : : : : : : : : : : : : : : : 85 3.7.1 Environnements virtuels cooperatifs : : : : : : : : : : : : 85 3.7.2 TeamRooms : : : : : : : : : : : : : : : : : : : : : : : : : 86 3.7.3 Comparaison generale : : : : : : : : : : : : : : : : : : : : 87 3.8 Conclusion : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 89 4 Contr^ole de la concurrence dans les collecticiels synchrones 91 4.1 Introduction : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 91 4.2 Denition du probleme : : : : : : : : : : : : : : : : : : : : : : : : 93 4.2.1 Modelisation d'un collecticiel synchrone : : : : : : : : : : : 93 4.2.2 Proprietes : : : : : : : : : : : : : : : : : : : : : : : : : : : 95 4.3 E lements d'un protocole de gestion de la concurrence : : : : : : : 96 4.4 Mise en uvre d'un protocole de gestion de la concurrence : : : : 98 4.4.1 Les mecanismes : : : : : : : : : : : : : : : : : : : : : : : : 99 4.4.2 Les politiques : : : : : : : : : : : : : : : : : : : : : : : : : 100 4.4.3 Exemples : : : : : : : : : : : : : : : : : : : : : : : : : : : 102 4.5 L'algorithme LICRA : : : : : : : : : : : : : : : : : : : : : : : : : 105 4.5.1 Presentation informelle : : : : : : : : : : : : : : : : : : : : 105 4.5.2 Mise en uvre : : : : : : : : : : : : : : : : : : : : : : : : : 107 4.5.3 Description de l'algorithme : : : : : : : : : : : : : : : : : : 113 4.5.4 Exemples : : : : : : : : : : : : : : : : : : : : : : : : : : : 115 4.5.5 Preuve de correction : : : : : : : : : : : : : : : : : : : : : 117 4.5.6 Amelioration de l'algorithme : : : : : : : : : : : : : : : : : 118 4.6 Resume : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 122 5 Conclusion 123 5.1 Les principaux apports : : : : : : : : : : : : : : : : : : : : : : : : 123 5.2 Les perspectives : : : : : : : : : : : : : : : : : : : : : : : : : : : : 126 Annexe 128 TABLE DES MATIE RES 7 A Pluridisciplinarite du TCAO : Apport des sciences humaines 129 A.1 Le r^ole de l'ethnographie : : : : : : : : : : : : : : : : : : : : : : : 131 A.2 Le r^ole de la psychologie : : : : : : : : : : : : : : : : : : : : : : : 132 A.3 La psychologie cognitive : : : : : : : : : : : : : : : : : : : : : : : 133 A.4 Sciences de la communication : : : : : : : : : : : : : : : : : : : : 133 A.5 Pluridisciplinarite : mise en uvre : : : : : : : : : : : : : : : : : : 134 B Services pour la cooperation 137 B.1 Pourquoi? : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 138 B.2 Qui? : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 139 B.3 Quand? : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 140 B.4 Comment? : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 141 B.5 Contraintes : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 141 B.6 Synthese : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 143 C Les systemes repartis comme support pour le TCAO 145 C.1 Modeles de communication : : : : : : : : : : : : : : : : : : : : : : 145 C.2 La migration et la duplication transparentes : : : : : : : : : : : : 147 C.3 La gestion de la concurrence : : : : : : : : : : : : : : : : : : : : : 148 C.4 La transparence des pannes : : : : : : : : : : : : : : : : : : : : : 148 C.5 La memoire partagee repartie : : : : : : : : : : : : : : : : : : : : 149 C.6 Les modeles de protection de donnees : : : : : : : : : : : : : : : : 149 C.7 Synthese : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 152 D Le protocole dOPT - preuve d'incorrection 155 E Liste de Publications 159 8 TABLE DES MATIE RES Table des gures 2.1 Classication espace-temps des collecticiels. 24 : : : : : : : : : : : : 2.2 Classes d'applications multi-utilisateurs. 25 : : : : : : : : : : : : : : 2.3 Classication des plates-formes pour la construction de collecticiels. 34 2.4 Construction de collecticiels par partage d'applications. 35 : : : : : : 2.5 Decomposition modulaire d'un collecticiel. 37 : : : : : : : : : : : : : 2.6 Le modele client-serveur du systeme de fen^etres X-Window. 38 : : : 2.7 L'architecture de la plate-forme XTV 39 : : : : : : : : : : : : : : : : 2.8 Interface-utilisateur de XTV. 44 : : : : : : : : : : : : : : : : : : : : : 2.9 L'architecture de la plate-forme SOL 45 : : : : : : : : : : : : : : : : 2.10 Interface de contr^ole de CoopScan. 47 : : : : : : : : : : : : : : : : : 2.11 Echo graphique dans GroupDesign. 49 : : : : : : : : : : : : : : : : : 3.1 L'interface utilisateur d'un agent Colt. 62 : : : : : : : : : : : : : : : 3.2 Visualisation d'un document : Draw0 est au repos, Draw1 est oc- cupe et Draw2 est en etat d'exploitation. 63 : : : : : : : : : : : : : : 3.3 Les operations et les informations disponibles sur un document. 63 : 3.4 Architecture generale du Terrain. 66 : : : : : : : : : : : : : : : : : : 3.5 Exemple d'un arborescence d'un repertoire des utilisateurs. 69 : : : : 3.6 Exemple de presentation d'un utilisateur. 70 : : : : : : : : : : : : : : 3.7 Graphe de privileges associe a l'utilisateur 2 de l'organisation U illustree a la gure (3.5) 76 : : : : : : : : : : : : : : : : : : : : : : : 3.8 Protocole de la connexion d'un AgC au Terrain. 81 : : : : : : : : : : 3.9 Structure d'un outil de production dans l'environnement Colt. 82 : : 3.10 Implantation de l'environnement Colt. 85 : : : : : : : : : : : : : : : 4.1 Modelisation d'un site dans un collecticiel synchrone a architecture dupliquee. 94 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4.2 Exemples de relations de dependance et de concurrence entre ope- rations. 100 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4.3 Exemple d'une echange d'operations entre trois sites. 110 : : : : : : : 4.4 Echange simultane entre trois sites. 115 : : : : : : : : : : : : : : : : : 4.5 Situation de concurrence partielle. 116 : : : : : : : : : : : : : : : : : : 4.6 Exemple de deroulement de l'algorithme de la connexion dynamique.120 10 TABLE DES FIGURES A.1 Le concept de la masse critique : le nombre des utilisateurs du collecticiel doit ^etre superieur a c pour que son rendement soit N positif. 130 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : A.2 Pluridisciplinarite du developpement du collecticiel 134 : : : : : : : : A.3 Alternatives de cooperation socio-technique pour la conception de collecticiels [Hughes et al.94] 135 : : : : : : : : : : : : : : : : : : : : : C.1 Concepts et schema de mise en uvre d'une matrice de protection. 152 D.1 Denition de la concurrence partielle. 156 : : : : : : : : : : : : : : : : Liste des tableaux 2.1 Les deux approches d'implantation d'un service de rendez-vous. 28 : 2.2 Modication et ajout de code necessaires pour l'adaptation d'ap- plications dans CoEx. 41 : : : : : : : : : : : : : : : : : : : : : : : : : 2.3 Principales caracteristiques des approches de transformation d'ap- plications existantes en collecticiels. 42 : : : : : : : : : : : : : : : : : 2.4 Inventaire des plates-formes choisies pour l'etude de comparaison des approches de construction de plates-formes pour le TCAO. 42 : : 2.5 Exemple d'une matrice de protection d'un bouton Solo associe a un r^ole . R 45 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2.6 Satisfaction des services requis pour la gestion de la participation et de la coordination par les plates-formes etudiees. 51 : : : : : : : : 3.1 Principales fonctions de manipulation de documents. 65 : : : : : : : 3.2 Structure d'un DD. 67 : : : : : : : : : : : : : : : : : : : : : : : : : : 3.3 Modele d'un seminaire. 72 : : : : : : : : : : : : : : : : : : : : : : : : 3.4 Exemples de regles de protection. 77 : : : : : : : : : : : : : : : : : : 3.5 Comparaison fonctionnelle entre Colt et les plates-formes presen- tees dans la section 2.5. 88 : : : : : : : : : : : : : : : : : : : : : : : : 4.1 Exemples de protocoles de tour de r^ole. 101 : : : : : : : : : : : : : : : 4.2 Les contextes de generation des operations illustrees sur la gure (5.3) 110 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : C.1 E valuation de la satisfaction des besoins des collecticiels par les systemes repartis. 152 : : : : : : : : : : : : : : : : : : : : : : : : : : 12 LISTE DES TABLEAUX Chapitre 1 Introduction 1.1 Le contexte general du travail Nous nous interessons dans ce travail a la construction d'un nouvel type d'ap- plications informatiques dites applications cooperatives ou collecticiels. Une ap- plication cooperative est un logiciel qui permet a un groupe d'utilisateurs de travailler ensemble et d'interagir entre eux dans le but de realiser une t^ache com- mune. La motivation pour la construction de telles applications est evidente : Dans la vie reelle des entreprises et des organisations humaines les individus pas- sent une grande part de leurs temps en travaillant en groupes (reunions de travail, discussions, redaction commune de plans et de rapports d'activites, sessions de diagnostic et de prise de decisions). Par suite l'idee de construire des logiciels qui supportent aussi bien le travail en groupe que les applications actuelles suppor- tent le travail individuel est forcement seduisante. Cependant la construction de collecticiels s'avere une t^ache intrinsequement dicile. Les constructeurs doivent traiter de nouveaux problemes qui s'ajoutent a la problematique classique de la construction de logiciels. Certains de ces problemes sont techniques ; d'autres ap- partient au domaine sociologique. Parmi les problemes techniques nous citons les suivants : Le collecticiel est une application multi-utilisateurs. Il doit traiter plusieurs ux d'entree a la fois. Des strategies de synchronisation entre les contri- butions des dierents utilisateurs et de gestion de la concurrence d'acces doivent ^etre prevues [Greenberg et al.94]. Le collecticiel est une application repartie. Les utilisateurs sont dans la plu- part de cas geographiquement disperses. Par consequent le collecticiel doit prendre en consideration l'aspect de communication a travers des reseaux informatiques ; l'ordonnancement des messages echanges et l'absence d'un etat global du systeme [Balter et al.91]. 14 Introduction Le collecticiel est une application interactive. Il est soumis a des contraintes temporelles severes. De plus il doit verier de nombreuses proprietes ergo- nomiques [Salber95]. Sur le plan sociologique plusieurs problemes sont a resoudre : Comment concilier la protection de la vie privee et la securite des utilisa- teurs d'une part et le besoin de rendre visible l'activite de chacun (pour favoriser la cooperation) d'une autre part. Quel modele de rendez-vous faut-il adopter ? et comment les utilisateurs peuvent se mettre a cooperer [Edwards95]. Comment equilibrer l'eort fourni pour utiliser le collecticiel et le prot apporte par son utilisation [Markus et al.90]. Comment concilier les deux modes de travail : individuel et cooperatif? La cooperation entre des informaticiens, des sociologues et des ethnologues semble ^etre une necessite pour la construction de collecticiels operationnels [Grundin94]. La pluridisciplinarite est une caracteristique du Travail Cooperatif Assiste par Or- dinateur (TCAO). Elle est en m^eme temps la principale source de diculte de construction des collecticiels. Le poids considerable qu'ont les aspects sociaux renforce la necessite des outils de prototypage rapide. Avec de tels outils les constructeurs peuvent rapidement evaluer l'utilisabilite des solutions techniques qu'ils proposent dans des conditions reelles de travail [Cosquer et al.94]. En conse- quence la tendance actuelle des constructeurs des applications cooperatives est orientee vers le developpement des plates-formes qui serviront pour le developpe- ment et l'execution des collecticiels varies. Cette approche, comparee a une ap- proche monolithique, presente outre le prototypage rapide l'avantage de reduire le co^ut de developpement de nouvelles applications et d'augmenter la abilite des applications due a la reutilisation de code. De nombreux projets de recherche se xent l'objectif de construire une plate-forme pour supporter le travail cooperatif. Nous citons pour l'exemple GroupKit [Greenberg et al.94], XTV [AW96], Rendez- vous [Hill92] et COLA [Trevor et al.93]. La presente these vise a contribuer a la denition d'une plate- forme generique pour le travail cooperatif. Par generique nous voulons dire supporter de scenarios et de types varies de cooperation. Nous resumons nos objectifs dans la section suivante. 1.2 Objectifs Ce travail est a un objectif double : 1. Identier les services systemes necessaires pour supporter la construction et l'execution des collecticiels. 1.3 Cadre du travail 15 2. E tudier et comparer les dierentes approches possibles pour la mise en uvre des services identies. Le but est de xer un ensemble de directives pour la construction d'une plate-forme generique pour le TCAO. Concernant le premier objectif, notre position est la suivante. La cooperation repose sur le partage de ressources par un groupe d'utilisateurs. La technologie actuelle de l'information presente des solutions interessantes pour faciliter le par- tage d'informations entre des utilisateurs geographiquement disperses (systemes repartis, bases de donnees, le WEB). La construction d'applications cooperatives repose sans doute sur l'exploitation de ces technologies. Cependant elle neces- sitera de modier les politiques d'exploitation de services actuellement dispo- nibles (par exemple abandonner le principe de la transparence de la distribution [Greenberg et al.94]) et d'ajouter de nouveaux services (par exemple un service de gestion de rendez-vous [Edwards95]). Nous souhaitons fournir une couche lo- gicielle qui regroupe les services requis pour supporter la cooperation assistee par ordinateur. La construction de cette couche repose sur une technologie de gestion de la distribution et du partage d'informations non forcement orientee cooperation. Concernant le deuxieme objectif, il est clair que nous ne pouvons pas aborder dans l'espace d'une seule these tous les problemes poses par la mise en uvre des services requis pour la construction des collecticiels. Nous avons choisi de concentrer notre action sur les deux problemes suivants : 1. Comment supporter la creation de nouvelles activites cooperatives? et quel modele de rendez-vous faut-il fournir? 2. Comment coordonner les contributions des utilisateurs impliques dans une t^ache commune surtout en cas de cooperation temps reel ou chaque utili- sateur est sense recevoir immediatement toute contribution des autres uti- lisateurs. 1.3 Cadre du travail Ce travail est mene au sein du projet Sirac (IMAG-INRIA) dont l'objectif principal est de concevoir et de realiser un environnement pour le developpe- ment et l'execution d'applications reparties [Balter et al.95]. Les recherches sont menees dans les deux themes suivants : 1. Construire des applications reparties en combinant des techniques de pro- grammation a base d'objets et des techniques d'integration de composants. 2. Developper un service pour le support d'objets partages persistants repartis. L'objectif est de fournir un support adaptable et ecace utilisable pour la construction de plates-formes a objets repartis et de serveurs d'objets en utilisant une memoire virtuelle partagee repartie. 16 Introduction Les applications cooperatives sont choisies comme des applications pilotes pour explorer les nouveaux besoins systemes et pour tester et valider les services fournis par le systeme Sirac. 1.4 Demarche suivie Dans un premier temps, nous nous somme interesses, a travers le develop- pement d'une plate-forme appelee CoopScan1 a la construction des applications cooperatives temps reels [Balter et al.96b]. Dans CoopScan nous nous sommes xes les objectifs suivants : Experimenter l'approche de construction de collecticiels synchrones par reutilisation d'applications mono-utilisateurs existantes. Experimenter l'approche de separation des politiques de contr^ole des appli- cations employees. Les resultats de l'experimentation de CoopScan nous ont conforte dans notre choix de separer les politiques de contr^ole des applications utilisees. Ils montrent aussi que la transformation d'applications existantes en applications cooperatives est une approche viable a condition que l'application a transformer verie cer- taines conditions de modularite et d'ouverture a son environnement d'execution. Dans une deuxieme phase nous avons travaille a etendre les fonctions oertes par CoopScan an de supporter des formes plus generiques du travail cooperatif. Nous avons aborde en particulier les problemes suivants : E tudier le probleme du passage facile entre le mode de travail individuel et le mode de travail en groupe. Fournir un modele de specication et de gestion des activites cooperatives. E tudier le probleme d'expression de droit d'acces et de securite des donnees employees dans des activites de groupe. Les solutions proposees pour resoudre les problemes cites ci-dessus sont re- groupees dans une plate-forme appelee Colt que nous decrivons dans le (chapitre 4). 1.5 Contributions Cette these contribue au domaine du TCAO selon les axes suivants : 1. Identication des besoins requis d'une plate-forme generique pour le TCAO (chapitre 2). 1Le developpement de CoopScan est fait en etroite collaboration avec Slim Ben Atallah du projet Sirac et l'equipe de recherche en systemes repartis au CNET-Paris (Issy les Moulineaux). 1.6 Organisation de la suite du rapport 17 2. E tude et comparaison des dierentes approches pour le developpement de plates-formes pour le TCAO (chapitre 2). 3. Proposition d'un nouvel modele de gestion d'activites cooperatives (chapitre 3). 4. Proposition d'un nouvel protocole pour la gestion de la concurrence pour les collecticiels temps reel (chapitre 3). 1.6 Organisation de la suite du rapport La suite du rapport est organisee en quatre chapitres qui sont les suivants : Chapitre 2 : La TCAO, problematique et solutions Ce chapitre est divise en trois parties. La premiere denit la classe d'applications que nous sou- haitons supporter la construction. La deuxieme analyse les besoins requis pour developper les applications choisies. Finalement, la troisieme partie presente une comparaison fonctionnelle des travaux existants qui visent a fournir une plate-forme pour le TCAO. Le but est de degager les choix de construction les plus adaptes pour realiser les services identies. Chapitre 3 : Colt, un environnement de cooperation decrit notre propo- sition d'un environnement integre pour supporter le travail cooperatif. Dans un premier temps nous motivons notre choix pour la construction d'envi- ronnement integre pour le travail cooperatif et nous precisons les objectifs xes pour un tel environnement. Ensuite nous decrivons l'architecture lo- gique de Colt et la mise en uvre de cet environnement. Finalement nous comparons notre proposition avec d'autres travaux similaires. Chapitre 4 : Contr^ole de la concurrence dans les collecticiels synchrones presente une etude des dierentes solutions du probleme de la concurrence d'acces et de gestion de droit de parole dans les collecticiels synchrones a ar- chitecture dupliquee. Un nouvel algorithme optimiste fonde sur le principe de la transformation d'operations est propose dans ce chapitre. Chapitre 5 : Conclusion rappelle les principaux resultats et evoque des pers- pectives de ce travail. 18 Introduction Chapitre 2 Le TCAO, problematique et solutions 2.1 Introduction Le Travail Cooperatif Assiste par Ordinateur (TCAO1) est un recent domaine d'activites qui suscite l'inter^et de la recherche et de l'industrie. L'objet du TCAO est d'adapter la technologie de l'information aux besoins des utilisateurs impliques dans des activites de groupe. Une denition du TCAO que nous devons a Bannon et Schmidt est la suivante [Bannon et al.91] : Le TCAO est le domaine de recherche repondant aux questions sui- vantes : quelles sont les caracteristiques speciques du travail coope- ratif comme oppose au travail eectue par des individus isoles? Com- ment l'informatique peut-elle ^etre appliquee pour soutenir les pro- blemes logistiques du travail cooperatif ? Comment les conceptions abordent-elles les delicats et complexes problemes des systemes qui faconnent les relations sociales? Le terme collecticiel, par analogie a logiciel et didacticiel, est choisi pour traduire le terme anglais groupware2. Une approche souvent empruntee pour la construc- tion des collecticiels consiste a developper une plate-forme qui fournit les services requis pour la cooperation. Cette approche, compare a l'approche de construction monolithique, presente l'avantage de reduire le co^ut de developpement et de facili- ter le prototypage rapide de nouveaux collecticiels. De plus elle permet de fournir aux utilisateurs un environnement homogene (en terme d'interface-utilisateur) pour utiliser des collecticiels variees et par consequence faciliter l'emploi des col- lecticiels. 1TCAO est la traduction en francais du CSCW : Computer Supported Collaborative Work. 2La traduction ocielle est synergiciel mais ce terme est peu employe dans les communica- tions scientiques. 20 Le TCAO, problematique et solutions Le presente chapitre a trois objectifs : 1. Preciser et denir la classe des applications que nous voulons construire (section 2.2). 2. E tudier et comparer les dierentes approches possibles pour la construction des applications identiees. Pour delimiter notre etude de comparaison nous avons choisi d'evaluer les travaux existants en termes des fonctions et des services qu'ils proposent pour resoudre deux problemes fondamentaux : 1. Comment un utilisateur peut faire partie d'une activite cooperative? 2. Comment coordonner les contributions des participants a une activite co- operative? Notre demarche est la suivante. D'abord nous etudions dans la section (2.3) qu'est ce qu'une plate-forme exemplaire devrait fournir comme services pour re- soudre les deux problemes cites ci-dessus. Cette etude nous permet de xer un ensemble de fonctions qui servent de base d'evaluation fonctionnelle des plates- formes existantes. Le nombre des plates-formes pour le TCAO etant tres grand, il devient souhaitable, voire necessaire, de comparer de familles ou de classes, de plates-formes. Dans cette optique nous proposons dans la section (2.4) une classi- cation des approches de construction des plates-formes pour le TCAO. Ensuite nous presentons dans la section (2.5) des exemples representatifs des approches identiees et nous les comparons en fonction des criteres retenus dans la section (2.3). Les principaux resultats tires de cette etude sont resumes dans la section (2.6). 2.2 Denitions et classications A part le consensus qu'un collecticiel est une application qui assiste un groupe d'individus impliques dans une t^ache commune, peu d'autres points regroupent les dierentes denitions du collecticiel. La divergence entre les denitions proposees dans la litterature est due d'une part a la grande diversite des applications qui assistent les groupes et d'autre part aux divers origines de la recherche en TCAO (systemes repartis, interface homme-machine, automatisation du bureau). Nous exposons dans la suite trois approches classiques pour la denition et la classication des collecticiels : par analyse de fonctions, par analyse de composants et par analyse de communication. 2.2 Denitions et classications 21 2.2.1 Denitions par analyse de fonctions Cette approche repose sur l'identication des fonctions (ou des services) atten- dues d'un collecticiel. De la facon la plus elementaire une denition par analyse de fonctions se fait en enumerant des exemples de collecticiels. Une telle de- marche est empruntee dans [Karsenty94a] ou l'auteur classe les collecticiels dans cinq categories : 1) les messageries electroniques, 2) les editeurs partages, 3) les conferences assistees par ordinateur, 4) les systemes d'aide a la decision et 5) les coordinateurs. Le bas niveau d'abstraction d'une telle denition limite son uti- lite ; etant fondee sur l'analyse des systemes existants cette classication ne peut pas prendre en compte les nouveaux types de systemes pouvant appara^tre. Ellis et Wainer proposent dans [Ellis et al.94b] une classication fonctionnelle selon laquelle ils distinguent quatre classes de collecticiels : Le depositaire est une application qui permet a un groupe d'utilisateurs de manipuler un ensemble d'objets communs (ex. editeur cooperatif). Le \synchroniseur" est une application dont l'objectif est de coordonner les activites d'un groupe (ex. ux de travail3). Le communicateur est une application qui supporte les communications inter- personnelles (ex. le courrier electronique, applications de teleconference). L'agent est une application qui fait appel a des methodes de l'intelligence articielle pour assister un groupe d'utilisateurs engages dans un travail commun. L'introduction de la classe agent met en cause l'orthogonalite de la classication proposee. La notion d'agent peut ^etre employee dans des applications variees, y compris les trois premieres classes de collecticiels identiees par la classication introduite ci-dessus. 2.2.2 Denitions par analyse de composants Une denition par analyse de composants consiste a identier les principaux composants qui forment un collecticiel. Un premier exemple est le modele propose dans [Ellis et al.94b]. D'apres ce modele un collecticiel est deni par la combinai- son de trois composants, dits aussi modeles, qui sont les suivants : Le modele "ontologique"4 decrit les classes des objets manipules par le collecti- ciel ainsi que l'ensemble des operations possibles sur ces objets. 3 Traduction du terme anglais Work ow. 4 Bien que le sens exacte du terme ontologique est relatif a l'^etre en tant que tel, son usage est etendu a tort au domaine des logiciels. 22 Le TCAO, problematique et solutions Le modele de coordination decrit les activites associees a chaque participant ainsi que les regles de coordination entre les dierentes activites (par exemple precedences temporelles) necessaires pour accomplir une t^ache. Le modele de l'interface utilisateur decrit les modeles de visualisation et des interactions avec les objets disponibles, les autres participants et le contexte du travail (representation de la composition du groupe, les participants actuelles, les positions des autres dans l'espace partage, etc). Les deux modeles \ontologique" et d'interface utilisateur sont communs a tous les logiciels. Ils ne sont pas propres au domaine des collecticiels. Par suite, le trait caracteristique des collecticiels, d'apres ce modele, est le modele de coordination. Or la fonction de coordination telle qu'elle est denie ci- dessus est une fonction de base dans toute application ou systeme multi-processus. C'est le cas par exemple des environnements integres pour le developpement de logiciels. En fait, nous pou- vons considerer une telle application comme un collecticiel atypique ou un seul utilisateur humain (le programmeur) coopere avec des agents logiciels (editeur, compilateur, debouggeur) pour accomplir une t^ache donnee (le developpement d'un logiciel). C'est sans doute le raisonnement qui a conduit Ellis et Wainer a ajouter la classe agent dans leur classication fonctionnelle [Ellis et al.94a] (voir 2.2.1). En raison de la specicite evidente du travail en groupe, nous suggerons d'exclure du domaine du TCAO toute application faisant intervenir des groupes atypiques composes d'un seul individu. Ceci n'exclut pas la possibilite que l'en- semble d'acteurs dans un collecticiel soit compose d'un groupe hybride d'acteurs : acteurs humains et autres logiciels. Un deuxieme exemple de denition par analyse de composants est le modele du tre e propose par le groupe francais de travail Scoop du p^ole de recherche centree sur la communication homme machine 5. Le modele du tre e decompose un collecticiel en trois espaces que nous citons les denitions telles qu'elles sont donnees dans [Salber95] : L'espace de production designe les objets qui resultent d'une activite de groupe. Il decrit les concepts qui motivent l'action de groupe et qui denotent l'uvre commun mais aussi l'espace prive de chaque utilisateur comme dans un systeme mono-utilisateur. L'espace de coordination denit les acteurs notamment les individus, les groupes, les r^oles, voire des agents logiciels intelligents, identie les activites et les t^aches (notamment leurs relations temporelles), designe enn les acteurs responsables des t^aches et des activites. Tandis que l'espace de production ore une vue statique du systeme, l'espace de coordination en denit la dynamique. 5 http://iihm.imag.fr/scoop/ 2.2 Denitions et classications 23 L'espace de communication fournit aux acteurs du systeme la possibilite d'echan- ger de l'information. Le contenu semantique de cette information concerne les acteurs communicants. Il est etranger au systeme qui se contente de servir de messager. Cette decomposition a le merite de rendre explicite l'aspect de communica- tion directe entre les utilisateurs ; l'essence de toute activite de groupe. Les trois espaces cites ci-dessus sont presents dans tout collecticiel m^eme s'ils sont accen- tues dieremment par les dierents collecticiels (par exemple, une application de messagerie electronique met l'accent sur l'espace de communication tandis qu'une application d'edition cooperative met l'accent sur l'espace de la production). Par suite, le tre e donne une denition generale d'une application de TCAO sans denir de classes de collecticiels. 2.2.3 Denition par analyse de la communication La communication est a la base de toute activite de groupe. Une classi- cation classique des collecticiels est fondee sur les caracteristiques du lien de communication employe. Deux criteres fondamentaux caracterisent un lien de communication : 1. L'espace qui separe les personnes communicantes. Ces dernieres peuvent ^etre au m^eme endroit physique ou geographiquement eloignees. 2. Le mode de communication qui peut ^etre synchrone ou asynchrone. Dans le premier cas toute action pertinente faite par un utilisateur est transmise immediatement aux autres tandis que dans le deuxieme cas la transmission des actions d'un utilisateur est contraint a respecter certaines regles (par exemple, avoir la conrmation explicite de l'utilisateur lui m^eme). Par consequent, quatre classes de collecticiels peuvent ^etre identiees (voir gure 2.1). Grundin ane la classication precedente en introduisant la notion de l'imprevisibilite sur les deux axes. Un travail cooperatif peut avoir lieu en m^eme temps a des instants previsibles ou non. De m^eme, il peut se faire a des endroits distincts previsibles ou non (cas d'emploi des postes de travail mobiles). En pratique le m^eme collecticiel doit satisfaire les quatre types de coopera- tion illustres a la gure (2.1). Pour justier ceci prenons l'exemple de la redaction commune d'un document. Une telle activite passe par au moins trois phases : 1) Discussion et elaboration du plan du document et attribution des r^oles aux co- auteurs, 2) Redaction des dierentes parties du document et 3) Correction du document. Les deux phases 1 et 3 necessitent souvent des communications syn- chrones, tandis qu'il est opportun d'eectuer la phase 2 d'une maniere asynchrone [Nastos92]. De m^eme les redacteurs doivent pouvoir continuer a cooperer qu'ils soient dans le m^eme local physique ou geographiquement distribues. 24 Le TCAO, problematique et solutions Lieu Téléconférence Édition coopérative Différent Ex. GroupKit [Roseman92] Ex. Alliance [Decouchant94] Salle de réunions Même Ex. CourtYard [Tani94] Même Différent Temps Fig. 2.1 - : Classication espace-temps des collecticiels. 2.2.4 Synthese Les dierentes denitions presentees ci-dessus montrent que les collecticiels forment une sous-classe de la classe des applications multi-utilisateurs. A la dif- ference des applications multi-utilisateurs classiques telles que les bases de don- nees, les collecticiels ont la particularite de rendre chaque utilisateur conscient de l'existence des autres dans le systeme (propagation synchrone ou asynchrone des actions). Nous disons que les collecticiels sont des applications multi-utilisateurs non-transparentes. Comme le montre le modele du tre e (section 2.2.2), trois principales fonctions caracterisent le fonctionnement d'un collecticiel : La fonction de communication dont la t^ache est de permettre le transfert et l'echange directe de connaissances entre les individus cooperants. La fonction de partage est fondee sur le partage d'un espace d'information commun. La fonction de coordination denit les regles d'interaction entre les utilisa- teurs et entre les utilisateurs et l'espace d'information partage. Nous proposons dans la suite une nouvelle classication de collecticiels fondee sur la nature de l'entite contr^ole par le systeme. Trois types de collecticiels sont identies : Les collecticiels a immersion ou le systeme contr^ole les utilisateurs (ou la communication directe entre les utilisateurs). Ces collecticiels implantent des extensions virtuelles de l'espace physique. Un premier exemple est consti- tue par les applications de mediaspaces permanents [Dourish95b]. D'autres exemples sont les applications des mondes virtuels [Palanque et al.95] et les 2.2 Denitions et classications 25 applications de realite augmentee pour les groupes. La mise en uvre des collecticiels a immersion pose de nombreux problemes au niveau de la pro- tection de la vie privee et de l'expression de droits d'acces [Salber et al.95, Dourish95b]. Les collecticiels proc eduraux ou le systeme contr^ole la communication et l'acheminement des connaissances entre les utilisateurs. Dans ce type de col- lecticiels les interactions possibles entre les utilisateurs sont connues et xees a l'avance. Les collecticiels proceduraux couvrent des domaines de travail dont les regles sont bien etablies. La plupart des exemples de ce type d'ap- plications sont developpes dans le domaine de l'automatisation du bureau comme le systeme OM-1 [Ishii et al.91] et le systeme OTM [Lochovsky et al.88]. Les collecticiels contractuels dans lesquels les interactions entre les utilisa- teurs sont imprevisibles et ou la participation d'un utilisateur a une activite cooperative est precedee par un contrat (description du but et des politiques de contr^ole et d'interaction a employer). Le contrat peut ^etre explicite ou implicite. Le lancement d'une activite cooperative par invitation est un exemple de contrat explicite tandis que le lancement d'une activite suite a un acces simultane a un document partage est un exemple de contrat im- plicite [Edwards94]. Les applications d'edition cooperative, d'apprentissage assiste par ordinateur ou de teleconference sont des exemples des collecti- ciels contractuels. Systèmes multiutilisateurs transparents Ex. Base de données Contractuel Ex. Éditeur partagé Procédural À immersion Ex. Flux de travail Ex. Médiaspace Applications de TCAO Systèmes multi-utilisateurs Fig. 2.2 - : Classes d'applications multi-utilisateurs. Il est a noter que les dierents types de collecticiels font appel aux m^emes me- canismes de base. Leurs dierences resident dans la politique d'exploitation de ces mecanismes. Par exemple, une application de mediaspace et une application d'edition cooperative font usage d'un canal multimedias temps reel pour assurer la communication entre les utilisateurs. Tandis que le demarrage d'une commu- nication multimedias est liee a l'edition d'un document dans l'editeur cooperatif, 26 Le TCAO, problematique et solutions celui-ci est fait automatiquement lorsque deux ou plusieurs utilisateurs se croisent dans le mediaspace. Les besoins en termes de contr^ole ne sont evidement pas les m^emes dans les deux cas. Nous nous interessons dans la suite de ce travail aux collecticiels contractuels qui representent pour nous le cas le plus general des applications cooperatives. En fait, un collecticiel procedural est, par nature, dedie a une organisation ou a un type d'organisations precis (il implante des regles d'interaction gees a l'avance selon le modele de l'organisation). De son c^ote, un collecticiel a immersion est avant tout une application qui favorisent les communications interpersonnelles non planiees. De ce point de vue ce type de d'applications peut ^etre considere comme un cas particulier de la classe des collecticiels contractuels. 2.3 Criteres d'etudes : fonctions de contr^ole Nous presentons dans ce chapitre une etude d'identication des servives qu'une plate-forme exemplaire pour le TCAO doit fournir pour resoudre deux problemes fondamentaux qui sont : 1. La participation a une activite cooperative. 2. La coordination des contributions des utilisateurs au sein d'une activite. Dans l'annexe B. nous presentons une etude plus generale pour l'identication des services requis pour le TCAO. 2.3.1 La participation a une activite cooperative Nous decomposons la procedure de la participation d'un utilisateur a une activite de groupe en trois phases : 1. La phase de l'information pendant laquelle l'utilisateur prend conscience de l'existence de l'activite. 2. La phase de l'enregistrement dont le debut est marque par la mani- festation de l'inter^et de l'utilisateur a rejoindre l'activite en question. Elle se termine par l'autorisation ou le refus de la participation de cet utilisateur. 3. La phase de l'integration pendant laquelle l'utilisateur prend posses- sion des ressources qui lui faut (donnees, droits, applications) pour pleine- ment participer au deroulement de l'activite. Un exemple qui illustre cette decomposition est la procedure classique de la participation a une conference scientique. La phase de l'information correspond a la diusion d'appel aux communications, la phase de l'enregistrement correspond a la soumission d'un article a la comite de programme de la conference et la phase 2.3 Criteres d'etudes : fonctions de contr^ole 27 de l'integration correspond au deplacement vers le lieu de la conference et la presentation du papier soumis. La derniere phase est subordonnee a l'acceptation par la comite de programme de l'article soumis. La mise en uvre des trois phases denies ci-dessus repose sur la realisa- tion des trois services que nous appelons respectivement, service de rendez-vous, service d'enregistrement et service d'integration. Nous presentons dans la suite chacun des services cites ci-dessus. 2.3.1.1 Service de rendez-vous Il s'agit de fournir un mecanisme qui permet aux utilisateurs de se rencontrer et de demarrer de nouvelles activites cooperatives. Nous distinguons deux prin- cipales approches de gestion de rendez-vous ; l'approche explicite et l'approche implicite. Selon l'approche explicite un utilisateur se charge de designer les parti- cipants potentiels a l'activite. La designation des utilisateurs peut ^etre directe ou indirecte. De m^eme les utilisateurs designes peuvent ^etre noties par la creation d'une activite d'une maniere directe ou indirecte. La notication directe corres- pond a la reception automatique de l'evenement (par exemple reception d'un courrier). Dans le deuxieme cas il faut que l'utilisateur lui-m^eme consulte un serveur specique pour trouver les activites qui lui concernent. Selon l'approche implicite le systeme se charge de detecter les situations pos- sibles de cooperation. Par exemple le systeme peut proposer a deux utilisateurs qui emploient le m^eme document (en m^eme temps) de cooperer ensemble sur l'edition de ce document [Benford et al.95]. C'est le cas du systeme Intermizzo qui propose un service sophistique pour la gestion implicite de rendez-vous ; le systeme maintient une base de description des activites (individuelles ou coope- ratives) actuelles de chacun des utilisateurs du systeme. Les descripteurs des activites sont examines systematiquement dans le but de detecter des eventuelles recouvrements entre les objectifs de deux activites isolees l'une de l'autre. Lors- qu'un tel recouvrement est detecte le systeme propose aux utilisateurs concernes de fusionner leurs activites en une seule activite cooperative. Pour aider le sys- teme a prendre les bonnes initiatives chaque utilisateur peut indiquer au systeme, sous forme de regles d'interaction, sa disponibilite a la cooperation. Par exemple un doctorant qui redige son memoire de these peut specier la regle suivante : Que personne ne me derange sauf mon tuteur !!. Le systeme integre une base organisationnelle qui contient une description des relations formelles entre les utilisateurs. Cette base permet au systeme de reconna^tre le tuteur de l'etudiant dans l'exemple precedant. L'approche explicite est adaptee a la gestion des activites formelles dont les utilisateurs ont une certaine connaissance a priori (ex. reunion d'equipe, semi- naire). En revanche, l'approche implicite favorise la cooperation non planiee ; elle simule les discussions qui peuvent ^etre generees suit a des rencontres fortuites. Par exemple une cooperation, ou disons une conversation utile, peut ^etre engagee 28 Le TCAO, problematique et solutions entre deux personnes qui se rencontrent dans le m^eme rayon d'une bibliotheque et qui s'apercoivent que tous les deux s'interessent au m^eme sujet (ils cherchent le m^eme ouvrage par exemple). Plusieurs etudes montrent que la cooperation non planiee est aussi importante pour la progression du travail dans une organisation que la cooperation planiee d'ou l'importance de supporter les deux modeles de gestion de rendez-vous. Les deux approches ont des avantages et des inconvenient inverses. En transfe- rant la responsabilite de prise de decisions pour la creation d'une activite de l'utili- sateur (approche explicite) au systeme (approche implicite) nous degageons l'uti- lisateur de la charge de gestion de rendez-vous (adresser les invitations, consulter un agenda, etc) et nous facilitons la transition entre le travail individuel et le travail en groupe. Mais en m^eme temps nous rendons la mise en uvre du ser- vice de rendez-vous plus complexe car il faut assurer au systeme un minimum d'intelligence pour que ses initiatives ne soient pas trop deplacees de point de vue des utilisateurs (interrompre systematiquement l'activite d'un utilisateur pour lui proposer de cooperer avec d'autres peut conduire l'utilisateur a ne plus utiliser le systeme). Le tableau (2.1) resume les caracteristiques des deux approches de gestion de rendez-vous. Approche explicite Approche implicite Mise en uvre Simple Complexe Nature de l'activite Formelle Informelle Surco^ut utilisateur Oui Non Integration du travail individuel Non Oui Tab. 2.1 - : Les deux approches d'implantation d'un service de rendez-vous. 2.3.1.2 Service de l'enregistrement Pour qu'un individu s'integre dans un groupe il lui faut generalement remplir certaines conditions ou avoir l'autorisation d'un ou plusieurs membres du groupe cible. L'enregistrement dans ce cas est qualie d'enregistrement supervise. A l'op- pose nous trouvons le mode d'enregistrement libre ou aucune condition n'est posee sur la participation de nouveaux utilisateurs (cas d'une reunion publique). Dans le cas de l'application d'une politique d'enregistrement supervise l'appro- bation de la participation d'un nouvel utilisateur peut ^etre faite par un autre utili- sateur ou par le systeme lui m^eme. Dans le premier cas nous parlons d'enregistrement supervise explicite tandis que dans le deuxieme cas nous parlons d'enregistrement supervise implicite. Un exemple d'une politique explicite est l'emploi d'un sys- teme de vote. L'implantation d'une politique implicite repose sur la denition de 2.3 Criteres d'etudes : fonctions de contr^ole 29 contraintes sur la participation a l'activite. Un exemple est de limiter le nombre de participants comme c'est le cas dans la plupart des jeux. Le choix de la strategie d'enregistrement depend de la nature de la t^ache a eectuer. Une plate-forme generique doit permettre l'emploi de deux strategies denies ci-dessus. 2.3.1.3 Service de l'integration La fonction principale du service de l'integration est de transmettre aux nou- veaux arrivants le contexte actuel de l'activite (la description de la conguration de l'activite : les participants, les politiques de contr^ole employees et les donnees manipulees dans l'activite). A la n de l'integration d'un utilisateur il faut que tous les participants aient la m^eme vision du contexte de l'activite. Une pro- priete centrale de la fonction d'integration est de supporter l'integration d'un utilisateur pendant le deroulement de l'activite (probleme de la participation dy- namique) [Chung et al.94, Villemur95]. L'importance de cette propriete decoule de la nature imprevisible du comportement des utilisateurs qui fait qu'une de- mande d'integration peut survenir a n'importe quel moment. 2.3.2 La coordination Le but d'un service de coordination est de fournir aux utilisateurs impliques dans une activite cooperative des mecanismes qui leur permettent de coordon- ner leurs eorts an d'atteindre les objectifs xes. Nous identions trois aspects principaux traites par un service de coordination : 1. La repartition des ta^ches consiste a denir les responsabilites de dif- ferents utilisateurs. 2. La presentation de la co-presence dont le but est de fournir a chaque participant des connaissances decrivant les interactions des autres utilisateurs avec l'espace partage. 3. La resolution des conflits dont le but est d'eviter que l'application des operations contradictoires sur un m^eme objet par deux utilisateurs dif- ferents en m^eme temps. 2.3.2.1 La repartition des t^ aches Une approche classique pour faciliter la repartition et l'assignation des res- ponsabilites dans le contexte d'une activite cooperative repose sur l'emploi du concept du r^ole fonctionnel. Un r^ole fonctionnel est une representation d'un ac- teur (utilisateur) abstrait auquel on assigne un ensemble de droits. Les droits associes a un r^ole fonctionnel denissent les actions que peuvent entreprendre 30 Le TCAO, problematique et solutions ce r^ole dans l'activite. Des exemples classiques sont les r^oles redacteur et lecteur dans une activite d'edition. Une classe particuliere des r^oles fonctionnels est constituee par les r^oles de contr^ole. Ces derniers portent sur la gestion et le contr^ole du deroulement de l'activite. L'exemple type est le r^ole du president ou du gestionnaire d'une ac- tivite. Le president est assigne la responsabilite de xer les parametres de la conguration de l'activite (le choix des politiques de contr^ole a appliquer). Plu- sieurs travaux dans le domaine du TCAO proposent des modeles dierents pour la denition et la gestion des r^oles fonctionnels [Shen et al.92, Coulouris et al.94, Smith et al.94, Kanawati95]. Ces dierentes etudes montrent que les proprietes suivantes sont requises d'un systeme de gestion de r^oles : Expression de droits en termes d'operations possibles sur les objets manipu- les au lieu de simples operations de lecture et l'ecriture. Plus generalement l'expression de droits d'acces doit ^etre faite a grain n (ceci concerne les trois dimensions d'une regle d'acces a savoir l'acteur, l'objet et le droit). Permettre l'attribution et le changement dynamiques des r^oles attribues aux utilisateurs. Permettre l'evolution dynamique des regles d'acces associes a un r^ole. 2.3.2.2 La presentation de la co-presence Dans le contexte d'une activite cooperative, avoir des connaissances sur les contributions, les attributions, les positions et les interactions des autres avec l'es- pace partage est une condition necessaire pour qu'un utilisateur puisse planier ses propres actions et ses propres contributions. Fournir les renseignements cites ci-dessus est la fonction du service de la presentation de la co-presence. Curieu- sement, l'analyse des besoins et des approches de presentation de la co-presence est souvent occulte ou partiellement traite dans la litterature du TCAO. Peu de travaux ont traite ce sujet pourtant d'importance capitale. Pour cela nous etu- dions dans la suite ce service en plus de detail que nous le faisons pour les autres services. Un service de presentation de la co-presence permet a chaque participant de repondre aux questions suivantes [Karsenty94b, Gutwin et al.96] : Qui sommes-nous? Autrement dit, un utilisateur doit ^etre informe des noms et des attributions des participants actuels et potentiels (enregistres et/ou invites) a l'activite. Ou sommes-nous? Cette question comprend deux volets que nous represen- tons par les deux questions suivantes qu'un utilisateur peut poser : 1. Ou suis-je par rapport aux autres ? Il s'agit de montrer les positions des autres utilisateurs dans l'espace partage. Par exemple dans une 2.3 Criteres d'etudes : fonctions de contr^ole 31 activite d'edition il faut montrer les sections et les paragraphes edites par chacun des participants. Un outil largement employe pour donner ce genre d'information est le bar de delement multi-ascenseurs (un ascenseur par utilisateur). 2. Ou sont les autres ? Il s'agit de montrer comment les autres percoi- vent l'espace partage. Pouvoir voir ce que les autres voient permet de comprendre leurs commentaires. Une experimentation d'un collecticiel synchrone d'aide a la decoration des pieces (en trois dimensions) a montre que les participants emploient frequemment dans leurs com- munications orales des mots deictiques (par exemple eaces-moi cet objet, bouger vers le droit, approches ici..,etc) [Shu et al.94]. Avoir une fonction qui permet de voir ce qu'un autre voit permet de mieux comprendre ce qu'il veux dire. Une extension de la fonction precedente consiste a fournir une fonction miroir qui permet a un utilisateur de voir comment un autre utilisateur le percoit. Que faisons-nous? Et que pouvons-nous faire? Le premier volet de cette ques- tion concerne la notication de chaque participant des actions faites par les autres dans l'espace partage. La notication peut prendre deux formes : 1. Propager dans la session les actions faites par un participant. Deux politiques de propagation d'actions peuvent ^etre employees : la pro- pagation synchrone et la propagation asynchrone. Les deux modes de propagation peuvent ^etre employes simultanement ou alternativement dans une m^eme session [Nastos92]. 2. Decrire la nature des actions faites par chaque participant sans re- jouer les actions elles-m^emes. Cette approche convient pour les si- tuations de cooperation asynchrone. Une solution souvent emprun- tee pour mettre en uvre cette approche consiste a employer des ic^ones speciales comme c'est le cas de l'editeur cooperatif Alliance [Decouchant et al.96]. La deuxieme question concerne la visualisation des limites d'action de chaque utilisateur en fonction de l'etat actuel de l'exploitation de l'espace partage et en fonction des privileges attribues a cet utilisateur. Un exemple est de montrer les zones de l'espace verrouillees par les autres utilisateurs. Comment sommes-nous arrive ici? Il s'agit de presenter l'historique de l'evo- lution de l'uvre commun. Avoir acces a l'historique de l'activite sert d'une part a xer les responsabilites (qui a fait quoi?) et en consequence mieux equilibrer le delicat rapport eort fourni / gain individuel apporte par l'em- ploi du collecticiel. D'autre part, l'historique permet a un utilisateur qui rejoint une session (qu'elle soit synchrone ou asynchrone) de mieux com- prendre son evolution an de mieux re echir ses propres contributions. 32 Le TCAO, problematique et solutions La mise en uvre des mecanismes repondant aux diverses questions prece- dentes est sujet a plusieurs contraintes que nous regroupons sous la forme de trois principes : 1. Le principe du collecte passifselon lequel il faut eviter d'impliquer les utili- sateurs dans le processus du collecte et de la distribution des informations decrivant la co-presence [Dourish et al.92]. 2. Le principe de la non-distraction complemente le premier principe dans le sens ou la presentation de la co-presence ne doit pas distraire les utilisa- teurs de leurs t^aches. Dans cette m^eme optique Dourish et Bellotti suggerent dans [Dourish et al.92] que la presentation de la co-presence doit prendre lieu dans le m^eme espace visuel occupe par l'uvre commun. Au contraire, d'autres travaux concluent que peu importe la zone d'achage pourvue que l'interpretation des informations de la co-presence soit facile voire im- mediate [Tatar et al.91, Gutwin et al.96]. Certains constructeurs des col- lecticiels ont opte vers l'emploi des eets sonores speciaux pour decrire la co-presence. Le principe est d'associer des sons signicatifs aux dierentes operations fournies par le collecticiel. Par exemple jouer le son d'ouver- ture d'une porte pour annoncer l'arrivee d'un nouvel participant et jouer le son de glisse pour decrire une operation de deplacement d'un objet. Nous pensons que l'emploi des sons doit ^etre limite a la representation des actes plut^ot rares comme l'arrivee et le depart des utilisateurs ou l'ouverture d'un nouveau document. La transcription sonore de toute action peut generer un vacarme peu informatif. 3. Le principe de la non-interference fonctionnelleselon lequel les outils de la presentation de la co-presence ne doivent pas aecter les fonctions propres du collecticiel. Par exemple plusieurs travaux emploient les couleurs pour identier les participants et leur actions comme c'est le cas dans GroupDe- sign [Karsenty94a] , ceci implique que l'application elle-m^eme ne peut plus manipuler des objets couloures sinon les utilisateurs seront confus. Une diculte majeur que rencontrent les constructeurs des collecticiels est l'absence de metrique pour evaluer la conformite de leurs realisations aux prin- cipes cites ci-dessus. Peu de travaux ont aborde le probleme complexe de l'eva- luation de l'utilite des mecanismes de la co-presence. Ceci constitue a notre avis un axe important de recherche dans le domaine de construction de collecticiels. 2.3.2.3 La resolution de con its L'existence d'un service de presentation de la co-presence, aussi complet qu'il soit t-il, n'elimine pas le risque d'acces concurrents a un m^eme objet de l'espace partage. Des protocoles de gestion de la concurrence doivent ^etre prevus. Dans 2.3 Criteres d'etudes : fonctions de contr^ole 33 [Greenberg et al.94], les auteurs montrent qu'il n'existe pas une politique qui soit compatible avec tous les besoins des collecticiels. Une plate-forme doit fournir une variete de protocoles de gestion de la concurrence. Nous etudions ce probleme en details dans le chapitre (4). 2.3.3 Synthese Nous resumons dans cette section les services identies a l'issue de notre etude des deux problemes de la participation et de la coordination dans les activites cooperatives. Services requis pour la participation Implanter les deux strategies de gestion de rendez-vous : explicite et impli- cite. Permettre le passage souple entre les deux modes de travail individuel et en groupe. Implanter les deux strategies d'enregistrement : libre et supervise (implicite ou explicite) Permettre la participation dynamique de nouvel arrivants ainsi que les de- parts anticipes. Services requis pour la coordination Fournir un service de denition et de gestion de r^oles fonctionnels. Supporter les deux types d'interaction : synchrone et asynchrone. Implanter un service de presentation de la co-presence. Ce service doit cou- vrir les quatre aspects de la description de la co-presence (Qui? Ou? Quoi? et Comment?) Implanter des strategies variees de gestion de la concurrence. A l'ensemble des fonctions citees ci-dessus s'ajoutent les deux fonctions gene- rales suivantes (voir annexe B) : Permettre le changement dynamique de la conguration des activites. Permettre l'evolution future des fonctions oertes. Nous nous servons des fonctions citees ci-dessus pour evaluer fonctionnelle- ment les dierentes plates-formes pour le TCAO proposees dans la litterature. Avant, nous presentons dans la section suivante une nouvelle classication des approches de construction de ces plates-formes. 34 Le TCAO, problematique et solutions 2.4 Classication de plates-formes pour le TCAO Nous proposons dans cette section une classication de plates-formes pour le TCAO fondee sur les trois criteres suivants (voir gure 2.3): 1. Le niveau du support de la cooperation qui peut ^etre au niveau de l'inter- face homme-machine, au niveau des donnees manipulees ou au niveau du support de la communication. 2. Le schema de mise en uvre qui peut ^etre centralise, distribue ou hybride. 3. La nature des applications supportees. Une plate-forme peut supporter le developpement de nouvelles applications ou la reutilisation d'applications existantes. IHM Niveau du Nouvelles Applications Visées Support Communication Plate forme Pour Collecticiels Existantes Données Centralisée Distribuée Hybride Schéma de mise en œuvre Fig. 2.3 - : Classication des plates-formes pour la construction de collecticiels. 2.4.1 Niveau du support Niveau de l'interface homme-machine Il s'agit de concevoir un systeme de gestion d'interfaces-utilisateurs qui prend en compte les aspects du travail en groupe (presentation de la co-presence, coordination, communication et partage). Cette approche repose sur l'implantation d'une couche logicielle qui intercepte les interactions d'un utilisateur avec l'interface homme-machine d'une application et de reprdouir ces interactions sur les interfaces-utilisateurs des autres. Ainsi cette approche concoit un collecticiel comme une application partagee entre plusieurs utilisateurs. Le partage d'une application sous entends que les utilisateurs sont tous presents ensemble en m^eme temps dans l'espace de l'application. L'interac- tion entre les utilisateurs peut ^etre synchrone ou asynchrone selon la strategie de la diusion des evenements interceptes. Plusieurs approches sont possibles pour construire une application partagee. Pour les comprendre nous commencons par rappeler la structuration d'une ap- 2.4 Classication de plates-formes pour le TCAO 35 plication interactive mono-utilisateur. Une decomposition classique d'une appli- cation interactive separe celle-ci en deux modules [Coutaz90] : 1. Le module de presentation gere l'interaction de l'utilisateur avec l'applica- tion. 2. Le noyau fonctionnel implante les fonctions propres de l'application. Il gere les donnees manipules par l'application. Le module de la presentation est decompose a son tour en deux sous mo- dules : le pilote et le gestionnaire. Le pilote se charge d'interagir avec les unites d'entrees/sorties de l'ordinateur (clavier, ecran, souris, , etc). Le ux d'entree ::: est traite par le gestionnaire qui possede une description de l'interface-utilisateur de l'application qui lui permet d'interpreter les sequences d'evenements bas ni- veau captes et de les synthetiser en commandes applicatives. Par exemple un clic souris dans une zone de l'ecran ou se trouve un bouton est interprete d'^etre une commande d'activation de ce bouton ; la connaissance employee par le gestion- naire pour interpreter cette commande est simplement la position du bouton et la surface qu'il occupe sur l'ecran. Présentation Utilisateurs Noyau a) Décomposition d’une Pilote Gestionnaire Fonctionnel application interactive Présentation b) Implantation bas niveau Utilisateurs Noyau Pilote Gestionnaire d’un SGIG Fonctionnel Ex. XTV [AW 96] Présentation c) Implantation haut niveau Utilisateurs Noyau d’un SGIG. Pilote Gestionnaire Fonctionnel Ex. Sol [Smith et al. 94] SGIG : Système de Gestion d’Interface pour les Groupes. Fig. 2.4 - : Construction de collecticiels par partage d'applications. La gure (2.4.a) illustre la structuration d'une application interactive. Les deux gures (2.4.b) et (2.4.c) illustrent les deux principales approches de construc- tion d'applications partagees. La premiere approche dite bas niveau consiste a intercepter le ux d'entree produit par chaque utilisateur et de le diuser aux autres utilisateurs. La deuxieme approche dite haut niveau consiste a diuser les commandes produites par le gestionnaire. 36 Le TCAO, problematique et solutions Niveau de donnees Selon cette approche les fonctions de la cooperation sont rattachees directement aux primitives de manipulation de donnees. Le principe est de construire des bases de stockage de donnees (ou de documents) partagees entre les utilisateurs du systeme. A chaque utilisateur est associee une vue sur la base partagee. Une vue denit les informations disponibles pour l'utilisateur et les fonctions que ce dernier peut appliquer sur ces informations. Lorsqu'un utili- sateur modie un objet qui appartient a la vue d'un autre utilisateur ce dernier sera averti. Les utilisateurs ne sont pas forcement co-presents en m^eme temps dans l'espace partage. Une premiere approche de mise en uvre de la coope- ration par partage de donnees consiste a implanter un serveur partage ou les utilisateurs peuvent deposer et retirer de l'information. Un tel serveur est dote generalement des mecanismes de presentation de la co-presence des utilisateurs. Un exemple est l'application BCSW [Bentley et al.97]. Une deuxieme approche consiste a faire propager les modications apportees a un objet a tous les utilisa- teurs qui posedent cet objet comme c'est le cas dans GroupDesign [Karsenty94b] et CoopScan [Balter et al.96b]. Niveau de la communication Cette approche repose sur l'elaboration de mecanismes de contr^ole du routage de l'information au sein d'un groupe d'utili- sateurs. Il s'agit de fournir un service de messagerie evolue qui permet d'adresser un message a des groupes d'utilisateurs, specier la maniere d'acheminement d'un message (ex. diusion, envoi d'une maniere sequentielle, ), attacher des ::: reactions a la reception d'un type de messages, etc. Cette approche implante un modele d'interaction asynchrone. Des exemples qui illustrent cette approche sont : Messie [Sasse et al.96] et ActiveMail [Goldberg et al.92] qui sont tous les deux fondes sur l'extension du courrier electronique (e-mail). 2.4.2 Schema de mise en uvre Tout collecticiel peut ^etre decompose en trois modules : la presentation, le noyau fonctionnel et le module de contr^ole [Balter et al.96a]. Le r^ole de ce dernier est de gerer la cooperation entre les utilisateurs. Parmi les fonctions du module de contr^ole nous retrouvons les fonctions de gestion de groupe, la gestion des acces concurrents aux donnees partagees et la gestion des r^oles des utilisateurs. Le schema de mise en uvre d'un collecticiel decrit le schema de la reparti- tion de dierents modules identies ci-dessus entre les sites participants. Dans le cas general, un exemplaire de l'unite de presentation graphique est duplique sur chaque site. Par consequent, le type de l'architecture d'un collecticiel depend du schema de la repartition des deux modules restant : le noyau fonctionnel et le mo- dule de contr^ole. Chacun de ces deux modules peut ^etre implante d'une maniere centralisee ou dupliquee. Ceci nous laisse le choix entre trois types d'architectures possibles : centralisee, dupliquee et hybride. 2.4 Classication de plates-formes pour le TCAO 37 Unité de Noyau Présentation Fonctionnel Graphique Contrôle Pour la Coopération Fig. 2.5 - : Decomposition modulaire d'un collecticiel. L'architecture centralisee selon laquelle une seule instance du noyau fonc- tionnel et une autre du module de contr^ole sont executees sur un site central. Des exemples de plates-formes a architecture centralisee sont les plates-formes XTV [AW96] et Rendez-vous [Patterson et al.90]. Un inconvenient majeur de cette architecture est sa vulnerabilite (la de- faillance ou l'isolation du site central entra^ne l'arr^et du systeme). Un deuxieme inconvenient est le trac reseau important (en nombre et en volume de mes- sages) qu'elle induit puisque toutes les commandes utilisateurs et leurs resultats (y compris l'achage des resultats) sont vehicules a travers le reseau. Des etudes de comparaison de cette architecture avec l'architecture dupliquee sont presentees dans [Balter et al.96a, Crowley et al.90]. L'architecture totalement dupliquee selon laquelle chaque site execute une instance du noyau fonctionnel et une autre du module de contr^ole. Des exemples sont CoopScan [Balter et al.96b], MMconf [Crowley et al.90] et GroupKit [Roseman et al.92]. Cette architecture resout les problemes de la centralisation. Cependant elle ne- cessite d'elaborer des politiques de contr^ole de la concurrence et de gestion de la coherence de donnees plus complexes que dans le cas de l'architecture centralisee (voir chapitre 4). L'architecture hybride repose sur la combinaison des deux architectures de- nies ci-dessus. Par exemple une architecture hybride peut consister a avoir une seule instance du noyau fonctionnel et des modules de contr^ole dupliques. C'est le cas par exemple de l'architecture MEAD [Bentely et al.92b]. Une autre realisa- tion d'une architecture hybride consiste a repartir les ressources d'un collecticiel sur les sites participants. Un exemple est le modele d'architecture a serveurs dupliques propose dans [Cortes et al.95]. 38 Le TCAO, problematique et solutions 2.4.3 Nature des applications supportees Une plate-forme peut supporter la construction de nouvelles applications comme c'est le cas de GroupKit [Roseman et al.92] et Sol [Smith et al.94] ou la transformation d'applications existantes en applications cooperatives comme c'est le cas de XTV [AW96] et CoopScan [Balter et al.96a]. La transformation d'applications existantes peut ^etre faite avec ou sans modication de code source. Dans le premier cas (transformation avec modication de code) nous parlons de construction par adaptation [Knister et al.93] tandis que dans le deuxieme cas nous parlons d'integration d'applications existantes. En ce qui concerne l'integra- tion, deux grandes approches sont possibles 1) l'integration au niveau du systeme de fen^etres et 2) l'integration au niveau de l'application [Benatallah et al.94]. Integration au niveau de systeme de fen^etres. Pour illustrer cette ap- proche prenons l'exemple concret des applications qui s'executent sous le systeme de fen^etres X-Window. X-Window implante un modele client-serveur ; une appli- cation X, dite aussi client X, delegue la gestion de son interface utilisateur a un serveur d'achage : le serveur X. Le client et le serveur communiquent entre eux par le biais d'un canal d'achage. Canal d’affichage Serveur X Client X Fig. 2.6 - : Le modele client-serveur du systeme de fen^etres X-Window. La communication a travers le canal d'achage est regie par le protocole de communication X. Celui-ci decrit le format logique (les structures de donnees) et la signication des messages echanges dans les deux sens sur le canal d'a- chage. Deux types de messages sont denis par le protocole X : les requ^etes et les evenements, emis respectivement par le client et par le serveur. Le principe de transformation d'une application X en collecticiel consiste a intercaler un pseudo-serveur entre le client (l'application a transformer) et le ser- veurX. Le pseudo-serveur se comporte comme un client X vis a vis des serveurs X et en tant que serveur vis a vis des clients. Ainsi il joue le r^ole de demulti- plexeur pour transmettre les requ^etes d'achage aux dierents serveurs et pour transmettre les evenements d'entree au(x) client(s). Ce schema d'integration est valide pour toute application X. Une fois le pseudo-serveur est mis en place les utilisateurs peuvent partager toutes les ap- plications X qui leurs sont disponibles. Toute la diculte reside donc dans la construction et la mise en uvre du pseudo-serveur. Une etude detaillee de l'im- plantation d'un pseudo-serveur est presentee dans [AW96]. La mise en uvre 2.4 Classication de plates-formes pour le TCAO 39 d'une plate-forme d'extension d'un systeme de fen^etres peut ^etre faite d'une ma- niere centralisee ou dupliquee. Des exemples d'implantation centralisee sont la plate-forme XTV [AW96] et Shared X [Gust88]. MMconf est un exemple d'une implantation dupliquee [Crowley et al.90]. Serveur X Serveur X Client X Pseudo-Serveur Serveur X Fig. 2.7 - : L'architecture de la plate-forme XTV Integration au niveau de l'application. Cette approche est restreinte aux applications dites ouvertes. Une application est ouverte si elle verie les deux conditions suivantes : Fournir a son environnement d'execution une interface de programmation (API) qui permet a des modules logiciels exterieurs a l'application d'acceder aux ressources de celle-ci et de reproduire les m^emes actions qu'on peut eectuer a travers son interface-utilisateur. Fournir a son environnement d'execution un systeme de notication (Call- back). Ce systeme donne la possibilite a des modules logiciels exterieurs d'^etre avertis des tentatives d'actions faites a travers l'interface-utilisateur. Un exemple d'une application ouverte est l'editeur Thot [Quint et al.94] et l'ap- plication GraphWidget [BL91]. Pour illustrer l'approche de l'integration au niveau de l'application nous decrivons dans la suite notre experience de la transformation de Thot en editeur cooperatif synchrone [Balter et al.96b]. Le systeme de noti- cation fourni par Thot, nomme ECF pour External Call Facility, genere deux types d'evenements : 1. Les evenements de type Pre qui precedent l'execution eective d'une action commandee via l'interface utilisateur. Un evenement Pre specie la nature de la commande demandee (ex. modication, suppression, insertion) mais pas les parametres de la commande (qui ne sont pas encore connus). 40 Le TCAO, problematique et solutions 2. Les evenements de type Post produits apres l'execution d'une commande. Un evenement Post decrit tous les parametres de l'action accomplie : na- ture, element cible et modication apportee. Un langage specique, appele le langage I, permet d'associer des reactions aux evenements produits. Les reactions sont des fonctions C. Dans le cas des eve- nements Pre les reactions sont obligatoirement de type booleen dont la valeur est True si la reaction remplace le traitement standard de l'editeur. La transfor- mation du Thot en editeur cooperatif synchrone est faite de la facon suivante. Chaque site participant a une session d'edition execute une copie de l'editeur et une copie de module de contr^ole ; l'architecture est donc completement dupli- quee. Lorsqu'un utilisateur applique une commande via l'interface utilisateur, un evenement Pre decrivant la commande est intercepte par le module de contr^ole. Ce dernier permet l'execution locale de l'operation si celle-ci est une operation a eet exclusivement local (comme par exemple le sauvegarde du document) ou bien si le site local detient le droit de parole. Dans le cas contraire le module de contr^ole emp^eche l'execution de l'operation, en retournant a l'editeur la valeur booleen True. L'algorithme suivant montre la reaction du module de contr^ole aux evenements Pre. Algorithme 2.1 Reaction aux evenements Pre; Soit Op l'operation decrite par l'evenement intercepte; Si (Op est locale) Ou (je suis le detenteur de droit de parole) Alors Executer localement Op; // Un evenement Post va ^etre genere Sinon Emp^echer l'execution de Op; L'execution d'une operation est suivie par la generation d'un evenement Post. Le module de contr^ole reagit a ce type d'evenements selon l'algorithme suivant : Algorithme 2.2 Reaction aux evenements Post; Soit Op l'operation decrite par l'evenement capte; Si Op est locale Alors Exit; Sinon Diuser l'operation a tous les autres sites; Adaptation d'applications. Une approche generale pour adapter des appli- cations existantes en vue de les transformer en collecticiels consiste a proceder en deux etapes : 1. Fournir une bibliotheque de fonctions de gestion de la cooperation dont le code est independant des applications cibles. 2.4 Classication de plates-formes pour le TCAO 41 2. Developper pour chaque application a adapter un module specique qui fait la liaison entre les fonctions de l'application et la bibliotheque de gestion de la cooperation. Cette approche suppose que le code source de l'application est disponible. La diculte principale reside dans l'analyse du code des applications existantes an de localiser les points ou il faut inserer les appels aux primitives de la bibliotheque. Des exemples de cette approche sont la plate-forme CoEx [Patel et al.93] et la plate-forme ConferenceToolKit [Bonglio et al.91]. Des applications dierentes requierent des eorts dierents de transformation. L'experience de CoEx montre que les applications construites d'une maniere mo- dulaire avec une separation nette entre le noyau fonctionnel et le module de l'interface-utilisateur sont les applications les plus faciles a transformer. Le ta- bleau (2.2) montre que l'adaptation des applications est plut^ot une operation non-co^uteuse. Les trois chires representent respectivement le nombre de lignes de code initial, modies et ajoutes. Application Code initial Code modie Code ajoute Editeur de texte (sted) 500 100 300 Editeur de dessin (idraw) 19,000 700 800 Tableau de calcul 119,000 1,000 2,000 Tab. 2.2 - : Modication et ajout de code necessaires pour l'adaptation d'appli- cations dans CoEx. La construction de collecticiels par adaptation presente l'avantage d'^etre plus souple pour la mise en uvre de protocoles de contr^ole. L'inconvenient majeur est qu'elle necessite d'avoir le code source de l'application. L'approche d'integration d'applications, au niveau de l'application ou au niveau de systeme de fen^etres, n'a pas cette limitation. La dierence principale entre les deux approches d'integra- tion d'applications reside dans le niveau semantique des evenements manipules. Dans le cas de l'integration au niveau de systeme de fen^etres les evenements sont des evenements de bas niveau semantique, tandis que dans l'integration au ni- veau de l'application les evenements sont d'un niveau semantique eleve : insertion d'une texte, application d'une commande. L'approche d'integration au niveau du systeme de fen^etres presente l'avantage d'^etre independant des applications a integrer. La construction du module de contr^ole, dans ce cas, depend exclusivement du systeme de fen^etres en question. Les objets manipules selon cette approche sont de bas niveau : ecran, fen^etres et pixels. Ceci implique le partage de tout autre objet d'un niveau semantique plus haut comme par exemple un curseur de delement. Dans [Balter et al.96a] une comparaison entre les deux approches en termes de nombre de messages vehicules 42 Le TCAO, problematique et solutions et en termes de volume de messages echanges montre que l'integration au niveau du systeme de fen^etres consomme plus de ressources (nombre de messages et bande passante du reseau) que son homologue au niveau de l'application. Le tableau (2.3) resume les caracteristiques de chacune des approches de reutilisation d'applications. Critere Int.-SF. Int.-App. Adaptation Mise en uvre Independant de l'app. Depend de l'app. Depend de l'app. Inter-operabilite Non Oui Oui Trafic reseau Eleve Moins important Moins important Code Source Non necessaire Necessaire Necessaire Application Ouvert Non necessaire Necessaire Non necessaire Tab. 2.3 - : Principales caracteristiques des approches de transformation d'ap- plications existantes en collecticiels. 2.5 Exemples Nous presentons dans la suite quelques plates-formes representatives des ap- proches de construction discutees ci-dessus. Noue mettons l'accent dans cette presentation sur la satisfaction des plates-formes retenues des services identies dans la section (2.3.3). Les plates-formes choisies sont enumerees dans le tableau suivant. Plate-forme Support Architecture Applications XTV IHM Centralisee Integration- SF Sol IHM Hybride Nouvelles GroupKit IHM-Donnees Dupliquee Nouvelles CoopScan Donnees Dupliquee Integration-App. Mead Donnees Hybride Nouvelles GroupDesign Donnees Dupliquee Integration-App. ActiveMail Communication Centralisee Nouvelles Tab. 2.4 - : Inventaire des plates-formes choisies pour l'etude de comparaison des approches de construction de plates-formes pour le TCAO. Nous analysons et justions les limitations fonctionnelles presentees par les dierentes plates-formes etudiees ici dans la section (2.6). 2.5 Exemples 43 2.5.1 XTV La plate-forme XTV supporte exclusivement la construction de collecticiels par integration d'applications existantes au niveau du systeme de fen^etres X- Window[AW96].Les collecticiels construits implantent tous un modele de coope- ration synchrone. L'architecture de mise en uvre est totalement centralisee (voir Figure 2.7). Le lancement d'une nouvelle session correspond a l'execution d'un serveur XTV sur un site central. Une session est identiee par une adresse constituee par le nom de la machine h^ote et le numero de la session (donne par l'utilisateur). Pour participer a une session un utilisateur lance un client XTV qui se connecte au serveur de la session. Pour etablir la connexion, le client doit savoir l'identi- cateur de la session a rejoindre. La diusion de l'adresse d'une session est a la charge de l'utilisateur qui la cree. Celui-ci peut notier les participants poten- tiels, directement par l'envoi d'un courrier ou par telephone, ou indirectement en enregistrant l'adresse dans un repertoire, ou un annuaire de sessions. Par suite XTV ore seulement un systeme explicite de gestion de rendez-vous. L'enregistrement est libre. Cependant un utilisateur privilegie, dit le president, a le droit de forcer la deconnexion de n'importe quel participant. Le r^ole president est automatiquement attribue a l'utilisateur qui demarre la session. Celui-ci garde ce r^ole le long de la session. La participation tardive des utilisateurs est toleree gr^ace a la mise en uvre d'un protocole de participation dynamique [Chung et al.93]. Une politique de tour de r^ole est implantee pour resoudre le probleme des acces concurrents. A chaque application integree est associe un jeton. Le passage du jeton entre les participants est fait selon la regle du premier demandeur premier servi. La gure (2.8) illustre l'interface de contr^ole de XTV. Cette interface ache d'une maniere permanente les informations suivantes : le nom du president de la session, la liste des participants et la liste des applications employees. Pour savoir qui a le droit de parole sur une application donnee, l'utilisateur doit d'abord selectionner l'application dans la liste des outils ensuite appuyer sur le bouton Floor-Info. Le nom du detenteur du jeton est alors ache dans la zone de messages systeme (en bas de la fen^etre de contr^ole). Pour avoir plus de renseignements sur un participant il sut de selectionner son nom dans la liste des participants et appuyer sur le bouton Participant-Info. Ceci a pour eet de montrer le nom et l'adresse de l'utilisateur ainsi que l'ensemble des applications qu'il utilise. Une idee interessante proposee dans XTV consiste a fournir des outils d'aide a la discussion. Dans cette optique, deux applications sont constamment a la disposition des participants a une session XTV : une application de bavardage (chatting) et une autre implantant un tableau blanc partage. Une autre idee qui vise a ameliorer la perception de l'espace partage (consti- tue par l'ensemble des applications partagees) consiste a permettre de visualiser toutes les applications partagees dans la m^eme fen^etre virtuelle. 44 Le TCAO, problematique et solutions Fig. 2.8 - : Interface-utilisateur de XTV. 2.5.2 La plate-forme SOL SOL est un environnement de construction d'interfaces de groupe. L'unite de construction est un objet d'interface dit SOLO (pour SOL object) [Smith et al.94]. Des exemples de SOLO sont un bouton, un champ texte ou n'importe quel autre objet utilise dans la construction des interfaces utilisateurs. A chaque type de SOLO est associe un nombre ni d'operations et une matrice de protection par r^ole existant. Un r^ole est simplement un groupe d'utilisateurs qui partagent les m^emes privileges. La matrice de protection comprend deux listes extensibles de droits d'acces. La premiere liste specie le droit d'utilisation des operations asso- ciees au SOLO en question. La deuxieme liste specie le partage des resultats des operations appliquees entre les dierents utilisateurs. Le tableau (2.5) presente un exemple d'une matrice de protection associe a un r^ole R sur un bouton qui fournit les operations suivantes : Appuyer, Bouger et Redimensionner. Un T ou t (respectivement un F ou f ) dans la liste d'utilisation signient que l'operation correspondante est autorisee (respectivement non autorisee). Un T ou t (respec- tivement un F ou f ) dans la liste de partage signient que les autres utilisateurs partagent (respectivement ne partagent pas) l'eet de l'execution de l'operation 2.5 Exemples 45 Op eration Utilisation Partage Appuyer T T Bouger t f Redimensionner F F Tab. 2.5 - : Exemple d'une matrice de protection d'un bouton Solo associe a un r^ole R. correspondante par un detenteur du r^ole R. Les valeurs T et F ne sont pas modi- ables par l'utilisateur contrairement aux valeurs t et f . Deux types d'interaction avec une application sont denies : Interaction supercielle : c'est le cas d'une action utilisateur qui ne necessite pas un traitement par le noyau fonctionnel de l'application. Par exemple, bouger un objet d'interface. Interaction profonde : c'est le cas d'une action qui necessite un traitement par l'application partagee. Comme par exemple l'activation d'un bouton. La gure (2.9) illustre l'architecture generale d'une application construite a l'aide du systeme SOL. L'architecture est d'hybride puisque certaines operations sont User User User Interaction de surface La plate-forme SOL Interaction profonde Noyau fonctionnel de l’application partagée Fig. 2.9 - : L'architecture de la plate-forme SOL prises en compte en local (cas d'interactions supercielles) d'autres sont executees par le noyau fonctionnel central de l'application. 46 Le TCAO, problematique et solutions 2.5.3 GroupKit L'objectif de GroupKit est de faciliter la construction des collecticiels syn- chrones [Roseman et al.96b]. La plate-forme fournit un ensemble de services pour la cooperation notamment un systeme de gestion explicite de rendez-vous, un service de communication de groupe et des widgets specialement concus pour la presentation de la co-presence comme par exemple un pointeur partage ou une barre de delement multi-ascenseurs. En revanche GroupKit ne fournit aucune politique de gestion de rendez-vous, de participation ou de resolution de con its. L'implantation des politiques de contr^ole est laissee aux constructeurs des appli- cations [Roseman et al.92]. La plate-forme est initialement concue pour la construction de nouvelles ap- plications. Or, etant developpe en langage interprete (en occurrenceTcl/TK) il est possible d'adapter des applications developpees en m^eme langage pour les rendre cooperatives. Les collecticiels construits a l'aide de GroupKit ont une ar- chitecture totalement dupliquee. Chaque execution d'un collecticiel constitue une session a part entiere. GroupKit fournit un mecanisme de gestion de sessions qui met en jeux un composant central appele registar. Le registar tient a jour une liste des sessions courantes (fonctionne comme un repertoire de sessions). Il ne gere pas les politiques qui denissent comment est creee une session ou comment un utilisateur s'enregistre et s'integre dans une session existante. A cote du registar central, il existe un registar client par utilisateur. Ce dernier permet la creation, la suppression et l'integration aux sessions existantes. 2.5.4 CoopScan CoopScan est une plate-forme generique concue pour le developpement des collecticiels synchrones [Balter et al.96b]. La plate-forme est implantee selon une architecture completement dupliquee. Elle est fondee sur l'integration d'appli- cations existantes au niveau de l'application. Aucun mecanisme de rendez-vous n'est fourni par la plate-forme. Un utilisateur qui demarre une nouvelle session previent les utilisateurs potentiels de l'adresse de la nouvelle session par un outil exterieur (courrier electronique, telephone). Deux modes de participation peuvent ^etre appliques : la participation libre et la participation supervisee. Dans le dernier mode un seul utilisateur, qui a le r^ole du president de la session, a le potentiel de parrainer de nouveaux utilisateurs. Ce m^eme utilisateur peut changer le mode de la participation pendant le deroulement de la session. Deux r^oles fonctionnels sont denis : le r^ole president et le r^ole participant. Les deux r^oles ont les m^emes droits d'acces mais le president a le privilege de determiner la conguration de la session ; c'est a dire la politique de gestion de la concurrence et le mode de participation. Il se reserve le droit de recuperer le droit de parole a n'importe quel instant. A la dierence de XTV, le president peut de- missionner au cours de la session. CoopScan implante un modele de cooperation 2.5 Exemples 47 synchrone. L'interaction est faite selon un mode WYSIWIS-rel^ache. Les partici- pants ne partagent pas forcement les m^emes applications. Lorsqu'un utilisateur lance une nouvelle application, les autres utilisateurs seront prevenues. Le choix de participer a une application est laisse aux utilisateurs eux-m^emes. La gure (2.10) montre l'interface de contr^ole d'une session CoopScan. Cette interface ache d'une maniere permanente les informations suivantes : la liste des participants, la liste des applications employees par l'utilisateur local (la liste In Tools), la liste des applications employees par les autres participants (la liste On Tools), la nom de l'actuel detenteur du droit de parole et le nom du president de la session. Fig. 2.10 - : Interface de contr^ole de CoopScan. CoopScan fournit une variete de protocoles de tour de r^ole. Un seul jeton contr^ole l'acces a toutes les applications utilisees dans une session. Le president a le potentiel de changer dynamiquement la politique de gestion de la concurrence. 48 Le TCAO, problematique et solutions 2.5.5 La plate-forme MEAD La plate-forme Mead est implantee selon une architecture hybride [Bentely et al.92b]. Un serveur central, appele Object Store Server (OSS), maintient l'ensemble des objets constituant l'espace partage. Chaque participant a une vue de l'es- pace partage presentee par un agent autonome dit User Display (UD). Chaque UD est contr^ole par un ensemble d'agents nommes User Display Agents (UDA). Un UDA denit une vue particulier sur le OSS. Une vue comprend un ensemble d'objets, des methodes de presentation de ces objets et des operations sur les ob- jets. Deux UDA peuvent avoir des objets en commun mais ils peuvent les presenter dieremment et permettre d'appliquer des operations dierentes sur eux. Un UDA peut ^etre partage par deux ou plusieurs UD. Les UDA peuvent ^etre rajoutes et retires dynamiquement aux UD. Cette architecture permet de realiser des formes varies de partage d'information entre les utilisateurs. Trois principales formes de partage sont denies : 1. Partage au niveau de la presentation ou ce qu'on appelle habituellement le couplage WYSIWIS. Pour implanter cette forme de partage entre deux uti- lisateurs il sut que leurs ecrans d'achage (les UD) soient associes aux m^emes (UDA). 2. Partage au niveau des vues selon lequel deux utilisateurs partagent les m^emes objets mais sans avoir forcement les m^emes presentations ou les m^emes droits sur ces objets. Par exemple deux utilisateurs peuvent partager le m^eme tableau de calcul ; le premier percoit le tableau sous forme graphique tandis que le deuxieme le voit sous forme de tableau. 3. Partage au niveau des objets ou les dierents utilisateurs ont acces a des ensembles des objets dierents (avec possibilite de recouvrement entre les dierents ensembles). Outre la denition des schema de partage et de cooperation dierentes, la hie- rarchie (OSS, UDA, UD) permet de personnaliser le modele de la cooperation entre chaque deux utilisateurs. Autrement dit, les dierents participants n'interagissent pas entre eux de la m^eme maniere. Cette hierarchie implante implicitement un systeme de denition et de gestion de r^oles fonctionnels dont le seul inconvenient est qu'il est peu comprehensible par les utilisateurs nales (les r^oles sont codes dans les relations UD-UDA denies par le programmeur de l'application). 2.5.6 GroupDesign GroupDesign est un collecticiel de dessins structures. L'application est im- plantee selon une architecture dupliquee [Karsenty94a]. Elle est fondee sur l'in- tegration d'applications existantes au niveau de l'application. Aucun mecanisme de rendez-vous n'est fourni par l'application. La participation a une session est 2.5 Exemples 49 libre. GroupDesign ne fournit pas des r^oles fonctionnels d'une maniere explicite mais elle permet d'attribuer aux dierents utilisateurs de droits dierents sur des zones dierentes des documents partages. L'application supporte les deux modes d'interaction : synchrone et asynchrone. Les utilisateurs ont le choix de transiter d'un mode de travail WYSIWIS-strict a un mode WYSIWIS-rel^ache. Une facon pour travailler d'une maniere asynchrone consiste a verrouiller une zone du des- sin. Le verrouillage interdit l'acces en ecriture a cette zone. Il peut aussi interdire l'acces en lecture, dans ce cas la zone serait achee sous forme d'une zone noire avec une ic^one speciale qui montre le type du verrou et le nom de l'utilisateur proprietaire. Un point fort dans la conception de GroupDesign est la richesse et la variete des mecanismes qu'elle fournit pour decrire la co-presence. A chaque utilisateur est associee une couleur qui l'identie. An de notier un utilisateur des actions faites par un autre utilisateur l'application emploie un outil d'echo. Deux types d'echos sont utilises : echo graphique et echo audio. Les echos sont actives lorsque les utilisateurs sont en mode d'interaction synchrone. L'echo graphique represente l'action d'un utilisateur sur les ecrans des autres membres du groupe. Cet echo prend la forme d'une animation. Par exemple si un utilisateur redimensionne un rectangle, l'echo de cette operation consiste en une animation qui modie progressivement la taille du rectangle (voir gure 2.11). L'echo audio previent Vue de l’utilisateur Vue du groupe Feed-back Temps Fig. 2.11 - : E cho graphique dans GroupDesign. les utilisateurs de l'occurrence d'une operation qui prend place a l'exterieur de leur fen^etre d'achage. A chaque operation denie par l'application est associe un son specique. L'application permet aussi a un utilisateur de visualiser le champ de vision d'un autre utilisateur. De plus les objets dessines ont toujours le couleur du dernier utilisateur qui l'a modie. GroupDesign fournit un service d'historique de dessins qui permet de tracer l'evolution d'un diagramme et trouver qui a fait quelle modication. Deux principales politiques de gestion de la concurrence sont fournies : 1. Une politique de verrouillage pessimiste. L'acquisition et la liberation de 50 Le TCAO, problematique et solutions verrous sont fait d'une maniere explicite. 2. Une politique optimiste fondee sur l'algorithme Oreste [Karsenty et al.93a]. Une dernier caracteristique importante de GroupDesign est qu'elle permet la co- operation entre des sites et des applications heterogenes [Karsenty et al.93b]. 2.5.7 ActiveMail La plate-forme ActiveMail est fondee sur l'extension du courrier electronique [Goldberg et al.92]. Le modele de rendez-vous fourni par ActiveMail realise un compromis entre les deux approches explicite et implicite. Pour initialiser une nouvelle session de travail, un utilisateur envoie un message aux participants po- tentiels. Lorsqu'un utilisateur recoit un message il a directement les moyens de se connecter a des applications partagees via des boutons de connexion integres dans le message. Dans le mesure ou la participation est conditionnee par la reception d'un message, l'enregistrement est supervise. ActiveMail supporte le developpe- ment de deux types d'applications cooperatives : les collecticiels synchrones et les collecticiels asynchrones. Mais il n'ore pas la possibilite de changer dynami- quement la nature d'interaction pour la m^eme application.Tous les utilisateurs ont des attributions identiques. L'implantation d'une politique de gestion de la concurrence est faite au niveau des applications integrees dans la plate-forme. Aucune politique n'est imposee par la plate-forme. 2.6 Synthese et discussion Le tableau (2.6) resume les services oerts par chacune des plates-formes decrites ci-dessus pour resoudre les deux problemes de la participation et de la coordination dans une activite cooperative. Les trois premieres lignes rappellent les choix de construction de chacune des plates-formes. Les notations suivantes sont employees : pour implantation convenable, pour implantation partielle, , pour implantation absente et blanc pour implantation non precisee. Le tableau 2.6 revele deux caracteristiques importantes des travaux actuels : 1. La plupart des plates-formes existantes se contentent de supporter une seule type d'interaction : l'interaction synchrone ou l'interaction asynchrone. A l'origine de cette dichotomie se trouve, a notre avis, la diversite des inte- r^ets des dierentes disciplines informatiques participant a la recherche en TCAO. La construction d'interfaces-utilisateurs qui prennent en compte les besoins de la cooperation synchrone est un de majeur lance aux chercheurs qdans le domaine de l'ingenerie des interfaces homme-machine [Salber95]. Le m^eme type d'applications interessent les chercheurs dans les domaines de reseaux, des protocoles de communication et des systemes repartis en raison 2.6 Synthese et discussion 51 XTV Sol Mead GroupKit CoopScan ActiveMail GroupDesign Support IHM IHM Donnee IHM- Donnee Donnee Communication Donnees Architecture Centralisee Hybride Hybride Dupliquee Dupliquee Centralisee Dupliquee Applications Int. SF Nouvelles Nouvelles Nouvelles Int.-App. Adapt. Int. App. Rdv. explicite - - Rdv. implicite - - - - Integration du travail individuel - - - - - Enregistrement - - - Participation dynamique - R^oles fonctionnels - - - - Interaction synchrone - Interaction asynchrone - - - - - Co-presence - - - Conguration dynamique - - Ouverture - - - - Tab. 2.6 - : Satisfaction des services requis pour la gestion de la participation et de la coordination par les plates-formes etudiees. des contraintes temporelles exigees par ces applications. D'autre part, les chercheurs dans les domaines de documents electroniques, d'automatisation du bureau et de bases de donnees traitent des problematiques plus proches de la cooperation asynchrone. 2. La majorite des plates-formes pr^etent peu d'attention a la relation entre le travail individuel et le travail en groupe. La plupart des travaux concoivent le travail en groupe comme un mode de travail particulier et independant du travail individuel. La majorite des plates-formes existantes etant construit par des equipes informatique mono-disciplinaire, les constructeurs semblent ^etre prises par le de technique que lance le travail en groupe. Nous rappelons que notre objectif de l'etude des travaux existants est de xer les choix de construction les plus opportunes pour le developpement d'une plate- forme pour le TCAO qui ore l'ensemble des services identies dans la section (2.3.3). Le tableau precedent montre qu'aucune des plates- formes etudiees n'ore pas la totalite des services requis. L'incompletude fonctionnelle d'une plate-forme peut ^etre le resultat d'une manque d'eort de developpement ou bien innee dans les choix de construction de la plate- forme. E videment, ce que nous interesse ici est l'identication des choix de construction qui limitent la completude fonction- nelle des plates-formes. Nous enumerons dans la suite les choix de construction 52 Le TCAO, problematique et solutions que nous identions d'^etre limitatifs (au niveau fonctionnel) : Avoir le support au niveau de l'IHM ne permet pas d'implanter un systeme implicite de gestion de rendez-vous, ni de supporter la transition facile entre les deux modes de travail : individuel et de groupe. C'est le cas de XTV et de Sol. Les fonctions de la cooperation etant exclusivement rattachees au systeme de gestion de l'interface la semantique des donnees manipulees par l'application ne serait pas prise en compte. Par suite il est dicile de distin- guer les donnees personnelles des donnees partagees. De plus cette approche necessite l'existence simultanee de tous les utilisateurs dans l'espace du col- lecticiel. Avoir le support au niveau de la communication cette approche repose sur l'idee de l'echange asynchrone de l'information. Elle est par consequent non adaptee a supporter la cooperation synchrone. D'un autre cote, cette ap- proche favorise la gestion explicite de la cooperation. Il est par exemple dicile d'imaginer l'emploi de cette approche pour implanter un modele implicite de gestion de rendez-vous. L'integration au niveau de systeme de fen^etres est un cas particulier de la mise en uvre des fonctions de la cooperation au niveau de l'IHM. Cette approche presente donc les m^emes inconvenients presentes ci- dessus. Les informations echangees entre les utilisateurs, selon cette approche, ont un niveau semantique tres bas (fen^etre, ascenseur, pointeur) ; toute entite d'un niveau semantique plus haut est forcement partagee par les utilisateurs. Ceci implique l'impossibilite d'associer des r^oles fonctionnels dierents aux dierents utilisateurs et que le seul type d'interaction possible est l'inter- action synchrone stricte (WYSIWIS). D'autre part, les systemes de fen^etres fondes sur le paradigme client-serveur tel que X-Window impose l'emploi des protocoles de tour de r^ole pour gerer la concurrence. L'emploi des pro- tocoles optimistes peut generer des sequences non autorises par le protocole client- serveur et en consequence faire arr^eter le systeme. Par exemple dans le cas de X-Window une sequence formee de deux clics souris (MouseDown) non separes par un evenement de type souris rel^achee viole le protocole X et entra^ne l'arr^et du systeme. La mise en uvre selon une architecture centralisee force le choix des po- litiques restrictives pour la gestion de la concurrence. Il est dicile d'im- planter une politique qui permet l'acces simultane a l'espace partage. 2.7 Conclusion L'objet de ce chapitre est d'etudier et de comparer les dierentes approches pour la construction de collecticiels. Dans un premier temps nous avons presente 2.7 Conclusion 53 une etude de denition et de classication de collecticiels. Trois classes sont iden- tiees : les collecticiels proceduraux, les collecticiels a immersion et les collecticiels contractuels. Dans un deuxieme temps nous avons propose une nouvelle classi- cation des principales approches de construction des plates-formes pour le TCAO. La classication proposee est fondee sur les trois axes suivants : Le niveau du support qui peut ^etre au niveau de l'IHM, au niveau de don- nees ou au niveau de la communication. L'architecture de mise en uvre qui peut ^etre centralisee, dupliquee ou hybride. La nature des applications supportees qui peuvent ^etre des nouvelles appli- cations ou des applications existantes. Dans le dernier cas, nous avons dis- tingue deux approches de reutilisation d'applications existantes : par adap- tation et par integration. L'intgration d'applications peut se faire au niveau du systeme de fen^etre ou au niveau de l'application. Des exemples representatifs des dierentes approches de construction evo- quees ci-dessus sont decrits. Nous les avons compare en fonction de leurs com- pletude fonctionnelle vis a vis des services requis pour resoudre deux problemes fondamentaux : la participation a une activite cooperative et la coordination a l'interieur d'une activite. Notre etude de comparaison nous a permet de montrer que certains choix de construction ne sont pas pertinents pour la construction d'une plate-forme generique pour le TCAO. Les principaux choix a eviter sont : 1. avoir le support au niveau de l'IHM, 2. avoir le support au niveau de la communication, 3. la mise en uvre selon une architecture centralisee et 4. l'integration d'applications existantes au niveau de systeme de fen^etres. 54 Le TCAO, problematique et solutions Chapitre 3 Colt, un environnement de cooperation 3.1 Introduction La plupart des collecticiels contractuels1 existants sourent de deux defauts qui sont a notre avis a l'origine de leur faible notoriete dans les organisations reelles : 1. La cooperation entre collecticiels : Peu de mecanismes sont oerts par les plates-formes actuelles pour coordonner et orchestrer l'execution d'un groupe de collecticiels. Pourtant dans la vie reelle des organisations et des entreprises les activites sont rarement isolees l'une de l'autre [Schmidt et al.93]. 2. L'integration du travail individuel : Les collecticiels existants pr^etent peu d'attention a l'integration des modes du travail individuel et en groupe. Pour remedier aux defauts precedents, le concept d'Environnement de Coope- ration (EdC) est introduit [Schmidt et al.93, Navarro et al.93]. Un EdC fournit a un groupe organise d'individus un support pour orchestrer le lancement et l'execution de collecticiels varies en fonction de besoins du groupe. Comme le fait remarquer Croisy dans [Croisy94] le concept d'EdC est une generalisation directe de celui du collecticiel. Si nous associons un collecticiel a une relation N ! 1 ou N personnes interagissent avec une application un EdC serait associe a une relation N ! M ou N utilisateurs travaillent ensemble en utilisant M applications. Nous presentons dans ce chapitre un nouvel environnement de cooperation ap- pele Colt (abreviation de Collaboration Terrain). Colt est un environnement inte- gre pour le travail individuel et le travail cooperatif. Les utilisateurs partagent un espace d'information ou chacun a le droit de voir et de se mouvoir selon des r^oles 1 voir la denition dans 2.2.4 56 Colt, un environnement de cooperation qui lui sont attribues. Les utilisateurs peuvent creer et participer a des activites cooperatives. Une activite est denie par l'ensemble des regles de contr^ole qui y sont appliquees et par les documents qui y sont manipules. Chaque activite de- nit un sous-espace de l'espace d'information partage. Une activite dans Colt peut ^etre persistante ou non. Une activite est persistante si tous les acteurs peuvent se deconnecter puis revenir plus tard et retrouver l'activite dans le m^eme etat ob- serve par le dernier des acteurs deconnectes. Recemment quelques travaux se sont interesse a la construction d' EdC. Nous citons en particulier les travaux fondes sur la double metaphore piece-outil tel que TeamRooms [Roseman et al.96b] et Co-Learn [Croisy94]. Le principe est de permettre aux utilisateurs de construire des pieces dans lesquelles ils partagent des outils. Contrairement a ces travaux nous decouplons dans Colt la metaphore d'outil de celle de la piece ; les utilisa- teurs rassemblent des outils individuels pour travailler ensemble dans une piece. Les outils ne sont pas partages. Nous montrons que notre approche permet une integration plus simple du travail individuel et le travail en groupe et qu'elle permet de construire un systeme souple et adaptable. Dans la section suivante nous precisons les objectifs xes pour l'environnement Colt. La section (3.3) decrit les choix de construction adoptes pour atteindre les objectifs xes. Une description informelle de l'environnement est donnee dans la section (3.4). L'architecture generale du systeme est expose dans la section (3.5). Un premier prototype de Colt est realise sur une plate-forme Unix et est implante en utilisant l'environnement graphique TCL-TK. Nous decrivons ce prototype dans la section (3.6). Une evaluation fonctionnelle de Colt est faite dans la section (3.7). 3.2 Objectifs L'objectif principal de Colt est de fournir un systeme integre qui assiste un ensemble organise d'individus dans leur travail. Nous ne visons pas un type precis d'organisations mais nous cherchons plut^ot a fournir un environnement generique et adaptable qui permet la construction et l'execution des collecticiels contractuels varies. Les services requis d'un tel environnement sont presentes et analyses dans (2.3.3). Cinq groupes de services ont ete identies a savoir : 1) la conscience de groupe, 2) le partage et l'echange d'informations, 3) la gestion des groupes d'uti- lisateurs, 4) la reconguration dynamique et 5) l'ouverture du systeme a toute evolution future. S'occuper de l'ensemble des services requis echappe au volume d'une seule these. Dans le cahier des charges de Colt, nous mettons l'accent sur les points suivants : 1. Fournir un modele generique de rendez-vous. 2. Permettre le lancement et l'execution de scenarios cooperatifs varies. Par scenarios varies nous voulons dire des activites cooperatives synchrones ou 3.3 Choix de construction 57 asynchrones, planiees ou fortuites, persistantes pu on persistantes. 3. Rendre aise le passage entre le travail individuel et le travail en groupe. Les criteres cites ci-dessus sont inspires de l'etude des deux problemes de la participation et de la coordination dans les activites cooperatives presentes dans la section (2.3). 3.3 Choix de construction Nous exposons et nous argumentons dans cette section les choix que nous avons fait pour la mise en uvre de Colt. Deux sortes de choix sont a faire : 1. Le choix de la strategie de mise en uvre que nous exprimons en fonction des approches de construction des collecticiels identiees dans la section (3.3). 2. Le choix des metaphores a employer pour la conception de l'environnement et pour la presentation de l'interface utilisateur du systeme. 3.3.1 Strategie de mise en uvre Dans (2.4) nous avons identie trois criteres pour la classication des ap- proches de construction des collecticiels : 1) le niveau du support, 2) le schema de mise en uvre et 3) la nature des applications supportees. Nos choix pour la mise en uvre de Colt sont fondes sur les resultats de l'etude de comparaison fonctionnelle des dierentes approches faite dans (2.6), a savoir : Le niveau du support est au niveau des donn ees. Les deux autres niveaux identies (le niveau de l'interface utilisateur et le niveau de la communication) ne permettent pas l'implantation de certains modeles de cooperation ou de fonctions de gestions de rendez-vous. L'architecture de mise en uvre est totalement dupliqu ee. Ce choix est motive par les nombreux avantages de l'architecture dupliquee notam- ment : la reactivite des applications, la reduction du trac reseau, la dispo- nibilite des donnees et une meilleur tolerance aux pannes [Roseman et al.92, Balter et al.96a]. Les applications construites sont nouvelles. Nous supportons egale- ment l'adaptation et l'integration des applications au niveau de l'application sous certaines contraintes que nous precisons ulterieurement. L'integration d'applications au niveau de systeme de fen^etres n'est pas supportee en rai- son des nombreuses limitations fonctionnelles qu'elle induit. 58 Colt, un environnement de cooperation 3.3.2 Choix de metaphores Les concepteurs des applications interactives ont recours aux metaphores pour identier les fonctions et les services a fournir et pour munir l'interface utilisateur de l'application d'une representation facile a interpreter et a utiliser. Souvent la m^eme metaphore est employee pour les deux t^aches a la fois. Nous presentons dans la suite les metaphores les plus employees pour modeliser les collecticiels : 1. Les collecticiels sous forme de reunions ou de sessions. La cooperation entre deux utilisateurs necessite qu'ils soient tous les deux presents au m^eme ins- tant dans l'espace deni par l'activite. Cependant l'interaction entre les utilisateurs peut ^etre de nature synchrone ou asynchrone (voir 2.2.3). L'ac- tivite se termine avec le depart du dernier participant. Les uvres produites dans le contexte de l'activite n'existeront plus apres la terminaison de l'ac- tivite 2. 2. Les collecticiels sous forme de procedures. Selon cette metaphore de concep- tion chaque participant a le potentiel d'executer un ensemble ni d'actions dont les resultats et les impacts sur les vues des autres utilisateurs sont determines a l'avance. Les utilisateurs peuvent travailler en m^eme temps ou en temps diere. Bien que cette metaphore de conception convienne a l'implantation des collecticiels proceduraux elle est employee parfois pour modeliser des collecticiels contractuels dans lesquels les actions possibles sont bien limitees et determines a l'avance et ou le travail a accomplir suit un plan structure. C'est le cas par exemple d'une application de vote ou d'un systeme de prise de decisions. 3. Les collecticiels sous forme de locaux partages. Chaque execution d'un col- lecticiel prend place dans un local bien deni. Ainsi pour participer a une activite l'utilisateur doit se rendre au local qui lui est associe. Un local est deni par son adresse et son etendue (les donnees et les outils qu'il contient). Les utilisateurs peuvent acceder a un local quand ils veulent (du moment qu'ils ont l'autorisation de s'y rendre). Lorsque deux utilisateurs sont dans le m^eme local en m^eme temps ils peuvent interagir entre eux d'une ma- niere synchrone ou asynchrone en fonction des outils dont ils disposent. Les uvres contenues dans un local y restent tant que le local existe. Dans ce sens un local peut ^etre vu comme une session persistante. La persistance permet aux utilisateurs de travailler et de faire evoluer leur t^ache commune aussi bien en temps diere qu'en m^eme temps ; le travail individuel trouve aussi sa place dans un systeme reposant sur la metaphore de locaux (^etre seul dans le local). Comparee aux autres metaphores le local partage est la metaphore la plus ge- nerique puisqu'elle permet de modeliser de types varies d'activites cooperatives. 2 Sauf s'ils sont explicitement sauvegardes par l'un des participants. 3.3 Choix de construction 59 En consequence la plupart des environnements de cooperation qui se veulent ge- neriques sont construits selon cette metaphore. Deux principales variations d'im- plantation de la metaphore de locaux partages sont proposees dans la litterature du TCAO : la piece et le terrain. La metaphore de la piece : L'espace partage est compose d'un ensemble de pieces. Une piece correspond a une activite ; elle contient les documents et les outils necessaires pour mener cette activite. Pour manipuler un do- cument il faut d'abord acceder a la piece qui le contient. Lorsque deux utilisateurs se trouvent dans la m^eme piece ils peuvent travailler ensemble sur les documents contenus dans cette piece. Le concept de piece est donc un moyen pour structurer a la fois l'espace partage et les activites des uti- lisateurs. Les utilisateurs peuvent creer de nouvelles pieces en fonction de leurs besoins. Un mecanisme de deplacement entre les dierentes pieces doit ^etre fournit par le systeme. Un premier exemple de la realisation de cette metaphore est constitue par les systemes dits MUD (pour Multi User Dun- geons). Un autre exemple est le systeme Co-Learn [Croisy95] qui denit des pieces typees. Le type d'une piece determine la nature de l'activite qui peut y prendre place. D'autres systemes comme TeamRooms [Roseman et al.96b] fournissent des pieces identiques que les utilisateurs faconnent et meublent en fonction de leurs besoins. Les locaux sous forme d'un terrain. L'espace partage est represente sous forme d'une structure abstraite (non conforme a une realite physique) dotee d'un systeme d'aide a la navigation entre les donnees. Un exemple classique est de presenter l'espace partage sous forme de structure hypertexte comme c'est le cas dans le systeme BSCW [Bentley et al.97]. Un autre exemple est constitue par les systemes dits PIT (Populated Information Terrains) [Benford et al.95]. Un PIT consiste a donner a un systeme d'information (par exemple un systeme de chiers) une conguration spatiale qui permet aux utilisateurs de visualiser les donnees partagees et de voir ou sont les autres dans le systeme. Les dierentes approches de conguration spatiales des PIT sont presentees dans [Benford et al.95]. Selon la metaphore de la piece, la denition de l'activite (creation d'une piece) precede l'existence des donnees a manipuler dans l'activite tandis que selon la me- taphore du terrain les donnees existent avant les activites. C'est l'acces simultane de deux ou plusieurs utilisateurs au m^eme document qui peut engendrer une ac- tivite. Ainsi la metaphore de la piece supporte l'execution des activites planiees tandis que celle du terrain supporte principalement les activites non planiees. Le choix de la metaphore de la presentation de l'interface homme machine d'un systeme fonde sur la metaphore de locaux partages depend fortement du meca- nisme de navigation fourni par le systeme. Dans le cas d'un PIT l'espace partage 60 Colt, un environnement de cooperation est souvent represente sous forme d'un graphe ou les nuds representent les do- cuments et les arr^etes representent des liens sur lesquels l'utilisateur peut glisser pour aller d'un document a un autre (comme dans le cas de la navigation dans un systeme hypertext). Dierentes methodes de navigation sont proposees dans les systemes fondes sur la metaphore de la piece. Dans GroupKit les pieces dispo- nibles sont presentees dans une seule fen^etre. Chaque piece est representee sous forme d'un rectangle qui porte le nom de la piece et les noms des utilisateurs qui sont dedans. Il sut d'appuyer sur le rectangle pour entrer dans la piece [Greenberg91]. La disposition des pieces dans l'espace de la fen^etre est aleatoire. Co-Learn emploie une strategie semblable a la precedente sauf que les pieces sont organisees dans un sorte de plan d'immeuble [Croisy95]. L'existence d'un plan facilite l'orientation des utilisateurs dans l'espace. D'autres systemes emploient la metaphore de la porte pour assurer le deplacement entre les dierentes pieces. Le systeme MILAN [Condon92] presente une interface utilisateur sous forme d'un village ; les pieces sont organisees en immeubles qui sont a leur tour organises en quartiers. Ainsi pour aller d'une piece a une autre il faut passer par un niveau organisationnel plus eleve. Dans Colt nous empruntons une approche originale que nous resumons par les trois points suivants : { La metaphore de conception est une combinaison des deux metaphores : la piece et le terrain. Les utilisateurs partagent un espace d'information qui contient des documents partages et des pieces. La combinaison des deux metaphores nous permet de supporter a la fois les activites planiees et les activites non planiees. { La metaphore de la presentation de l'interface homme machine est la meta- phore classique de surface du bureau. La surface du bureau d'un utilisateur porte tous les documents que l'utilisateur a le droit de voir, qu'ils appar- tiennent a une piece ou au terrain. L'utilisateur accede a un document contenu dans une piece (donc appartenant a une activite cooperative) de la m^eme maniere qu'il accede a un document individuel ou a un document partage (appartient au terrain). L'uniformite d'acces et d'emploi des docu- ments renforce l'integration entre le mode de travail individuel et le travail en groupe. { Contrairement a la majorite des systemes implantant la metaphore de la piece, nous decouplons dans Colt le concept d'outil de celui de la piece. Une piece est une structure de contr^ole et d'organisation qui contient un ensemble des documents que les utilisateurs peuvent manipuler tout en respectant des regles d'acces et d'interaction propres a la piece. Pour acceder a un document chaque utilisateur emploie son propre outil individuel. Ainsi le m^eme outil (application) est utilise pour travailler individuellement ou en groupe. Ceci facilite l'emploi de notre environnement et le rend plus 3.4 Colt : presentation informelle 61 exible en permettant aux utilisateurs de cooperer tout en employant des outils heterogenes. 3.4 Colt : presentation informelle L'architecture de Colt fait intervenir deux entites conceptuelles dites le Ter- rain et l'Agent Colt (AgC). Le Terrain est un serveur auquel se connectent les utilisateurs via des clients qui sont les AgC. Il ne faut pas confondre ici le concept du Terrain dans Colt avec la metaphore du terrain presentee dans la section (3.3.2). Le Terrain implante la totalite de l'espace partage : les documents par- tages et les pieces disponibles dans le systeme. Il implante aussi les modules de contr^ole des activites (cooperatives ou individuelles) qui peuvent prendre place dans l'environnement. De son c^ote un AgC represente un utilisateur enregistre dans l'environnement. Il permet a l'utilisateur qu'il represente d'agir dans le Ter- rain en fonction des privileges qui lui sont attribues. Ainsi le deploiement de Colt consiste a avoir un seul Terrain et autant d'AgC qu'il y a d'individus dans l'orga- nisation cible. Lorsqu'un utilisateur se connecte au Terrain, son AgC lui montre la vue qui lui est attribue sur ce Terrain. La vue d'un utilisateur comprend les documents et les pieces disponibles pour cet utilisateur. Un document est dispo- nible pour un utilisateur si ce dernier a au moins le droit de le lire. Une piece est disponible pour un utilisateur si ce dernier est y deja enregistre ou invite a s'y rendre (cooperant potentiel). Les documents contenus dans les pieces auxquelles l'utilisateur est invite ne gurent evidemment pas dans la vue de l'utilisateur. La denition de la vue d'un utilisateur depend de son r^ole dans l'organisation. Un systeme de denition et d'attribution des r^oles organisationnels est implante par le Terrain (4.5.1.4). La gure (3.1) montre l'interface utilisateur d'un AgC construit selon la metaphore de surface du bureau. Contrairement aux implan- tations habituelles de cette metaphore, la surface du bureau dans Colt ne porte que des documents. Les applications disponibles (les outils) pour l'utilisateur sont regroupees sous le menu Tools. Ce choix est fait dans l'optique de faciliter la lo- calisation des outils. Outre le menu Tools la barre de menu porte quatre entrees qui sont les suivantes : 1. Le menu Activities propose les commandes de creation de nouvelle ac- tivites de groupe (pieces), de visualisation de la liste des activites dans lesquelles l'utilisateur est enregistrees et la liste d'activites auxquelles il est invite a participer. 2. Le menu Organisation propose les commandes de visualisation de la hie- rarchie de l'organisation des utilisateurs (les r^oles organisationnels et les relations entre eux). Ce menu propose a l'administrateur de l'environne- ment des commandes de gestion de l'organisation (creation, modication et eacement des r^oles ou des liens entre les r^oles). 62 Colt, un environnement de cooperation 3. Le menu People propose les commandes de renseignement sur les utilisa- teurs enregistres dans l'environnement. 4. Le menu Manager propose une commande qui permet a l'utilisateur de changer son mot de passe et une autre pour quitter l'environnement. Fig. 3.1 - : L'interface utilisateur d'un agent Colt. Les documents sont representes sur le surface du bureau sous forme ic^onique. L'ic^one d'un document designe l'outil qui peut ^etre utilise pour manipuler le do- cument. Le mode d'achage d'une ic^one change en fonction de l'etat de l'emploi du document qu'elle represente. De point de vue d'un utilisateur un document peut ^etre dans l'un des trois etats suivants : 1. Etat de repos ou le document n'est pas utilise par aucun utilisateur. Son ic^one est achee en mode plat. 3.4 Colt : presentation informelle 63 Fig. 3.2 - : Visualisation d'un document : Draw0 est au repos, Draw1 est occupe et Draw2 est en etat d'exploitation. 2. d'occupation Etat ou le document est charge par un autre utilisateur mais pas par l'utilisateur local. Dans ce cas l'ic^one est achee en mode sur-eleve. 3. d'exploitation Etat ou le document est utilise par l'utilisateur local. L'ic^one est achee en mode enfonce. Les trois modes d'acahge d'ic^ones sont illustres sur la gure (3.2). A chaque document est attachee une che d'information que l'utilisateur peut acher en appuyant deux fois (bouton droit de la souris) sur l'ic^one du document. Un exemple d'une che d'information est illustre a la gure (3.3) Fig. 3.3 - : Les operations et les informations disponibles sur un document. Outre la description du document (dates de creation et de derniere sauve- garde, etat d'emploi et les proprietaires du document) la che porte des boutons qui permettent d'appliquer les commandes usuelles sur les documents (copier, eacer et changer le mode de protection). La che porte deux autres boutons ; le premier (History) permet d'acher l'historique d'acces au document tandis que le deuxieme a pour eet d'acher la liste des utilisateurs actuels du document. 64 Colt, un environnement de cooperation Lorsqu'un utilisateur accede a un document l'evenement est propage a tous les autres utilisateurs connectes au Terrain et qui ont le m^eme document sur leur bureau. Deux utilisateurs partagent un document dans l'un des deux cas suivants : 1. si le document appartient a une activite cooperative dans laquelle les deux utilisateurs sont enregistres. Nous disons que le document est un document de cooperation, 2. si le document n'appartient pas a une activite cooperative mais si les deux utilisateurs ont au moins le droit de le lire (par exemple les deux utilisateurs ont le m^eme r^ole organisationnel). Nous designons ce type de documents par le terme document public. Lorsque deux ou plusieurs utilisateurs accedent en m^eme temps a un docu- ment public ils vont se retrouver dans une situation de cooperation synchrone ou ils peuvent manipuler tous ensemble le document chacun en fonction des droits qu'il possede sur ce document. Nous appelons cette situation une rencontre. Les rencontres sont des activites de groupe non-planiees. La creation des rencontres repose sur un modele de rendez-vous implicite. L'environnement Colt fournit aussi un modele explicite de rendez-vous im- plante sous forme d'un repertoire d'activites. Les commandes de la gestion de ce repertoire sont regroupees sous le menu Activities. An de faciliter la t^ache de la creation de nouvelles activites, nous avons opte vers un mecanisme de crea- tion par instanciation des modeles predenis. Un modele decrit les protocoles de contr^ole (politiques d'enregistrement, d'integration et de mediation) qui peuvent ^etre appliques dans l'activite et les privileges attribues aux participants a l'acti- vite. La denition des privileges des participants repose sur un systeme de deni- tion et d'attribution de r^oles fonctionnels. Par exemple dans un seminaire nous denissons les trois r^oles fonctionnels suivants : orateur, public et animateur (ou president). A chaque participant a une activite sont associes un ou plusieurs r^oles fonctionnels. En fait, lors de la creation d'une nouvelle activite, l'utilisateur doit specier qui parmi les utilisateurs enregistres dans l'organisation peut avoir quel r^ole fonctionnel. Un utilisateur peut ^etre enregistre dans plusieurs activites, mais il ne peut ^etre actif que dans une seule activite a la fois. Ce choix nous evite de se preoccuper du probleme complexe de fusion d'activites. Pour manipuler les documents dis- ponibles dans une activite les utilisateurs emploient les m^emes outils qui sont dis- ponibles sous le menu Tools. Cependant les participants a une activite disposent d'un autre type d'outils que nous appelons les Outils d'Aide a la Conversation (OAC). Un OAC est un outil de communication directe entre les participants. Des exemples sont : un tableau blanc partage ou un canal audio-video temps reel. Il est important de noter qu'un OAC ne peut ^etre employe que dans le contexte d'une activite. Donc deux utilisateurs ne peuvent pas communiquer directement 3.5 Architecture generale 65 sauf s'ils sont dans la m^eme piece. Ce choix decoule de notre objectif de four- nir un environnement de cooperation contractuelle ; nous evitons l'immersion des utilisateurs dans l'environnement informatique (voir 2.2). 3.5 Architecture generale 3.5.1 Le Terrain Le Terrain denit et gere le contexte de l'organisation cible de l'environne- ment. A ce titre il maintient les documents manipules dans l'environnement, denit l'organisation et les utilisateurs qui la forment et decrit la nature des ac- tivites qui peuvent avoir lieu dans l'environnement. Les fonctions citees ci-dessus sont assurees par des agents specialises, appeles les gestionnaires (voir gure 3.4). La structuration du Terrain en gestionnaires cooperants nous permet de decrire son fonctionnement independamment du schema de mise en uvre adopte. Cinq gestionnaires specialises constituent le Terrain : 1) le gestionnaire de l'espace de travail, 2) le gestionnaire de l'organisation, 3) le gestionnaire des activites, 4) le gestionnaire de la protection et 5) le gestionnaire de la communication. 3.5.1.1 Le gestionnaire de l'espace du travail (GET) Le gestionnaire de l'espace du travail (GET) assure le stockage permanent des documents utilisateurs et l'acces a ces documents. Il fournit une interface classique de manipulation de documents dont les principales fonctions sont donnees dans le tableau (3.1). Fonction Description NewDoc Creation d'un nouveau document. OpenDoc Ouverture d'un document existant. WriteDoc Modication d'un document existant. CloseDoc Fermeture d'un document. DelDoc Detruire un document ChDocOwn Changement du proprietaire du document. GetDocInfo Donner les informations contenues dans le descripteur. Tab. 3.1 - : Principales fonctions de manipulation de documents. L'environnement Colt etant concu pour fonctionner sur des systemes d'ex- ploitation existants, la gestion de la persistance des documents est geree par le systeme de gestion de chiers (SGF) fourni par le systeme sous-jacent. Par 66 Colt, un environnement de cooperation Gestionnaire Gestionnaire de l’espace des activités de travail GAC GET Gestionnaire Gestionnaire de de protection l’organisation GOR GDP Le Terrain Gestionnaire de la communication GCM Les Agents Colt (AgC) Fig. 3.4 - : Architecture generale du Terrain. consequent le GET est aranchi des t^aches de bas niveau (gestion de la memoire, localisation des documents, : : : ). Le GET implante une couche intermediaire entre Colt et le SGF employe. L'inter^et principal de cette couche est de collecter une partie des informations necessaires pour la presentation de la co-presence des utilisateurs dans l'environ- nement. Le r^ole d'interface que joue le GET entre Colt et le SGF sous-jacent lui permet de conna^tre, pour chaque document, l'etat d'emploi, l'historique et la liste des utilisateurs actuels et potentiels. An de sauvegarder et d'exploiter les dierentes informations citees ci-dessus le GET associe a chaque document Colt une structure de contr^ole dite descripteur de document (DD). Les informations contenues dans un DD sont explicitees dans le tableau 3.2. Nous decrivons dans la suite l'utilite et la fonction de chacun des champs constituant un DD. Les trois premiers champs dans un DD servent pour designer et localiser les documents. La cha^ne d'acces a un document est la suivante : Nom !AgC Identificateur !GET Adresse physique 3.5 Architecture generale 67 Champ Contenu Identificateur Identicateur unique attribue par le GET. Nom Nom symbolique attribue par le createur du document. Adresse physique Listes des chiers contenant le document Applications Liste d'applications pouvant manipuler le document. Propri etaire identicateur d'un utilisateur ou d'un groupe ou d'une activite. Historique Nom du chier contenant l'historique d'acces au document. Les utilisateurs potentiels Liste des utilisateurs connectes au Terrain ayant le droit d'acceder au document. Les utilisateurs actuels Liste des utilisateurs employant actuellement le document. Tab. 3.2 - : Structure d'un DD. L'agent colt d'un utilisateur (l'entite qui gere l'interface utilisateur) s'appuie sur une table de correspondance pour retrouver l'identicateur d'un document a partir de son Nom (voir 3.5.2). Le GET en consultant le DD adequat localise les chiers implantant le document designe. Le Nom d'un document ne le caracterise pas d'une maniere unique. Deux documents peuvent avoir le m^eme Nom. Rien n'emp^eche que deux utilisateurs utilisent le m^eme Nom pour nommer deux do- cuments dierents. Un probleme se pose si deux documents ayant le m^eme nom font partie d'une m^eme vue d'un utilisateur. Pour resoudre ce probleme l'AgC renomme localement l'un des deux documents. C'est ainsi que le m^eme document peut ^etre designe dieremment par dierents utilisateurs. Le champ Applications enumere les applications qui peuvent manipuler le document. Il denit le type du document . Le m^eme document peut ^etre mani- pule par des applications dierentes. Par exemple un dessin peut ^etre edite par un editeur graphique ou visualise par un browser d'images. La liste des appli- cations pouvant manipuler un document est determinee automatiquement lors de la creation du document en fonction des relations predenies de compatibi- lite entre l'application qui cree le document et les autres applications disponibles dans l'environnement. Chaque document a un seul proprietaire dont l'identite est donnee par le champ proprietaire. Le proprietaire a tous les droits sur le document qu'il possede y compris la denition des droits des autres utilisateurs sur ce document. La notion de propriete sert aussi a structurer l'espace des documents colt. Chaque proprietaire denit un groupe de documents. Le proprietaire d'un document peut ^etre un : 1) un utilisateur, 2) un groupe d'utilisateurs designe par un r^ole organisationnel ou 3) une activite cooperative. La structuration facilite la localisation d'un document en reduisant la recherche a un sous ensemble de documents. Cependant il faut trouver des criteres qui per- mettent de structurer la liste des documents appartenant au m^eme proprietaire. Le choix de tels criteres est un probleme ouvert [Coulouris et al.94]. 68 Colt, un environnement de cooperation Les trois derniers champs d'un DD portent les informations decrivant la co- presence des utilisateurs. Ils designent respectivement, le chier qui contient l'his- torique d'acces au document, la liste (UP) des utilisateurs connectes au Terrain ayant le droit d'acceder au document et nalement la liste (UA) des utilisateurs employant le document. La construction de la liste UP se fait au fur et a mesure de la connexion des utilisateurs au Terrain (voir 3.5.2.1). Lorsqu'un utilisateur ac- cede au document, le GET transfere son identicateur de la liste UP a la liste UA. Ainsi l'intersection des deux listes est vide. Le contr^ole de l'achage de l'ic^one d'un document repose sur les informations contenues dans les deux listes UP et UA. Les regles suivants sont appliquees pour determiner le mode d'achage : L'ic^one est achee sur les surfaces de bureaux des utilisateurs references dans les deux listes. L'ic^one est achee en mode enfonc e pour tout utilisateur reference dans la liste UA. Si la liste UA est non vide les utilisateurs references dans la liste UP achent l'ic^one en mode sur-eleve. Si la liste UA est vide les utilisateurs references dans la liste UP achent l'ic^one en mode plat. Selon les regles precedentes le GET se contente de modier le mode d'achage de l'ic^one d'un document pour ses utilisateurs potentiels (UP) lors de l'occurence d'un des deux evenements suivants : le passage de la liste UA de l'etat vide a l'etat non vide et lors du passage de la m^eme liste de l'etat non vide a l'etat vide. 3.5.1.2 Le gestionnaire de l'organisation (GOR) Le gestionnaire de l'organisation (GOR) a le r^ole de denir et de presenter les utilisateurs qui forment l'organisation cible de l'environnement. La modeli- sation de l'organisation des utilisateurs repose sur la denition de deux espaces interconnectes appeles l'espace organisationnel et l'espace utilisateurs. L'espace organisationnel (respectivement utilisateurs) est compose d'un en- semble de r^oles organisationnels (respectivement utilisateurs). Un r^ole organisa- tionnel (RO) correspond a un groupe social reconnu dans l'organisation cible. Par exemple dans un milieu universitaire nous retrouvons les deux r^oles classiques : etudiant et professeur. Un r^ole utilisateurs (RU) designe un utilisateur humain enregistre dans l'organisation. La denition des r^oles est faite par l'administra- teur de l'environnement Colt. L'administrateur peut denir un nouvel RO par specialisation d'un ou plusieurs RO existants. C'est le cas par exemple du r^ole ATER dans l'organisation illustree a la gure (3.5) qui est deni par specialisation des trois r^oles etudiant, chercheur et enseignant. Les relations de speciali- sation entre les RO denissent une hierarchie sur l'espace organisationnel. Cette 3.5 Architecture generale 69 hierarchie facilite la gestion des RO en denissant des regles d'heritage entre les RO. Un RO herite les attributions de ses ascendants. Personnels Rôles organisationnels Étudiant Chercheur Enseignant Doctorant ATER Professeur U1 U2 U3 Rôles utilisateurs Fig. 3.5 - : Exemple d'un arborescence d'un repertoire des utilisateurs. Aucune hierarchie n'est denie sur l'espace utilisateurs. Par contre chaque RU est relie a un ou plusieurs RO qui denissent les groupes auxquels appartient l'utilisateur. Outre la description de la position de l'utilisateur dans l'organisation (a travers les RO qui lui sont associes), un RU porte des informations personnelles destinees a presenter l'utilisateur qu'il represente a ses collegues (nom, photo, coordonnees, etc). La gure (3.6) illustre un exemple de la presentation d'un utilisateur. Un utilisateur peut demander au GOR la liste des utilisateurs ayant un certain RO, ou bien quels sont les r^oles attribues a un utilisateur donne. D'autre part, un utilisateur peut combiner les dierents r^oles pour designer un nouveau groupe d'utilisateurs. La combinaison des r^oles existants ne denit pas un nouveau r^ole. Deux operations de combinaison de r^oles sont fournies : l'union de r^oles (ET) et l'exception (Sauf). La decomposition de l'organisation en deux espaces, organisationnel et utili- sateurs augmentee des operations de combinaison de r^oles fournit un modele de designation des utilisateurs qui est a la fois ecace (gr^ace a la manipulation de groupes) et precis car il permet de distinguer les individus (gr^ace a l'emploi des r^oles utilisateurs). La souplesse de notre modele de designation prend toute son importance lors du son couplage avec les deux systemes de gestion de la protec- tion et de gestion des activites cooperatives (voir 3.5.1.3 et 3.5.1.4). Le concept du r^ole est employe a la fois comme unite de designation et comme unite de protection. 70 Colt, un environnement de cooperation Fig. 3.6 - : Exemple de presentation d'un utilisateur. 3.5.1.3 Le gestionnaire des activites (GAC) Le gestionnaire des activites (GAC) a la charge de gerer la specication, la creation et l'evolution des activites cooperatives qui peuvent avoir lieu dans l'en- vironnement. Selon l'axe du temps, nous distinguons deux types d'activites : les activites persistantes et les activites ephemeres. Une activite est persistante si elle persiste lorsque tous les participants l'ont quitte. Une activite ephemere se de- truit avec le depart du dernier participant. La propriete de la persistance permet d'eectuer des t^aches dont l'accomplissement necessite des durees de travail assez longues (plusieurs heures voir plusieurs jours) comme par exemple la redaction d'un document. Nous detaillons dans la suite les trois fonctions du GAC. 1. Specication d'activites : les modeles d'activites La specication d'une activite de groupe revient a denir les actions que chaque participant peut eectuer dans le contexte de l'activite, la nature des interac- tions entre les participants et les dierentes politiques de contr^ole qui gouver- nent l'evolution de l'activite (politiques d'enregistrement, de participation et de mediation). Une approche generale pour resoudre ce probleme consiste a four- nir un langage specique de description des activites comme c'est propose dans [Paoli et al.94],[Pons et al.96]. Les utilisateurs nals d'un environnement de co- operation n'etant pas des programmeurs, il est dicile de leur apprendre a utiliser un tel dispositif pour specier des nouvelles activites de groupe. Une alternative s'impose. Dans Colt nous avons opte pour le choix de fournir des modeles souples 3.5 Architecture generale 71 d'activites de groupe. La construction d'un modele d'activite est a la charge de l'administrateur de l'environnement qui peut employer un langage evolue pour realiser cette t^ache. Un modele denit la nature de l'activite (persistante ou ephemere), les poli- tiques de contr^ole qui peuvent ^etre appliquees et les actions que les utilisateurs peuvent eectuer dans le contexte de l'activite. La denition des privileges des uti- lisateurs repose sur un systeme d'attribution de r^oles fonctionnels (RF). Chaque RF est associe a un ensemble de regles d'acces qui determinent les actions per- mises pour ce r^ole. Nous expliquons la mise en uvre du systeme de protection applique dans une piece dans la section (3.5.1.4). Un RF particulier que l'on retrouve dans tout modele est le r^ole president. Le president a la charge de choi- sir les politiques de contr^ole a appliquer parmi les choix prevus par le modele de piece. Ce r^ole est attribue automatiquement a l'utilisateur qui cree l'activite. Cependant, le president peut demissionner en designant un successeur. Un seul utilisateur peut avoir ce r^ole dans la m^eme activite. Les politiques de contr^ole xees par un modele d'activite regroupent les stra- tegies d'enregistrement et d'integration (acces aux pieces) et les strategies de gestion de con its. L'enregistrement des utilisateurs et le deroulement des acti- vites dans une piece doivent verier certaines contraintes que nous appelons les conditions de la validite de l'activite. La violation d'une condition de validite en- tra^ne la terminaison ou la suspension de l'activite. Par suite, une activite peut ^etre dans l'un des etats suivants : Inactive si tout les participants sont deconnectes. Suspendue si certains participants sont connectes mais si une ou plusieurs conditions de validite de l'activite ne sont pas respectees. Active si toutes les conditions de validite sont remplies. Actuellement nous utilisons un seul type de conditions de validite qui consiste a exprimer des limites superieures et inferieures sur le nombre des utilisateurs connectes par r^ole fonctionnel. En general les conditions de validite servent pour forcer le respect de regles et de code de travail comme par exemple forcer l'ap- plication du principe de separation de pouvoirs ou certains r^oles fonctionnels ne peuvent pas ^etre attribues a la m^eme personne. Un aspect important dans la specication d'activites est la denition de la nature des interactions entre les utilisateurs. Dans les modeles fournis a present cet aspect reste implicite. Tous les utilisateurs presents en m^eme temps dans l'espace de l'activite interagissent entre eux d'une maniere synchrone. L'elabo- ration des modeles implantant des schemas d'interaction plus sophistiques reste une perspective. Trois modeles d'activite sont fournis par le prototype actuel : le modele d'un seminaire (voir tableau 3.3), le modele d'une reunion et le modele d'une rencontre. 72 Colt, un environnement de cooperation Parametres Valeur Nature Persistante, E phemere R^oles fonctionnels Orateur, Participant, President Strategies d'enregistrement Libre , Supervise Mediation Par tour de r^ole. Conditions de validite k Orateur k = 1 , k President k =1, k Participant k 20 Outil de conversation Tableau blanc, Bavardage. Tab. 3.3 - : Modele d'un seminaire. 1. Creation d'une activite La creation d'une nouvelle activite est faite par instanciation d'un des mo- deles fournis par le systeme. L'instanciation d'un modele resulte en la creation d'une entite logicielle dite contr^oleur d'activite (CA). En plus des parametres de- nis par le modele a partir duquel un CA est instancie, ce dernier comprend les informations suivantes : l'en-t^ete de l'activite est une cha^ne de caracteres qui decrit le but de l'acti- vite. L'en-t^ete est redige par l'utilisateur qui cree l'activite. Il est visible pour l'ensemble des participants eectifs et potentiels de l'activite. En consultant l'en-t^ete, un participant potentiel (invite) peut avoir une idee sur l'activite et en consequence ^etre en mesure de decider s'il veut partici- per ou non a l'activite en question. Il est a noter que l'information contenue dans l'en-t^ete ne peut pas ^etre traitee par le systeme. La distribution des r^oles fonctionnels. Il s'agit d'associer a chaque r^ole fonc- tionnel prevu dans le contexte de l'activite un groupe d'utilisateurs. La de- signation des utilisateurs qui peuvent jouer un r^ole fonctionnel se fait en associant a ce r^ole une combinaison de r^oles utilisateurs et organisationnels (voir 3.5.1.3). Cette association tient lieu d'invitation a participer a acti- vite ; chaque utilisateur designe directement (par son r^ole utilisateur) ou indirectement (par un r^ole organisationnel) est averti de la creation de l'ac- tivite. Un utilisateur peut avoir plusieurs r^oles fonctionnels a la fois. Nous montrons dans la section (3.5.1.4) comment resoudre les eventuels con its entre les r^oles. La liste des utilisateurs enregistres et la liste des participants actuels. La liste des documents appartenant a l'activite. 3.5 Architecture generale 73 3. Contr^ole de l'evolution d'une activite A chaque activite est attribue un identicateur unique qui la distingue des autres activites. Toutes les activites sont enregistrees dans une structure de don- nees specique geree par le GOR. Toute nouvelle activite commence par entrer dans l'etat inactif. Dans cet etat les utilisateurs potentiels, etant informes de l'existence de l'activite peuvent envoyer des requ^etes d'enregistrement. Le traite- ment de ces requ^etes est fait selon la politique xee par le president de l'activite. Une activite sort de l'etat inactif lorsque l'un des participants enregistres envoie au GOR une requ^ete d'integration a cette activite. Si la requ^ete d'integration est acceptee le contr^oleur de l'activite en question examine si toutes les conditions de validite de l'activite sont satisfaites. Le cas echeant, l'activite passe a l'etat actif. Sinon elle passe a l'etat suspendu. L'utilisateur qui a demande l'integration est mis en attente jusqu'a ce que l'activite passe a l'etat actif. Il peut cependant retirer sa demande d'integration (quitter l'activite). Pendant le deroulement de l'activite (dans l'etat actif) les participants com- muniquent via les outils d'aide a la conversation disponibles dans l'activite. Un participant peut apporter (par creation ou par importation) de nouveaux docu- ments a l'activite. Les documents sont manipules par les outils de production. Les outils d'aide a la conversation etant des outils concus specialement pour les groupes, ils orent leurs propres politiques de gestion de droit de parole. Par exemple, l'emploi de l'outil de bavardage est libre ; tout utilisateur peut envoyer un message texte a tout autre participant sans qu'il ait le droit de parole dans l'activite. Le choix de separer le contr^ole des outils de production de ceux d'aide a la conversation est justie par la dierence fonctionnelle entre les deux types d'outils. 3.5.1.4 Le gestionnaire de protection (GDP) Le principal but d'un systeme de protection est d'emp^echer l'acces et la mani- pulation des donnees par des utilisateurs non autorises. Une premiere phase dans le processus de contr^ole d'acces consiste a authentier les utilisateurs. L'authen- tication repose sur la procedure classique de presentation de mots de passe. Comme nous l'avons evoque dans la section (3.3), le Terrain est compose d'un espace partage et d'un ensemble de pieces. Par consequent un utilisateur ne peut ^etre que dans l'une des deux situations suivantes: 1) dans le Terrain, ou 2) dans une piece. Les mecanismes d'expression, d'administration et d'evaluation de droits d'acces sont similaires dans les deux situations. Dans le suivant nous presentons le systeme de protection du Terrain. Ensuite nous citons les points de dierence entre ce systeme et celui de la protection d'une piece. 74 Colt, un environnement de cooperation Protection du Terrain Expression de droits d'acces Nous utilisons le modele d'organisation presente dans (3.5.1.2) comme un sup- port d'attribution et d'expression de droits d'acces au Terrain. Chaque r^ole, utili- sateur ou organisationnel, est associe a un ensemble de regles de protection. Une regle de protection, r a la forme suivante : r = [ ; A ; O] Le signe au debut d'une regle determine si le droit A donne sur le(s) docu- ment(s) O est positif ou negatif. L'emploi de droits negatifs facilite d'attribution et la revocation selectives des droits. Par exemple pour donner a un r^ole R le droit de lire tous les documents d'un groupe G sauf pour un document parti- culier d 2 G il sut de lui donner le droit de lecture sur le groupe G et de lui interdire le lecture du d (lui attribuer un droit negatif de lecture sur d). Un droit A est exprime en fonction des cinq operations de base suivantes : 1. Administrer (A) donne la capacite de modier le prol de protection des objets designes. Ce droit peut ^etre attribue sur des groupes de documents ou sur des documents individuels. 2. Importer (I) donne la capacite d'introduire un nouveau document dans le groupe de documents designe. Naturellement ce droit s'applique unique- ment aux groupes de documents. 3. Exporter (E) donne la capacite d'extraire un document du groupe designe. 4. Editer (W) donne la capacite de modier (y compris eacer) le document ou le groupe de documents designe. 5. Lire (L) donne la capacite de lire le document ou le groupe de documents designes. Pour faciliter l'attribution des droits, des regles implicites d'inference sont denies sur les droits denis ci-dessus. Les regles d'inference sont les suivantes : (A ! I ; E:), (E ; I ! W:), (W ! L:), (E ! L:). L'interpretation des regles precedentes est directe. Par exemple la premiere regle implique qu'en attribuant le droit d'administration d'un groupe de docu- ments a un r^ole on lui attribue implicitement les droits d'importation et d'ex- portation a ce m^eme groupe. Ces regles d'inference sont utilisees par la fonction d'evaluation de droits d'acces que nous exposons plus loin dans cette m^eme sec- tion. 3.5 Architecture generale 75 Notre systeme d'expression de droits d'acces permet de denir des regles de protection qui sont synthetiques et precises. Par exemple pour interdire aux etu- diants de modier les donnees des enseignants il sut d'ajouter au r^ole organisa- tionnel etudiant la regle suivante : (-, W, Enseignant). Cette regle est valide pour tout etudiant qu'il soit declare avant ou apres l'introduction de cette regle. En m^eme temps nous pouvons exprimer des exceptions ; par exemple permettre a un etudiant privilegie de modier les documents d'un enseignant ou un document particulier en ajoutant a son r^ole utilisateur une regle de type (+ , W, Doc) ou Doc est le document en question. L'attribution des r^oles et la denition des regles au niveau de chaque r^ole utilisateur ou organisationnel est de la responsabilite de l'administrateur de Colt. Cependant un utilisateur a la possibilite de partager avec d'autres les privileges qui lui sont attribues. Deux principales fonctions sont fournies a cet eet : 1. La fonction de delegation de droits permet a un utilisateur de deleguer a un autre certains de ses propres privileges. La fonction de delegation prend la forme suivante : Deleguer (RU, R, +A, D), qui veut dire que l'utilisateur dont le r^ole utilisateur est RU delegue au r^ole R le droit A sur l'objet D. Le r^ole R peut ^etre un r^ole utilisateur ou organisationnel. Dans le cas ou R est un r^ole organisationnel la nouvelle regle de protection (le droit delegue) est ajoutee a tous les r^oles utilisateurs qui sont associes au r^ole organisationnel designe et pas au niveau du r^ole R lui m^eme. Un utilisateur ne delegue que des droits positifs. E videment il ne peut pas deleguer des droits qu'il ne possede pas. Un utilisateur qui possede un droit par voie de delegation ne peut pas le deleguer a d'autres utilisateurs. Les droits deleguees peuvent ^etre revoques en appliquant l'operation inverse Revoquer (RU; R; +A; D). 2. La fonction d'attribution de droits permet a un utilisateur d'attribuer a d'autres des droits sur des objets sur lesquels il a le droit d'administration. Cette fonction prend la forme suivante Attribuer(RU, R, A , D) qui veut dire que l'utilisateur RU attribue au r^ole R le droit A sur l'objet D. Le droit attribue peut ^etre positif ou negatif. Il est acquis denitivement par les utilisateurs ayant le r^ole R. Ceci veut dire que l'utilisateur recepteur peut attribuer ou deleguer le droit recu a d'autres utilisateurs. La fonc- tion d'attribution n'est valide que si l'utilisateur emetteur possede le droit d'administration sur les objets designes. D'autre part, dans le cas d'attri- bution d'un droit negatif, il ne faut pas que l'utilisateur recepteur soit un des proprietaires des objets designes. Par exemple, un utilisateur qui a le r^ole etudiant ne peut pas attribuer un droit negatif sur un document du groupe etudiant a un autre utilisateur qui a le m^eme r^ole organisationnel. Toute modication de droits d'acces d'un utilisateur prend eet immediate- ment. Le gestionnaire de protection previent l'agent colt de l'utilisateur concerne pour qu'il agisse en conformite avec les nouvelles regles qui lui sont attribuees. 76 Colt, un environnement de cooperation Par exemple si on interdit a un utilisateur de lire un document, l'agent colt de cet utilisateur va ^etre averti pour qu'il retire le document en question de la vue associe a l'utilisateur. Si cet utilisateur est en train de lire ce document l'AgC informe l'application a travers laquelle le document est manipule pour qu'elle quitte ce document. Une explication est donnee a l'utilisateur sous forme de boite de dialogue. E valuation des droits d'acces La fonction d'evaluation de droits d'acces est denie comme suit : Eval : U A O ! (False ; True) ou U est l'utilisateur qui demande d'appliquer l'operation A sur le document O. La fonction Eval renvoie 1 si la requ^ete d'acces est accordee, 0 sinon. A Chaque utilisateur est associe un graphe, dit graphe de privileges, qui est compose de son r^ole utilisateur et des r^oles organisationnels qui lui sont associes. La construction du graphe de privileges est faite en remontant les liens entre le r^ole utilisateur et la hierarchie organisationnelle. La gure (3.7) illustre le graphe de privileges de l'utilisateur U2 dans l'organisation illustree a la gure (3.5). Étudiant U2 ATER Chercheur Enseignant Fig. 3.7 - : Graphe de privileges associe a l'utilisateur U2 de l'organisation illustree a la gure (3.5) Pour evaluer une requ^ete d'acces, la fonction Eval applique un simple me- canisme d'inference sur les regles de protection portees par le graphe de privi- leges de l'utilisateur qui demande l'acces. L'evaluation d'une requ^ete en fonction d'une regle de protection peut donner l'un des trois resultats suivants : Acceptee, Refusee, Non Decidee. La procedure de l'evaluation est la suivante. E tant don- nee une requ^ete d'acces Q = (a ; d) dont le but est d'appliquer l'operation a sur le document ou le groupe de documents d et etant donne une regle de protection de la forme R = (Signe ; A ; D), le resultat de l'evaluation est la suivante : 1. La requ^ete est acceptee si d 2 D et A ! a et Signe == +. 2. La requ^ete est refusee si (d 2 D et a ! A et Signe == -). 3.5 Architecture generale 77 3. L'evaluation donne le resultat Non Decide dans les autres cas. La fonction Eval examine chacune des regles contenues dans le graphe de pri- vileges jusqu'a l'obtention d'une acceptation ou d'un refus explicite de la requ^ete. Si toutes les regles sont epuisees sans avoir une reponse explicite (acceptee ou re- fusee) la requ^ete est refusee. E videment, le resultat de la fonction Eval depend de l'ordre de l'exploration du graphe de privileges et de l'ordre de l'examen des regles de protection dans chacun des r^oles. Pour eviter tout ambigute d'interpretation, nous xons les regles d'evaluation suivantes : Dans un r^ole, la regle qui s'applique au groupe d'objets le plus specique contenant l'objet designe par la requ^ete est la regle prioritaire. Ainsi la regle qui designe un document par son identicateur est prioritaire sur les regles qui designent le groupe auquel appartient le document. Le graphe de privilege est explore en profondeur d'abord. Ceci donne la priorite au r^ole le plus a droit dans le graphe. Ainsi dans l'exemple illustre a la gure (3.7) le graphe est explore dans l'ordre suivant : U2 , ATER, E tudiant, Chercheur, Enseignant. Nous faisons l'hypothese ici que les r^oles sont coherents dans le sens qu'ils ne contientent pas de regles de protection contradictoires. Exemples d'evaluation des requ^etes d'acces Pour illustrer la procedure de l'evaluation d'une requ^ete d'acces nous prenons le cas de l'utilisateur U2 dont le graphe de privileges est illustre a la gure (3.7). Le tableau (3.4) donne les regles de protection contenues dans chacun des r^oles faisant partie du graphe precedent. Dans la specication des regles nous utilisons la notation diG pour designer un document di appartenant au groupe G. Par exemple d1ATER et d2ATER sont deux documents appartenant au groupe ATER. R^ole Regles U2 R1 : (+, A , U2), R2 : (-, L, d1Enseignant ).; R3 : (+, W, d2Chercheur ) ATER R4 : (+, A, ATER). R5 : (+, I, E tudiant). R6 : (+, I, Enseignant) E tudiant R7 : (+, A, E tudiant) Chercheur R8 : (+, A, Chercheur) Enseignant R9 : (+, A, Enseignant) Tab. 3.4 - : Exemples de regles de protection. 78 Colt, un environnement de cooperation Dans la suite nous enumerons quelques exemples de requ^etes d'acces avec leur resultats d'evaluation selon la procedure decrite ci-dessus. 1 =( Q W; d 1 ) est autoris U2 ee gr^ace a la regle 1. R 2 =( Q L; d Enseignant ) est autorise car c'est la regle 7 qui s'applique. 2 R 3 =( Q L; d Enseignant ) est refusee car c'est la regle 2 qui s'applique. 1 R 4 =( Q L; d Chercheur ) est autorisee car c'est la regle 3 qui s'applique. 1 R 5 =( Q W; d Doctorant ) est refusee car il y aucune regle qui l'autorise. 1 La protection d'une piece Le mecanisme de protection est semblable au me- canisme de protection du Terrain ; il sut de remplacer les r^oles organisationnels par les r^oles fonctionnels denis dans le contexte de la piece. Quatre dierences principales neanmoins existent entre les deux mecanismes de protection : 1. L'ensemble des r^oles fonctionnels a une structure plate ce qui simplie la fonction de l'evaluation des requ^etes d'acces. 2. Les droits sur les objets sont exprimes en fonction d'operations qu'on peut appliquer sur les donnees au lieu de simples operations d'administration de lecture et d'ecriture des documents. Par exemple dans une piece ou les utilisateurs elaborent ensemble un dessin, il peut y avoir besoin de specier qu'un r^ole fonctionnel a le potentiel de changer les couleurs des objets sans avoir le droit de les eacer. Pourtant les deux operations de changement de couleur et d'eacement d'objets sont des operations d'ecriture. L'emploi de droits a grains ns est dicte par le fait que dans une piece les utilisateurs sont plus proches les un des autres. Ils ont, par consequent, besoin d'une grille plus ne pour denir leurs marges de manuvre. 3. Le champ d'objet dans une regle de protection designe soit un document de cooperation appartenant a l'activite courante soit tous les documents existant dans la piece. 4. Le president de l'activite est le seul proprietaire de tous les documents manipules dans la piece. Par consequent il est le seul a pouvoir changer les droits des autres participants sur les documents contenus dans l'activite qu'il preside. 3.5.1.5 Le gestionnaire de la communication (GCM) Le gestionnaire de la communication fournit des mecanismes de transfert de donnees entre les dierents composants actifs (gestionnaires et agents) de l'envi- ronnement Colt. Le GCM fonctionne comme un courtier de messages. Les die- rents composants lui adressent des messages dont les destinataires sont species 3.5 Architecture generale 79 par leurs identicateurs ou par un critere associatif. L'emploi de criteres asso- ciatifs est restreint a la designation des agents colts (AgC). A la reception d'un message, le GCM fait la resolution des adresses des destinataires et s'occupe de l'acheminement du message. Pour eectuer la resolution des adresses le GCM maintient a jour une liste des adresses de toutes les entites actives dans l'environ- nement. Trois types de criteres de designation des agents peuvent ^etre employes : Les criteres fondes sur la combinaison des r^oles organisationnels et utilisa- teurs. Par exemple envoyer un message a tous les utilisateurs qu'ont le r^ole organisationnel Etudiant. C'est le cas typique d'un message envoye par le gestionnaire des activites pour informer les agents connectes au Terrain de la creation d'une nouvelle activite. Les criteres fondes sur la possession d'un privilege. Par exemple l'envoi d'un message a tous les agents connectes qui ont le droit de lire un document donne. C'est le cas typique d'un message envoye par le gestionnaire de l'espace de travail pour informer les utilisateurs de l'ouverture ou de la fermeture d'un document. Les criteres fondes sur l'appartenance a une activite donnee. C'est le cas de la diusion d'un message a tous les participants a une activite. Le GCM coopere avec les autres gestionnaires notamment avec le GET, le GAC et le GDP pour trouver la liste des identicateurs des agents designes a partir d'un critere associatif, puis il se refere a sa propre liste pour la resolution des adresses des destinataires. Le GCM supporte donc les deux paradigmes de communication : point a point et communication de groupe. Un probleme important que nous n'avons pas aborde est le probleme de l'ordonnancement des messages diuses a un groupe de composants. Pour l'instant, nous fournissons un support minimal d'un service de communication de groupe, a savoir la communication able a ordre FIFO. Outre l'acheminement de messages, le GCM ore aussi des mecanismes pour le telechargement d'informations plus complexes telles que des documents. En fait, il implante un protocole de transfert de chier (style ftp) qui permet d'echanger des documents entre le Terrain et les agents colts. 3.5.2 L'agent-colt (AgC) Un agent colt est une entite logicielle qui represente un utilisateur enregistre dans l'environnement. Il est charge de 1) presenter et gerer la vue attribuee a l'utilisateur et 2) fournir et contr^oler l'emploi des outils de production. Les deux fonctions d'un AgC sont detaillees ci-apres. 80 Colt, un environnement de cooperation 3.5.2.1 Presentation et gestion des vues A chaque utilisateur est attribue une vue sur le Terrain qui comprend les informations suivantes : 1. La liste des documents accessibles pour l'utilisateur. Chaque document pour lequel l'utilisateur a au moins le droit de lecture fait partie de cette liste. 2. Les activites dans lesquelles l'utilisateur est enregistre. 3. Les activites auxquelles l'utilisateur est invite. Les documents sont representes sur l'interface utilisateur sous forme ic^onique (voir 3.4) tandis que les activites sont representees sous forme de deux listes : la liste des activites courantes et la liste des invitations. Par suite pour visualiser la vue attribuee a l'utilisateur l'AgC maintient les structures des donnees suivantes : { Une liste des documents contenus dans la vue. Une entree dans cette liste contient les informations suivantes : le nom utilisateur du document, le pro- prietaire du document, l'application de manipulation du document (pour acher l'ic^one adequat) et l'etat d'utilisation du document (determine le mode d'achage de son ic^one). { Deux listes d'activites ; l'une contient les activites dans lesquelles l'utilisa- teur est enregistre et l'autre contient les activites auxquelles l'utilisateur est invite. Une entree dans une liste d'activite contient les informations suivantes : l'identicateur de l'activite, son en-t^ete et son etat actuel. La vue d'un utilisateur change d'une maniere dynamique en fonction de crea- tion et de destruction de documents et d'activites dans l'environnement et en fonction de changement de droits (par delegation, revocation ou attribution) de l'utilisateur. Toute modication apportee a la vue d'un utilisateur connecte au Terrain est immediatement notiee a l'AgC de cet utilisateur. La version initiale de la vue d'un utilisateur est calculee lors de son connexion au Terrain. La pro- cedure de la connexion d'un utilisateur au Terrain est schematisee sur la gure (3.8). 3.5.2.2 Denition et gestion d'un outil de production Un outil de production (OP) est compose des trois parties suivantes : La presentation gere les interactions de l'utilisateur avec l'outil. Le noyau fonctionnel implante les fonctions fournies par l'outil et gere les don- nees associees a l'outil. 3.5 Architecture generale 81 Fig. 3.8 - : Protocole de la connexion d'un AgC au Terrain. L'adaptateur est l'unite de contr^ole. Il conditionne le comportement de l'ou- til en fonction de son contexte d'utilisation et en fonction des droits que possede l'utilisateur sur le document manipule par l'outil. La gure (3.9) montre la disposition des trois parties constituant un OP et les interactions entre elles. L'adaptateur contr^ole le comportement de l'outil en fonction des instructions qu'il recoit de la part de l'AgC. Ce dernier possede les connaissances necessaires pour preciser le contexte de l'emploi d'un outil et par suite son comportement. A cet eet, l'AgC maintient une structure de donnees speciale qui contient pour chaque document employe par l'utilisateur local les informations suivantes : 1) les droits de l'utilisateur sur le document et 2) l'etat d'utilisation de ce document (individuel ou en groupe). Les informations prece- dentes sont obtenues lors de l'acces au document en question. L'adaptateur traduit les droits attribues a l'utilisateur sur un document en in- hibant les commandes non permises (griser les commandes non autorisees). Dans le cas ou le document est manipule par un groupe (dans une rencontre ou dans une piece), l'adaptateur se charge de contr^oler l'interaction de l'utilisateur avec les documents courants en fonction de la politique de gestion de droit de parole employee par le groupe. Par exemple dans le cas de l'utilisation d'une politique de tour de r^ole (ou par circulation d'un jeton) pour la gestion de droit de parole, l'AgC informe l'adaptateur s'il possede le jeton ou non. Si l'AgC possede le jeton l'adaptateur debloque l'outil et permet ainsi a l'utilisateur de modier le docu- ment. Lorsqu'un utilisateur applique une commande sur le document, le noyau fonctionnel envoie la commande appliquee a l'adapatateur qui se charge de l'en- voyer aux autres sites participant a l'activite. L'adaptateur traduit la commande 82 Colt, un environnement de cooperation AgC requêtes de configuration requêtes de manipulation du document opérations génériques à opérations génériques appliquées sur le document appliquer Adaptateur requêtes de configuration opérations réelles appliquées sur le document requêtes de manipulation du document opérations réelles à appliquer Noyau Fonctionnel requêtes d’affichage événements d’entrées Présentation Fig. 3.9 - : Structure d'un outil de production dans l'environnement Colt. en termes d'operations generiques. Les operations generiques sont les m^emes que celles employees pour specier les privileges attribues aux r^oles fonctionnels. A la reception, l'adaptateur de l'outil concerne par la commande traduit les operations generiques en operations reelles que le noyau fonctionnel peut executer. Le passage par des operations generiques permet d'employer des outils dierents pour mani- puler le m^eme document. Par exemple lorsqu'un utilisateur modie a travers un editeur de texte un document representant une page WEB qu'un autre utilisateur est en train de lire via un browser (les deux utilisateurs sont donc dans la m^eme piece) l'adaptateur du browser traduit l'operation en operation de rechargement de la page lue. Le principe d'echange d'operations generiques peut ^etre vu comme une generalisation de la cooperation par des outils heterogenes via l'implantation des protocoles inter-applications comme le propose [Karsenty et al.93b]. Au lieu d'implanter un protocole specialise par pair d'outils susceptibles d'^etre utilises pour manipuler un document, nous implantons un protocole par outil qui traduit les operations de cet outil en operations generiques. L'environnement Colt integre actuellement deux outils de production : un edi- teur graphique nomme ColtDraw et un browser d'images nomme ColtSlideShow. Les deux outils sont developpes en modiant des applications de demonstra- tion jointes a la distribution de la version 4.0 de Tk. Noter que le schema de construction d'OP decrit ci-dessus nous permet aussi de construire de nouveaux OP par integration d'applications existantes au niveau de l'application comme nous l'avons explique dans (3.3.3). 3.6 Realisation 83 3.6 Realisation 3.6.1 L'environnement de developpement Un premier prototype de l'environnement Colt a ete developpe sur un en- semble de stations Sun Sparc utilisant le systeme d'exploitation SunOs 4. Les developpements sont realises en utilisant le langage de programmation Tcl 7.0 et l'environnement graphique Tk 4.0 [Welch95]. Le choix de Tcl-Tk est motive par les arguments suivants : Tcl est un langage interprete. Il favorise a ce titre le prototypage et le test rapide des applications. Il permet aussi l'evolution facile (l'ouverture) et le changement dynamique de comportement des applications. L'environnement graphique Tk ore un large eventail de widgets graphiques necessaires pour le developpement des interfaces utilisateurs pour les ap- plications interactives (fen^etres, boutons, listes et menus, etc). Les widgets fournies sont tres adaptables. De plus Tk est un environnement extensible. Il est facile de creer de nouveaux widgets graphiques ou d'adapter le com- portement des widgets existants. L'environnement Tcl-Tk est disponible pour une grande variete de plates- formes telle que Unix, Linux, MacOS et MS-Windows. Par consequent Colt sera facilement portable a pour autres types de plates-formes. Il existe plusieurs interfaces du langage Tcl avec d'autres langages evolues notamment le C. L'existence d'une interface simple avec des langages com- piles remedie au defaut principal des langages interpretes a savoir leurs performances en termes de temps d'execution. Il est facile de remplacer les fonctions Tcl qui representent le goulot d'etranglement de l'application par des fonctions C alliant ainsi la performance a la simplicite de la program- mation. Un dernier argument mais pas le moins important est que l'environnement Tcl-Tk est disponible dans le domaine public. Il b enecie du support d'une communaute d'utilisateurs particulierement active qui accro^t sans cesse le nombre d'applications et d'extensions de cet environnement et qui fournit un support de documentation On-line a travers un groupe de News tres sollicite3 et plusieurs serveurs WEB. 3.6.2 Mise en uvre La mise en uvre de l'environnement Colt a ete fait de la maniere suivante. Un site central execute un processus unix qui implante les fonctions du Terrain et 3 comp.lang.tcl 84 Colt, un environnement de cooperation chaque site utilisateur execute un processus qui implante les fonctions de l'AgC. La communication entre les processus est faite en utilisant les sockets unix en mode connecte (en utilisant le protocole TCP/IP) [Comer92]. TCP/IP garantit la abilite de la communication et la reception des messages en ordre FIFO. La diusion d'un message a un groupe de processus est faite en maintenant N N connexions TCP/IP entre l'emetteur et les recepteurs. La description de la conguration de l'environnement (les utilisateurs, l'espace du travail, les regles de protection, , etc) est conserve dans de chiers textes ::: maintenus sur le site central. Chaque modication apportee a la conguration de l'environnement est immediatement enregistree dans le chier adequat. Un docu- ment Colt correspond a un ou plusieurs chiers unix (selon le type de l'application employee pour la creation et la manipulation du document). Par exemple un do- cument cree par l'application ColtDraw est un chier texte qui contient la liste des instructions Tcl necessaires pour redessiner les objets sauvegardes dans le document, tandis qu'un document genere par l'application ColtSlideShow corres- pond a plusieurs chiers unix : un chier par image contenue dans le document, un chier contenant les commentaires sur les images et un autre qui contient la liste des chiers unix precedents constituant le document. Le processus Terrain cree lors de son lancement une socket d'ecoute lie a un port de communication dont le numero est connu par tous les agents de l'envi- ronnement. Le paire constitue par le numero de port et l'adresse du site central identie d'une maniere unique l'adresse du Terrain. Pour acceder au Terrain un utilisateur execute sur son site local un processus AgC. Ce dernier commence par acher sur l'ecran de l'utilisateur une bo^te de dialogue qui demande a l'utilisa- teur d'entrer son nom et son mot de passe. Apres l'introduction des informations demandees, l'agent etablit un canal TCP/IP avec le Terrain a travers lequel il envoie la requ^ete de connexion. Si la requ^ete de connexion est valide le Terrain envoie a l'agent colt la vue attribuee au nouvel arrivant selon le protocole de connexion decrit dans (3.5.2). L'AgC se charge de la presentation graphique de la vue attribuee a l'utilisateur (voir gure 3.1). Le canal de communication est maintenu tout au long de la connexion de l'AgC au Terrain. Il sert a vehiculer les messages entre les deux entites. L'activation d'un outil correspond a l'execution d'un autre processus Unix qui implante l'outil. L'AgC communique avec les outils qu'il emploie via des canaux de communication TCP/IP. Ces canaux servent pour vehiculer les informations entre les adaptateurs des outils et l'AgC. Une seule instance d'un outil par site utilisateur peut ^etre active a la fois. Chaque activite de groupe est contr^olee par une entite specique dite le contr^o- leur de l'activite. Le passage d'une activite de l'etat inactif a l'etat suspendu ou actif se traduit par le lancement d'un nouveau processus unix sur le site du Ter- rain. Ce dernier processus etablit des canaux TCP/IP avec le Terrain et avec chaque AgC representant un utilisateur integre dans l'activite. La gure (3.10) illustre le schema d'implantation du prototype actuel. 3.7 Discussion et comparaison 85 Processus Ubix Autres AgC Terrain GaC Socket Unix canal TCP/IP AgC AgC OP OAC OAC OP OP Doc Doc Doc Site utilisateur Site utilisateur Fig. 3.10 - : Implantation de l'environnement Colt. 3.7 Discussion et comparaison Dans un premier nous presentons une breve comparaison entre l'environne- ment Colt et deux autres EdC. Le premier, EVC [Benford et al.95] est fonde sur la metaphore du terrain tandis que le deuxieme, TeamRooms [Roseman et al.96a] qui repose sur la metaphore de la piece. Ensuite nous presentons une comparai- son plus generale entre notre approches et les dierentes plates-formes presentees dans la section (2.5). 3.7.1 Environnements virtuels cooperatifs Un environnement virtuel cooperatif (EVC) marie les deux domaines de la realite virtuelle et du TCAO [Benford et al.95]. Le principe est de doter un sys- teme d'information (base de donnees, systeme de chiers) d'une representation visuelle abstraite qui englobe aussi les utilisateurs eux m^emes. Une representa- tion est dite abstraite si elle ne repose pas sur une metaphore de la realite phy- sique. Plusieurs approches de representations abstraites sont proposees dans la litterature. La representation proposee dans [Benford et al.95] est fondee sur une interpretation graphique des proprietes extrinseques et intrinseques des objets 86 Colt, un environnement de cooperation visualises. D'autres approches sont l'approche statistique et la structure hyper- texte. Chaque representation des donnees et des utilisateurs est augmentee d'une methode de navigation et de deplacement qui permet aux utilisateurs de se mou- voir dans l'espace. Chaque utilisateur a une vision de l'espace partage qui depend de sa position dans l'espace. Il voit aussi les autres utilisateurs qui sont dans son champ de vision. Si deux utilisateurs accedent en m^eme temps au m^eme objet, des liens de communication directes entre eux s'etablissent directement permettant ainsi leur cooperation (synchrone). Les utilisateurs peuvent communiquer direc- tement entre eux en clinquant tout simplement sur l'objet representant l'autre utilisateur. Ainsi un EVC est un systeme hybride qui regroupe des fonctions des systemes de cooperation a immersion et des systemes de cooperation contractuels (2.2.4). Cependant les EVC actuels ne supportent pas totalement la cooperation contractuelle. Ils implantent un modele de rendez-vous implicite. Les activites cooperatives dans un EVC sont les analogues des rencontres supportees par Colt. Les pieces n'existent pas dans un EVC. Un autre defaut des EVC est de negliger les aspects organisationnels du travail cooperatif. Tous les utilisateurs partagent tout l'espace d'information (pas de r^oles organisationnels). En fait la prise en compte de l'aspect organisationnel pose un probleme interessant au niveau de la representation de l'espace et des utilisateurs : Un utilisateur U voit-il un autre U y x si ce dernier manipule un objet O proche d'un objet O si l'objet O gure dans i j j la vue de U mais pas l'objet O ? Un autre probleme est celui de l'implantation y i des methodes de navigation : la representation spatiale des donnees impose t-elle des contraintes sur les deplacements des utilisateurs dans l'espace? Par exemple dans le cas d'une representation de type hypertexte faut-il suivre les liens? ou l'utilisateur peut-il sauter d'un objet a un autre sans respecter la topologie de l'espace? Un dernier probleme pose par le concept d'EVC est l'absence d'un es- pace prive et l'immersion des utilisateurs dans l'espace partage ? Des mecanismes de protection de la vie privee doivent ^etre fourni sinon le systeme ne peut pas ^etre utilisable [Salber95]. Les dierences majeures entre notre approche dans Colt et celle du EVC sont les suivantes : 1) l'absence d'une representation explicite des utilisateurs et l'absence d'une presentation spatiale de l'espace partage (le PIT) ce qui nous evite de traiter les problemes de la protection de la vie privee et de la navigation dans l'espace. 2) les EVC ne supportent pas la cooperation organisee. Le concept de piece n'etant pas supporte, aucune structure de contr^ole de la cooperation n'est mis en place outre l'etablissement des communications directes lorsque deux utilisateurs accedent au m^eme objet partage. 3.7.2 TeamRooms TeamRooms est un environnement de cooperation fonde sur la metaphore de la piece [Roseman et al.96b]. Pour cooperer les utilisateurs se connectent a un serveur central qui maintient une liste des pieces disponibles dans l'environne- 3.7 Discussion et comparaison 87 ment. Le concept de piece est semblable a celui employe dans Colt. Les pieces sont persistantes. Chaque piece contient un ensemble d'outils d'aide a la coope- ration (outil de bavardage, tableau blanc partage) et des outils de production et ore un ensemble de mecanismes de presentation de la co-presence (pointeur partage, liste des utilisateurs presents, , etc). La dierence principale entre ::: une piece Colt et une piece TeamRooms est que les outils de production dans TeamRooms sont des collecticiels ; ils sont construits a l'aide de la plate-forme GroupKit [Roseman et al.92] developpee par la m^eme equipe de recherche qui a developpe TeamRooms. Chaque outil de production (collecticiel) implante son propre modele de contr^ole (protocoles de contr^ole et r^oles fonctionnels). Par consequent le contr^ole de la co- operation varie d'un outil a un autre dans la m^eme piece. Une piece se resume a une collection de collecticiels. Une autre consequence du choix de collecticiels comme outils de production est que chaque utilisateur doit ^etre associe a un ou plusieurs r^oles fonctionnels par outil disponible dans la piece. Les r^oles fonctionnels ne sont plus denis en fonction de la nature de la t^ache a realiser (selon le type de la piece) mais en fonction des actions qu'un outil peut eectuer. Or compte tenu qu'il est impossible d'imaginer lors de la conception tout contexte possible d'utilisation d'un outil les r^oles fonctionnels denis par un outil ne peuvent qu'^etre generiques. Ceci peut poser un probleme lors de la denition d'une nouvelle t^ache (piece). Par exemple un collecticiel d'edition cooperative peut proposer les r^oles fonctionnels suivants : administrateur, redacteur et lecteur. Par exemple, la mise en page d'une publication requiert la denition d'un r^ole d'imprimeur qui doit avoir la possibilite de changer l'apparence du document sans pouvoir changer son contenu ni sa structure logique. Il est impossible dans TeamRooms de denir un tel r^ole sans modier le collecticiel d'edition employe. Par contre la denition du r^ole decrit ci-dessus est directe dans Colt ; il sut de creer ce r^ole fonctionnel et lui associer les operations necessaires pour la mise en page. 3.7.3 Comparaison generale L'environnement Colt presente une solution complete pour supporter le travail cooperatif contractuel. Il realise l'ensemble des objectifs que nous avons xes dans le paragraphe (3.2) a savoir : l'implantation d'un modele generique de rendez- vous, l'integration du travail individuel et du travail cooperatif et le support d'execution des scenarios cooperatifs varies. Les objectifs sont atteints gr^ace a la souplesse fonctionnelle et structurelle du systeme. Selon l'axe structurel Colt permet de denir et de reajuster dynamiquement les r^oles des utilisateurs, de denir autant d'activites de groupe que l'on souhaite et d'utiliser dans ces die- rentes activites les outils que l'on a besoin. Sur l'axe fonctionnel les utilisateurs peuvent denir et changer dynamiquement la conguration d'une activite. Le ta- bleau (3.5) dresse une comparaison fonctionnelle entre Colt et les plates-formes 88 Colt, un environnement de cooperation XTV Sol Mead GroupKit CoopScan ActiveMail GroupDesign Colt Rdv. explicite - - Rdv. implicite - - - - Groupe$individuel - - - - - Enregistrment libre - - - Enreg. supervise - - Participation dynamique - R^oles fonctionnels - - - - Interaction synchrone - Interaction asynchrone - - - - - Co-presence - - - Gestion de droits de parole - Conguration dynamique - - Ouverture - - - - Tab. 3.5 - : Comparaison fonctionnelle entre Colt et les plates-formes presentees dans la section 2.5. presentees dans la section (2.5). Dans ce tableau nous utilisons la notation sui- vante : pour implantation convenable, pour implantation partielle, , pour implantation absente et blanc pour implantation non precisee. Le tableau (3.5) montre que Colt repond a l'ensemble des besoins demandes a une plate-forme pour le travail cooperatif. C'est le choix de denir les fonctions de la cooperation au niveau des donnees qui nous a permis, en premier chef, d'atteindre cette degre completude fonctionnelle. D'autres travaux ont explore l'axe de denition de la cooperation au niveau des donnees. Un premier exemple est la plate-forme Mead presentee dans la sec- tion (2.5.5). Nous rappelons que la conception de Mead repose sur la denition d'un serveur d'objets partages (OSS) sur lequel a chaque utilisateur est attribue une vue personnalisee (UD). La vue d'un utilisateur est denie par des agents spe- ciaux (les UDA). Les UDA peuvent ^etre partagees par plusieurs utilisateurs ce qui rend possible l'implantation et la cohabitation des formes variees de cooperation. La souplesse de Mead, comparee a celle de Colt, est bien limitee. Elle est contr^olee par deux variables qui sont les relations UD-UDA et les relations UDA-OSS. Ainsi MEAD propose deux parametres de contr^ole (les deux relations citees ci-dessus) pour decrire ce que dans Colt est exprime par les r^oles utilisateurs, les r^oles orga- nisationnels et les modeles d'activites qui englobent la denition des r^oles fonc- tionnels et des politiques de contr^ole, d'enregistrement et de participation variees. Un UDA compile les concepts des r^oles organisationnels, utilisateurs et fonction- nels dans une seule entite logicielle. Il faut rappeler que MEAD est a l'origine concu pour realiser un systeme cooperatif de contr^ole aerien [Bentely et al.92a]. 3.8 Conclusion 89 Ayant une application cible bien denie justie la reduction de la souplesse du systeme au prot de la simplicite du contr^ole. La plupart des dimensions faco- nables dans Colt comme par exemple la structure de l'organisation, la natures des t^aches a realiser, les relations entre les membres de l'organisation, sont plus au moins connues a l'avance dans le cadre d'une organisation specique telle que un groupe de contr^oleurs aeriens. Les deux plates-formes CoopScan et GroupDesign qui sont fondees sur le prin- cipe d'integration d'applications existantes au niveau de l'application implantent a leur tour les fonctions de la cooperation au niveau des donnees gr^ace a l'ex- ploitation de la semantique des commandes utilisateurs. Les deux systemes ne se sont pas intresse au volet organisationnel du travail cooperatif mais ils s'appuient sur une representation explicite des activites a realiser (denition explicite des sessions de travail en groupe). Dans CoopScan la propagation des actions entre les sites repose sur l'implantation d'un protocole specique par application employee entre l'agent local et ses representants sur les autres sites. GroupDesign etend l'experience de CoopScan en implantant des protocoles inter-applications ce qui permet d'utiliser des applications heterogenes dans la m^eme session. Dans Colt nous generalisons l'approche de GroupDesign en employant le concept d'opera- tions generiques. Au lieu d'implanter un protocole d'echanges d'actions par paire d'applications integrees, nous fournissons un seul module de traduction entre les operations eectives des applications et les operations generiques qui les re- presentent. La plate-forme GroupDesign presente, par rapport a CoopScan et a Colt, l'avantage de fournir des outils de fragmentation des documents employes et des commandes pour specier les droits d'acces des utilisateurs aux dierentes fragments. La fragmentation dynamique des documents permet d'envisager des formes plus variees de cooperation comme par exemple ^etre en cooperation syn- chrone sur un fragment du document et en asynchrone sur un autre fragment du m^eme document. L'environnement Colt a aussi ses limits. Le premier est le manque d'un langage evolue pour la specication des activites cooperatives comme c'est dans [Paoli et al.94]. De plus, les modeles d'activites fournis par Colt sont tres simples. Les interactions possibles entre les utilisateurs sont limi- tees : si les utilisateurs sont en m^eme temps dans la m^eme piece, ils sont forcement en mode d'interaction synchrone. Un autre probleme non traite par Colt est celui des apartes qui peuvent avoir lieu dans une activite [Villemur95]. 3.8 Conclusion Le concept d'environnement de cooperation represente la derniere etape de l'evolution des systemes interactifs. Du paradigme d'interaction 1 $ 1 c'est a dire le dialogue homme-application, les systemes interactifs ont evolue vers le paradigme 1 $ N ou un seul utilisateur interagit avec plusieurs applications a la fois, puis vers le paradigme M $ 1 qui represente les collecticiels ou un en- 90 Colt, un environnement de cooperation semble d'utilisateurs interagissent entre eux via le partage d'une application. En n, un EdC implante le paradigme M $ N ou plusieurs utilisateurs travaillent ensemble en utilisant plusieurs applications. Dans ce chapitre, nous avons pro- pose une approche originale pour la construction d'un environnement d'EdC qui soit adaptable tant au niveau structurel qu'au niveau fonctionnel. Notre approche consiste a : 1) implanter un espace partage par les utilisateurs ou chacun peut voir et se mouvoir selon des r^oles organisationnels qui lui sont attribues et 2) fournir des mecanismes de representation et de manipulation explicite des acti- vites cooperatives (gestion explicite des pieces partagees). La conception de Colt presente plusieurs points innovant, en particulier l'abondon du principe de par- tage d'applications pour cooperer au prot du reassemblage des outils individuels dans l'espace d'une activite. Un autre point interessant est l'implantation d'un modele souple pour la denition et l'evaluation des droits d'acces et de regles de protection de l'espace partage. Une nouveaute presentee par ce modele est l'introduction de la notion du r^ole utilisateur comme un r^ole a part entiere au- quel nous pouvons associer des privileges exceptionnels (positifs ou negatifs). Une comparaison avec d'autres plates-formes et environnements de cooperation nous a montre la richesse fonctionnelle de notre proposition. La faisabilite du concept est demontree par le developpement d'un prototype reduit. Cependant un probleme qui reste ouvert et dont sourent la plupart des collecticiels, est celui de l'utilisabilite de l'environnement. L'etude d'utilisabilite necessite des compe- tences pluridisciplinaires qui n'etaient disponibles lors du prototypage de notre environnement. Chapitre 4 Contr^ ole de la concurrence dans les collecticiels synchrones 4.1 Introduction Nous etudions dans ce chapitre le probleme de gestion des acces concurrents aux donnees partagees dans les collecticiels synchrones. Nous considerons ici les collecticiels synchrones a architecture totalement dupliquee. Nous rappelons que la plupart des collecticiels synchrones sont mis en uvre selon ce type d'archi- tecture qui presente les avantages suivantes : Un court temps de reponse puisque tous les traitements sont faits en local. Un trac reseau reduit puisque seules les requ^etes des utilisateurs sont ve- hiculees a travers le reseau. Une bonne disponibilite des donnees et une bonne resistance aux pannes due a la duplication des ressources. Selon cette architecture chaque utilisateur possede sa copie locale des donnees. Il est evident que si rien n'est prevu pour contr^oler l'acces et les mises a jour des copies locales les dierentes copies peuvent devenir mutuellement incoherentes. L'incoherence rend dicile l'avancement de la t^ache du groupe. La resolution de ce probleme repose sur l'emploi d'un mecanisme qui contr^ole les modications concurrentes des objets dupliques. Le probleme pose ci-dessus est le m^eme que celui de la gestion des caches1 dans les systemes repartis [Balter et al.91]. De nombreux protocoles sont proposes dans la litterature des systemes repartis pour resoudre ce probleme. Malheureu- sement ces protocoles ne satisfont pas les besoins des collecticiels synchrones. A 1Un cache est un dispositif materiel ou logiciel qui conserve une copie d'une information dite primitive, l'acces a la copie du cache etant plus rapide que l'acces a l'information primitive. 92 Contr^ ole de la concurrence dans les collecticiels synchrones l'origine de cette inadequation se trouve l'aspect interactif des collecticiels. Nous developpons ce point dans le paragraphe suivant. L'inadequation des protocoles classiques de gestion de la concurrence La mise en uvre de l'interface utilisateur d'une application interactive repose generalement sur le principe de la manipulation directe [Shneiderman83]. Selon ce principe, pour modier un objet l'utilisateur interagit directement avec une representation de cet objet sur l'interface utilisateur. Par exemple dans un editeur graphique, pour changer la taille d'un rectangle l'utilisateur selectionne d'abord le rectangle a modier puis deplace l'un de ses angles jusqu'a l'obtention de la taille desiree. Selon le principe de la manipulation directe toutes les copies dupliquees sont en etat de lecture permanent. Ainsi les protocoles classiques qui garantissent la coherence des copies dupliquees au lecture ne trouvent pas leur place dans le contexte des collecticiels. Une autre consequence de ce principe est que toute mo- dication d'une copie locale est immediatement visible sur l'interface utilisateur sur le site local. Les protocoles qui peuvent produire des sequences de d'annu- lation d'operations, suite a l'annulation d'une transaction par exemple, peuvent alors generer une confusion chez l'utilisateur [Greenberg et al.94]. D'autre part, toute mise en uvre du principe de la manipulation directe est contrainte de verier deux proprietes fondamentales : 1) l'honn^etete de la representation des objets et 2) la reduction du temps de reaction a toute action de modication d'un objet. Une representation est honn^ete si elle est conforme a l'etat interne de l'objet represente. L'honn^etete implique que toute modication d'un objet sur un site doit ^etre notiee au plus vite possible aux autres sites. La deuxieme propriete implique que le temps de reponse du collecticiel doit ^etre le plus court possible. Par consequent, les collecticiels synchrones posent des contraintes temporelles plus severes que celles posees par les applications reparties classiques (transparentes). Une derniere propriete requise pour les collecticiels et qui est mal supportee par les protocoles classiques de gestion de la concurrence est celui la presentation de la co-presence des utilisateurs dans l'espace du collecticiel. Les protocoles clas- siques sont fondes sur le principe de la transparence de la concurrence ou chaque utilisateur a l'illusion qu'il est le seul a utiliser le systeme. Or la presentation de la co-presence des utilisateurs necessite de prevenir chaque utilisateur de la position et des actions faites par tout autre participant. Par exemple, lorsqu'un utilisa- teur verrouille un objet en vue de le modier, les autres utilisateurs du systeme doivent ^etre prevenus du verrouillage de cet objet et de l'identite de l'utilisateur qui l'a fait. Ayant les informations precedentes, les utilisateurs seront en mesure de negocier entre eux la possession des droits d'acces a chaque objet du systeme. Nous presentons le probleme de gestion des acces concurrents et les princi- pales proprietes requises d'un protocole de gestion de la concurrence, dit aussi 4.2 Denition du probleme 93 protocole de gestion de droits de parole ou encore protocole de mediation, dans la section (4.2). Une classication des protocoles existants est donnee dans la section (4.3), les dierents mecanismes et politiques de mise en uvre des pro- tocoles identies sont resumes dans la section (4.4). Une comparaison entre les dierentes approches en termes de leur satisfaction des proprietes enumerees dans (4.2.1) est faite dans la section (4.4.3). Nous savons a l'avance qu'il n'existe pas un protocole qui peut ^etre employe dans tout type d'activite cooperative. L'etude menee dans [Greenberg et al.94] montre qu'un collecticiel synchrone doit implan- ter plusieurs protocoles de gestion de droit de parole. Nous ajoutons a l'ensemble des protocoles proposes dans la litterature du TCAO un nouveau protocole que nous appelons LICRA (4.5). LICRA est un protocole completement automatique (ne necessite pas l'intervention des utilisateurs) ; par consequent il est facile a utiliser par les utilisateurs nals. Il permet au collecticiel d'avoir un temps de reponse optimal. L'approche empruntee par LICRA est la suivante : chaque utili- sateur peut modier sa copie locale des donnees a n'importe quel moment. Toute operation est executee immediatement sur la copie locale ce qui permet d'avoir un temps de reponse optimal. Chaque operation executee sur un site est diusee aux autres sites participant a la session. A la reception d'une operation LICRA execute une procedure qui garantit que toutes les copies des donnees sur tous les sites soient les m^emes lorsque toutes les operations generees dans la session sont recues et traitees par tous les sites. En contre partie de la simplicite et de l'ecacite du protocole propose se trouve une lourde procedure d'installation : La procedure automatique de la resolution des con its s'appuie sur l'exploitation des connaissances semantiques des operations echangees entre les sites. 4.2 Denition du probleme 4.2.1 Modelisation d'un collecticiel synchrone Nous decrivons dans cette section un modele abstrait d'un collecticiel syn- chrone a architecture dupliquee. Ce modele nous sert a clarier les proprietes requises d'un protocole de gestion de la concurrence que nous presentons dans la section qui suit. Nous utilisons le terme session pour designer l'execution d'un collecticiel syn- chrone. Une session S a l'instant t est denie par : S = f ; g ou est t t t t l'ensemble des sites impliques a l'instant t et l'ensemble des fonctions four- t nies par le collecticiel au m^eme instant. Les compositions des deux ensembles precedents varient avec le temps. La composition de change en fonction de la connexion et de la deconnexion des utilisateurs tandis que la composition de change en fonction du lancement et de la terminaison d'applications. Un site 2 est deni par le couple : = (P ; O ) ou i est l'identicateur i t i i i du site, P est le processus du site et O la copie locale des donnees manipulees i i 94 Contr^ ole de la concurrence dans les collecticiels synchrones par le collecticiel. L'ensemble O comprend des objets passifs qui representent les i donnees utilisateurs. Le processus d'un site execute quatre types d'actions : 1. Generation d'une operation qui correspond a la demande de l'application d'une operation a travers l'interface-utilisateur. 2. Execution d'une operation qui correspond a l'application d'une operation generee localement ou recue d'un autre site sur la copie locale de donnees (O ). i 3. Diusion d'une operation qui correspond a la diusion d'une operation generee localement vers les autres sites. 4. Reception d'une operation qui correspond a la reception d'une operation envoyee par un autre site. La gure (4.1) illustre le modele d'un site. Génerateur Vers les autres sites Emetteur Queue d’attente Exécution Objets du site Provenant des autres sites Recepteur Site1 Fig. 4.1 - : Modelisation d'un site dans un collecticiel synchrone a architecture dupliquee. Le deroulement d'une session est fait de la facon suivante : lorsqu'un utilisa- teur demande l'application d'une commande, via l'interface homme-machine, le processus de son site genere une ou plusieurs operations. Les operations generees sont inserees dans une le locale d'operations en attente d'execution. Parallele- ment, le processus du site diuse les operations generees aux autres sites dans la session. Les operations recues des autres sites sont egalement inserees dans la m^eme le d'attente. L'ordre d'insertion et d'extraction des operations de la le d'attente depend du protocole de gestion de la concurrence employe. Nous presentons les dierentes politiques et schemas de mise en uvre de protocoles de gestion de la concurrence dans la section (4.3). 4.2 Denition du probleme 95 4.2.2 Proprietes Nous enumerons dans la suite les principales proprietes requises d'un protocole de gestion de la concurrence dans les collecticiels synchrones. La correction L'objectif principal d'un protocole de gestion de la concurrence est de preserver la coherence des donnees dupliquees. La verication de cette propriete n'a de sens qu'aux instants ou toutes les operations generees par tous les sites sont recues et traitees par tous les autres sites. De tels instants, denotes par QT , sont appeles les instants de repos. La propriete de la correction s'ecrit alors de la maniere suivante : 8t 2 QT ; 8i ; j 2 t : Oi = Oj L'interactivite L'interactivite est mesuree par deux parametres : le temps de reponse et le temps de notication. Le premier (respectivement le dernier) correspond a la duree qui separe le lancement d'une action de la visualisa- tion de ses eets sur l'ecran de l'utilisateur local (respectivement les ecrans des utilisateurs distants). Un collecticiel a un temps de reponse optimal si toute operation locale est executee immediatement. Le temps de noti- cation, entre deux sites, (denote TN ), est donne par la formule suivante : TN = Te + Tr + Tl o u: Te est le temps necessaire pour preparer l'emission de l'operation. Tr est le temps qui separe l'emission d'un operation de sa reception sur le site distant. Autrement dit Tr est le temps du passage de l'operation dans le reseau. Tl est le temps qui s epare la reception d'une operation de son execution sur le site recepteur. Le temps Tr depend des caracteristiques du reseau employe. Par consequent, un protocole de gestion de la concurrence doit chercher a minimiser Te et Tl. L'interactivite se resume donc a minimiser le passage des operations dans les les d'attente sur les sites participant a la session. La faisabilite Il s'agit de reduire le surco^ut du fonctionnement du protocole. Cette propriete exprime des contraintes sur la consommation des autres ressources comme l'espace memoire et le debit du reseau de communication. Par exemple il faut eviter d'employer de structures de donnees dont la taille augmente avec le temps (ex. les logs d'execution) ou au moins prevoir de mecanismes de reduction qui limite la croissance monotone de ce type des structures de donnees. 96 Contr^ole de la concurrence dans les collecticiels synchrones L'ergonomie de l'interface-utilisateur Une liste des proprietes ergonomiques qu'il est souhaitable qu'une interface-utilisateur d'une application interac- tive verie est donnee dans [Abowd et al.92]. La mise en uvre d'un proto- cole de gestion de la concurrence doit respecter ces proprietes ergonomiques. Nous citons deux proprietes particulierement importantes : La pro-activite caracterise les retours qui indiquent a l'utilisateur les actions interdites. Par exemple dans le cas de l'emploi d'une politique fondee sur le verrouillage, les objets verrouilles doivent ^etre mis en relief an qu'un autre utilisateur n'essaie pas de les modier. La stabilite du temps de reponse denote la capacite du systeme a en- tretenir un m^eme temps de reponse pour un traitement donne. Autre- ment dit il est souhaitable que le surco^ut introduit par le protocole de gestion de la concurrence soit constant. La simplicite de l'emploi L'eort que chaque utilisateur doit fournir pour la coordination d'un travail cooperatif doit ^etre nettement inferieur au prot apporte par l'utilisation du collecticiel [Grundin88]. Par consequent il est souhaitable que l'intervention des utilisateurs dans le contr^ole de l'execution d'un protocole de gestion de la concurrence soit aussi reduit que possible. A une extremite de ce critere nous trouvons les protocoles automatiques, a l'autre extremite il y a les protocoles manuels. 4.3 E lements d'un protocole de gestion de la concurrence Nous decomposons un protocole de gestion de la concurrence en trois couches, dites modeles : 1) le modele de la concurrence, 2) le modele de la coherence et 3) le modele de la communication. 1. Le modele de la concurrence decrit le degre de parallelisme supporte par le protocole. Trois degres de concurrence sont identies : 1. Tout ou rien ou un seul utilisateur a le droit de modier l'espace partage a un instant donne. 2. Acces paralleles ou plusieurs utilisateurs peuvent modier des zones die- rentes et independantes dans l'espace partage ou bien appliquer des opera- tions non contradictoires sur un m^eme objet. Un exemple est l'application sur un objet graphique les deux commandes : ChangerCouleur et Changer- Taille. 4.3 E lements d'un protocole de gestion de la concurrence 97 3. Acces simultanes ou plusieurs utilisateurs peuvent modier en m^eme temps les m^emes donnees (chacune sur son site local). 2. Le modele de la coherence decrit les contraintes imposees aux mises a jour des objets dupliques. Des denitions formelles de dierentes criteres de coherence sont donnees dans [Raynal et al.95]. Nous citons dans la suite trois types de coherence les plus employes : 1. La coherence faible selon laquelle la mise a jour de toute copie doit avoir lieu au bout d'un temps borne ; neanmoins aucune contrainte n'est imposee sur l'ordre de mise a jour. 2. La coherence causale complete la coherence faible par la contrainte suivante : les modications de toutes les copies doivent ^etre faites selon l'ordre causal des mises a jour. L'ordre causal est deni comme suit. Si une operation Opm est g eneree sur un site i apres l'execution d'une operation Opn alors l'execution de Opm prend lieu apres l'execution de Opn sur tous les autres sites. 3. La coherence forte (dite aussi coherence sequentielle) complete la coherence faible par la contrainte suivante : les modications de toutes les copies doi- vent ^etre faites dans le m^eme ordre. 3. Le modele de la communication decrit les proprietes du protocole de communication de groupe sur lequel s'appuie le protocole de gestion de la concur- rence. Deux proprietes decrivent le comportement d'un protocole de communica- tion de groupe : 1) la abilite et 2) l'ordre de delivrance de messages. Un protocole de communication est able s'il garantit que tout message emis par un site est recu correctement par tous les autres sites au bout d'un temps ni et borne. En ce qui concerne l'ordre de livraison de messages plusieurs relations d'ordre peuvent ^etre denies. Trois relations d'ordre classiques sont les suivantes [Raynal90] : 1. L'ordre FIFO selon lequel deux messages consecutifs emis par le m^eme site sont recus par tous les autres sites dans leurs ordre d'emission. 2. L'ordre causal selon lequel la livraison de messages est faite selon l'ordre causal. 3. L'ordre total selon lequel les processus des sites recoivent dans le m^eme ordre les operations generees dans la session. Les deux modeles de la concurrence et de la coherence constituent le cahier de charge du concepteur d'un protocole de gestion de la concurrence tandis que 98 Contr^ ole de la concurrence dans les collecticiels synchrones le modele de la communication fait partie des caracteristiques de l'environne- ment de l'execution du collecticiel. Le probleme de la conception d'un nouveau protocole est alors exprime de la maniere suivante : etant donne un modele de communication, comment faire pour realiser tel modele de concurrence et tel mo- dele de coherence tout en respectant au mieux les proprietes citees dans la section (4.2.1)? La simple combinaison des deux modeles de la concurrence et de la coherence denit huit classes fonctionnellement dierentes de protocoles de gestion de la concurrence. Quelle classe est la plus adaptee pour les collecticiels synchrones? Plusieurs etudes dans le domaine du TCAO ont montre qu'il n'existe pas un seul protocole qui soit adapte a tous les collecticiels synchrones ou m^eme a toutes les executions du m^eme collecticiel. A titre d'exemple, nous enumerons dans la suite quelques parametres qui peuvent in uencer le choix du protocole a appliquer. Le nombre de participants. Si le nombre de participants est petit, il y a plus de chance que les utilisateurs arrivent a coordonner leurs actions en s'appuyant simplement sur les retours visuels indiquant la position de cha- cun d'eux. Dans ce cas un protocole a haut degre de concurrence peut ^etre employe sans provoquer beaucoup de con its. La probabilite de l'occurence d'un con it augmente avec l'augmentation du nombre de participants. Pour un grande nombre il est preferable d'appliquer un protocole a faible degre de concurrence. La nature de la session. Dans une session de tele-enseignement ou d'une seminaire l'orateur est le seul a pouvoir adresser le parole a l'ensemble des participants. Pour intervenir, un utilisateur demande normalement l'autori- sation de l'orateur. Les politiques a forte degre de concurrence ne trouvent leur place dans pareilles sessions. La nature des applications employees. Par exemple dans un collecticiel de vote il est possible d'employer un protocole a coherence faible puisque l'ordre de mise a jour des votes n'in uence pas le resultat nal. Par contre dans un collecticiel d'edition il est souhaitable que les utilisateurs percoivent les mises a jour selon un ordre causal an de mieux comprendre l'evolution du document. 4.4 Mise en uvre d'un protocole de gestion de la concurrence Nous identions deux niveaux distincts dans la mise en uvre d'un protocole de gestion de la concurrence : le niveau des mecanismes employes et le niveau de la politique d'exploitation des mecanismes choisis. 4.4 Mise en uvre d'un protocole de gestion de la concurrence 99 4.4.1 Les mecanismes Deux types de mecanismes sont generalement employes : le verrouillage et l'ordonnancement des operations. 1. Le verrouillage Le principe est de lier la capacite de modier un objet a l'acquisition d'un verrou exclusif sur cet objet. La gestion des verrous necessite l'introduction des fonctions suivantes : 1. DemanderVerrou (Objet). L'execution de cette fonction est une condition necessaire mais non susante pour verrouiller un objet ; la requ^ete de ver- rouillage peut ^etre rejetee. Par exemple lorsque deux utilisateurs demandent en m^eme temps de verrouiller le m^eme objet, le systeme d'allocation de ver- rous est contraint de preferer l'un a l'autre. 2. AttribuerVerrou(Objet,U). Cette fonction verrouille l'objet Objet au pro- t de l'utilisateur U . A partir de ce moment et jusqu'a la liberation de l'objet designe, seul U a le droit de modier cet objet. 3. LibererVerrou(Objet). Cette fonction permet de rel^acher le verrou associe a un objet. L'objet designe devient de nouveau libre. D'autres utilisateurs peuvent alors le verrouiller. La plupart des systemes cooperatifs implantant de protocoles de verrouillage rendent visible a chaque utilisateur le contenu de la table d'allocation de ver- rous. L'achage du contenu de la table d'allocation revient a presenter sur l'in- terface utilisateur les objets verrouilles et l'identite des detenteurs des verrous [Baecker et al.93, Karsenty94a]. 2. La detection de dependances Le principe est de denir une relation d'ordre sur l'ensemble des operations generees dans la session et de garantir que sur chaque site l'execution de la session donne le m^eme resultat que l'execution des operations selon l'ordre deni. Une operation Opx depend directement d'une operation Opy (denote Opy 7! Opx ) si Opx est generee sur un site immediatement apres l'execution de Opy sur le m^eme site. Sur l'exemple illustre a la gure (4.2) nous avons Op1 7! Op2 et Op1 7! Op3. Deux operations Opx et Opy sont en concurrence (denotees Opx k Opy ) si aucune d'elles ne depend de l'autre. Ainsi dans l'exemple precedent nous avons Op2 k Op3 . Plusieurs mecanismes sont elabores an d'ordonner les operations dans un sys- teme reparti. Parmi ceux-ci nous citons l'emploi d'horloges logiques [Lamport78] et les horloges vectorielles [Fidge88]. Un mecanisme d'estampillage denit la structure de l'estampille, la fonction de mise a jour de l'estampille et une relation de comparaison entre estampilles. La relation de dependance entre operations 100 Contr^ole de la concurrence dans les collecticiels synchrones Op1 Site1 Op1 Op2 Site2 Op2 Op3 Site3 Op3 Op4 Op4 (a) (b) Fig. 4.2 - : Exemples de relations de dependance et de concurrence entre opera- tions. n'etant pas une relation d'ordre global le systeme est complete par une fonction de priorite entre les sites an de pouvoir ordonner les operations concurrentes. 4.4.2 Les politiques Bien evidement la denition d'une politique depend de la nature des me- canismes a employer (verrous ou estampilles). Cependant nous identions trois criteres de classement de politiques qui sont les suivants : 1) la demarche, 2) la resolution et 3) l'automatisme. 1. La demarche Nous identions deux demarches possibles : la demarche pes- simiste et la demarche optimiste. La demarche pessimiste repose sur le principe d'eviter les con its. Chaque operation est soupconnee d'^etre en con it avec une autre. Une operation n'est executee qu'apres avoir contr^ole l'absence des con its. Dans le cas d'utilisation de verrous, une politique pessimiste ne permet pas la modication d'un objet avant l'acquisition denitive d'un verrou sur cet objet. Un protocole pessimiste qui repose sur une technique de detection de dependances force l'execution eective des operations selon l'ordre employe. Une demarche optimiste consiste a proceder par certication d'absence de con its apres l'execution des operations. En cas de detection d'un con it la po- litique fait appel a un mecanisme de reperartion (ou de restauration de la cohe- rence) qui ramene le systeme a un etat coherent. 2. La Resolution Il s'agit de denir le degre de la concurrence supporte par la politique (voir 4.3). 3. L'automatisme Il s'agit de denir le degre d'implication des utilisateurs dans le contr^ole de deroulement du protocole. Theoriquement toute fonction de manipulation des mecanismes employes par un protocole peut ^etre declenchee par le systeme ou par un utilisateur. Dans le premier cas nous disons que la fonction est declenchee d'une maniere implicite tandis que dans le deuxieme cas nous disons que la fonction est declenchee d'une maniere explicite. 4.4 Mise en uvre d'un protocole de gestion de la concurrence 101 Pour xer les idees, prenons l'exemple d'une politique qui repose sur un me- canisme de verrouillage et dont la taille de verrou est egale a la taille de l'espace tout entier (cas d'un protocole de tour de r^ole). La tableau (4.1) illustre quelques variations possibles des protocoles de tour de r^ole selon la nature de l'utilisation des fonctions de gestion du verrou. Dans ce tableau le lettre E (respectivement I ) designe une manipulation explicite (respectivement implicite). Demande Liberation Attribution Animation E/I E E FIFO E E/I I D esignation E E E Anneau I E/I I Temps partag e I I I Tab. 4.1 - : Exemples de protocoles de tour de r^ole. Dans certains cas, le choix du mode d'utilisation d'une fonction est reglee d'avance. Par exemple dans un protocole a base de detection de dependance il est peu utile que l'estampillage des operations soit fait par les utilisateurs ! Plus un protocole est automatise, plus son utilisation est simple, mais moins il est souple. Les decisions faites par le systeme dans la cadre de l'automatisa- tion d'un protocole peuvent ne pas correspondre a l'attente des utilisateurs. Par exemple dans un protocole a base de verrouillage quelle taille choisir pour un ver- rou? Quand faut-il demander un verrou? et quand faut-il le liberer? Une autre fonction dont l'automatisation est tres controversee est la fonction de restauration de la coherence des copies que tout protocole a politique optimiste doit utiliser. La restauration automatique de la coherence des copies s'appuie forcement sur une fonction de priorite entre les sites. La simple suppression des contributions faites par un site defavorise peut priver le groupe des contributions interessantes. En contre partie, la restauration manuelle de la coherence necessite l'implantation d'un systeme de gestion et de presentation de versions de donnees [Condon92], [Moran et al.93]. Lorsque deux utilisateurs modient en m^eme temps un m^eme objet le systeme cree deux versions de cet objet, une par modication. Or si les utilisateurs ne decident pas rapidement quelle version il faut adopter, le nombre de versions va augmenter d'une maniere exponentielle suite a des modications concurrentes des versions initiales ; la gestion et la representation du document deviennent de plus en plus lourdes. 102 Contr^ole de la concurrence dans les collecticiels synchrones 4.4.3 Exemples 4.4.3.1 Tour de r^ole Un protocole de tour de r^ole implante un modele de concurrence de type tout ou rien ; le modele de la coherence peut ^etre la coherence faible ou la coherence forte. Le principe est d'associer la capacite a modier l'espace partage a l'acqui- sition d'un verrou unique dit le jeton. Le fait qu'un seul utilisateur peut modier l'espace partage a un moment donne rend equivalents les deux modeles de la cohe- rence causale et la coherence forte. Une strategie de negociation de la possession du jeton (ou negociation de droit de parole) decrit le protocole de circulation du jeton entre les participants a la session. L'implantation d'une strategie fait appel aux trois mecanismes suivants : 1) Demande du jeton, 2) Liberation du jeton et 3) Attribution du jeton. Chacun des mecanismes precedents peut ^etre implante d'une maniere explicite ou implicite. Le tableau (4.1) illustre les principales strategies de negociation de possession du jeton. La validite d'un protocole de tour de r^ole repose sur l'existence d'un jeton unique, qui peut ^etre mise en defaut par la panne d'un site (au moment ou il devient le jeton) ou du systeme de communication. Une autre caracteristique requise d'un protocole de tour de r^ole est l'absence de la famine qui se traduit par la condition suivante : toute demande d'acquisition du jeton doit ^etre traitee au bout d'un temps borne. La complexite de la mise en uvre d'un protocole de tour de r^ole depend des caracteristiques du systeme cible (abilite des sites) et du modele de com- munication employe. Les protocoles de tour de r^ole presentent l'avantage d'^etre a la fois simples a employer par les utilisateurs et simples a mettre en uvre. Leurs principal inconvenient est le mode de concurrence tres restrictive qu'ils implantent. 4.4.3.2 Verrouillage implicite, l'exemple d'Ensemble Ensemble est un editeur graphique cooperatif synchrone [NW et al.92]. Il pro- pose un protocole de gestion de droit de parole qui implante un modele de concur- rence d'acces parallele et un modele de coherence forte. La mise en uvre du protocole est faite sur un modele de communication able a ordre causal. Le protocole repose sur l'emploi des verrous. La politique de gestion de verrous suit une demarche pessimiste. Il presente la particularite d'^etre entierement automatique. Le principe de fonctionnement du protocole est le suivant. A chaque partici- pant est attribuee une couleur qui le distingue des autres participants. Lorsqu'un utilisateur demande via l'interface utilisateur la selection d'un objet le processus du site local envoie une requ^ete de verrouillage de l'objet designe a un serveur de verrouillage. Ce dernier maintient une table d'allocation de verrous aux utilisa- teurs. Si la requ^ete de verrouillage est acceptee le serveur informe l'ensemble des 4.4 Mise en uvre d'un protocole de gestion de la concurrence 103 sites de l'identite de l'utilisateur ayant verrouille l'objet. La couleur de marque de selection de l'objet est celle de l'utilisateur qui possede ce verrou. Un utilisateur ne peut pas modier un objet selectionne par un autre utilisateur. Lorsqu'un utilisateur deselectionne un objet, le serveur de verrous libere l'objet designe. Les autres utilisateurs sont en mesure de le verrouiller. L'avantage de ce protocole est qu'il permet aux utilisateur d'interagir avec l'editeur dans les situations de travail en groupe de la m^eme facon que dans le cas d'utilisation individuelle de l'editeur. 4.4.3.3 Verrouillage explicite, l'exemple de Mace MACE est une application cooperative de traitement de texte [Nastos92]. Il implante un protocole de gestion de la concurrence a base de verrouillage. La gestion des verrous est presque entierement manuelle. Pour verrouiller une zone du texte, un utilisateur doit placer deux verrous qui delimitent la zone a verrouiller. Les verrous sont presentes sous forme d'une petite ic^one de verrou portant le nom du proprietaire. Ici, la taille du verrou et les demandes de verrouillage et de liberation sont faites d'une maniere explicite. Par consequent les utilisateurs peuvent negocier entre eux les limites et les tailles des zones accessibles pour chacun d'eux. 4.4.3.4 Le pelrin Ce protocole est propose dans le cadre de la plate-forme cooperatif CAliF [Guyennet et al.97]. Il implante un modele de concurrence d'acces parallels et un modele de coherence faible. La mise en uvre du protocole est faite sur un modele de communication able. Un souci principal du Pelrin est d'alleger le trac reseau. Dans cette optique le protocole emploi un jeton, appele le pelrin, dont la structure de donnees porte a la fois les commandes de negociation des proprietes des objets manipules dans le systeme et les mise a jours eectues. Chaque objet est a un instant donne la propriete d'un seul site qui est le seul a pouvoir la manipuler (acces parallels). Les sites cooperants sont places sur un anneau virtuel sur lequel le pelrin circule automatiquement. Arriver sur un site le pelrin subit le traitement suivant avant d'^etre expedie sur le site voisin : 1. Lecture : Le site applique les mises a jour portes par le pelrin et traite les demandes d'acquisition de propriete des objets en son possesion. 2. E criture : Le site ajoute au jeton les modications qu'il applique aux objets locals depuis le dernier passage du pelrin puis ajoute a celui-ci ses reponses aux requ^etes d'acquisition d'objets et ses propres requ^etes de demandes d'acquisition d'objets. Selon ce protocole les seuls messages qui transitent sur le reseau sont les messages de circulation du pelrin. Le protocole atteint son objectif de reduction du 104 Contr^ ole de la concurrence dans les collecticiels synchrones trac reseau sur le compte des proprietes requises de l'interface homme-machine du systeme. En eet le temps de reponse de l'interface n'est plus optimal (du au temps d'attente d'acquisition des verrous) et il n'est plus stable (la m^eme action peut prendre des duree variees selon la taille du pelrin et du nombre des sites participants. Le temps de notication est aussi penalise par le choix d'un anneau undirectionel. 4.4.3.5 Oreste Le protocole Oreste est propose dans le cadre de la plate-forme GroupDesign [Karsenty et al.93b]. Il a le prol suivant : Le modele de la concurrence est celui des accedes simultanes. Le modele de la coherence est la coherence faible. Oreste repose sur l'emploi d'un mecanisme de detection de la dependance. La politique implantee par le protocole suit une demarche optimiste. La restauration de la coherence des copies est faite d'une maniere automatique. La mise en uvre du protocole est faite sur un modele de communication able. La reception des messages echanges entre les sites est fait dans un ordre quelconque. Le principe de fonctionnement d'Oreste est le suivant. Chaque operation ge- neree par un site est immediatement executee sur le site local et en m^eme temps envoyee aux autres sites. Chaque site maintient deux listes d'operations : une liste d'historique d'execution (H ) et une liste d'operations en attente d'execu- i tion (Q ). Seules les operations qui s'appliquent a des objets non encore crees sur i le site de reception sont mises en attente sur ce site. Des horloges vectorielles sont employees pour detecter la causalite entre les operations generees dans la session [Raynal et al.96]. Lorsqu'un site envoie une operation, il envoie avec elle son horloge logique. A la reception d'une operation (Op) le site recepteur compare l'horloge logique de Op avec l'horloge locale. Trois cas de gure peuvent avoir lieu : 1. L'objet auquel s'applique Op n'est pas encore cree sur le site local (l'ope- ration de creation de l'objet n'est pas encore recue). Op est alors ajoutee a la liste Q . i 2. L'objet auquel s'applique Op n'existe plus. Op est alors ajoutee a l'histo- rique de l'execution (H ) sans devoir ^etre execute. i 3. L'objet designe par Op existe. Deux cas peuvent se presenter : l'horloge logique de Op est superieure ou egale a l'horloge locale ; dans ce cas Op est immediatement executee et ajoutee a H . Dans le cas contraire l'algorithme defait toutes les operations executees sur le site local (dans H ) et qui sont i plus recentes que Op, execute Op puis refait toutes les operations defaites. i 4.5 L'algorithme LICRA 105 4.5 L'algorithme LICRA 4.5.1 Presentation informelle Le prol Nous proposons dans la suite un nouveau protocole pour la gestion de la concurrence nomme LICRA (abreviation de Lock-free Interactive Concurrence Control Resolution Algorithm). Ce protocole implante un modele de concurrence a acces simultanes et un modele de coherence causale. Il s'appuie sur un meca- nisme de detection de dependances. La mise en uvre de LICRA repose sur une politique optimiste dont le deroulement est completement automatique. La conception de LICRA presente plusieurs originalites parmi lesquelles nous citons les deux points suivants. LICRA est le seul protocole qui combine les trois caracteristiques suivantes : a) permettre les acces simultanes (gr^ace a sa politique optimiste), b) realiser un modele de coherence causale et c) ^etre completement automatique. Peu de protocoles existants implantent une politique optimiste. Les deux systemes Milan et Tivoli [Condon92] implantent des protocoles optimistes ou la restauration de la coherence est a faire par les utilisateurs eux-m^emes (res- tauration manuelle). Le protocole optimiste Oreste (voir 4.4.2.4) est complete- ment automatique mais il implante un modele de coherence faible. Ainsi LICRA remplit un vide dans la grille des protocoles de gestion de la concurrence dans les collecticiels synchrones. D'autre part, le mecanisme de la restauration automatique de la coherence employe dans LICRA repose sur une procedure originale fondee sur le principe de transformation d'operations. La transformation d'operations evite aux utilisa- teurs la confusion que peut generer l'emploi d'un mecanisme de restauration au- tomatique de la coherence fonde sur le principe d'execution reversible. L'exemple (4.1) illustre le principe de la transformation d'operations tout en le comparant avec un mecanisme a execution reversible. Le principe de la transformation d'operations a ete introduit par Ellis et Gibbs dans leurs proposition d'un protocole, nomme dOPT [Ellis et al.89]. dOPT est la premiere tentative de developpement d'un protocole de gestion de la concurrence qui soit optimiste, automatique et qui ne repose pas sur le principe d'execution reversible. Malheureusement dOPT s'avere incorrect comme l'ont montre Allison et Livesely dans [Allison et al.94] (voir l'annexe B). Exemple 4.1 Soit une session d'edition cooperative impliquant deux sites 1 et 2. Les deux sites manipulent une cha^ne de caracteres S . Au debut S est vide. Le site 1 genere l'operation Op1 = Inserer(S; 1; A) et en m^eme temps le site 2 genere Op2 = Inserer(S; 1; B ). Pour xer les idees nous supposons que 1 est prioritaire sur le site 2 ce qui implique que la sequence correcte d'application des deux operations est la suivante : Op1 ; Op2. La valeur correcte de S est S = BA. Cas d'un protocole optimiste a execution reversible: Conformement a la nature optimiste du protocole chaque site execute immediatement l'operation qu'il 106 Contr^ole de la concurrence dans les collecticiels synchrones genere. Nous avons S = A (respectivement S = B ) sur 1 (respectivement 2 ). A la reception de Op2 sur 1 le site execute simplement Op2 ce qui donne le resultat S = BA sur ce site. A la reception de Op1 sur 2 le site defait Op2 , execute Op1 puis execute Op2 pour avoir S = BA. L'utilisateur sur le site 2 n'a aucun moyen de savoir si toutes les trois dernieres operations sont faites par l'autre utilisateur ou si elles sont induites par le fonctionnement du protocole. Cas d'un protocole optimiste a base de transformation d'operations : Le scenario est le m^eme que dans la cas precedent sauf pour la traitement de la reception de Op1 sur 2 . Ici le site 2 transforme Op1 en Opt1 = Inserer(S; 2; A) et il execute l'operation transformee. Le resultat est le m^eme que dans le premier cas mais avec moins de perturbation de l'utilisateur sur le site 2 . Ce dernier voit en eet une seule mise a jour de son interface utilisateur suite a l'execution d'une operation envoyee par l'autre utilisateur. L'inter^et principal d'un mecanisme de transformation d'operations est de ca- cher aux utilisateurs le fonctionnement interne du protocole reduisant ainsi la confusion que peut induire un modele de concurrence a acces simultanes. La contrepartie d'un tel mecanisme est la necessite de denir des rgles de transfor- mation d'operations ; une t^ache parfois dicille et delicate. Le fonctionnement Intuitivement LICRA fonctionne comme suit. A chaque operation est attribuee une etiquette qui la designe d'une maniere unique dans l'espace de la session. A la generation d'une operation Op le processus du site generateur execute Op immediatement et la transmet aux autres sites. Chaque operation envoyee est accompagnee d'une information dite le contexte de gene- ration. Ce dernier denit l'etat des objets du site lors de la generation de Op. Le contexte de generation d'une operation est constitue par l'ensemble des iden- ticateurs des operations non causalement liees entre elles et qui sont executees immediatement avant la generation de Op. La procedure de calcul du contexte de generation d'une operation est donne dans la section (4.5.2.2). A la reception d'une operation Op le site recepteur compare le contexte de generation de Op avec son propre historique d'execution. Deux cas peuvent avoir lieu : Toutes les operations referencees dans le contexte de generation de Op sont executees sur le site recepteur. L'operation Op peut alors ^etre executee mais avant elle a eventuellement besoin d'^etre transformee. Deux raisons motivent la transformation d'une operation Op : 1. Une ou plusieurs operations referencees dans le contexte de genera- tion de Op ont deja subi des transformations sur le site recepteur. L'operation Op doit evidemment subir les m^emes transformations. 4.5 L'algorithme LICRA 107 2. Le site recepteur a execute de nouvelles operations apres l'execution des operations referencees dans le contexte de generation de Op. Par consequent Op doit ^etre transformee an de prendre en compte les eets d'execution de ces operations. Il existe une operation referencee dans le contexte de generation de Op qui n'est pas encore recue ou qui est en attente d'execution. Nous disons que Op arrive en avance ; elle est par consequent mise en attente. Les deux regles precedentes assurent la mise a jour des copies selon l'ordre causal ; une operation n'est executee sur un site que si toutes les operations qui la precedent causalement sont deja executees sur ce site. Le fonctionnement du LICRA decrit ci-dessus revele le besoin de garder sur chaque site l'historique d'execution locale. L'historique etant une structure de donnees dont la taille est croissante avec le temps, il risque de saturer la memoire disponible sur le site. Ce probleme est d'ailleurs commun a tous les protocoles optimistes et automatiques. Un mecanisme de reduction de la taille de l'historique est prevu. Nous explicitons dans la section suivante le schema de mise en uvre du protocole propose. 4.5.2 Mise en uvre 4.5.2.1 Hypotheses de travail An de simplier la presentation de l'algorithme nous faisons les hypotheses suivants : H1 Le nombre de sites impliques dans la session est constante. H2 La communication entre les dierentes sites est faite selon un protocole able. Nous montrons dans la section (4.5.6) comment traiter le cas de la connexion et deconnexion dynamiques de sites ainsi que le traitement de certain types de pannes. 4.5.2.2 Denitions Nous denissons dans la suite les principaux concepts employes dans le pro- tocole LICRA. Une operation (Op) est denie par un quadruple Op = (Site; Sequence; ; ) ou Site est l'identicateur du site generateur de l'operation, Sequence est un compteur du nombre d'operations generees par le site generateur, est la fonc- tion appliquee par l'operation et est l'ensemble des parametres de la fonction . Nous utilisons la notation Op:x pour designer le champ x d'une operation ; ainsi l'identicateur du site generateur d'une operation est designe par Op:Site. 108 Contr^ole de la concurrence dans les collecticiels synchrones Les deux premiers champs constituent l'etiquette (ou l'identicateur) univer- selle de l'operation. Nous utilisons la notation Op:ID pour designer le couple Op:Site et Op:S equence. Toute operation garde le long de la session la m^eme eti- quette attribuee par son site generateur. La transformation d'une operation agit sur les deux champs et . Une liste d'operations. Chaque site maintient deux types de listes d'ope- rations : une liste d'historique H et des listes d'attente. Une liste d'operations L i i est constituee par une suite d'elements ; un element decrit une operation recue sur le site local. Nous detaillons la structure d'un element dans la section (4.5.3.1). Nous avons besoin a present de denir trois fonctions principales de manipulation de listes qui sont necessaires pour la denition des concepts cites ci-apres. Les trois fonctions sont les suivantes : Succ(Op; L); Cette fonction renvoie l'element qui suit Op (l'element decrivant Op) dans la liste L. La fonction Succ(Op; L) renvoie tous les elements qui suivent Op dans L. P red(Op; L); Cette fonction renvoie l'element qui precede Op dans L. La fonc- tion P red(Op; L) renvoie tous les elements qui precedent Op dans L. Last(L) Cette fonction renvoie le dernier element dans L. Le contexte de generation (C G) A la generation d'une operation Op le site x generateur calcule le contexte de generation de Op selon l'algorithme suivant : Algorithme 4.1 CxG ( Op ); // Le site local est le site i ; CxG = nil; // initialisation du contexte de generation Opl = Last ( Hi ); // Opl est la derniere operation executee avant la generation de Op Si (Opl :Site == i) Alors // Opl est generee par le site local CxG = Opl :ID return (CxG); Sinon CxG = Opl :ID Opx = Pred ( Opl , Hi ); Tant que (Opx :CxG == Opl :CxG) Faire // Les deux operations sont concurrentes; CxG = CxG + Opx :ID Opl = Opx Opx = Pred(Opl , Hi ); 4.5 L'algorithme LICRA 109 Un message (M ). Les sites echangent entre eux les operations qu'il gene- rent sous forme de messages. Un message M est constitue par un couple M = (Op; Cx G(Op)), ou Op est l'operation emise et CxG(Op) est son contexte de ge- neration. Le contexte de production (CxP ) Il contient les operations executees sur le site recepteur apres l'execution de la derniere operation precedente l'operation Op. Soit L la liste contenant l'operation Op sur un site . Le contexte de production de Op sur est alors denie par l'expression suivante : CxP (Op) = Succ(Op; L). Le contexte d'adaptation (CxA) Le contexte d'adaptation d'une operation designe l'ensemble des operations en fonction desquelles une operation recue sur un site doit ^etre transformee. Le calcul du contexte d'adaptation est fait selon le formule suivant : CxA(Op) = [([X 2CxG Op CxA(X ))=CxG(Op)] [ CxP (Last(CxG(Op))) ( ) Derriere cette expression complexe se cache une denition simple : tout ope- ration ayant servi pour transformer une operation qui precede Op doit servir pour transformer Op elle m^eme. De l'ensemble precedent nous excluons les ope- rations qui appartiennent deja au contexte de generation de Op car l'eet de ces operations est deja prise en compte par Op. Puis nous ajoutons au contexte d'adaptation toute operation executee sur le site apres l'execution de la derniere operation precedant Op. L'exemple suivant illustre les dierents concepts denis ci-dessus. Exemple 4.2 Illustration des concepts de contextes de generation, d'adaptation et de production La gure (4.3) illustre un echange de cinq operations entre trois sites dans le cadre d'une session cooperative. La tableau suivant donne le contexte de generation de chacune des cinq operations. Le calcul de chacun des Gx G est immediat selon l'algorithme cite ci-dessus. Pour illustrer les deux concepts de contexte de production et d'adaptation nous prenons l'exemple de l'historique de l'execution sur le site3. L'historique de l'execution sur ce site est compose de cinq etapes : 1. Generation de Op2 : Op2 etant une operation locale elle est executee immedia- tement. La liste d'historique devient H3 = (Op2). 2. Reception de Op1 : Nous avons Cx G(Op1) = nil ) CxA(Op1) = (CxA(nil)=CxG(Op1))+ CxP (nil) = nil + Op2 = Op2. L'operation Op1 est transformee en fonction de Op2. L'historique local devient H3 = (Op2; Op1). 3. Reception de Op3 : Nous avons CxG(Op3) = (Op1; Op2) ) Cx A(Op3) = ((CxA(Op1)+ CxA(Op2))=(Op1; Op2)) + CxP (Op1) = nil + nil = nil. Alors l'operation Op3 est executee sans modication. Nous avons H3 = (Op2 ; Op1; Op3). 110 Contr^ ole de la concurrence dans les collecticiels synchrones Op1 Op4 Site 1 Op3 Site 2 Site3 Op2 Op5 Fig. 4.3 - : Exemple d'une echange d'operations entre trois sites. Operation Cx G Op1 - Op2 - Op3 [Op2; Op1] Op4 Op3 Op5 Op3 Tab. 4.2 - : Les contextes de generation des operations illustrees sur la gure (5.3) 4. Generation de Op5 : Op5 etant une operation locale elle est executee immediate- ment. La liste d'historique devient H3 = (Op2; Op1; Op3; Op5). 5. Reception de Op4 : Nous avons CxG(Op4) = (Op3), alors CxA(Op4) = Cx A(Op3)=(Op3)+ CxP (Op3) = nil + Op5 = Op5. L'operation Op4 est transformee en fonction de Op4 puis rajoutee a l'historique. 4.5.2.3 L'adaptation d'une operation La procedure d'adaptation d'une operation consiste a transformer cette ope- ration en fonction de chacune des operations contenues dans son contexte d'adap- tation. Le principe de la transformation d'operation est le suivant : etant donne deux operations Op et Op non causalement liees entre elles (donc generees par i j deux sites dierents) ; deux sites peuvent recevoir ces deux operations dans un ordre dierent ; c'est notamment le cas des deux sites generateurs. Tout site ayant execute Op (respectivement Op ) avant la reception de Op (respectivement Op ) i j j i transforme Op (respectivement Op ) des sa reception en Op (respectivement en j i t j Op ) de sorte que la condition suivante soit vraie : t i Op Op = Op Op t j i t i j 4.5 L'algorithme LICRA 111 Il est clair que le calcul de l'operation transformee depend de la semantique des deux operations impliquees et necessite aussi de denir une fonction de prio- rite entre les deux operations. La fonction de priorite est necessaire pour imposer un ordre de serialisation des operations. Pour cela nous denissons une fonction de priorite entres les sites participants a la session. La fonction de priorite est sim- plement l'ordre naturel denie sur l'ensemble des identicateurs (nombre entiers) des sites. Une operation prend la priorite de son site generateur. L'algorithme suivant resume la procedure d'adaptation d'une operation. Dans les procedures suivantes nous avons a transformer l'operation Op1 qui arrive sur un site en fonc- tion de Op2 deja executee sur le m^eme site. Algorithme 4.2 Adaptation (Op; Op:Cx A); Soit L = Nombre d'elements dans le contexte d'adaptation de Op; Pour (i = 1 ; i + + ; i L) Faire Op = Transforme ( < Op ; Op:Site > , < Op:CX A[i]:Op; Op:CX A[i]:Priorit >); Exemple 4.3 Denition de la fonction de transformation d'operations - cas d'un editeur de textes Nous considerons dans cet exemple un editeur de texte ou le document edite est une simple cha^ne de caracteres. L'editeur fournit les deux opera- tions suivantes : { Inserer(Position,Lettre) : inserer le lettre Lettre dans la position Position. Par exemple l'application de Inserer (3 , 'L') sur la cha^ne "COT" donne la cha^ne "COLT". { Supprimer(Position) : supprime la lettre a la position Position. Par exemple l'appli- cation de Supprimer(4) sur la cha^ne "COLT" donne la cha^ne "COL". Nous citons dans la suite les regles de transformation a appliquer dans chacun des quatre cas possibles de croisement d'operations. A chaque operation est associe une valeur P qui correspond a la priorite attribuee a l'operation. Algorithme 4.3 Transformer ( Op1 =< I ns(P os1 ; X ); P1 > ; Op2 =< I ns(P os2 ; Y ); P2 >); Cas P1 < P2 Faire // 1 est prioritaire a 2; Op Op Si P os 1< P os2 Alors 1 = Op 0 1 ; exit; Op Si P os 1 == 2 Alors P os Op1 = 0 ( 1 + 1 ); exit; I ns P os ;X Si P os 1> P os2 Alors Op 1 = 0 ( 1,1 ); exit; I ns P os ;X Cas 1 P > P 2 Faire // 2 est prioritaire Op a 1; Op Si P os 1 2 P osAlors Op 1 = 0 1 ; exit; Op Si P os 1> P os2 Alors 1 = Op 0 ( 1 , 1 ); exit; I ns P os ;X Algorithme 4.4 Transformer ( Op1 =< I ns(P os1 ; X ); P1 > ; Op2 = S up(P os2 ) ; P2 >); Cas P1 < P2 Faire // 1 est prioritaire a 2; Op Op Si P os1 2 Alors P os 1 = Op 1 ; exit; 0 Op Si P os1 2 Alors > P os 1 = Op 0 ( 1 , 1 ); exit; I ns P os ;X 112 Contr^ole de la concurrence dans les collecticiels synchrones Cas P1 > P2 Faire // 2 est prioritaire a 1; Op Op Si P os1 2 Alors P os 1 = 1 ; exit; Op 0 Op Si P os 1 2 Alors > P os 1 = ( 1 , 1 ); exit; Op 0 I ns P os ;X Algorithme 4.5 Transformer ( Op1 =< S up(P os1 ); P1 > ; Op2 = I ns(P os2 ; Y ) ; P2 >); Si P os1 < P os2 Alors Op1 0 = Op1; exit; Si P os1 P os 2 Alors Op1 0 = S up(P os1 + 1); exit; Algorithme 4.6 Transformer ( Op1 =< S up(P os1) ; P1 > ; Op2 = S up(P os2 ) ; P2 >); Si P os1 < P os2Alors 1 = 1; exit; Op 0 Op Si P os 1 == 2 Alors P os 1 = ; exit; Op 0 N OP Si P os 1 2 Alors P os1 = ( 1 , 1); exit; Op 0 S up P os Exemple 4.4. Transformation d'operation - cas de l'application ColtDraw ColtDraw est l'editeur graphique fournit par l'environnement de cooperation Colt. A la dierence d'un editeur de texte les operations dans un editeur graphique sont generalement commutatives ce qui simplie la denition des regles de transformation. A titre d'exemple nous illustrons dans la suite les regles de transformation concernant le couple d'operations suivant : SetFillColor(Objet,couleur) et Supprimer(Objet). Algorithme 4.7 Transformer( Op1 =< S etF illC olor(o1; C1); P2 >; Op2 =< S etF illC olor(o2; C2); P2 >); // Les deux operations s'appliquent a des objets dierents; Si o1 6= o2 Alors Op1 = Op1 ; 0 exit Sinon // Les deux operations s'appliquent au m^eme objet Si 1 2 Alors 1 = 1Sinon 1 = P < P Op 0 ; Op Op 0 N OP Pour simplier la presentation des autres regles de transformation nous ne conside- rons que le cas ou les deux operations s'appliquent sur le m^eme objet graphique. Dans le cas contraire l'operation a transformer reste telle qu'elle est. Algorithme 4.8 Transformer ( Op1 =< S etF illC olor(o1; C ); P1 < ; Op2 = S up(o1); P2 >); Op1 0 = N OP ; Algorithme 4.9 Transformer ( Op1 =< S up(o1); P1 > ; Op2 =< S etF illC olor(o1; C ); P2 >); Op1 0 = Op1 ; 4.5 L'algorithme LICRA 113 Les deux precedents exemples montrent que la complexite de la denition des regles de transformation depend fortement de la semantique de l'application. Dans certain cas il sut de savoir les commandes appliquees pour avoir l'opera- tion transformee ; dans d'autres il faut aller jusqu'a l'analyse des parametres des operations pour trouver le resultat de la transformation. Dans tous les cas, pour une application fournissant n operations il faut ecrire n2 regles de transforma- tions ; certaines sont plus faciles a formuler que d'autres. 4.5.3 Description de l'algorithme 4.5.3.1 Structures de donnees Chaque site i maintient les structures des donnees suivantes : Hi est la liste d'historique d'execution locale. W OP est la liste des identicateurs des operations attendues sur le site. Une operation OpA est attendue sur un site si celui-ci a recu une operation Op ou OpA :ID 2 CcG(Op) et OpA n'est pas encore recue. (Li) est un ensemble de listes d'operations en attente d'execution. V est un vecteur dont la dimension est le nombre de sites participants a la session. Une entree V [n] porte l'identicateur de la derniere operation recue de la part du site n. Le contenu de V servira a reduire la taille de la liste d'historique Hi evitant ainsi sa croissance monotone. T1 ; T2 sont deux horloges periodiques. Tous les T1 instants le site local envoie a tous les autres sites un evenement dont l'operation porte la fonction N OP . La fonction N OP n'aecte pas l'etat des objets dans Oi. L'horloge T1 ga- rantit que chaque site recoit au moins un message de tout autre site tous les T1 instants. Ceci sert a pouvoir reduire la taille de Hi . La reduction eective du Hi est faite tous les T2 instants. 4.5.3.2 Deroulement du protocole Chaque site execute le m^eme algorithme. Pendant le deroulement d'une ses- sion deux evenements peuvent arriver a un site : 1) la generation d'une operation, 2) la reception d'une operation. Nous decrivons dans la suite le comportement de l'algorithme dans chacun des deux cas precedents. Cas de generation d'une operation Op Le site execute Op immediatement, prepare le message M = (Op; Op:Cx G) puis l'envoie a tous les autres sites. Il ajoute aussi un nouvel element decrivant Op a la n de la liste de l'historique Hi. 114 Contr^ ole de la concurrence dans les collecticiels synchrones Cas de reception d'un message M A la reception d'un message M , deux cas peuvent avoir lieu : 1. Il existe une operation Opr referencee dans M:CxG qui ne soit pas encore recue sur le site local. Dans ce cas le processus du site cree une nouvelle liste d'attente dont la t^ete est Op. L'operation Opr est declaree comme une operation attendue ; son identicateur est ajoute a la liste des operations attendues W OP . 2. Toutes les operations referencees dans M:CxG sont deja recues. Elle sont forcement stockees dans une m^eme liste L. L peut ^etre la liste d'historique Hi ou une liste d'attente. Dans les deux cas, le processus du site calcule le contexte d'adaptation de Op. L'operation Op est adaptee puis ajoutee a la n de L. Si L est la liste d'historique, Op est executee sur le site sous sa forme transformee. Dans les deux cas, apres le traitement d'une operation recue Op, le processus du site verie si l'operation Op est une operation attendue. Si c'est le cas, il existe forcement une liste qui contient les operations en attente de Op. Le site est en mesure maintenant de traiter ces operations. La liste d'attente est supprimee apres le traitement de toutes les operations qu'elle contient. L'identicateur de op est supprim e de la liste des operations attendues : W OP . Reduction de l'historique Hi Le principe est le suivant. Chaque site garde un vecteur de references V dans lequel l'entree V [k] porte l'identicateur de la derniere operation recue de la part du site k . A l'expiration d'une horloge periodique T2, chaque site consulte le vecteur V pour determiner l'operation Opa : l'operation la plus ancienne dans Hi referencee dans V . Soit OpA l'operation la plus ancienne dans le contexte d'adaptation de Opa . OpA est forcement dans Hi puisque Opa 2 Hi . Toute op eration avant OpA peut ^etre supprimee puisque aucune adaptation ulterieure ne peut s'en servir. Un probleme que peut rencontrer l'algorithme precedent est le probleme du site inactif. Un site est inactif s'il se contente de recevoir des messages sans en produire. Par consequent aucune reduction sur aucun site ne peut s'eectuer car du point de vue des autres sites, le site inactif est toujours soupcone de produire une operation qui depend de l'origine de l'historique de la session. Une premiere solution consisterait a envoyer systematiquement accuse de reception des evenements recus mais ceci menerait aussi a une degradation des performances du systeme en augmentant le nombre de messages a vehiculer. La solution adoptee est de forcer chaque site a diuser d'une maniere periodique un evenement qui porte l'operation N OP . Cet evenement porte ainsi l'identicateur de la derniere operation recue et executee sur ce site. 4.5 L'algorithme LICRA 115 4.5.4 Exemples Nous presentons dans cette section quelque exemples d'applications du pro- tocole LICRA. Dans l'ensemble des exemples presentes ci-dessous la fonction de priorite entre les sites est simplement la relation d'ordre normal sur les identi- cateurs des sites ; le site 1 est prioritaire sur le site 2 et ainsi de suite. 4.5.4.1 E change simultane entre trois sites Dans ce premier exemple nous considerons le cas d'echanges simultane de trois operations entre trois sites. L'ordre de la reception des operations sur chaque site est illustre a la gure (4.4). Site 1 Op1 Site 2 Op2 Site3 Op3 Fig. 4.4 - : E change simultane entre trois sites. Pour xer les idees, nous considerons le cas d'edition d'une cha^ne de carac- teres S . Au debut la cha^ne est vide. Nous considerons les operations suivantes : { Op1 = Inserer(1,A); { Op2 = Inserer(1,B); { Op3 = Inserer(1,C); Nous tracons dans la suite l'execution des trois operations sur les trois sites. Execution sur le site 1 L'operation Op1 etant locale elle est executee imme- diatement. Nous avons S = A et H1 = (Op1 ). Ensuite le site recoit Op3 dont le contexte de generation est l'origine, par consequence le contexte d'adaptation de Op3 est constitue par l'historique du site ; nous avons CxA(Op3) = (Op1). Or, d'apres les regles de transformation l'operation Op3 se transforme en operation identique. Nous avons S = CA et H1 = (Op1 ; Op3). Enn le site recoit Op2 dont le contexte de generation est l'operation origine. Elle doit ^etre transformee en fonction de l'historique local, c'est a dire en fonction de Op1 et Op3 . La trans- formation de Op2 en fonction de Op1 laisse l'operation Op2 intacte tandis que la transformation en fonction de Op3 la change en Op2 = Inserer(2; B ). Nous avons 0 alors S = CBA et H1 = (Op1 ; Op3 ; Op2 ). 0 116 Contr^ ole de la concurrence dans les collecticiels synchrones Execution sur le site 2 Op2 est d'abord executee. Nous avons S = B et H2 = (Op2 ). A la reception de Op3 le site la transforme en fonction de Op2 ; le site 3 est moins prioritaire que 2 l'operation Op3 reste intacte conformement aux regles de transformation decrites ci-dessus. Nous avons maintenant S = CB et H2 = (Op2 ; Op3). Lorsque le site recoit Op1 , il la transforme en fonction de Op2 et Op3 . L'operation Op1 est transformee en Op1 = Inserer(3; A). Nous avons 0 alors S = CBA. Execution sur le site 1 D'une maniere similaire, aux autres sites, le site 3 execute d'abord Op3 transforme Op2 en Op2 = Inserer(2; B ) et l'execute. Puis 0 transforme Op1 en Op1 = Inserer(3; A) et l'execute. Le contenu de S passe du 0 vide a B puis a CB en enn a CBA. 4.5.4.2 Cas de concurrence partielle Nous considerons ici un cas particulier d'echanges entre deux sites dit echange en concurrence partielle. Un ensemble d'operations est dit en concurrence partielle si une operation est en concurrence avec une serie d'operations toutes causalement liees elles. Le cas le plus simple d'une situation de concurrence partielle est illustre a la gure (4.5). Site1 Op1 Op2 Site2 Op3 Fig. 4.5 - : Situation de concurrence partielle. L'inter^et d'etudier le comportement de LICRA dans une situation de concur- rence partielle est de montrer le succes du protocole la ou le seul autre protocole a base de transformation d'operations (le protocole dOPT) est montre incor- recte [Allison et al.94] (voir aussi annexe B). Pour xer les idees considerons le cas d'une session impliquant deux sites qui utilisent l'application ColtDraw. Pre- nons le cas ou Op1 = SetFillColor(o1; V ert) ; Op2 = SetFillColor(o1; Bleu) et Op3 = SetFillColor(o1; Rouge). Execution sur le site 1 Les deux operations Op1 et Op2 sont executees se- quentiellement. L'objet o1 a la couleur bleue. A la reception de Op3 le site l'adapte en fonction de deux operations precedemment executees. Selon les regles de la transformation decrites dans l'exemple (5.4) l'operation Op3 reste intacte ; a son execution l'objet o1 devient rouge. Les copies des donnees restent ainsi coherentes entre elles. Dans l'annexe B, nous reprenons le m^eme exemple pour montrer l'in- correction du protocole dOPT. 4.5 L'algorithme LICRA 117 Execution sur le site 2 L'operation Op3 est executee immediatement. L'ob- jet o1 a la couleur rouge. A la reception de Op2 le site la transforme en fonction de Op1 . Le site 1 est plus prioritaire donc Op2 est transform e en Op2 = N OP (voir 0 les regles de transformation donnees dans l'exemple 5.2). Le contexte d'adap- tation de Op2 sur le site 1 contient l'operation Op1 . Par consequence Op2 est transformee a son tour en N OP . L'objet o1 reste en rouge sur le site 1. 4.5.5 Preuve de correction Soit S une session de cooperation synchrone. Le protocole LICRA etant fonde sur un modele de communication able tous les sites dans S vont recevoir toutes les operations generees dans la session ; l'ordre de la reception des operations peut dierer d'un site a un autre. LICRA est correct si quelque soit l'ordre de la reception des operations sur les dierents sites les deux conditions suivantes sont satisfaites : C1. Tous les sites executent les operations generees dans la session dans leurs ordre causal. C2. Aux moments de repos les objets de tous les sites sont identiques. La premiere condition est veriee par la construction m^eme du protocole : une operation ne peut pas ^etre executee sur un site (avec ou sans transformation) sauf si toutes les operations qui la precedent sont deja executees sur ce site. Il nous reste donc a prouver que LICRA satisfait la deuxieme condition. Pour cela pre- nons deux sites quelconque x et y . Soit G = (Op1 ; Op2; : : : ; Opm ) une sequence d'operation generees dans la session. Nous designons par Gx (respectivement Gy ) l'ordre de la reception de la sequence G sur x (respectivement y ). G etant un ensemble ni d'operations il est donc possible d'obtenir Gy en appliquant un nombre ni de permutations sur Gx. Par consequent il nous sut de montrer la veracite de la condition C2 dans le cas ou les deux sequences Gx et Gy sont identiques a une permutation pres. Soient Opi et Opj les deux operations qu'il faut permuter dans Gx pour obtenir Gy . Deux cas peuvent avoir lieu : 1) une de deux operations depend de l'autre et 2) les deux operations sont en concurrence. Examinons d'abord le premier cas. Pour xer les idees supposons que Opj depend de Opi . Les deux sites executent la sequence dans Gx (ou Gy ) qui precede Opi de la m^ eme maniere puisque cette sequence est identique sur les deux sites. A la reception de Opj sur y , l'operation va ^etre mises en attente car il existe une operation qui la precede et qui n'est pas encore recue (Opi ). Soit Op une operation appartenant au segment qui separe Opj de Opi dans Gy . Deux cas sont possibles : soit Op depend de Opi ou soit elle est en concurrence avec elle. Dans le premier cas Op est ajout ee a la le des operations en attente d'execution. Dans le deuxieme cas l'operation est traitee sur le site y sans avoir subi les transformations qu'elle du subir en fonction de Opi . Mais selon la denition m^eme de la fonction de 118 Contr^ole de la concurrence dans les collecticiels synchrones l'adaptation lorsque le site recoit Op elle la transforme en fonction de Op de y i sorte que son resultat d'execution soit identique a l'execution de Op transformee en fonction Op sur le site . Ce m^eme raisonnement s'applique pour le cas de i x la concurrence entre Op et Op en remplacant Op par Op . et Op en Op i j j i j 4.5.6 Amelioration de l'algorithme Nous presentons dans cette section quelque possibilites d'amelioration de l'al- gorithme LICRA. Nous etudions en particulier les points suivants : Simplier la procedure d'adaptation d'une operation. E tendre l'algorithme an de supporter la participation dynamique de nou- veaux arrivants. Modier l'algorithme pour pouvoir tolerer certains types de pannes de sites ou de perte de messages. Les idees discutees ci-apres ne sont pas implantees dans l'actuel protocole. Leur implantation est planiee pour une nouvelle version du LICRA. 1. Simplier l'adaptation Nous proposons dans la suit de simplier la proce- dure d'adaptation en simpliant : 1) la denition de la matrice de transformation d'operations et 2) en simpliant le parcours que fait un operation de son contexte d'adaptation. Dans cette optique nous denissons la relation de commutation entre fonctions de la facon suivante : une fonction 1 commute avec une fonction 2 si l'appli- cation de deux fonctions dans les deux ordres possibles donne le m^eme resultat. Deux operations commutent si elles utilisent des fonctions qui commutent entre elles. Pendant l'adaptation d'une operation Op, on peut alors sauter immediate- ment tout operation dans la contexte de l'adaptation qui commute avec Op. Une fonction particuliere qui commute avec tout autre fonction est la fonction NOP . Lorsqu'une operation Op est transformee en NOP pendant son adaptation nous pouvons sauter immediatement le reste du contexte de l'adaptation et terminer la procedure. La procedure d'adaptation devient la suivante : Algorithme 4.10 Adapter (Op; C A(Op)); Soit Op = t^ete(C A(Op)); x Tant que Op :ID 6= nil Faire x x Cas Commute(Op: Op :) Alors Op x = Suivant(Op ; Op:C A); Cas Masquee(Op: Op :) Alors x x x x x Op: = NOP ; Ajouter(Op,L); // Op:C A L x exit; 4.5 L'algorithme LICRA 119 Defaut // l'operation doit ^etre transformee Op = Transformer(Op; Opx ); Opx = Suivant(Opx; Op:CxA); 2. Supporter la participation dynamique de nouvels sites Un service de gestion de la participation dynamique comprend deux volets : 1. un volet decisionnel correspondant a l'application d'une strategie de contr^ole d'appartenance, 2. et un volet technique correspondant au transfert au site du nouvel arrivant du contexte actuel de la session, une fois que la demande de connexion est approuvee. Dans cette section, nous nous interessons au deuxieme volet uniquement. Deux solutions sont envisagees pour que LICRA devienne tolerant a la participation dynamique des sites. La premiere solution consiste a geler la session et a forcer par consequent un etat de repos lors de la reception d'une requ^ete de connexion. Une fois que le systeme est au repos, n'importe quel site peut envoyer au nouvel arrivant une copie de son etat (donnees et historique). Cette approche est simple a mettre en uvre. Cette solution est implantee dans le prototype actuel de l'environnement Colt. Cependant forcer l'etat de repos ralentit le systeme. La session est gelee a chaque demande de connexion pour le temps necessaire pour transmettre l'etat courant. Ce temps peut ^etre important si les donnees manipulees dans une session ont une taille importante. Une deuxieme solution qui permet la participation dynamique de nouveaux ar- rivants sans interrompre la session est alors proposee. Le principe de l'algorithme est le suivant. Soit N le site du nouvel arrivant. Pour rejoindre une session, le site envoie une requ^ete de participation a tous les membres actuels de la session. Un site est choisi parmi les sites existants pour jouer le r^ole du Parrain du N . Le parrain, denote P , a la t^ache de transferer son etat au nouvel arrivant et de faire suivre les messages qu'il recoit des autres sites a N . Le site N execute le m^eme algorithme LICRA a la dierence pres qu'il ne peut pas lui m^eme generer des operations. Nous disons que le site est en etat semi actif. Tant que le site n'a pas recu une copie de l'etat du site du parrain, aucune operation recue d'un autre site ne peut ^etre executee. Par contre a la reception d'une operation d'un autre site N envoie un evenement d'acquitement a P pour lui informer de l'etablissement d'une liaison avec ce site. L'evenement d'acquitement porte l'identicateur de l'operation recue. Si cette operation est deja recue par le site parrain, ce dernier arr^ete la poursuite des evenements (operations) originaires du site acquitte et en relation avec N . Lorsque le parrain arr^ete les envois poursuite de tous les autres sites il envoie un evenement de n de parrainage. A la reception de cet evenement le site N devient un site participant a part entiere. 120 Contr^ole de la concurrence dans les collecticiels synchrones La gure (4.6) illustre le deroulement de l'algorithme pour un site qui participe a une session contenant deux autres sites. Remarquer que le site N peut recevoir certaines operations en double ; une fois par le site generateur et une deuxieme fois par le biais du parrain. C'est le cas par exemple de l'operation Op3 qui est recue sur le site parrain avant que celui-ci ne recoive l'acquitement du N qu'il est en liaison avec le troisieme site. La detection d'une reception redondante est triviale gr^ace a l'unicite des identicateurs des operations. Op1 Op3 Op4 Un participant M2 Op2 M4 Le parrain Le nouvel site M1 M3 Message de protocole de participation M1 Requête de connexion Opération M2 Transfert d’état M3 Acquittement de connexion avec Message de poursuite un site participant M4 Fin de parrinage Fig. 4.6 - : Exemple de deroulement de l'algorithme de la connexion dynamique. Tolerance aux pannes LICRA tel qu'il est presente ci-dessus est fonde sur un modele de communication able et a ordre FIFO. Nous montrons dans cette sec- tion comment rel^acher davantage les contraintes sur le modele de communication. Nous decrivons dans la suite comment l'algorithme LICRA peut ^etre adapte pour faire face a certains types de pannes et de perte de messages. Nous examinons en particulier les deux cas suivants : 1) panne transitoire d'un lien de communication 2) et panne d'un site. Panne transitoire d'un lien de communication Nous considerons ici le cas de la perte d'une operation envoyee par un site suite a une panne transitoire du reseau de communication. Pour xer les idees, supposons que l'operation Ope envoyee par le site e n'a pas atteint un autre site r . La panne etant transitoire, le site r va forcement recevoir une operation Opf qui elle depend directement de Ope . Noter que l'op eration Opf n'est pas necessairement generee par le m^eme site 4.5 L'algorithme LICRA 121 e .A la reception de Opf par r, ce dernier, conformement a LICRA va declarer l'operation Ope comme operation attendue (ajouter son identicateur a la liste W OP ). Pour chaque op eration attendue le site associe une periode d'expiration (Time out) au bout de laquelle il reclame la retransmission de cette operation. Ainsi le site r va demander au site emetteur de Opf de lui transmettre l'operation Ope . Le site generateur de Opf a une copie de Ope parce qu'il a genere Opf . Panne d'un site Nous considerons ici le cas de panne en silence d'un seul site. Considerons le cas ou le site e est tombe en panne immediatement apres l'emission d'une operation Opf . Supposons par ailleurs que Ope 7! Opf . Trois cas peuvent avoir lieu : L'operation Opf n'est recue par aucun site : dans ce cas Opf est ignoree. Tous les sites ont recu Opf : dans ce cas trois cas de gure peuvent avoir lieu : { Aucun site n'a recu l'operation Ope , dans ce cas l'operation Opf est ignoree. { Tous les sites ont recu Ope . Dans ce cas l'operation Opf peut ^etre executee normalement. { Quelque sites ont recu Ope . Dans ce cas les sites qui ne l'ont pas recu vont demander a un site qui a deja Ope de la retransmettre. Ceci est fait par diusion d'un requ^ete de retransmission de Ope apres l'expiration de la periode l'attente. Quelques sites ont recu Opf : les sites qui recoivent Opf vont le traiter comme dans le cas precedent. Si l'operation Opf n'est pas ignoree, un site qui ne l'a pas recu va fatalement recevoir une operation Opj de sorte que Ope 7! Opj ; alors un tel site va recevoir Opf comme c'est indiqu e dans le cas precedent. Cette extension de l'algorithme LICRA permet de garantir que tous les sites non defaillants vont pouvoir continuer a travailler malgre la defaillance d'un site. Le probleme de tolerance aux pannes dans sa generalite est un probleme complexe. Mais nous pensons que l'algorithme LICRA se pr^ete bien a traiter plusieurs cas de pannes a cause de la decentralisation totale de son fonctionnement et a l'echange periodique des operations N OP tous les T1 instants. Les evenements periodiques N OP peuvent ^ etre utilises pour detecter l'occurrence des pannes des sites ou de reseau. Une etude complete des aspects de tolerance de pannes echappe au cadre de cette these. 122 Contr^ ole de la concurrence dans les collecticiels synchrones 4.6 Resume Nous avons etudie dans ce chapitre le probleme de gestion de la concurrence pour les collecticiels synchrones. Ce type de collecticiels est souvent implante selon une architecture totalement dupliquee an de favoriser le temps de re- ponse et la resistance aux pannes. Dans une premiere partie nous avons deni les problemes poses par la concurrence d'acces a l'espace partage deni par un collecticiel synchrone et nous avons identie les principales proprietes requises d'un protocole de gestion de la concurrence pour ce type d'applications. Un mo- dele general de description des protocoles de gestion de la concurrence est ensuite propose. D'apres ce modele un protocole est divise en trois couches dites aussi modeles : le modele de la concurrence, le modele de la coherence et la modele de la communication. A partir de ces trois couches nous avons presente les dierentes approches de construction de protocoles de gestion de la concurrence. Deux me- canismes de base sont identies pour la construction d'un protocole de gestion de la concurrence : le mecanisme de verrouillage et le mecanisme de detection de dependances. Les deux mecanismes peuvent ^etre exploites de dierentes facons pour implanter une variete des protocoles. Une comparaison entre les dierents variantes est faite en fonction de la satisfaction des proprietes requises d'un tel protocole. La conclusion de cette etude est qu'il n'existe pas un seul protocole qui soit compatible avec les besoins de tous les types de sessions de travail cooperatif synchrone. Une plate-forme generique doit supporter une variete des protocoles et laisser le choix du protocole a appliquer aux utilisateurs. Dans une deuxieme partie de ce chapitre nous avons propose un nouvel algo- rithme de gestion de la concurrence, nomme LICRA. L'algorithme LICRA est un algorithme optimiste fonde sur la detection de dependances et la resolution au- tomatique des con its en utilisant un mecanisme de transformation d'operations. Le mecanisme presente l'originalite d'employer un mecanisme de detection des dependances directes entre les operations au lieu de l'emploi des horloges logiques comme c'est le cas dans d'autres algorithmes optimistes. Chapitre 5 Conclusion 5.1 Les principaux apports Les travaux presentes dans ce memoire ont permis d'une part d'elucider la problematique de la construction de collecticiels et d'autre part de denir une nouvelle architecture logicielle pour supporter le travail cooperatif. Nous resu- mons nos principales contributions a la recherche en TCAO dans les deux sections suivantes. 1. La problematique des collecticiels. Tout collecticiel se decompose en trois axes : la communication, la coordination et la production. Cependant nous distinguons selon la nature de l'unite du contr^ole trois classes disjointes de col- lecticiels : Les collecticiels a immersion ou le contr^ole s'exerce sur les utilisateurs eux- m^emes. Ce type de collecticiels implante une extension virtuelle de l'espace physique (ex. monde virtuel). Les collecticiels proceduraux ou le contr^ole s'exerce sur le routage de l'infor- mation entre les utilisateurs (ex. applications de ux de travail). Les collecticiels contractuels ou le contr^ole s'exerce sur les primitives de par- tage et d'acces aux donnees sujet de la cooperation (ex. editeur cooperatif). Nous nous somme interesse a la construction des collecticiels de troisieme type. Une approche generalement empruntee pour construire ces applications consiste a denir une plate-forme qui fournit l'ensemble des services requis pour la cooperation (communication, production et coordination). Nous avons montre que pour qu'une plate-forme soit generique elle doit fournir les deux services additionnels suivants : Permettre l'orchestration et l'emploi d'un groupe de collecticiels par le m^eme groupe d'individus. 124 Conclusion Integrer le travail individuel et le travail cooperatif. Nous avons utilise le terme environnement de cooperation (EdC) pour designer une plate-forme qui fournit ces deux services. Pour identier les choix a faire pour construire un EdC nous avons emprunte la demarche suivante : 1. Identier les services qu'une plate-forme exemplaire doit fournir pour re- soudre deux problemes fondamentaux dans le travail cooperatif a savoir : le probleme de la participation d'un utilisateur a une activite cooperative et le probleme de la coordination entre les participants a une activite. 2. Comparer les dierentes approches proposees dans la litterature de TCAO pour la construction d'une plate-forme cooperative en fonction de leur sa- tisfaction des services identies dans l'etape precedente. A l'issue de la premiere etape, nous avons identie les services suivants : Services requis pour la participation Implanter les deux strategies de gestion de rendez-vous : explicite et impli- cite. Permettre le passage souple entre les deux modes de travail individuel et en groupe. Implanter les deux strategies d'enregistrement : libre et supervise (implicite ou explicite. Permettre la participation dynamique de nouveaux arrivants ainsi que les departs anticipes. Services requis pour la coordination Fournir un service de denition et de gestion de r^oles fonctionnels. Supporter les deux types d'interaction : synchrone et asynchrone. Implanter un service de presentation de la co-presence. Ce service doit cou- vrir les quatre aspects de la description de la co-presence (Qui? Ou? Quoi? et Comment?) Implanter des strategies variees de gestion de la concurrence. A l'ensemble de services cites ci-dessus s'ajoutent les deux fonctions generales suivantes : Permettre le changement dynamique de la conguration des activites. 5.1 Les principaux apports 125 Permettre l'evolution future des fonctions oertes. La classication proposee des approches de construction de plates-formes pour le TCAO repose sur les trois criteres suivants : 1. Le niveau du support qui peut ^etre au niveau de l'interface homme machine, au niveau de donnees ou au niveau de la communication. 2. L'architecture de mise en uvre qui peut ^etre centralisee, dupliquee ou hybride. 3. Les applications supportees qui peuvent ^etre des nouvelles applications ou des applications existantes. Dans le dernier cas la transformation d'une application en collecticiel peut se faire par integration (sans modication de code) ou par adaptation (avec modication de code). La comparaison fonctionnelle des approches identiees ci-dessus nous a revele les choix suivants a suivre pour construire un EdC : 1. Denir le support de la cooperation au niveau de donnees. 2. Construire les collecticiels a employer dans l'EdC selon une architecture completement dupliquee. 3. Restreindre le reutilisation d'applications existantes a l'integration selon l'approche haut niveau (niveau de l'application) ou par voie d'adaptation. 2. La solution : Colt Nous avons propose une nouvelle architecture logicielle pour supporter le travail cooperatif appelee l'environnement de cooperation Colt. Les choix de construction de Colt s'appuient sur les resultats de notre etude de comparaison des approches de construction existantes dont le resultat est donne ci-dessus. Parmi les dierents services requis d'un EdC nous avons mis l'accent dans l'etude de conception de Colt sur les services suivants : 1. Fournir un modele generique de rendez-vous. 2. Permettre le lancement et l'execution de scenarios cooperatifs varies. 3. Permettre le passage facile entre le travail individuel et le travail en groupe. La conception de Colt presente plusieurs innovations en particulier la combi- naison des deux metaphores de conception : les locaux partages et les pieces pour modeliser les activites cooperatives. Un autre point interessant dans la conception de Colt est la denition d'un modele souple pour la specication et l'evaluation des droits d'acces et de regles de protection de l'espace partage. Une nouveaute presentee par ce modele est l'introduction de la notion du r^ole utilisateur comme un r^ole a part entiere auquel nous pouvons associer des privileges exceptionnels 126 Conclusion (positifs ou negatifs). Une attention particuliere est faite en vue de doter l'environ- nement de strategies variees pour contr^oler les acces concurrents des utilisateurs aux donnees partagees. L'environnement Colt propose une famille de protocoles de tour de r^oles et integre le protocole LICRA (chapitre 4) que nous avons concu et propose dans le cadre de cette these. Une etude de comparaison avec d'autres plates-formes et environnements de cooperation nous a montre la richesse fonctionnelle de notre proposition. La fai- sabilite du concept est demontree par le developpement d'un prototype reduit sur un ensemble de stations Unix et en utilisant l'environnement de programmation TCL-TK. 5.2 Les perspectives Les perspectives de ce travail sont nombreuses. Nous presentons dans la suite deux types de perspectives : des perspectives concernant l'environnement Colt et d'autres concernant la recherche dans le domaine du TCAO. Des perspectives pour l'environnement Colt Nous souhaitons continuer le developpement de l'environnement Colt selon les axes suivants : 1. Amelioration du mecanisme de specication des activites Un premier axe consiste a fournir un langage adapte a pour la specication des modeles d'ac- tivites cooperatives. Nous souhaitons aner les modeles d'activites pour pouvoir prendre en compte des formes plus variees d'interaction entre les utilisateurs. En particulier nous souhaitons mettre en uvre des services de fragmentation des documents de cooperation qui rendent possible d'attribuer a des utilisateurs dierents des privileges dierents sur des zones dierentes d'un m^eme document. 2. Integration des collecticiels proceduraux et des collecticiels a immer- sion Une approche envisageable pour l'integration de collecticiels proceduraux consiste a doter l'environnement d'un mecanisme d'expression et d'evaluation de regles d'induction qui agissent sur les criteres de demarrage, de validation et de terminaison des activites cooperatives. Par exemple pour specier qu'un docu- ment doit ^etre edite par un groupe et corrige par un autre, il nous sut de creer deux activites : la premiere correspond a la phase d'edition et la deuxieme a la phase de correction. Le demarrage de la deuxieme activite est subordonnee a la terminaison de la premiere activite. Des perspectives pour la recherche en TCAO Un premier objectif consiste a completer l'etude de comparaison des approches de construction des plates- formes pour les collecticiels en vue de proposer un veritable systeme d'aide a la 5.2 Les perspectives 127 conception des collecticiels. La fonction d'un tel systeme est d'indiquer l'approche la plus appropriee pour la construction d'un collecticiel en s'appuyant sur les connaissance suivantes : { Les limitations fonctionnelles des approches de construction de collecticiels. Avoir ce type de connaissance nous demande d'etendre l'ensemble des cri- teres retenus pour la comparaison fonctionnelle cites dans (chapitr 2) pour qu'il englobe l'ensemble des services requis pour la cooperation (voir annexe B). { Le co^ut de fonctionnement d'un collecticiel. Il depend de la conguration materielle disponibles (stations et reseau d'interconnexion) et du schema de mise en uvre du collecticiel. { Le co^ut de developpement du systeme. Il depend de la possibilite d'inte- gration ou d'adaptation des applications existantes et de la possibilite de reutilisation de codes et de l'emploi des services pre-denis pour la coope- ration. Un autre objectif sur lequel l'auteur de cette these souhaite continuer son tra- vail est l'etude des methodes de construction des interfaces homme-machine pour le travail cooperatif. Un probleme central dans la construction d'un collecticiel (ou d'un EdC) est celui de la presentation de la co-presence des utilisateurs. Peu de travaux dans la litterature ont aborde le delicat probleme de denition des nouvelles metaphores et de modeles d'interaction avec la machine qui prennent en compte les contraintes du travail en groupe. 128 Conclusion Annexe A Pluridisciplinarite du TCAO : Apport des sciences humaines Ayant pour clientele des groupes humains, le concepteur de collecticiels est contraint a comprendre la nature et la dynamique du travail en groupe et a pouvoir analyser et mesurer l'impact des collecticiels sur le comportement des groupes cibles. Par consequent la contribution des sciences humaines, qui ont pour objet d'etude l'homme et la societe, est primordiale. La pluridisciplinarite complique davantage le developpement des collecticiels. Elle demande d'etablir un dialogue et une synergie qui reunie dierentes domaines de competences cpmme l'informatique, la sociologie et la psychologie. E tablir un dialogue positif au sein d'une telle synergie demande a tous les partenaires de montrer une soupleless et une ouverture a l'egard des autres dis- ciplines. Un dialogue entre des individus qui ont des cultures dierentes est une t^ache reputee par sa diculte. Un premier obstacle est la construction d'un re- ferentiel commun ou chacun des partenaires peut interpreter correctement les actes et les contributions des autres. La construction d'un tel referentiel est d'au- tant plus dicile que la divergence initiale entre les referentiels propres a chaque partenaire est grande. L'interference des sciences sociales ou sciences humaines avec des sciences informatiques n'est pas une exclusivite du domaine de TCAO. La psychologie co- gnitive est deja au centre des etudes de conception et d'evaluation des interfaces homme-machine. La science de la gestion et la sociologie sont d'importance ex- tr^eme pour la conception des systemes d'automatisation de bureau (un domaine considere par certain comme le predecesseur directe du TCAO). La particularite des collecticiels est qu'ils font appelle a une grande nombre des disciplines variees a la fois. De nombreuse etudes ont montre que la faible notoriete des collecticiels est due a des raisons sociales plut^ot qu'a des raisons technologiques. Dans [Grundin88] l'auteur attribue l'echec de l'adoption des col- 130 Pluridisciplinarite du TCAO : Apport des sciences humaines lecticiels dans les organisations actuelles aux facteurs suivants : 1. La disparite de la distribution du prot apporte par l'utilisation d'un col- lecticiel. 2. La tendance presque monotone des directeurs de favoriser l'utilisation d'ap- plications qui servent leurs propres inter^ets. La diculte de satisfaire les contraintes precedents depende essentiellement du modele de communica- tion employe. Par exemple si le modele de communication garantit une communication able et en ordre total les trois conditions sans se soucier de leurs eets sur les autres membres de l'organisation. 3. La grande diculte d'evaluer les avantages et les inconvenients de l'introduction d'un collecticiel aux organisations. Dans [Markus et al.90] les auteurs renforcent l'analyse de l'echec cite ci- des- sus. Ils montrent que le prot apporte a un utilisateur est une fonction du ratio de nombre d'utilisateurs qui adopte le collecticiel par rapport au nombre de ceux qui ne l'adopte pas. Ils montrent qu'une masse critique d'utilisateurs du systeme doit ^etre atteinte an que le collecticiel soit protable. Pour illustrer cette notion de masse critique prenons l'exemple d'une simple application d'agenda coopera- tif. La gure A.1 montre les variations du prot d'un utilisateur (la courbe U) et de celui d'un non-utilisateur (la courbe N) en fonction du nombre total des utilisateurs de l'application. Les deux courbes sont des droits paralleles ou la dierence P2 , P1 represente le co^ut que paie un utilisateur pour utiliser le sys- teme (par exemple le temps qu'il passe a maintenir son entree dans l'agenda). Le prot collectif de l'ensemble de l'organisation est represente en courbe pointille. D'apres cette gure le nombre total d'utilisateurs doit ^etre superieur a Nc , la masse critique par denition, pour que l'utilisation du collecticiel soit protable. Profit (N) P3 P2 (U) P1 Nombre d’utilisateurs Nc Nmax Fig. A.1 - : Le concept de la masse critique : le nombre des utilisateurs du col- lecticiel doit ^etre superieur a Nc pour que son rendement soit positif. A.1 Le r^ole de l'ethnographie 131 Pour contourner le probleme de la creation d'une masse critique une organi- sation peut forcer l'utilisation du collecticiel a tous ses membres. Cette solution est loin d'^etre la bonne puisque toute sorte l'obligation cree une resistance qui ne serait pas toujours au prot du collectif. Les etudes citees ci-dessus et d'autres montrent que la conception et l'intro- duction d'un collecticiel au sein d'une organisation necessite une analyse sociale et organisationnelle du contexte du travail. Dans le m^eme temps l'emploi d'un collecticiel in uencerait sans doute la culture de l'organisation cible. Une relation dialectique existe entre la technologie du TCAO et la sociologie des organisations cibles. Nous exposons les dierentes facettes de cette relation dans les paragraphes qui suivent. A.1 Le r^ole de l'ethnographie La negligence des donnees sociales est designee d'^etre le facteur principale de l'echec constate des collecticiels [Markus et al.90], [Shapiro94]. An de combler la lacune, les informaticiens sont amenes a cooperer avec des sociologues et des ethnographes pour identier les besoins de travail en groupe. L'ethnographie, selon Larous, est la branche des sciences humaines qui a pour objet l'etude descriptive des ethnies. Un ethnie est un groupement de familles dans une aire geographiquement variable dont l'unite repose sur une structure familiale, economique ou sociale commune et sur une culture commune. L'ethno- graphie est en consequence la science qui s'occupe d'etudier le nature de travail et de relation au sein des entreprises et des organisations sociales. Une experience de construction d'un collecticiel de contr^ole aerien fondee sur une etude ethnographique est decrite dans [Hughes et al.92], [Bentely et al.92a]. Dans cette etude les auteurs concluent que malgre la diculte de la cooperation entre des ethnographes et des informaticiens (une diculte que nous explicitons dans la section A.5) l'etude ethnographique du contexte de l'utilisation du sys- temes a largement in uence les choix de conception du collecticiel. Les resultats de cette etude ont revele que certaines regles recommandees generalement pour la conception des systemes informatiques ne sont plus valables dans le domaine du collecticiel. A titre d'exemple, nous citons la regle suivante contredite par l'etude ethnographique : Le systeme informatique doit automatiser toutes les t^aches manuelles qui consiste a comparer des donnees semblables et a trier des listes de donnees. Les observations ethnographiques montrent que certaines interventions ma- nuelles doivent le rester. D'autre c^ote, l'ethnographe apres avoir etudie le do- maine de l'utilisation d'un systeme, devient la personne la plus apte a remplacer l'utilisateur nal pour l'evaluation du systeme avant son delivrance. Ainsi, il peut 132 Pluridisciplinarite du TCAO : Apport des sciences humaines contribuer a decouvrir des erreurs et des defauts de conception et d'implantation dans une phase preliminaire de la construction du produit. Pour resumer, l'eth- nographie contribue a la fois a guider l'etude de conception du collecticiel et a participer a l'evaluation du systeme pendent et apres son developpement. A.2 Le r^ole de la psychologie L'autre facette de la dialectique socio-technique du TCAO se manifeste dans les eets psycho-sociales de l'emploi des collecticiels. L'etude de l'impact des collecticiels sur le comportement des utilisateurs entre par excellence dans le domaine de la psychologie sociale. Les eets psychologiques de l'utilisation de collecticiels ont ete d'abord ob- serves dans le cas des collecticiels de communication homme-homme mediatisee (CHHM) tels le courrier electronique (e-mail) et le News. Les etudes de l'utili- sation des outils de CHHM ont revele que les utilisateurs montrent une agres- sivite nettement superieur par rapport aux autres methodes de communication (par exemple dans le cas des reunions conventionnelles). Les insultes et l'utilisa- tion des mots et des expressions inappropries ne sont pas rares [Dyre et al.95]. L'agressivite verbale peut favoriser la violence et aaiblir la cohesion interne de l'organisation. L'analyse faite dans [Dyre et al.95] suggere que l'emploi d'appli- cation de CHHM conduit les utilisateurs a un etat psychologique d'individuation ou chacun est moins conscient des ses propres actes et des eets de ses actes sur les autres. Dans [Sproull et al.91] les auteurs comparent le deroulement et la qualite des decisions prises par des groupes mediatises (qui se servent des outils de CHHM) par rapport a des groupes conventionnels (ou les reunions sont faites face a face). A l'issu de cette etude les auteurs identient les caracteristiques suivantes des groupes mediatises : c1. La distribution de periodes de prise de parole est plus equitable. c2. La participation des individus places vers l'haut du pyramide organisationnel du groupe est beaucoup plus reduit. Ceci a le consequence directe de reduire le poids d'avis de ces personnes contrairement aux reunions conventionnelles ou ces m^eme gens dominent le groupe. c3. Obtenir un consensus est plus dicile pour les groupes mediatises. L'emploi d'une langage violente est l'un des facteurs sources de cette diculte. c4. En consequence directe de c1 et de c2, la qualite des decisions prises par les groupes mediatises est meilleur puisque l'expertise est devenu prioritaire a la position sociale. A.3 La psychologie cognitive 133 c5. Les decisions prises par les groupes mediatises comprennent plus des risques que celles prises par les groupes conventionnelles. Les resultats de cette etude montrent que l'emploi de collecticiels n'est pas tou- jours recommande. La decision d'entreprendre une reunion mediatisee ou une reunion conventionnelle depende du contexte du travail et des enjeux a discuter. A.3 La psychologie cognitive La psychologie cognitive vise a comprendre et a modeliser les mecanismes co- gnitifs mis en jeu dans les activites humaines (planication, execution d'un plan, apprentissage, memorisation et perception de l'environnement). La contribution de la psychologie cognitive est une extension directe de sa contribution dans le domaine de la conception et de l'evaluation des interfaces homme- machine. Un aspect important de l'application de la psychologie cognitive dans le domaine du travail cooperatif consiste a evaluer la capacite de l'interface d'un collecti- ciel a favoriser la communication et la cooperation. Des systemes d'evaluation des interfaces de collecticiels fondes sur des theories cognitives sont deja dispo- nibles. Nous citons pour l'exemple le systeme MESC (methode d'evaluation du support a la cooperation) [ZV et al.95a], et le systeme ICS (Interacting Cognitive Subsystemes) [Salber95]. La methode MESC est une methode d'evaluation pre- dictive. Elle utilise les modeles de specications conceptuelles et de l'interaction homme-machine pour evaluer plusieurs alternatives de conception [ZV et al.95b]. Le systeme ICS presente l'inter^et de prendre en consideration les aspects cognitifs de l'interaction humaine avec des systemes informatiques multimedias. A.4 Sciences de la communication Il y a communication chaque fois un ensemble d'individus se met a travailler en commun. La communication fait depuis long temps l'objet des etudes scien- tiques. Les sciences de la communication se sont interesse a toutes les facettes d'un processus de communication : la transmission de donnees, les langages ver- bales et non verbales (gestuelle), l'organisation des individus communicants et m^eme la formation a la communication [Amado et al.93]. Il est evident que les resultats apportes par les sciences de communication sont d'extr^eme importance pour l'etude de conception des collecticiels. Une presentation complete des die- rentes theories de communication et de leurs in uence dans le domaine du TCAO est faite dans [Mccarthy et al.94]. D'autres branches des sciences sociales, comme l'ethique informatique et le droit sont aussi demande a contribuer au domaine du collecticiel. L'etude de contributions de ces sciences est encore dans des phase primaires. Nous renvoyons le lecteur au [Salber95] pour une essaie sur la contri- 134 Pluridisciplinarite du TCAO : Apport des sciences humaines bution attendue de ces deux branches de sciences sociales dans le domaine de TCAO. A.5 Pluridisciplinarite : mise en uvre Le large eventail des domaines et de disciplines lies a l'etude et a la realisa- tion des collecticiels montrent qu'une equipe de recherche qui s'occupe du travail cooperatif assiste par ordinateur doit ^etre une equipe pluridisciplinaire. La pro- jection des contributions de dierentes disciplines sur les trois principales phases de developpement d'un logiciel, a savoir : analyse de besoins, conception et proto- typage, et evaluation est donnee a la gure (A.2). En pratique, la mise en uvre Analyse de Besoins Sciences Humaines Prototypage Évaluation Sciences Pluri- Informatiques Disciplinaire Fig. A.2 - : Pluridisciplinarite du developpement du collecticiel d'une telle synergie rencontre de nombreuse dicultes. Parmi ces dicultes nous citons les suivantes : 1. La taille du groupe : les presentes methodes d'etudes sociologiques et ethno- graphiques s'appliquent a des populations quasi- fermees et a eectif reduit. Il est dicile d'eectuer des etudes sociologiques poussees sur des popula- tions complexes (organisations). 2. Le temps d'etude : les etudes sociologiques exigent des durees d'etude ty- piquement longues. Le temps requis pour faire une etude ethnographique depassent facilement toutes contraintes raisonnables pour la realisation des systemes informatiques. 3. La nature analytique des sciences humaines : les sciences sociales sont ty- piquement des sciences analytiques. Elles decrivent les problemes sans pro- poser des solutions. Les informaticiens auront la t^ache dicile d'interpreter A.5 Pluridisciplinarite : mise en uvre 135 les resultats des etudes sociologiques et de degager des solutions techniques aux problemes identies. An d'eviter les problemes cites ci-dessus, de nouveaux schemas de cooperation entre des sociologues et des informaticiens sont proposes dans [Hughes et al.94] : 1. L'ethnographie concurrente : ou la conception d'un collecticiel est faite en parallele avec une etude ethnographique de son domaine d'utilisation. 2. L'ethnographie rapide et sale : ou une breve etude ethnographique precede la conception du systeme 3. L'ethnographie evaluative : ou une etude ethnographique est faite pour va- lider des choix de conception deja faits. La gure A.3 illustre les trois schemas proposes ci-dessus. Conception préliminaire Étude Conception de Étude Réunion de discussion Ethnographique Système Ethnographique Réunion de discussion Courte & Ciblée Prototype du système Etude de conception (a) Ethongraphie concurrente (b) Ethongraphie Rapide Spécification du Système Étude Ethnographique Réunion de discussion Courte Conception approuvée (c) Ethongraphie évaluative Fig. A.3 - : Alternatives de coop eration socio-technique pour la conception de collecticiels [Hughes et al.94] 136 Pluridisciplinarite du TCAO : Apport des sciences humaines Annexe B Services pour la cooperation L'objectif de cette section est d'identier les services requis d'un support sys- teme informatique pour la construction et l'execution des collecticiels contrac- tuels. Plusieurs approches sont empruntees dans la litterature du TCAO an d'atteindre cet objectif. Une premiere approche, dite formelle, repose sur l'intro- duction d'un formalisme qui modelise la cooperation. Plusieurs modeles formels pour le travail cooperatif sont proposes. Des exemples sont le modele fonde sur la logique modale [Diaz92] et le modele d'objets cooperatifs fonde sur l'integra- tion des techniques de reseaux de Petri et l'approche de modelisation par objets [Palanque et al.95]. C'est aussi le cas du modele d'objets re ectifs propose dans [Dourish95a]. Le domaine des applications cooperatives etant vaste, il est dicile de trouver un modele formel qui modelise les dierents types de collecticiels. A notre avis, un formalisme sert avant tout a clarier un aspect particulier du tra- vail cooperatif. Il serta verier la correction des solutions proposees qui mettent en uvre les aspects qu'il modelise. Une deuxieme approche, que nous qualions d'approche sectorielle, consiste a identier les besoins d'une classe restreinte de collecticiels. Des exemples sont les etudes centrees sur les besoins des collecticiels synchrones [Roseman et al.93, Edwards95, Balter et al.96a] ou les travaux centres sur le probleme de l'edition cooperative [Nastos92, Knister et al.93]. Par nature, les etudes sectorielles pre- sentent une vue partielle de l'ensemble des besoins du travail cooperatif. Elle peuvent neanmoins alimenter des etudes dont les perspectives sont plus larges. Une autre approche, que nous qualions de pragmatique repose sur l'analyse des scenarios varies de cooperation pour en deduire les besoins communs. Deux travaux interessants dans ce domaine sont l'etude menee par Schmidt et Rodden dans [Schmidt et al.93] et l'etude reportee dans [Almasi et al.94]. Notre etude reprend et complete les resultats de ces deux travaux. Par souci de clarte, nous avons choisi de structurer notre demarche en appor- tant des elements de reponse a la suite logique des questions suivantes : Pourquoi travaille t-on en groupe? Avec qui? Quand choisir de travailler ensemble? Comment? Et sous quelles contraintes? Nous developpons nos reponses a chacune des ques- 138 Services pour la cooperation tions precedentes dans la suite. B.1 Pourquoi ? Pour resumer l'inter^et et les enjeux du TCAO, Derycke et Hoogstoel font dans [Derycke et al.95] l'analogie du travail cooperatif avec les systemes multi- processeurs : \: : : le passage d'un individu/processeur a N individus/processeurs n'en- tra^ne pas un gain d'un facteur N. Pour certains processus, il peut m^eme y avoir deterioration de la performance (le cas de la vitesse dans la prise de decision), dans d'autres cas, le gain est inni : un individu seul ne pouvant accomplir la t^ache". L'analogie TCAO / systemes multi-processeurs montre que deux motivations principales peuvent ^etre a l'origine du lancement d'une activite cooperative : 1. La nature de la t^ache a faire necessite l'intervention de plusieurs individus. C'est le cas d'une activite d'enseignement ou une cooperation enseignant- eleve est requis. 2. L'intervention de plusieurs individus peut ameliorer la qualite du travail ou reduire le temps de l'execution de la t^ache. C'est le cas d'un processus de prise de decision (ameliorer la qualite) ou de la redaction commune d'un document (reduire le temps). La decision d'eectuer en groupe une t^ache qui peut ^etre faite individuellement est generalement fondee sur une conviction que le prot apporte par le groupe est plus important que le co^ut de la coordination entre les membres du groupe. Parfois le besoin de cooperer avec d'autres peut ^etre ressentie pendent l'exe- cution individuelle d'une t^ache ; souvent la progression d'une t^ache necessite d'al- terner des phases de travail individuel et des phases de travail en groupe. Pour illustrer ceci prenons l'exemple d' un utilisateur qui redige une lettre ou un cour- rier electronique. Il estime qu'il a besoin de l'avis d'une autre personne pour corriger et reviser sa lettre. Demander l'aide d'un autre utilisateur ne doit obliger l'utilisateur a changer l'application de traitement de texte qu'il utilise pour redi- ger la lettre. Par suit, un premier besoin requis d'une plate-forme pour collecticiels est le suivant : B1. Permettre le passage facile entre les deux modes de travail : individuel et en groupe. B.2 Qui ? 139 B.2 Qui ? La designation des individus qui peuvent participer a une activite cooperative depend de la nature et du but de l'activite en question. Nous distinguons deux sortes de designation : 1. Designation directe ou les participants potentiels sont designes chacun par son propre nom. C'est le cas par exemple d'une reunion entre amis. 2. Designation indirecte ou la participation d'un individu a une activite lui demande de remplir un critere ou d'avoir un r^ole particulier. C'est le cas par exemple d'une reunion d'equipe de travail dont seuls les membres de l'equipe peuvent y faire part. La mise en uvre des politiques de designation citees ci-dessus demande de fournir a chaque utilisateur (qui demarre une activite) des informations sur les autres utilisateurs potentiels du systeme. Le support systeme doit donc fournir une base d'informations qui decrit les membres de l'organisation cible du collec- ticiel. Cette base contient des informations sur les utilisateurs, leurs noms, leurs coordonnees, leurs r^oles et leurs rangs dans l'organisation, leurs competences et les t^aches qui leurs sont conees. Un utilisateur doit pouvoir interroger cette base pour trouver les personnes les plus aptes a cooperer avec lui sur sa t^ache cou- rante. Par consequent, un support systeme pour le travail cooperatif doit remplir le besoin suivant : B2. Fournir un repertoire organisationnel. E^ tre designe pour participer a une activite est une condition necessaire mais non susante pour participer eectivement a l'activite en question. D'autres conditions peuvent ^etre exigees. Par exemple, le nombre de participants peut ^etre limite pour certaines t^aches. C'est le cas dans la plupart des jeux multi- utilisateurs. D'autres t^aches exigent que la participation d'un individu soit parrine par un ou plusieurs participants actuels. Il n'existe pas une seule politique de contr^ole d'appartenance qui soit compatible avec tout sorte de collecticiels. De la, une plate- forme pour le travail cooperatif doit satisfaire le besoin suivant : B3. Fournir une variet e de politiques de gestion d'appartenance aux groupes. Dans certains cas, surtout lors de l'initiation des activites cooperatives temps reel, il est souhaitable, voire necessaire, de coupler le service de designation par un service qui montre l'etat actuel de l'occupation des utilisateurs designes (comme c'est le cas lors d'un appel telephonique). Il en decoule qu'un support systeme pour le TCAO doit fournir le besoin suivant : B4. Rendre perceptible a chaque utilisateur l'existence et la disponibilite des autres utilisateurs dans l'espace partage. 140 Services pour la cooperation Independamment du mode de designation des utilisateurs, il se peut qu'un utilisateur qualie pour participer a une t^ache ne soit pas disponible lors du lancement de l'activite. De m^eme, il se peut qu'un participant quitte une t^ache avant sa terminaison. L'arrivee tardive ou le depart anticipe d'un utilisateur ne doivent pas perturber le deroulement d'une activite. Par exemple, dans une seance de tele-enseignement un etudiant qui arrive en retard doit avoir la possibilite de rejoindre la session. De m^eme, le depart d'un etudiant ne doit pas entra^ner l'interruption de la session. D'autre part, les besoins d'une activite cooperative peuvent changer en cours du deroulement de l'activite. Par exemple, dans une activite de prise de decision, l'examen du probleme a resoudre peut montrer que la participation de nouveaux experts est recommandee, ou l'inverse. Par consequent, un support systeme doit remplir le besoin suivant : B5. Permettre la composition dynamique du groupe des coop erants. B.3 Quand ? Selon leurs modes de lancement les activites cooperatives peuvent ^etre classees en deux classes : 1. Les activites planiees pour lesquelles le moment du demarrage est connu a l'avance. La date de demarrage peut ^etre absolue ou relative. Un exemple d'une date absolue est l'inscription d'une reunion sur un agenda. Un exemple de date relative est de lier le demarrage a l'occurence d'un ou plusieurs eve- nements, par exemple la terminaison d'une autre activite. 2. Les activites opportunistes ou le lancement de l'activite est fait d'une ma- niere fortuite. C'est le cas du rencontre de deux ou plusieurs utilisateurs sur un m^eme document (ex. acceder en m^eme temps a la m^eme page Web). An de supporter l'execution des activites du premier type le systeme doit fournir aux utilisateurs la possibilite de conna^tre les activites planiees et les activites en cours. Les caracteristiques de chaque activite annoncee doivent ^etre precisees (par exemple les conditions et le mode de participation). De plus, les utilisateurs doivent avoir la possibilite d'annoncer la creation d'une nouvelle ac- tivite (par publication ou par envoi des invitations aux autres utilisateurs). Ceci nous laisse deduire le besoin suivant : B6. Fournir un r epertoire des activit es coop eratives. Favoriser le lancement fortuit des activites renforce le besoin B4 qui incite a fournir une service de conscience de groupe qui rend chaque utilisateur conscient de l'existence et des positions des autres dans l'espace partage. B.4 Comment? 141 B.4 Comment? Generalement, la realisation d'un uvre commun par un groupe demande aux acteurs : de communiquer entre eux pour discuter, argumenter et commenter leurs contributions, de partager les objets constituant l'uvre et de pouvoir les echanger entre eux. Par exemple lors de la redaction d'un document les coauteurs doivent avoir la possibilite de communiquer entre eux pour discuter l'elaboration du document, de corriger et d'annoter leurs contributions et en m^eme temps ils doivent avoir acces au m^eme document ou pouvoir echanger entre eux les fragments du document qu'ils redigent. Par consequent un support pour la cooperation doit fournir le besoin suivant : B7. Fournir des m ecanismes de communications directes entre les utilisateurs et des m ecanismes de partage et/ou echange d'informations. La mise en uvre des mecanismes de communication et de partage d'infor- mations necessite de fournir des politiques de coordination entre les dierents utilisateurs (par exemple il faut eviter que tous les utilisateurs editent en m^eme temps la m^eme section d'un document partage ou que tous les utilisateurs parlent en m^eme temps sur un canal audio). Une variete de politiques de coordination peuvent ^etre mises en place. Dans [Greenberg et al.94] les auteurs montrent qu'il n'existe pas une politique de gestion de la concurrence qui peut ^etre appliquee dans tout sorte de collecticiel. Le choix de la politique a appliquer depend du contexte et de la nature de l'activite cooperative. De la nous deduisons le besoin suivant : B8. Fournir une vari et e de politiques de coordination pour la gestion de la communication et du partage d'informations. B.5 Contraintes L'introduction des collecticiels aux organisations humaines rencontre beau- coup de dicultes. Plusieurs travaux attribuent l'echec des collecticiels a la negli- gence des aspects sociaux des organisations cibles et a l'insusance des etudes des eets sociaux et psychologiques de l'emploi des collecticiels [Grundin88, Grundin94, Dyre et al.95]. La prise en compte des aspects sociaux et psychologiques demande d'etablir une synergie qui reunit des informaticiens, des psychologues et des eth- nologues. Nous developpons l'aspect pluridisciplinaire du TCAO et les problemes 142 Services pour la cooperation qui en resultent dans l'annexe A. Dans ce m^eme annexe nous presentons une etude decrite initialement dans [Markus et al.90] dont la conclusion est la suivante : Pour qu'un collecticiel soit utilisable il faut qu'il satisfait une masse critique de ses utilisateurs potentiels. L'ordre de grandeur de la masse critique est bien s^ure une fonction du nombre total des utilisateurs potentiels, mais il est aussi fonction du rapport Satisfaction Effort pour chacun des utilisateurs. Il est clair que pour satisfaire le plus d'utilisateurs il ne faut pas que la technologie de la cooperation compromette les avantages acquises de la technologie traditionnelle de l'information (surtout par rapport a l'emploi des ordinateurs personnels en conjugaison avec des simples outils de communication comme le courrier electronique ou les systemes de transfert de chiers). Un premier aspect important dans ce contexte consiste a garantir la dispo- nibilite des informations ; une disponibilite assez elevee lors de l'utilisation des applications mono-utilisateurs sur des stations de travail personnelles. Par conse- quent un support systeme pour la cooperation doit repondre au besoin suivant : B9. Garantir la disponibilit e des informations partag ees. Le besoin precedent implique la necessite de fournir des mecanismes de tole- rance aux pannes et aux defaillances de sites et de reseaux d'interconnexion. D'autre part, les utilisateurs n'ont pas forcement les m^emes environnements informatiques du travail (materiels et logiciels). Les dierents utilisateurs posse- dent des stations de travail dierentes ( Sun, PC ou Macintosh), des systemes d'exploitation dierents ( Unix, Dos, Windows ou MacOs) et des applications dierentes pour mener la m^eme t^ache (par exemple deux utilisateurs peuvent employer deux editeurs de texte dierents pour rediger le m^eme document). Il est souhaitable donc qu'un support systeme pour le TCAO verie le besoin sui- vant : B10. Permettre l'h et erog enit e des environnements de travail en termes de plates-formes mat erielles et des equipements logiciels (syst emes et applications). Le fonctionnement et l'utilisation d'un collecticiel dependent fortement de son contexte d'utilisation. Par exemple ils dependent du but de l'activite coope- rative, du nombre de participants, des relations qui regroupent les participants et m^eme de l'etat d'avancement du travail. Pour illustrer la dependance entre la conguration du collecticiel et son contexte d'emploi prenons l'exemple concret du choix de la politique de gestion de droit de parole dans un collecticiel syn- chrone. Lorsque le nombre de participants est relativement petit (deux ou trois) une politique sociale, a l'instar du cas d'une communication telephonique, peut B.6 Synthese 143 ^etre ecacement employee. Mais lorsque le nombre de participants devient plus important (de l'ordre de dix personnes) il faut mieux remplacer la politique so- ciale par une autre politique (ex. passage du jeton) an de garantir une meilleure comprehension du deroulement de l'activite [Greenberg et al.94]. De m^eme, dans une reunion informelle nous pouvons appliquer une politique de prise de parole fondee sur le principe du premier demandeur premier servi, tandis que dans une reunion formelle on emploi souvent une politique d'animation ou un utilisateur privilegie se charge de d'attribution de droit de parole. Le contexte de l'emploi d'un collecticiel pouvant changer dynamiquement, il est important qu'un support systeme pour le TCAO verie le besoin suivant : B11. Permettre la configuration dynamique des activit es coop eratives. Un dernier mais pas le moins important besoin concerne l'ouverture du sup- port systeme. Le domaine des applications cooperatives etant tres vaste, il est nave d'accepter qu'une realisation d'un support systeme fournit tout les services dont tous les scenarios cooperatifs imaginables ont besoin. D'ou le besoin suivant : B12. Un support syst eme pour le TCAO doit ^ etre ouvert a toute evolution future. B.6 Synthese Nous regroupons les besoins identies dans les sections precedentes en cinq principaux services qui sont les suivants : La conscience de groupe donne a chaque utilisateur une description des co- operants potentiels (B2), leurs positions dans l'espace partage et leurs etats actuels d'occupation (B3). Le service de conscience de groupe sert aussi a prevenir chaque utilisateur des activites en cours d'execution et des acti- vites planiees (B6) ainsi de lui montrer les zones de l'espace du travail auquel il a le droit d'acces (B7). Le partage et l'echange d'informations constitue un service de base pour la realisation en groupe des uvres communs (B7). La mise en uvre des mecanismes de partage et d'echange d'informations necessite le developpe- ment de mecanismes de coordination entre les utilisateurs (B8) ainsi que des fonctions de tolerance aux pannes an d'augmenter la disponibilite des informations partagees (B9). La gestion de groupes couvre les aspects de la denition de groupes (B2), de la gestion de l'appartenance aux groupes (B3,B5) ainsi que les aspects de communication directe a l'interieur d'un groupe (B7). 144 Services pour la cooperation La reconguration dynamique du systeme porte sur le changement dyna- mique de la conguration des activites cooperatives. Ceci couvre la possibi- lite de supporter la connexion et la deconnexion dynamiques des utilisateurs (B6), de changer les politiques de coordination appliquees au cours de la cooperation (B3,B11) ou de changer le mode de travail (B1). L'ouverture porte sur la possibilite d'enrichir les applications et les services of- ferts par de nouveaux services et de comportements non initialement prevus par le systeme (B12). Une autre facette de l'ouverture consiste a supporter l'hetrogenite (materielle et logicielle) des systemes d'informations employees par les dierents utilisateurs (B10). Annexe C Les systemes repartis comme support pour le TCAO Les systemes repartis (SR) visent a faciliter la communication et le partage de ressources (memoire, prepheriques et puissance de calcul) disponibles sur des stations de travail connectees entre elles par un reseau informatique. Le but de la presente section est d'evaluer a quel point les actuels SR supportent la construc- tion des collecticiels. La quasi majorite des SR sont fondes sur le principe de la transparence de la distribution selon lequel la repartition de ressources est cachee aux applications et aux utilisateurs. Le but est de donner l'illusion aux utilisateurs qu'ils disposent d'une seule machine dont la capacite est egale a la somme des capacites des machines connectees sur le reseau. Nous analysons rapidement dans la suite la compatibilite du principe de la transparence de la distribution avec les besoins des collecticiels. L'etude est faite en analysant l'impact de ce principe sur la mise en uvre de six principaux services fournis par les SR qui sont les suivants : 1) la communication, 2) la duplication et la migration, 3) la gestion de la concurrence, 4) la tolerance aux pannes, 5) la memoire partagee repartie et 6) la protection des donnees. C.1 Modeles de communication Tout SR repose sur un modele de communication selon lequel un objet peut provoquer l'execution d'une operation sur un autre objet du systeme. La pro- jection de la transparence de la distribution sur le modele de communication se traduit par rendre identiques, du point de vue des applications, l'acces aux objets distants et locaux. Plusieurs modeles de communication sont proposes et utilises par les divers systemes. Nous examinons dans la suite les trois modeles les plus 146 Les systemes repartis comme support pour le TCAO employes. 1. Le modele client-serveur selon lequel la structuration d'un SR met en jeu deux entites : un client qui demande l'execution d'un service et un serveur qui realise ce service. Ce modele de communication est adopte par plu- sieurs systemes standards tels que ODP, OMG et DCE. Souvent, la mise en uvre du modele client-serveur repose sur l'emploi des appels de pro- cedures a distance (RPC1). Le principe est de permettre a un processus p, s'executant sur un site C (client) d'executer une procedure P sur un site S (serveur) avec un eet global identique a celui qui serait obtenu par l'execution locale de P [Balter et al.91]. A l'image d'un appel de procedure classique, le processus qui fait un RPC se bloque en attente du resultat. On dit alors que le RPC implante un modele de communication synchrone. Bien que le RPC puisse servir comme un mecanisme de base pour le par- tage et l'echange d'informations ainsi que pour implanter un service de conscience de groupe, il presente des proprietes qui limitent son utilite pour la construction des collecticiels dont les principales sont les suivantes : (a) La synchronisation entre le client et le serveur rend la cooperation plus dicile en raison de suspensions des executions a chaque envoi de mes- sage. Par exemple dans le cas d'edition synchrone d'un document l'uti- lisateur doit patienter apres chaque modication (ex. insertion d'un caractere) le temps qu'il faut pour notier les autres utilisateurs de la modication du texte. Ceci peut rendre l'editeur non-utilisable a cause de son long temps de reponse. (b) Les clients doivent conna^tre a l'avance les serveurs dont ils auront be- soin pendent leurs execution. Ceci est peu compatible avec les collec- ticiels qui sont des applications dont le comportement est dynamique et peu previsible. (c) Le modele client-serveur est un modele de communication bi-points qui ore peu de services pour la communication de groupe. 2. Le modele a diusion selon lequel le destinataire d'un message est un groupe de processus. L'exemple phare de l'emploi de ce modele est le systeme qISIS [Birman et al.94]. L'emploi d'un systeme a diusion pose le probleme ma- jeur de la gestion de l'ordonnancement de la reception des messages par le groupe destinataire. ISIS propose des mecanismes interessants qui per- mettent une grande soupeless dans le choix de l'ordre de la reception des messages (Ordre FIFO, causal, total) [Reness et al.96]. Ce modele de com- munication est particulierement attractif pour les applications cooperatives ou la notion de groupe est une notion centrale. 1 Remote Procedure Call. C.2 La migration et la duplication transparentes 147 3. Le bus de messages dont le principe repose sur le dep^ot asynchrone et la circulation des messages sur un bus logiciel auquel sont connectes les pro- cessus communicants (dits clients). Des exemples des bus de messages sont The Information Bus [Oki et al.93], Koala [Beust93] et Field [Reiss90]. La reception de messages par les clients est subordonnee a une acte d'abonne- ment. L'abonnement correspond a la mise en place d'un ltre qui permet de capter des messages circulant sur le bus et dont le client veut recevoir. La connexion au bus peut se faire d'une maniere dynamique. De plus les clients peuvent modier dynamiquement leurs abonnements. Le concept de bus de messages presente l'avantage d'^etre un moyen de communication asynchrone et anonyme. Il permet aussi une diusion asynchrone a de nom- breux destinataires. Cependant il n'ore pas un support adequat pour la gestion de groupes puisque la reception des messages est contr^olee par les recepteurs et non pas par l'emetteur. Ce dernier se contente de coner le message au bus sans avoir aucune information sur l'existence d'un destina- taire ou sans pouvoir restreindre l'emission a un ensemble des destinataires potentiels. D'autres modeles de communication, dont l'emploi est moins repandu que les modeles presentes ci-dessus sont : le modele de communication par espace de tuple, le RPC asynchrone et le modele communication evenementielle. Certains de ces modeles sont d'ailleurs proposes pour repondre en partie aux besoins de coordination non transparente entre processus communicants et le besoin de co- operation, comme c'est notamment le cas de la communication evenementielle. Une etude plus detaillee d'evaluation des mecanismes de communication pour les applications cooperatives est faite dans [Lenormand96]. C.2 La migration et la duplication transparentes La repartition des objets d'un systeme reparti pose un probleme de perfor- mance en raison des envois de messages a travers un reseau. Pour remedier a ce probleme deux mecanismes sont proposes : la duplication et la migration des objets. L'objectif est de raccourcir les distances entre les objets communicants et en consequence diminuer le co^ut de la communication. Les deux mecanismes fa- vorisent donc le partage de donnees en reduisant le co^ut d'acces aux informations partagees. Cependant ces deux mecanismes ajoutent un surco^ut de fonctionne- ment. Par consequence, l'emploi de ces mecanismes est une question de compromis entre les co^uts qu'ils ajoutent et les beneces qu'ils realisent. Un probleme majeur dans la mise en uvre de la duplication transparente est la gestion de la coherence des copies des donnees dupliquees. Le systeme se charge de garantir la coherence des dierentes copies. Certaines applications de TCAO, notamment les applica- 148 Les systemes repartis comme support pour le TCAO tions fondees sur le paradigme WYSIWIS 2 peuvent benecier d'un support de duplication transparente. Or dans le cas general, l'execution d'un collecticiel re- pose sur un modele de succession de divergences et de fusions des versions de donnees partagees [Dourish95b]. Remonter la divergence des donnees au niveau de l'interface-utilisateur est parfois une fonction necessaire [Condon92]. Par suite la gestion de la duplication doit ^etre faite dans le contexte de l'application et non pas au niveau du support systeme. La migration transparente fournit un moyen interessant pour supporter la dy- namicite et la exibilite requises pour les collecticiels. Par exemple il est tout a fait envisageable de faire recours a la migration pour informer un nouvel arrivant de l'etat actuel de la session cooperative qu'il vient de rejoindre. Le m^eme meca- nisme peut servir a optimiser le temps de reponse des applications a travers un meilleur equilibrage de la charge du systeme. Peu de travaux dans la litterature du TCAO ont etudie l'utilite de la migration pour la construction des collecticiels. Ceci constitue un axe de recherche qui nous semble interessant a explorer. C.3 La gestion de la concurrence Conformement au principe de la transparence de la distribution la plupart des protocoles de gestion de la concurrence sont fondes sur l'idee de donner a chaque utilisateur l'illusion qu'il est le seul a utiliser le systeme. Les activites de dierents utilisateurs sont isolees les unes des autres. La mise en uvre de l'isolation repose sur l'emploi des mecanismes de serialisation globale des actions faites par les utilisateurs. L'emploi des transactions est l'une des approches les plus classiques pour realiser ce type de transparence [Bernstein et al.87]. Or le principe de l'isolation est a l'oppose du principe de la cooperation ou chaque utilisateur doit avoir une vision des activites des autres utilisateurs (la fonction de conscience de groupe). De nouvelles politiques de gestion de la concurrence sont a fournir pour supporter le travail cooperatif. Ces nouvelles politiques reposeront sur les m^emes mecanismes de base (verrous et ordonnancement de messages). Nous etudions ce probleme en detail dans le chapitre 5. C.4 La transparence des pannes Le but est de cacher l'occurence d'une panne (du reseau ou d'un site) aux sites non defectueux. Or pour les collecticiels, le traitement des pannes ne doit pas ^etre systematiquemt cache aux participants. La reaction du systeme a l'occurence d'une panne depend de son contexte d'utilisation. Pour illustrer ce point, prenons l'exemple d'un collecticiel d'apprentissage cooperatif. Une session d'enseignement comprend, dans sa forme la plus simple, un enseignant et plusieurs etudiants. 2 What You See Is What I See. C.5 La memoire partagee repartie 149 L'arr^et ou l'isolation d'un site etudiant ne doit normalement pas entra^ner l'arr^et total de la session (transparence de la panne d'un site etudiant). Par contre la deconnexion du site de l'enseignant met le deroulement de la session en cause. Normalement, la session doit ^etre avortee. D'une maniere generale, le deroulement d'une session cooperative est garde par des conditions de travail. Ces conditions expriment la validite de l'execution de la session [Paoli et al.94, Villemur95]. La violation des conditions de garde entra^ne l'arr^et ou la suspension de la session. C.5 La memoire partagee repartie Un service de memoire partagee repartie (MPR) permet a des processus s'exe- cutant sur des sites interconnectes par un reseau de partager un m^eme espace d'adressage [Nitzberg et al.91]. Ainsi, chaque modication de la memoire parta- gee par l'un des processus va ^etre percue par les autres processus puisque ils partagent la m^eme memoire. Le concept de MPR permet une partage souple et ecace d'informations. De plus une MPR facilite la mise en uvre de certaines fonctions de traitement des evolutions dynamiques de la conguration d'un col- lecticiel, comme par exemple l'integration d'un nouvel arrivant ou la mise a jour des privileges d'un groupe d'utilisateurs, en raison de la propagation automatique a travers le systeme de tout mis a jour de la memoire.Un probleme cependant, pose par la mise en uvre d'une MPR, est celui de la gestion de la coherence de la memoire. La plupart des MPR emploient des protocoles de gestion de la coherence qui ne sont pas compatibles avec les besoins des applications coope- ratives (voir C.3). Une solution interessante a ce probleme est presentee par la MPR ARIAS qui fournit un service generique pour la gestion de la coherence qui permet aux applications de specier et d'implanter les protocoles de coherence qui conviennent le mieux a leurs besoins [Cortez96]. D'un autre c^ote, le concept de MPR ne fournit pas un support explicite pour la gestion des groupes d'utili- sateurs. Finalement, bien que une MPR se pr^ete bien pour implanter un service de conscience de groupe peu des MPR actuelles fournissent un tel service. C.6 Les modeles de protection de donnees Un aspect important dans tout systeme multi-utilisateurs est celui de la pro- tection des donnees. Le but d'un service de protection est d'inhiber toute mani- pulation des objets maintenus dans le systeme par des utilisateurs non autorises. Le principe d'un service de protection est de determiner si un acteur (applica- P tion executee au prot d'un utilisateur) a le droit d'appliquer une operation (lire, ecrire, supprimer, ,etc) sur un objet (chier, objet dans un dessin, case dans ::: O un tableau de calcul). La mise en uvre d'un service de protection doit satisfaire 150 Les systemes repartis comme support pour le TCAO plusieurs contraintes parmi lesquelles nous citons les suivantes : Le co^ut de l'execution de la fonction d'evaluation de droits d'acces doit ^etre le plus faible possible. Ce besoin est motive par l'execution tres frequente de cette fonction (a chaque demande d'acces a un objet). Un co^ut eleve peut aecter gravement les performances generales du systeme. Les utilisateurs doivent avoir une vision claire des regles d'acces mises en vigueur. En d'autres termes, le systeme doit permettre d'identier facile- ment les droits des dierents acteurs sur un objet donne ainsi que les droits attribues a un acteur precis. Les privileges attribues aux acteurs peuvent changes dynamiquement. Ceci est particulierement vrai dans le contexte du TCAO [Shen et al.92, Kanawati95]. Il est donc necessaire que le systeme de protection permette de changer les regles d'acces d'une maniere dynamique. Pour des raisons evidents de secu- rite, il est souhaitable que le changement d'une regle de protection prenne eet immediatement. Generalement les utilisateurs nals du systeme seront amenes a denir eux m^emes les regles d'acces des autres utilisateurs sur les objets qu'ils creent. Il est donc souhaitable que le systeme fournisse des primitives de manipulation et de denition de regles d'acces qui soient simples a employer. Le grand nombre d'entites (acteurs, objets et droits) qui intervient dans un sys- teme reparti (et dans un systeme cooperatif) complique davantage la mise en uvre des systemes de protection. Plusieurs modeles de gestion et d'expression de droit d'acces sont proposes dans la litterature. Nous presentons brievement dans la suite les deux approches les plus employees : les systemes a base de ma- trice de protection et les systemes a base de r^oles. 1. Les systemes fondes sur l'emploi de la matrice de protection : le concept de la matrice de protection est initialement propose par Lampson [Lampson74]. Les colonnes de la matrice representent les acteurs denis dans le systeme tandis que les lignes representent les objets disponibles. A l'intersection d'une ligne et d'une colonne se trouve le droit attribue a l'acteur associe a la colonne sur l'objet indexe par la ligne courante. An d'eviter de manipu- ler des matrices de grande taille et qui sont souvent creuses, deux strategies d'implantation de matrice de protection sont employees : implantation sous forme de listes d'acces (ACL) et implantation sous forme de listes de capa- cites. Selon la premiere approche chaque objet est associe une liste qui denit les acteurs qu'ont le droit de l'acceder (ca revient a couper la matrice en lignes). La deuxieme approche consiste a associer a chaque acteur une liste C.6 Les modeles de protection de donnees 151 qui donne les privileges qui lui sont attribues (voir gure C.1). Le concept de matrice de protection est assez intuitif. Il est simple a mettre en uvre. Les deux schemas d'implantation (ACL et capacites) permettent de reduire le co^ut de l'evaluation de droit d'acces. Cependant, ce type de systemes ore peu de support pour la gestion de groupes. De plus les privileges attribues aux utilisateurs sont en somme tres peu lisibles. Pour illustrer notre point de vue, prenons l'exemple concret du systeme Unix. Le systeme de protec- tion dans Unix est implante sous forme d'ACL. Des groupes d'utilisateurs peuvent ^etre denis an de faciliter l'expression des regles de protection. La composition des groupes est denie dans les deux chiers /etc/passwd et /etc/group. Il est donc tres facile de determiner les groupes auxquels un utilisateur appartient. Par contre, il est moins evident de recenser les pri- vileges attribues a un groupe, a defaut de parcourir l'ensemble du systeme de chiers. La decentralisation totale d'attribution des droits aux groupes (n'importe que utilisateur peut donner a un groupe le droit sur les chiers qu'il administre) rend la notion de groupe peu utile en terme d'unite d'or- ganisation. 2. Les systemes a base de r^oles. Un r^ole est une entite semantique qui denit un ensemble de privileges dans le systeme. Tandis que la notion de groupe, evo- que ci-dessus, designe un ensemble d'utilisateurs la notion de r^ole designe un ensemble de privileges. Un r^ole peut modeliser une competence particuliere (ex. informaticien) ou une autorite (ex. administrateur systeme). Plusieurs types de systemes de protection a base de r^oles sont denis. Une synthese des dierentes approches de denition des r^oles est donnee dans [Sandhu96]. Les droits attribues a un utilisateur sont determines par la combinaison des relations suivantes : (a) La relation r^ole-privilege qui decrit les droits associes a un r^ole. (b) La relation r^ole-r^ole ou certains r^oles peuvent heriter certaines de leurs attributions d'autres r^oles [Shen et al.92, ?]. (c) La relation r^ole-utilisateur qui denit l'ensemble des r^oles attribues a chaque utilisateur. L'articulation de ces trois relations permet de personnaliser facilement les privileges des utilisateurs. De plus, ce schema de protection semble ^etre plus naturel, de point de vue des utilisateurs vu la ressemblance avec les mecanismes de securite (non informatique) generalement employes dans les organisations. 152 Les systemes repartis comme support pour le TCAO Les Acteurs du système A1 A2 A3 A2 A3 Les objets du système O1 E E O1 E E O2 L L (b) Liste d’accès associé au objet O1 O3 L A2 O1 E Le droit attribué à l’acteur A3 sur l’objet O3 E = Ecrire, L = Lire O2 L (a) Structure d’une matrice de protection (c) Liste de capacités de l’acteur A2 Fig. C.1 - : Concepts et schema de mise en uvre d'une matrice de protection. C.7 Synthese Dans les sections precedentes, nous avons examine le support oert par les ac- tuels systemes repartis pour la construction et l'execution des collecticiels. L'etude d'analyse est recapitulee dans le tableau C.1. Les notations suivantes sont em- ployees : = support convenable , = Support partiel, = Peu de support et - = non appliquable. Services/Besoin Conscience de groupe Partage Gestion de groupes Reconguration dynamique Ouverture RPC - Diusion - Bus de communication Duplication - Concurrence transparente - - Transparence de pannes - MPR - Matrice de protection - R^oles de protection - Tab. C.1 - : E valuation de la satisfaction des besoins des collecticiels par les systemes repartis. En resume, les systemes repartis ne fournissent qu'un support partiel pour les collecticiels. Certains besoins du travail cooperatif sont plus au moins bien C.7 Synthese 153 supportes, c'est notamment le cas du besoin de partage d'informations et de communication. D'autres besoins sont bien moins supportes comme par exemple la conscience de groupe et l'ouverture du support systeme. Une application co- operative peut benecier des services de base fournis par les supports systemes disponibles pour construire les services dont elle a besoin. Notre conclusion est en fait previsible. Elle est dictee par l'objectif m^eme des systemes repartis qui visent a supporter une large eventail de types d'applications (transactions bancaires, contr^ole aerien, messagerie, , etc). Il est dicile de concevoir un systeme qui ::: soit a la fois generique et qui ore un support complet pour des classes variees d'applications. 154 Les systemes repartis comme support pour le TCAO Annexe D Le protocole dOPT - preuve d'incorrection Le protocole dOPT est implante dans le cadre de l'editeur de texte cooperatif Groove [Ellis et al.89]. Le principe de dOPT est de forcer l'execution des opera- tions echangees entre les sites selon l'ordre causal. Des horloges vectorielles sont employees an de detecter l'ordre causal des evenements. Un processus de site P i maintient un vecteur d'etats S dont la dimension est le nombre des sites partici- pants. Deux vecteurs d'etats sont compares au moyen des relations suivantes : { S > S , 9n : S [n] > S [n]. i j i j { S < S , 8n : S [n] S [n]. i j i j { S = S , 8n : S [n] = S [n]. i j i j Lorsque P genere une operation Op l'operation est immediatement executee sur i le site local , l'entree dans le vecteur d'etat S [i] est incementee et un evene- i ment de notication est envoye aux autres sites. Un evenement est un quaruplets E = (i; S ; Op; p) o| i u i est l'identicateur du site, S son vecteur d'etat, Op est i l'operation generee et p est une valeur de priorite de l'operation. Le protocole fonctionne comme suit. A la reception d'une operation Op sur un site , le processus du site compare le vecteur d'etat local avec le vecteur j associe a l'operation recue. Trois cas de gure peuvent avoir lieu : { S > S l'operation O ne peut pas ^etre executee sur le site car le site i j j i a execute des operations qui ne sont pas encore recues sur . Op est alors j mise dans une le d'attente. { S = S l'operation Op est executee immediatement. i j { S < S l'operation Op doit ^etre transformee car le site a execute d'autres i j j operations qui sont concurrentes a Op. dOPT cherche la plus recente ope- ration dans la liste d'historique locale dont l'horloge soit inferieur ou egale 156 Le protocole dOPT - preuve d'incorrection a l'horloge de Op. Soit OpA l'operation ainsi determinee. L'operation recue est transformee en fonction du segment de l'historique local qui commence par l'operation OpA . Allison et Livesely montrent dans [Allison et al.94] que le protocole dOPT ne verie pas la propriete de la correction dans des situations dites de concurrence partielle. Un ensemble d'operations sont en concurrence partielle si une operation au moins est en concurrence avec un serie d'operations toutes causalement liees entre elles. La gure D.1 illustre la situation la plus elementaire de la concurrence partielle. Site1 Op1 Op2 Site2 Op3 Fig. D.1 - : Denition de la concurrence partielle. Pour illustrer la defaillance de dOPT nous consiederos l'exemple (4.6) donne dans le chapitre 4 (4.5.4.2). Selon dOPT les sequences d'execution suivantes au- ront lieu sur les sites impliques : Execution sur le site 1 les deux operations Op1 et Op2 sont executees sequen- tiellement. Apres leurs execution l'horloge locale a la valeur (0,2). A la reception de Op3 dont l'horloge est (0,0), l'algorithme dOPT transforme cette operation d'abord en fonction de Op1 puis en fonction de Op2. Dans les deux cas l'opera- tion Op1 reste telle qu'elle est car le site 1 est plus prioritaire que 2. La couleur de l'objet o1 passe donc au rouge. Execution sur le 2 conformement a l'algorithme dOPT, l'operation Op3 est d'abord executee et ajoutee a la liste de l'historique locale H2. L'operation est envoyee au site 1 avec l'horloge (0,0). Apres l'execution de Op3 l'horloge locale du site passe a (1,0). Le site va recevoir Op1 avec l'horloge (0,0). L'horloge de Op1 etant inferieur a l'horloge locale, l'operation doit ^etre transformee en fonction des operations executees sur le site 1. dOPT cherche la plus recente operation dans H2 dont l'horloge soit inf erieur ou egale a l'horloge de l'operation recue. Dans le cas actuel, l'operation Op1 sera transformee en fonction de Op3. Le site 1 etant plus prioritaire que le site 2, l'operation Op1 est transformee en N OP et est ajoutee a H2. L'objet o1 est toujours en rouge. L'horloge locale passe a la valeur (1,1). Maintenant a la reception de Op2 dont l'horloge est (0,1), une nouvelle transformation doit ^etre eectuee. Or la plus recente operation dans H2 dont l'horloge est est inferieur a celle de Op2 est l'operation Op1 . Les deux operations Op1 et Op2 ont la m^ eme priorite, l'operation Op2 est executee telle qu'elle est, la couleur de l'objet o1 passe au bleu. Ainsi a la n de l'echange des operations le site 1 a l'objet o1 en bleu tandis que le m^eme objet a la couleur rouge sur le Le protocole dOPT - preuve d'incorrection 157 site 2. L'incoherence resulte du fait que pour transformer une operation, dOPT prends en compte seules les operations dont l'horloge est plus grande que l'horloge de l'operation qui arrive en retard. Or certaines operations plus anciennes que l'operation a transformer peuvent avoir elles aussi subi des transformations (c'est le cas de Op1) et par consequent la nouvelle operation doit ^etre transformee aussi en fonction des transformations des operations qui la precedent. 158 Le protocole dOPT - preuve d'incorrection Annexe E Liste de Publications Cette these a donne lieu aux publications suivantes : Revues internationales R. Kanawati, LICRA : Lock-free Interactive Concurrency Resolution Algo- rithm for Real Time Groupware Applications , Parallel Computing Journal, 22(1997) pp. 1733-1746. Conferences avec comite de lecture S. Benatallah, R. Kanawati, R. Balter et M. Riveill, CoopScan : Une plate-forme generique pour le developpement de collecticiels, IHM'95, Toulouse, Octobre 1995. R. Kanawati et M. Riveill, Access Control Model for Groupware Applica- tions, Adjunct Proceedings of the British Conference on Human Computer Interaction (HCI'95), Hudderseld, UK, 1995. R. Balter, S. Benatallah et R. Kanawati, CoopScan : A Platform for Building Synchronous Groupware, International Conference on Human Computer Interaction - Tokyo, 1995. Conferences nationales et ateliers de recherche R. Kanawati, Replicated Data Management Algorithm for Distributed Syn- chronous Groupware Applications, Proceedings of the 1st Austrian-Hungarian Workshop on Distributed and Parallel Systems (DAPSYS'96), KEFI-1996- 09 TR - Miskolc, Hungary, October 1996. R. Kanawati, Un modele de protection de donnees pour les applications co- operatives, Actes de journees jeunes chercheurs en systeme repartis - IRISA, Rennes, Octobre 1995. 160 Liste de Publications R. Kanawati, Groupware : Architecture and control issues, Doctoral Consor- tium, HCI'95 - Hudderseld, UK, August 1995. S. Benatallah et R. Kanawati, Architecture logicielle pour les collecti- ciels synchrones, Actes de journees francaises sur l'ingenerie de l'interface homme mahine (IHM'94) , Lille, Novembre, 1994. Rapports techniques R. Balter, S. Benatallah, R. Kanawati et M. Riveill, Collecticiels synchrones : Analyse des besoins et etude des architectures, (SIRAC 10-96), IMAG-INRIA, 1996. R Balter, S. Benatallah, R. Kanawati et M Riveill, CoopScan : Une plate-forme generique pour la construction de collecticiels synchrones, (SIRAC-11-96), IMAG-INRIA, Juin 1996. Bibliographie [Abowd et al.92] Abowd (G.), Coutaz (J.) et Nigay (L.). { Structuring the space of interactive system properties. In : Proceedings of the IFIP TC2/WG2.7 on Engineering for Human Compu- ter Interaction. { Ellivuroi, Finland, 1992. [Allison et al.94] Allison (C.) et Livesey (M.). { Coping with concurrency in real time groupware. In : IEEE Conference on Distributed and Multiprocessor Systems. [Almasi et al.94] Almasi (G.), Babadi (A.), Brandt (W.), Butcher (A.), Cal- lahan (J.), Cleetus (K.), Fotta (M.), Gollapudy (C.), Gra- destky (N.), Iyer (S.), Jagannathan (V.), Karinthi (R.), Lawson (R.), Nichols (D.), Raman (R.), Shank (R.), So- bolewski (M.), Srinvas (K.) et Zhang (X.). { Functional specication for collaboration services. In : third workshop on enabling technologies infrastructure for collaborative en- treprise. IEEE. { Morgantown, West Virginia, April 1994. [Amado et al.93] Amado (G.) et Guittet (A.). { Dynamique des communi- cations dans les groupes. { Paris, Armand Colin, 1993. [AW96] Abdel-Wahab (H.). { The design and implementation of an internet conference information system. Journal of in- ternetworking research and experience, vol. 91 (1-2), May 1996. [Baecker et al.93] Baecker (R.), Nastos (D.), Posner (I.) et Mawby (K.). { The user centred iterative design of collaborative writing software. In : Proceedings of the ACM INTERCHI confe- rence on human factors in Computing Systems. { Amestr- dam, 1993. [Balter et al.91] Balter (R.), Ban^atre (J.-P.) et Krakowiak (S.). { Construc- tion des Systemes d'Exploitation Repartis. { INRIA - Col- lection Didactique, Avril 1991. 162 BIBLIOGRAPHIE [Balter et al.95] Balter (R.) et Krakowiak (S.). { Objectifs et plan du travail du projet sirac. { Rapport technique SIRAC RT-1-SIRAC, IMAG-INRIA, juin 1995. [Balter et al.96a] Balter (R.), Benatallah (S.), Kanawati (R.) et Riveill (M.). { Collecticiels synchrones: analyse des besoins et etudes des architectures. { Rapport technique, RT-10-96, IMAG- INRIA, 1996. [Balter et al.96b] Balter (R.), Benatallah (S.), Kanawati (R.) et Riveill (M.). { Coopscan : une plate-forme generique pour la construc- tion de collecticiels. { Rapport technique, RT-9-Sirac, IMAG-INRIA, 1996. [Bannon et al.91] Bannon (L.) et Schmidt (K.). { Studies in Computer Sup- ported Coopeartive Work, Theory, Practice and Design, chap. CSCW : four charecters in search of a context. { North-Holland, 1991. [Benatallah et al.94] Benatallah (S.) et Kanawati (R.). { Architectures systemes pour les collecticiels synchrones. In : Actes des journnees francaise sur l'ingenerie de l'IHM (IHM'94). { Lille France, December 1994. [Benford et al.95] Benford (S.), Greenhalgh (C.) et Snowden (D.). { Colla- borative virtual environments. { HCI'95 Tutorial Notes, Hudderseld, UK, August 1995. [Bentely et al.92a] Bentely (R.), Hughes (J.), Randall (D.), Rodden (T.), Sawyer (P.), Shapiro (D.) et Sommerville (I.). { Ethnographically-informed system design for air trac control, October 1992. [Bentely et al.92b] Bentely (R.), Rodden (T.), Sawyer (P.) et Sommerville (I.). { An architecture for tailoring cooperative multi-user dis- plays. In : CSCW'92. { ACM. [Bentley et al.97] Bentley (R.), Appelt (W.), Busbach (U.), Hinrichs (E.), Kerr (D.), Sikkel (S.), Trevor (J.) et Woetzel (G.). { Ba- sic support for cooperation work on the world wide web. International Journal of Human Computer studies, April 1997. [Bernstein et al.87] Bernstein (P. A.), Hadzilacos (V.) et Goodman (N.). { Concurrency Control and Recovery in Database Systems. { Addison-Wesley, 1987. BIBLIOGRAPHIE 163 [Beust93] Beust (C.). { Conception d'outils destines a assister au developpement d'applications distribuees. { These de doc- torat, Universite de Nice, 1993. [Birman et al.94] Birman (K.) et Renesse (R. Van). { Reliable distributed computing with the ISIS toolkit. IEEE Computer Society Press, 1994. [BL91] Beaudouin-Lafon (M.). { The graph widget - user's ma- nuel. { Rapport technique, Universite paris-sud, LRI, June 1991. [Bonglio et al.91] Bonglio (A.), Malatesta (G.) et Tisato (F.). { Studies in CSCW, chap. Conference toolkit: A framework for real time conferencing. { Elsevier-Sciences (North-Holland), 1991. [Chung et al.93] Chung (G.), Jeay (K.) et Abdel-Wahab (H.). { Accommo- dating latecomers in shared window systems. IEEE Com- puter, vol. 26 (1), January 1993. [Chung et al.94] Chung (G.), Jeay (K.) et Abdel-Wahab (H.). { Dyna- mic participation in a computer-based conferencing sys- tem. Journal of computer communications, vol. 17 (1), Ja- nuary 1994. [Comer92] Comer (D.). { TCP-IP : Architecture, protocoles et appli- cations. { Inter-Editions, 1992. [Condon92] Condon (C.). { CSCW: Cooperation or Con ict?, chap. The Computer Won't Let Me: Cooperation, Con ict and the Ownership of Information. { Springer-Verlag, January 1992. [Cortes et al.95] Cortes (M.) et Mishra (P.). { Replicated servers for on-line groupware. In : Proceedings of Concurrent engineering: re- search and applications. { Washington, August 1995. [Cortez96] Cortez (E.). { La coherence sur mesure dans un service de memoire virtuelle partagee. { These de doctorat, INPG, 1996. [Cosquer et al.94] Cosquer (F.) et Verissimo (P.). { Survey of Selected Group- ware Applications and Supporting platforms. { 1994. 164 BIBLIOGRAPHIE [Coulouris et al.94] Coulouris (G.) et Dollimore (J.). { A security model for cooperative work. In : ACM European SIGOPS Workshop. { Dagstul, September 1994. [Coutaz90] Coutaz (J.). { Interface homme ordinateur, conception et realisation. { Dunod Informatique, 1990. [Croisy94] Croisy (P.). { Modele multi-agent et conception d'applica- tions cooperatives interactives. In : IHM'94. { Lille, 1994. [Croisy95] Croisy (P.). { Collecticiel temps reel et apprentissage co- operatif : des aspects sociaux et pedagogiques jusqu'au mo- dele multi-agent de l'interface de groupe. { These de doc- torat, Universite de Lille, Janvier 1995. [Crowley et al.90] Crowley (T.), Milazzo (P.), Baker (E.), Forsdick (H.) et Tomlinson (R). { Mmconf: An infrastructure for building shared multimedia applications. In : CSCW`90, p. 329. { Los Angeles, October 1990. [Decouchant et al.96] Decouchant (D.), Quint (V.) et Romero (M.). { Groupware and authoring, chap. Structured and distributed coopera- tive editing in a large scale network. { Academic press, 1996. [Derycke et al.95] Derycke (A.) et Hoogstoel (F.). { Le travail cooperatif assiste par ordinateur : quels enjeux pour les concepteurs. In : Actes du XIII congres INFORSID. { Grenoble, France, June 1995. [Diaz92] Diaz (M.). { A logical model of cooperation. In : Pro- ceedings of the IEEE third workshop of future trends of distributed computing systems. [Dourish et al.92] Dourish (P.) et Belloti (V.). { Awareness and coordination in a shared workspace. In : CSCW'92. { Toronto, 1992. [Dourish95a] Dourish (P.). { Developping a re ective model of colla- borative systems. ACM transactions on computer-human Interaction, March 1995. [Dourish95b] Dourish (P.). { The parting of the ways: Divergence, data management and collaborative work. In : CSCW'95. { Sweeden, September 1995. BIBLIOGRAPHIE 165 [Dyre et al.95] Dyre (R.), Green (R.), Pitts (M.) et Millward (G.). { What's the amming problem ? or computer mediated communication - deindivduating or disinhibing? In : People and Computers X, ed. par M. Kirby (A. Dix J. Finlay). HCI'95. { Hudderseld - UK, August 195. [Edwards94] Edwards (W. K.). { Session management for collabora- tive applications. In : Proceedings of the ACM conference on Computer Supported Collaborative Work, CSCW'94. { Chapel-Hill, October 1994. [Edwards95] Edwards (W.). { Coordination Infrastructures in Collabo- rative Systems. { PhD thesis, Georgia Institute of Techno- logy, 1995. [Ellis et al.89] Ellis (C.) et Gibbs (S. J.). { Concurrency control in group- ware systems. In : ACM SIGMOD. p. 399. { Portland, Oregon, June 1989. [Ellis et al.94a] Ellis (C.) et Wainer (J.). { A conceptual model of group- ware. In : CSCW'94 Conference on Computer Supported Cooperative Work. { Chapel-Hill, North Carolina, USA, 1994. [Ellis et al.94b] Ellis (C.) et Wainer (J.). { Goal-based models of collabo- ration. Collaborative Computing, vol. 1 (1), March 1994. [Fidge88] Fidge (C.). { Timestamps in message-passing systems that preserve the partial ordering. In : the 11th Austra- lian Conference. { Australia, october 1988. [Goldberg et al.92] Goldberg (Y.), Safran (M.) et Shapiro (E.). { Active mail - a framework for implementing groupware. In : Sha- ring perspectives - Proceedings of the ACM conference on CSCW. { Canada, November 1992. [Greenberg et al.94] Greenberg (S.) et Marwood (D.). { Real time groupware as a distributed system: Concurrency control and its eect on the intertface. In : CSCW'94. { Chapel Hill, NC, October 1994. [Greenberg91] Greenberg (S.). { Personalizable groupware: Accomoda- ting individule roles and group dierences. In : Proceeding of the ECSCW European Conference of CSCW. { Amster- dam, September 1991. 166 BIBLIOGRAPHIE [Grundin88] Grundin (J.). { Why cscw applications fail: Problems in the design and evaluation of orgnisational interfaces. In : Proceedings of the rst conference on CSCW. ACM. { Port- land OR, 1988. [Grundin94] Grundin (J.). { Groupware & social dynamics: Eight chal- lenges for developeres. Communication of the ACM, vol. 37 (1), January 1994, pp. 93{105. [Gust88] Gust (P.). { Sharedx : X in a distributed group environ- ment. In : the second annual X technical conference, ed. par MIT. [Gutwin et al.96] Gutwin (C.), Roseman (M.) et Greenberg (S.). { A Usa- bility Study of Awareness Widgets in a Shared Workspace Groupware System. { Technical report, University of Cal- gary, Canada, 1996. [Guyennet et al.97] Guyennet (H.), Lapayre (J-C.) et Trehel (M.). { CAliF : une plate-forme de developpement de collecticiels a base de memoire partagee repartie. Calculateurs parallels, vol. 9 (2), July 1997. [Hill92] Hill (R.). { The abstraction-link-view paradigme. In : Proccedings of the ACM Conference on Computer Human Interaction, CHI'92. [Hughes et al.92] Hughes (J.), Randall (D.) et Shapiro (D.). { Faltering from ethnography to design. In : Proceedings of CSCW'92. ACM. { Canada, October 1992. [Hughes et al.94] Hughes (J.), King (V.), Rodden (T.) et Andersen (H.). { Moving out from the control room: Enthography in sys- tem design. In : Proceedings of CSCW'94, ed. par ACM. { Chapell-Hill, CA, October 1994. [Ishii et al.91] Ishii (H.) et Ohkubo (M.). { Message driven groupware design based on an oce procedural model. OM-1. Journal of Information Processing, vol. 14 (2), 1991. [Kanawati95] Kanawati (R.). { Un modele de protection de donnees pour les applications cooperatives. In : Journees Jeunes chercheurs en systemes repartis. { Rennes, Octobre 1995. [Karsenty et al.93a] Karsenty (A.) et Beaudouin-Lafon (M.). { An algorithm for distributed groupware applications. In : Proceedings of BIBLIOGRAPHIE 167 the 13 th Intl. Conf. on Distributed Computing Systems ICDCS'93. { Pittsburgh, May 1993. [Karsenty et al.93b] Karsenty (A.), Tronche (C.) et Beaudoin-Lafon (M.). { Groupdesign : Shared editing in a heterogeneous environ- ment. Computing Systems (Usenix), vol. 6 (2), Spring 1993. [Karsenty94a] Karsenty (A.). { Groupdesign : Un collecticiel synchrone pour l'edition de documents. { These de Doctorat, Univer- site de Paris sud, Fevrier 1994. [Karsenty94b] Karsenty (A.). { Le collecticiel : de l'interaction homme- homme a la communication homme-machine-homme. Technique et Science Informatiques, vol. 13 (1), 1994. [Knister et al.93] Knister (M.) et Parakash (A.). { Issues in the design of a toolkit for supporting multiple group editors. Usenix Com- puting Systems, vol. 6 (2), 1993. [Lamport78] Lamport (L.). { Time, clocks and the ordering of events in a distributed system. Communication of the ACM, vol. 21 (7), 1978. [Lampson74] Lampson (B. W.). { Protection. ACM Operating System Review, vol. 8 (1), 1974, p. 18. [Lenormand96] Lenormand (E.). { Coordination d'activites dans un sys- teme reparti. { These de doctorat, Universite Joseph Fou- rier, November 1996. [Lochovsky et al.88] Lochovsky (F.), Hogg (J.), Weiser (S.) et Mendelzon (A.). { OTM: Specifying oce tasks. In : ACM Proceedings on the Conference on Oce Information Systems. { Palo Alto, CA, 1988. [Markus et al.90] Markus (M.) et Connolly (T.). { Why cscw applica- tions fail: Problems in the adoption of interdependent work tools. In : Proceedings of CSCW'90. ACM. [Mccarthy et al.94] McCarthy (J. C.) et Monk (A. F.). { Channels, conversa- tion, cooperation and relevance: All you wanted to know about communication but were afraid to ask. Collaborative Computing, vol. 1 (1), March 1994. [Moran et al.93] Moran (T.), McCall (K.), Melle (B. Van), Pedersen (E.) et Haasz (F.). { Designing Principles for Sharing Data 168 BIBLIOGRAPHIE in Tivoli, a Whiteboard Meeting-Support Tool. { McGraw- Hill, 1993. [Nastos92] Nastos (D.). { A Structured Environment for Collaborative Writing. { PhD thesis, University of Toronto, 1992. [Navarro et al.93] Navarro (L.), Prinz (W.) et Rodden (T.). { Cscw requires open systems. Computer Communication, vol. 16 (5), May 1993. [Nitzberg et al.91] Nitzberg (B.) et Lo (V.). { Distributed shared memory: A survey of issues and algorithms. Computer, vol. 24 (8), August 1991. [NW et al.92] Newman-Wolfe (R. E.), Webb (M. L.) et Montes (M.). { Implicit locking in the ensemble concurrent object oriented graphics editor. In : Proceedings of CSCW'92. { Canada, November 1992. [Oki et al.93] Oki (B.), P uegl (M.), Siegel (A.) et Skeen (D.). { The information bus: an architecture for extensible distributed systems. Operating System review, vol. 27 (5), 1993. [Palanque et al.95] Palanque (Ph.) et Bastide (R.). { Formal specication and verication of cscw using interactive cooperative object for- malism. In : Proceedings of the HCI'95 Conference people and Computer X, ed. par Kirby (M.), Dix (A.) et Finlay (J.). { Hudderseld, UK, August 1995. [Paoli et al.94] Paoli (F. De) et Tisato (F.). { Csdl: A language for co- operative systems design. IEEE Transactions on Software Engineering, vol. 20 (8), August 1994. [Patel et al.93] Patel (D.) et Kalter (D.). { A unix toolkit for distri- buted synchronous collaborative applications. Computing Systems (Usenix), vol. 6 (2), 1993. [Patterson et al.90] Patterson (J.), Hill (R. D.), Rohall (S. L.) et Meeks (W. S.). { Rendezvous: An architecture for synchronous multi-user application. In : CSCW'90. { L. A., October 1990. [Pons et al.96] Pons (M-C.) et Merialdo (B.). { Un langage de description d'applications cooperatives. In : CRAC'96- Le contr^ole re- parti dans les applicatons Cooperatives. { Paris, May 1996. [Quint et al.94] Quint (V.) et Vatton (I.). { Making structured documents active. Electronic Publishing, vol. 7 (2), June 1994, p. 53. BIBLIOGRAPHIE 169 [Raynal et al.95] Raynal (M.) et Schiper (A.). { A suite of formal denitions for consistency criteria in distributed shared memories. { Rapport technique, IRISA No. 968, 1995. [Raynal et al.96] Raynal (M.) et Singhal (M.). { Logical time: Captu- ring causality in distributed systems. IEEE Computer, Fe- bruary 1996. [Raynal90] Raynal (M.). { Order notions and atomic multicast in distributed systems : a short survey. { Rapport technique, IRISA, Mars 1990. [Reiss90] Reiss (S.). { Connecting tools using message passing in the eld environment. IEEE software, vol. 7 (4), 1990. [Reness et al.96] Reness (R.), Birman (K.) et Maeis (S.). { Horus: a exible group communication system. Communications of the ACM, vol. 39 (4), April 1996. [Roseman et al.92] Roseman (M.) et Greenberg (S.). { Groupkit: A groupware toolkit for building real-time conferencing applications. In : CSCW`92. [Roseman et al.93] Roseman (M.) et Greenberg (S.). { Building exible group- ware through open protocols. In : Proceedings of the ACM Conference on Orgnizational Computing Systems. { Cali- fornia, 1993. [Roseman et al.96a] Roseman (M.) et Greenberg (S.). { Building real time groupware with groupkit, agroupware toolkit. ACM tran- sactions on CHI, March 1996. [Roseman et al.96b] Roseman (M.) et Greenberg (S.). { Teamrooms: Network places for collaboration. In : Proceedings of the Internatio- nal Conference on Computer Supported Cooperative Work Col. [Salber et al.95] Salber (D.), Coutaz (J.), Decouchant (D.) et Riveill (M.). { De l'observabilite et de l'honn^etete : le cas du contr^ole d'acces dans la communication homme-homme mediatisee. In : IHM'95. { Toulouse, Octobre 1995. [Salber95] Salber (D.). { De l'intercation homme-machine individuelle aux systemes multi-utilisateurs, l'exemple de la communi- cation homme-homme mediatisee. { These de doctorat, Universite Joseph Fourier, September 1995. 170 BIBLIOGRAPHIE [Sandhu96] Sandhu (R.). { Role-based access control models. IEEE Computer, february 1996. [Sasse et al.96] Sasse (M. A.) et Handley (M. J.). { Groupware and au- thoring, chap. Collaborative writing with synchronous and asynchronous support environments. { Academic press, 1996. [Schmidt et al.93] Schmidt (K.) et Rodden (T.). { Putting it all together: requirements for a cscw platform, 1993. [Shapiro94] Shapiro (D.). { The limits of ethnography: Combining so- cial sciences for cscw. In : proceeding of CSCW'94, ed. par ACM. { Chapel-Hill, CA, October 1994. [Shen et al.92] Shen (H.) et Dewan (P.). { Access control for collaborative environments. In : CSCW'92. p. 51. { Toronto Canada, November 1992. [Shneiderman83] Shneiderman (B.). { Direct manipulation : A step beyond programming languages. IEEE Computer, no16, february 1983. [Shu et al.94] Shu (L. I.) et Flowers (W.). { Teledesign: Groupware user experiment in three-dimensional computer aided design. Collaborative Computing, vol. 1 (1), March 1994, pp. 1{14. [Smith et al.94] Smith (G.) et Rodden (T.). { Access as a means of congu- ring cooperative interfaces. Collaborative Computing, vol. 1 (2), August 1994. [Sproull et al.91] Sproull (L.) et Kiesler (S.). { Connections, New ways of working in the Networked Orgnisation. { MIT press, 1991. [Tani et al.94] Tani (M.), Horita (M.), Yamashi (K.), Tanikoshi (K.) et Futakawa (M.). { Courtyard: integrating shared overview on a large screen and per-user detail on individual screens. In : Proceedings of ACM conference on human factors in Computing Systems. { Boston, April 1994. [Tatar et al.91] Tatar (J.), Foster (G.) et Bobrow (D.). { Design for conver- sation : Lessons from cognator. Int. Journal of Multi Media Systems, vol. 2 (34), 1991. [Trevor et al.93] Trevor (J.), Rodden (T.) et Balir (G.). { Cola: A light- weight platform for cscw. In : Proceedings of the Third BIBLIOGRAPHIE 171 European Conference on Computer-Supported Cooperative Work, ed. par Michelis (G. De), Simone (C.) et Schmidt (K.). [Villemur95] Villemur (T.). { Conception de services et de protocoles pour la gestion de groupes cooperatifs. { These de doctorat, Universite Paul Sabatier, January 1995. [Welch95] Welch (B.). { Practical Programming in Tcl and Tk. { Prentice-Hall, 1995. [ZV et al.95a] Zorola-Villarreal (R.) et Bastide (R.). { Mesc : Une me- thode de l'evaluation de l'utilisabilite des interfaces multi- utilisateurs. In : IHM'95, ed. par Cepadues-E ditions. { Toulouse, France, October 1995. [ZV et al.95b] Zorola-Villarreal (R.), Pavard (B.) et Bastide (R.). { Sim- coop : A tool to analyse and predict cooperation in com- plexe environments. In : Fifth International Conference on Human-Machine Interaction and Articial Intelligence in Aerospace. { Toulouse - France, September 1995.