You Will Never Work Alone

Page principale

Axes de recherche

Logiciels ECOO

Relations scientifiques et industrielles

Personnel

Publications

Français

English

Projet ECOO:
Environnements pour la COOpération
Version 4.1. du 09/04/99

Version Postscript

Mots-clés:

Coopération, Coordination, Distribution, Entreprise Virtuelle, Environnement, Interopérabilité, Objet, Système, Système de Gestion de Bases de Données Avancés, Transaction

Sur le WEB:

http://www.loria.fr/equipes/ecoo/

Ce document présente une proposition de projet dans le domaine des concepts, services et outils pour la coopération dans les entreprises virtuelles distribuées.

Il est organisé ainsi:

La section 1 présente le contexte et les motivations du projet (page 3), les objectifs et l'organisation de la recherche (page 4) et le domaine d'application (page 11).
La section 2 présente le programme de travail (page 13), d'abord une activité transversale d'analyse des usages (page 14), puis l'axe de recherche 1, Coordination(page 15), l'axe de recherche 2, Communication (page 21), les relations entre les deux axes (page 27) et finalement un plan de travail et les résultats attendus (page 29).
la section 3 (page 32) établit une liste de projets INRIA en relation avec le projet proposé, la section 4 (page 32) décrit les actions industrielles en cours, la section 5 (page 34) les actions nationales et internationales, la section 6 (page 35) la diffusion des résultats, la section 7 (page 37) les différentes référence et la section 8 (page 47) contient en annexe un exemple d'entreprise virtuelle et un scénario illustrant la complexité des relations synchrone/asynchrones.

Projet ECOO:
Environnements pour la COOpération
Version 4.1.du 09/04/99

Composition

Responsable scientifique:
Claude Godart, Professeur à l'Université Henri Poincaré, en détachement à l'INRIA (octobre 1998-)

Personnel UMR 7503:
Khalid Benali, Maître de Conférences à l'Université Nancy 2
Nacer Boudjlida, Professeur à l'Université Henri Poincaré
Gérôme Canals, Maître de Conférences à l'Université Nancy 2, en délégation à l'INRIA (octobre 1998-)
François Charoy, Maître de Conférences à l'Université Nancy 2
Dominique Colnet, Maître de Conférences à l'Université Henri Poincaré
Jacques Lonchamp, Professeur à l'Université Nancy 2
Pascal Molli, Maître de Conférences à l'Université Henri Poincaré
Olivier Perrin, Maître de Conférences à l'Université Nancy 2
Hala Skaf, Maître de Conférences à l'Université Henri Poincaré

Ingénieur Expert
Jean-Marc Humbert

Doctorants
Mohamed Bouchikhi, boursier UHP (Thèse en 2000)
Abdelmajid Bouazza, boursier Michelen-Ferbois (Thèse en 2000)
Daniela Grigori, boursier CNET (Thèse en 2001)
Olivier Malcurat, boursier CNET (Thèse en 2000)
Samir Tata, boursier du guvernement français (Thèse en 2000)
Olivier Zendra, boursier MESR (Thèse en 1999)

Post-doctorant
Manuel Munier, post doc INRIA/XEROX

Introduction

Contexte et motivations

L'évolution des performances des réseaux d'ordinateurs combinée à la baisse de leur coût permet désormais aux compagnies de coopérer électroniquement pour former des entreprises virtuelles.

Cette coopération peut être pérenne, comme par exemple entre un constructeur automobile et ses sous-traitants, ou éphémère comme par exemple les différents corps de métier dans la construction d'un bâtiment. Une telle construction assemble des partenaires avec des compétences complémentaires pour une durée limitée à la construction (c'est le concept d'entreprise projet).

Le projet ECOO est motivé par la mise en $\oe$ uvre des entreprises virtuelles [], en termes de concepts, de mécanismes et de langages. Les problèmes sont nombreux et variés, allant de l'hétérogénéité des matériels et des protocoles, à l'invention d'une nouvelle culture du travail, et en particulier du télétravail coopératif.

Il s'agit d'un sujet très actuel sur lequel de nombreuses recherches démarrent ou redémarrent en conjonction avec l'évolution des infrastructures matérielles-logicielles. Mais l'évolution des technologies, si elle contribue à une meilleure acceptation de la communication électronique n'en est qu'une composante. Une autre condition est que la communication électronique ne modifie pas inutilement le comportement des partenaires, et que la la modification de comportement soit compensée par une plus-value appréciable qui fasse accepter cette modification. Cela passe par la définition de modèles d'interaction, de coopération, qui correspondent le plus possible aux usages courants.

Un important travail de recherche est donc à faire, y compris dans des domaines où un effort de normalisation des échanges informatisés a été fait. En effet, cette normalisation porte essentiellement sur la définition de formats d'échange de données, mais la littérature sur le sujet souligne le manque d'information sémantique accompagnant ces échanges. Cela a pour effet de déranger la synergie entre partenaires pourtant souvent présente sur le terrain. Au contraire, il faut développer un média de communication qui amplifie cette synergie.

Le projet ECOO va mener une recherche dans cette direction. L'objectif est de développer des modèles informatiques simples permettant de mettre en $\oe$ uvre la coopération inhérente à toute entreprise virtuelle.

Soulignons aussi que, de la même façon que les intranets sont couramment développés en utilisant une technologie internet, nous pensons que les résultats des recherches que nous développerons pour les entreprises virtuelles s'appliqueront également à la mise en $\oe$ uvre de la coopération dans les entreprises au sens légal du terme.

Objectifs du projet

L'objectif général du projet est de développer des modèles informatiques simples permettant de mettre en $\oe$ uvre la coopération inhérente à toute entreprise virtuelle.

Concrètement, il s'agit de réaliser une infrastructure, en termes de concepts, mécanismes et langages pour la définition, l'administration, et la mise en $\oe$ uvre de la coopération dans ces entreprises.

Le problème dans sa globalité est très vaste. Il faut structurer les données de l'entreprise en intégrant les mémoires des entreprise partenaires, faciliter la communication et la négociation entre ces partenaires, définir, gérer et faire interopérer leurs procédés ... La section qui suit donne un modèle d'entreprise virtuelle et la section définit les contours de la recherche développée dans ECOO par rapport à ce modèle.

**Figure:** Entreprise virtuelle -- Architecture fonctionnelle
$\begin{figure} \centerline{ \epsfig {figure=archifonc2.eps} }\end{figure}$

Modèle d'entreprise virtuelle

La figure

décrit une architecture fonctionnelle d'une entreprise virtuelle. Elle dessine une telle entreprise comme un projet coopératif impliquant des partenaires autonomes devant faire interopérer leur procédés.

La fonction de gestion des données assure le stockage et l'accès aux informations nécessaires à la vie de l'entreprise. Les modèles prédéfinis (d'entreprise, de procédés ...) sont les briques de base sur lesquelles les concepteurs peuvent s'appuyer pour définir une nouvelle architecture d'entreprise ou de nouveaux procédés. L'état courant de l'entreprise est défini par l'état des produits, en particulier les documents, et des procédés actifs. Il fournit des informations sur l'état d'avancement des procédés actifs. Il peut être interrogé par les procédés actifs ou par une personne physique. Les données historiques et d'audit sur les procédés peuvent supporter des mesures d'efficacité, aider à l'évolution de l'entreprise et permettre de faire du data mining ...

La fonction d'organisation de l'entreprise doit permettre de modéliser l'entreprise pour la diriger en intégrant la dimension multi-partenariat, ce qui nécessite la définition de nouvelles architectures organisationnelles, de nouvelles structures hiérarchiques impliquants différents niveaux de responsabilités, d'autorisation, de nouveaux circuits de décision ...

La fonction de coordination de procédés assure l'<< enchaînement >> distribué de tâches, en coopération avec la fonction de communication. Elle se base sur un modèle de procédés, modélisant et gérant les flots de travail ( workflows) entre les participants à un projet commun. Celui-ci doit être suffisamment souple pour contrôler l'enchaînement des outils de production, pour prendre en compte les modes de travail que l'on trouve dans les tâches les plus créatives, pour permettre l'intégration de procédés interopérant (workflow inter-organisations), pour évoluer dynamiquement en fonction d'imprévus et s'adapter à différents points de vue ou différentes cultures d'entreprise. Il doit intégrer des tâches transactionnelles et des tâches non transactionnelles. La fonction de coordination s'appuiera également sur des mécanismes permettant de contrôler la divergence entre les entités coopérantes. Elle doit aussi permettre le déploiement des tâches (participants, lieux, responsabilités ...) sur le réseau d'entreprises et gérer des tâches mobiles.

La fonction de communication est tout aussi fondamentale. Elle doit fournir les moyens aux partenaires distribués de travailler (presque) comme s'il étaient sur le même lieu. Un premier problème dans ce contexte concerne la conscience qu'un individu a de l'intérêt et de l'avancement de son travail par rapport à la globalité ainsi que du travail des autres par rapport aux tâches communes et aux objets partagés. La communication s'appuie sur des modèles de travail coopératif synchrone ou asynchrone, plus ou moins formalisés, réutilisant ou pas les documents de l'entreprise. Parmi les tâches à supporter, celles du type aide à la décision et négociation sont primordiales.

La fonction d'interopérabilité gère les problèmes liés à la nature multi-entreprise d'une entreprise virtuelle: hétérogénéité, co-concurrence .... Elle doit rendre les procédés et les données des partenaires interopérants tout en préservant le besoin naturel d'autonomie de chacun. On intègre donc dans cette dimension les aspects gestion de la confidentialité et de la sécurité ...

La dernière fonction qui apparaît sur la figure est l'interface homme-machine. On comprend aisément son importance dans le contexte du travail coopératif en réseau, en particulier lorsqu'il s'agit de recréer une communauté de lieu. Les mécanismes à définir sont nombreux et variés, allant de simples formulaires du type WEB jusqu'à la modélisation 3D des entreprises en passant par la définition de métaphores.

Pour conclure cette section, rappelons, comme nous venons de le souligner à propos de la coordination et de la communication, que le contour entre ces fonctions n'est pas toujours simple à dessiner.

Caractéristiques et approche de la recherche prévue dans le projet ECOO

La recherche prévue dans le projet ECOO touchera aux différentes fonctions décrites, mais avec des forces différentes. On organisera principalement la recherche autour de deux axes principaux:

1.: la coordination de tâches,
2.: la communication.

Concernant l'interopérabilité, nous ne prévoyons pas a priori d'action spécifique. Il n'en reste pas moins que l'interopérabilité est fondamentale et sera une des dimensions de la recherche sur la coordination et la communication. Concernant la gestion des données, notre contribution devrait être limitée à l'exploitation des particularités du domaine pour définir des services plus efficaces (gestion de versions, de réplications ...). L'étude de l'organisation des entreprises est à la limite entre l'informatique et la gestion des entreprises; nous nous intéresserons à deux modèles d'entreprises virtuelles, l'une établissant des relations pérennes entre des partenaires habitués à travailler ensemble (dans le cadre du projet AEE (cf. ), l'autre gérant des relations plus éphémères (dans le domaine du BTP dans le cadre de ). Enfin, concernant les aspects IHM, on ne pense pas faire de contribution notable, tout au plus s'intéressera à mise en évidence de métaphores pour représenter les patrons de coopération.

On définit également une tâche analyse des usages commune aux deux axes de recherche principaux.

La section décrit cette tâche, la section décrit la recherche proposée sur la coordination, la section celle proposée sur la communication, la section discute de l'intégration de ces deux dimensions. Enfin, la section donne un plan de travail et situe les résultats attendus. Avant d'entrer dans le détail du programme de recherche, les paragraphes qui suivent introduisent les deux axes principaux.

Coordination de tâches

L'objectif de la coordination de tâches est de formaliser les tâches et les procédés qui décrivent l'enchaînement des tâches pour les automatiser. De plus, dans le contexte des entreprises virtuelles, l'objectif est aussi de formaliser et d'automatiser les interactions entre les procédés.

Le problème est vaste, et pour mieux le cerner, on fait un certain nombre d'hypothèses. La première est que la coordination des partenaires d'une entreprise virtuelle se fait pour beaucoup par l'échange de documents. La seconde est que les échanges de documents entre partenaires suivent des lois qui se répètent d'une application à une autre. Une dernière est que les partenaires d'une entreprise virtuelle ont souvent une infrastructure informatique << légère >>. Ces hypothèses nous ont amené à choisir une approche de type workflow transactionnel pour la coordination des tâches.

Un système de workflow a pour but d'automatiser des procédés, a priori de type administratif, en gérant l'échange de documents entre les intervenants. Un objectif recherché est que la définition des modèles soit simple et que toute la complexité des interactions soit cachée à ces intervenants. L'encapsulation des tâches dans des transactions ACID est un bon moyen de cacher la complexité du parallélisme dans ce genre d'application.

Si on se place dans cette veine, il est néanmoins clair que le concept traditionnel de workflow ne convient pas tel quel car il est pensé pour enchaîner des tâches << concurrentes >> se synchronisant en s'échangeant des documents en début et en fin d'exécution. Le concept de workflow doit évoluer pour prendre en compte des tâches coopératives, c'est-à-dire s'échangeant des documents en cours d'exécution. Pour cela, il faut définir de nouveaux opérateurs de description d'enchaînement de tâches et de nouveaux modèles de transaction pour encapsuler les tâches coopératives.

Cet objectif se basera sur une analyse des usages permettant de mettre en évidence des << patrons de coopération >>.

Une dimension de cette recherche est l'étude des relations entre transactions coopératives et transactions traditionnelles, certaines tâches et/ou fragments de procédés restant concurrents. Une autre dimension est l'étude des tâches transactionnelles coopératives avec les tâches non transactionnelles. Cela rejoint en partie la problématique de la communication développée ci-dessous, en particulier l'étude des relations entre coopération directe et coopération indirecte, coopération formelle et coopération informelle, coopération synchrone et coopération asynchrone.

D'autre part, ce modèle de workflow devra être suffisamment flexible pour prendre en compte la nature des entreprises qui nous intéressent. Cela signifie qu'il devra supporter une certaine adaptabilité, c'est à dire permettre le démarrage d'un workflow avant sa définition complète et son évolution dynamique à l'exécution. Il devra également être capable de supporter des exceptions aux règles prédéfinies.

Un autre dimension du problème est l'interopérabilité de workflows dans un contexte où chaque entreprise partenaire peut avoir son propre workflow, le système global étant une intégration de ces workflows locaux. De nouveaux mécanismes exécutifs sont à développer. Probablement aussi que des modèles de négociation et de médiation sont à développer dans cet objectif. Il est clair aussi que les agréments entre partenaires doivent pouvoir se limiter aux points d'interaction entre leurs procédés. D'autre part, dans bon nombre de cas, aucun partenaire n'a une vue globale de l'entreprise, ce qui complexifie le contrôle de l'application.

Une dernière dimension concerne le déploiement et l'exécution distribuée des procédés. On s'appuiera sur les composants existants (communication de groupe, gestion de réplications, gestionnaire de configurations distribués, consensus, évaluation de prédicats instables distribués ...) en essayant d'exploiter la connaissance des applications pour simplifier certaines fonctions, par exemple la formation des groupes de communication, pour assouplir les protocoles de réplication, pour supporter la mobilité ...Un principe directeur est que les utilisateurs doivent pouvoir continuer à travailler avec leurs outils habituels.

Enfin, soulignons que dans toutes ces études, on s'appuiera sur les standards existants: WfMC, OMG...

Nous développons ces aspects dans la section .

Communication

Le support à la communication est une fonctionnalité essentielle au bon fonctionnement d'une entreprise virtuelle. Ce support permet la reconstruction d'un espace social, disparu du fait de la dispersion géographique ou temporelle, où les différents participants peuvent interagir dans le déroulement de leurs travaux. La communication est complémentaire à la coordination de tâches : elle permet de mettre en relation les agents pour le compte de tâches communes et à ces agents d'interagir au travers de la construction d'une compréhension commune des artefacts et des travaux en cours.

La communication dans certains cas participe, voire même remplace, la coordination, notamment lorsque la coordination n'est pas explicitement formulée ou est insuffisamment formalisée pour être manipulable par le système support. C'est une activité transversale que l'on retrouve à tous les moments de la vie d'une entreprise virtuelle.

On distingue habituellement plusieurs dimensions caractéristiques dans la communication électronique. Elle peut être explicite lorsqu'elle utilise un canal dédié : message électronique, forums, publication (électronique ou non), audio ou vidéo conférence. A contraire, elle peut être implicite lorsque la communication prend place au travers du partage d'un objet ou d'un document : partage de plans de conception, de fichiers, de produits. D'autre part, la communication peut être synchrone, lorsque les partenaires interagissent en temps réel au travers d'une connexion établie, ou asynchrone lorsque les participants ne sont pas explicitement connectés et sont éventuellement distants sur le plan temporel. Enfin, la communication peut être plus ou moins formalisée : la structure et l'enchaînement des échanges ou des messages entre les partenaires peuvent être explicitement décrits ou au contraire ne faire l'objet d'aucune contrainte spécifique.

Le support à la communication électronique a fait l'objet de nombreux travaux et voit déjà des réalisations commerciales mais les principales contributions du domaine correspondent à des outils très divers le plus souvent dédiés a une des formes de communication énoncées ci-dessus.

Si de nombreuses solutions ponctuelles existent, leur mise en $\oe$ uvre au service d'un projet coopératif de taille importante reste problématique. Ces solutions sont en effet trop fragmentaires et n'abordent pas les besoins en communication de manière globale et en relation avec les besoins en coordination et en production.

Pour dépasser ces limites, le projet s'intéresse à la communication sur 3 plans :

l'intégration des mécanismes de communication avec les procédés de coordination de tâches,
l'intégration des différentes dimensions de la communication, au delà d'une simple juxtaposition d'outils répondant de façon isolée et partielle à des besoins pourtant plus globaux,
le passage à l'échelle : la coopération sur une grande échelle remet en cause à la fois les mécanismes sous-jacents et les modes d'interactions agents/agents et agents/procédés.

Nous développons ces aspects dans la section .

Stratégie de recherche et de transfert

La stratégie de recherche consiste:

à analyser les usages courants en relation avec nos actions industrielles (cf. et ) pour en tirer des usages de coordination et de communication,
à les formaliser et/ou mettre en $\oe$ uvre de la façon la plus générique possible,
à les valider au travers d'expérimentations avec retour chez les usagers de départ,
à transférer vers l'industrie,
à itérer ce processus

On pense princpalement à 2 types d'industries informatiques pour transférer nos résultats:

les éditeurs de logiciel: en particulier les éditeurs de logiciels workflow pour atteindre les applications coopératives intra- ou inter-entreprises, les éditeurs de logiciels de travail coopératif, les éditeurs de midleware, par exemple en définissant un nouveau moniteur transactionnel adapté aux besoins de coopération dans les entreprises virtuelles ...
les fournisseurs de services Internet qui pourront proposer de nouveaux services pour aider les entreprises à s'interconnecter.

Domaine d'application

La classe d'applications considérée en priorité est celle des entreprises virtuelles à usage intensif de documents. L'étude proposée intègre des dimensions de travail en groupe, d'enchaînement de procédés, d'ingénierie simultanée, d'édition coopérative, de télétravail ... présente dans ces entreprises. Elle intéresse de nombreux secteurs d'activités, parmi lesquels l'administration, le BTP, le génie logiciel, la médecine, le télé-enseignement ...

Une dimension de notre stratégie est de nous impliquer très tôt dans des domaines applicatifs par des relations industrielles. Nous avons la chance de pouvoir le faire dans deux applications pilotes très représentatives: l'automobile et le BTP. La section commente notre domaine d'application à travers ces exemples. La section la caractérise plus généralement. L'annexe illustre l'idée d'entreprise virtuelle.

Applications pilotes

Le BTP

Les caractéristiques de cette application nous semblent intéressantes pour plusieurs raisons. Tout d'abord, on y trouve des entreprises de tailles et de structures différentes, avec des problèmes organisationnels variés : si on trouve dans le BTP de très grandes entreprises, 95 pour cent de celles-ci sont de petites entreprises.

Une autre caractéristique est la nature très éphémère de la coopération entre les entreprises, contrastant avec la collaboration fortement intégratrice et relativement permanente entre agents, services et sous-traitants de l'industrie manufacturière. C'est le concept d'entreprise-projet introduit ci-dessus. Ce particularisme de l'entreprise-projet nous paraît intéressant car il met en $\oe$ uvre des pratiques coopératives essentiellement éphémères mais riches d'efficacité.

Ensuite, les acteurs du BTP ont une expertise très ancienne des pratiques coopératives. Plus qu'ailleurs, la communication sous des formes multiples constitue une préoccupation importante (échanges de données graphiques, techniques, échanges de pièces administratives, devis, bordereaux de paiement, compte rendus de chantier,...). Mais le déplacement direct et la discussion << au coin du comptoir >> sont encore très utilisés et l'échange de disquette est la pratique d'échange de données la plus répandue. Notons cependant que les partenaires plus réguliers ont mis en place des liaisons bi-points, souvent supportées par Numéris, et que certaines grandes entreprises fonctionnent réellement en réseau.

Un autre point important est que le domaine est déjà informatisé et qu'un travail important de normalisation des échanges informatisés est en cours. Nous pensons que cela simplifiera l'introduction des nouveaux outils que nous développerons.

Soulignons aussi que ces caractéristiques font que les concepts développés dans ce cadre doivent selon nous se généraliser à bon nombre d'applications rapprochant dans un objectif commun des partenaires distribués exerçant des rôles différents.

Le travail en relation avec les architectes se fait dans le cadre d'une CTI du CNET en relation avec le CRAI à Nancy.

L'automobile

On retrouve évidemment beaucoup de points communs avec le domaine précédent, mais aussi des spécificités. En particulier, une plus grande pérennité dans les relations peut permettre la mise en $\oe$ uvre de structures de coopération plus simples parce que nécessitant moins de flexibilité.

Le travail en relation avec les acteurs de l'automobile se fait dans le cadre du projet AEE, impliquant les constructeurs Peugeot et Renault et les équipementiers Sagem, Valéo et Siemens.

Caractéristiques des applications considérées

Au delà des études de cas, un objectif est de caractériser le domaine. D'ores et déjà, on peut souligner les caractéristiques suivantes :

la forte interdépendance entre les partenaires: si chacun a son objectif, la réussite de chacun dépend de la réussite des autres. Si chacun veut conserver une certaine autonomie, des connexions fréquentes sont nécessaires,
la forte créativité des tâches réalisées par les partenaires: les décisions essentielles reviennent aux agents humains,
la longue durée des tâches concernées: plusieurs heures, plusieurs jours, plusieurs semaines, voire plusieurs mois,
leur nature éventuellement éphémère: si la durée des tâches est longue par rapport aux unités d'exécution informatiques habituelles, elles s'exécutent au sein d'entreprises qui peuvent avoir pour durée de vie la durée d'un projet,
leur développement << incertain >> : le << programme >> de l'entreprise est défini interactivement et dynamiquement par les agents humains qui prennent les décisions sous le contrôle de << fragments >> de programme,
la nature révocable des tâches qui la compose,
et bien sûr, la nature inter-organisationnelle avec les problèmes que cela implique en relation avec un certain besoin d'autonomie et l'impossibilité d'une connexion permanente.

On verra par la suite que ces caractéristiques tantôt simplifient, tantôt complexifient les problèmes habituels de coordination et de communication.

Pour illustrer cela, on peut considérer par exemple la longue durée des tâches à coordonner. On pense qu'une approche transactionnelle est bien adaptée aux contrôles des échanges de documents entre les partenaires d'une entreprise parce qu'elle décharge les concepteurs d'application des problèmes liés au parallélisme des exécutions. Mais la longue durée des tâches à coordonner remet en cause le principe d'atomicité aux défaillances (tout ou rien) des modèles de transactions traditionnels. En effet, s'il est admissible d'annuler une transaction qui s'exécute en quelques millisecondes du fait d'un interblocage avec une autre transaction, cela n'est pas acceptable pour une transaction qui encapsule une tâche de conception qui s'exécute depuis plusieurs heures, voir plusieurs jours. Dans ce cas, la longue durée est un handicap. Mais dans d'autres cas, elle est un avantage. Par exemple en ce qui concerne les temps de transfert, si un décalage de plus de 20 millisecondes n'est pas acceptable entre une image et le son associé, un décalage de plusieurs minutes entre deux plans, mais qui nécessitent plusieurs jours d'élaboration, est tout a fait acceptable.

Programme de travail

Comme introduit en , le programme de travail est organisé autour de deux grands axes.

1.: la coordination de tâches,
2.: la communication.

Avant de présenter ces deux axes (sections et ), nous introduisons une action transversale dont l'objectif est de faire une analyse des usages courants de coopération en relation avec nos applications pilotes (section ). Après avoir présenté ces deux axes, nous montrerons les relations entre ceux-ci (section ). Enfin nous conclurons par un plan de travail, une liste de résultats attendus et une position de ces résultats par rapport à l'existant (section ).

Analyse des usages

Cette action s'appuiera sur nos applications pilotes, dans le domaine du BTP et dans celui de l'automobile (cf.

), et sur la littérature [].

L'objectif est la mise en évidence d'un noyau représentatif de pratiques courantes de coopération se répétant d'une application une autre. De pratiques définissent ce qu'on appelle un patron de coopération.

En particulier, on cherchera à mettre en évidence des règles d'échange de documents entre partenaires qui se répètent fréquemment d'une application à une autre. La figure donne l'exemple d'un tel patron appelé client/serveur. Un premier procédé P₁ produit un document x dont il fournit tôt une première version (préliminaire, incomplète, incohérente ...) à un second procédé P₂ pour lui permettre d'interagir rapidement avec lui. Les deux procédés s'exécutent en parallèle et P₁ produit différentes versions du document x qui sont consommées ou pas par P₂ . Avant de terminer, P₁ produit la version finale (cohérente) de x. P₂ consomme cette version finale, compense le travail réalisé avec les versions précédentes avant de conclure lui-même.

Dans un premier temps, nous étudierons avec le CRAI les usages de coopération sur de petits chantiers de construction. En complément, nous analyserons les logiciels utilisés par les architectes et plus particulièrement les échanges de documents s'opérant entre ces logiciels. Nous pensons que l'étude des flux de documents dans ces exemples réalistes nous permettra de mettre en évidence des comportements coopératifs représentatifs. Les travaux qui démarrent dans le cadre du projet AEE (cf ) doivent être tout aussi enrichissants de ce point de vue, en particulier du fait du contexte co-concurrentiel. La littérature nous aidera également dans cette tâche. Par exemple, une analyse intéressante a été faite dans []. Nous incluons également dans cette action une opération de veille technologique des outils du marché.

Un autre objectif est la classification des patrons de coopération. Pour cela, nous cherchons des critères de classification. Un premier travail dans ce sens est décrit dans [2]. Il utilise, pour des couples de tâches et un ensemble d'objets, les paramètres suivants: les dépendances lecture/écriture, le fait que la mise en cohérence soit synchrone ou asynchrone, le fait que les tâches doivent terminer ou pas avec une vue commune des documents partagés. Un objectif est de formaliser les patrons de coopération à un plus haut niveau d'abstraction que le niveau modèle de transaction. On pourra s'appuyer ici sur des formalismes de type CSP [], CCS [] ...

Pour terminer, soulignons que l'on pense utiliser les capacités des workflows adaptatifs pour structurer et analyser la coopération présente dans les projets considérés. L'idée est de partir d'un embryon de workflow, que l'on enrichit ensuite en traçant la réalité du terrain puis que l'on pondère par des statistiques d'utilisation des différentes alternatives (ou déviations) [].

Coordination

Approche et problèmes

**Figure:** Patron *client/serveur*
$\begin{figure} \centerline{ \epsfig {figure=client.eps} }\end{figure}$

Comme introduit précédemment, on s'intéresse ici à la coordination des procédés dans des applications créatives de type conception et ingénierie coopérative. Ces procédés se coordonnent en particulier par l'échange de documents qui sont créés et transformés par les outils de l'application sous le contrôle des agents humains. Cela est illustré par le client/serveur de la figure .

L'objectif de cet axe est d'outiller cette coordination en fournissant des briques de bas, les patrons de coopération et un langage pour décrire la coordination dans une application donnée, ainsi qu'une infrastructure pour mettre en $\oe$ uvre cette coordination dans un contexte plus global de coopération :

le recensement d'un noyau de patrons de coopération correspondant à la réalité du terrain,
la définition d'un modèle simple permettant une programmation simple et sûre de la coordination,
l'intégration de la coordination aux autres dimensions de la coopération,
le respect du besoin d'autonomie des partenaires.

**Figure:** Modèles de workflow *client/serveur*
$\begin{figure} \centerline{ \epsfig {figure=cl-work.eps} }\end{figure}$

Comme nous venons de le souligner, il faut permettre une description simple de la coordination dans les applications. Une telle description se base sur les patrons de coopération définis en et intègre plusieurs de ces patrons. Nous pensons que la philosophie workflow correspond bien à cet objectif de simplicité. L'idée de base y est de développer des primitives de description de procédés et des systèmes exécutifs simples à utiliser et permettant aux clients de se concentrer sur la logique de l'application en se déchargeant sur le système pour ce qui concerne, la gestion des données et des dépendances entre données, aini que le contrôle de l'enchaînement des tâches.

Cependant, si on veut développer une approche de ce type, il est clair que les modèles de workflow existants (qui en général mettent en $\oe$ ure les opérateurs définis par la Workflow Management Coalition ), conduisent, dans le cas où on veut modéliser des comportements coopératifs du type du client/serveur, à des modèles de procédés rigides qui ne correspondant pas à la nature coopérative des interactions existant dans les applications que l'on vise. La raison de cela est que ces opérateurs ont été implicitement définis pour des procédés concurrents, enchaînant des activités s'exécutant de façon isolée et se synchronisant uniquement sur leurs états de départ et de terminaison (normale ou anormale). Au contraire, la coopération implique des interactions fréquentes en cours d'exécution par échange de résultats intermédiaires. Un de nos objectif est de définir des opérateurs, au sens des opérateurs de workflow, mais qui permettent la prise en compte de modèles d'interaction adaptés à la coopération (les patrons de coopération de ).

Pour illustrer cela, on peut reprendre le comportement décrit dans la figure et considérer les modèles de la figure . Le modèle (1) conduit à une exécution en série des procédés, donc à l'absence de coopération; le modèle (2) conduit à une une décomposition artificielle des procédés et à une modification des interactions réelles; le modèle (3) s'appuie sur le modèle d'interopérabilité de la WfMC: les deux procédés se synchronisent par la programmation de rendez-vous mais cela rend (plus) synchrone un modèle asynchrone au départ. Notre objectif est de développer un opérateur qui permette une mise en $\oe$ uvre du comportement client/serveur aussi proche que possible de la réalité (modèle (4)).

**Figure:** Approche transactionnelle
$\begin{figure} \centerline{ \epsfig {figure=criteres.eps} }\end{figure}$

Pour permettre la mise en $\oe$ uvre simple de tels opérateurs de coordination, nous pensons que la philosophie transactionnelle est bien adaptée parce qu'elle cache la complexité induite par le parallélisme des exécutions (dans ce cas, chaque procédé est encapsulé dans une transaction). Mais par rapport aux transactions classiques, le problème est compliqué par : le fait que les exécutions ne sont plus isolées ce qui remet en cause le concept d'atomicité à la concurrence, le fait qu'elles sont de longue durée ce qui remet en cause le principe du tout ou rien et nécessite une évolution du concept de cohérence, le fait que les interactions entre les transactions suivent des patrons différents (dans les transactions classiques, le seul patron d'interaction est implicitement la concurrence) et finalement le fait qu'un partenaire veut conserver une certaine autonomie et donc un certain contrôle sur l'ouverture de son système qu'il consent.

Plusieurs modèles de transactions dits avancés ont été développés [], certains avec des objectifs connexes aux nôtres. Il s'agit en général de modèles ad hoc (encore dits exotiques) parce qu'exploitant la sémantique des applications pour relâcher la sérialisabilité (cf. fgure -a). En ce qui nous concerne, nous souhaitons poursuivre l'approche développée dans [], c'est à dire que nous cherchons de nouveaux critères de correction caractérisant les patrons de coopération. Dans cette approche les critères de correction, définis syntaxiquement (sans utiliser la sémantique des applications), dessinent une large sphère de sécurité que la sémantique des procédés restreint vers des exécutions correctes (cf. figure -b). L'intérêt est que l'on garantit ainsi des propriétés sur les exécutions correctes, alors que lorsqu'on relâche la sérialisabilité, on perd justement cette propriété. A noter aussi, comme cette figure le met en évidence, qu'une exécution sérialisable est un cas spécial d'exécution coopérative. Cela nous semble important pour l'étude des relations entre transactions coopératives et transactions traditionnelles: une transaction traditionnelle doit pouvoir être mise en $\oe$ uvre comme une transaction coopérative à laquelle on impose des contraintes. Concernant la recherche de critères de correction, on s'inspirera, certes des critères développés dans le domaine du transactionnel, [], mais aussi dans le domaine du groupware [] et des mémoires virtuelles []. Ce qui est important, c'est que ces critères soient comparables pour permettre la co-habitation de patrons différents au sein d'une même application. Soulignons aussi que, dans le contexte d'entreprises virtuelles où un partenaire connaît ses voisins immédiats avec qui il interagit directement mais pas l'ensemble du réseau de partenaires, une construction incrémentale du protocole de coordination global est nécessaire. Bien sûr, on imagine aisément la complexité de la définition de critères locaux dans sa généralité, mais l'étude menée [] ouvre des perspectives intéressantes dans un contexte limité.

Concernant l'implantation des modèles de transactions, parmi les difficultés relatives au contexte coopératif, soulignons à nouveau le problème du maintien de la cohérence: des résultats intermédiaires, donc par définition incohérents, peuvent être impliqués dans l'évaluation d'une contrainte [], les protocoles de contrôle des interactions et de correction individuelle des procédés peuvent interagir [], certains partenaires peuvent être déconnectés à un moment donné, les contraintes peuvent évoluer dynamiquement, on peut penser à évaluation coopérative de contraintes (plusieurs transactions valident une seule contrainte) ... Enfin, on s'intéressera également à l'imbrication de critères en relation avec la structure composite des documents: en fonction des patrons choisi à un niveau donné d'un document, quels sont les choix acceptables à un niveau plus interne ?

Pour conclure momentanément sur la dimension transactionnelle, et dans l'objectif de programmation simple introduit précédemment, nous prévoyons de développer des outils de génération de protocoles. Il s'agit, d'une part de fournir un environnement pour définir de façon simple des protocoles de coopération, d'autre part, partant d'une description de procédés dans un langage de description de procédés, de générer automatiquement un protocole assurant la cohérence des interactions coopératives mises en jeu dans la description.

Un problème important est celui de la gestion des exceptions. On s'est placé pour l'instant dans le cas favorable d'un cycle de vie simple : définition du modèle de coopération, exécution du modèle. Force est de constater que la réalité est aussi faite d'imprévus qu'il faut être capable de gérer (annulation d'un vol d'avion, mauvaise évaluation de la difficulté d'un problème ...). Selon la nature exceptionnelle ou pas, profonde ou pas, de l'exception rencontrée, il faut gérer une déviation au niveau d'une instance d'un procédé ou une évolution au niveau du modèle. L'évolution peut être à plusieurs niveaux: par rapport au procédé prévu, par rapport aux techniques/outils qui devaient être utilisés, par rapport aux événements qui se sont produits, par rapport aux personnes concernées, par rapport au mode de coopération prévu (asynchrone/synchrone) ... Dans ce cas, le système pour permettre de défaire les procédés en cours, soit automatiquement, soit en apportant une aide, par exemple, en mettant en relation les personnes concernées. On pourra aussi s'appuyer ici sur les techniques de recouvrement en avant développées dans le cadre du transactionnel avancé []. Et dans ce contexte, peut-être est-il plus judicieux de définir un workflow comme un ensemble de fragments de modèles, souples et adaptables (workflow adaptatif []), que comme un modèle monolitique. Ces différents fragments seraient alors assemblés grâce à des points de contrôle (réunions de chantier (électronique ?), deadline pour la production d'un document,...).

Un autre problème est celui du déploiement des applications. Il faut d'abord définir un modèle d'activité. On peut ici s'appuyer sur les modèles proposé par la WfMC ou l'OMG. Comme les applications coopèrent en interconnectant leurs procédés, il faudra définir des modèles d'interopérabilité. Là encore, on pourra s'appuyer sur ceux de la WfMC, de l'OMG ou sur SWAP. Mais il est certain qu'il faudra les étendre, par exemple pour mettre en $\oe$ uvre des modèles de transaction coopératives multi-partenaires. On pourra pour cela avoir une approche de type moniteur transactionnel, la complexité du problème nous semblant du même ordre que la terminaison (two phases commit) d'une transaction multibase.

Concernant l'infrastructure d'exécution, la mise en $\oe$ uvre des modèles de coopération nécessite l'intégration de technologies complexes : gestion d'objets persistants, gestion de versions, réplication d'objets partagés, notification d'événements, structuration du partage des objets, gestion de la mobilité ...qui ne sont pas ou peu intégrés dans les infrastructures logicielles existantes. Notre objectif est de préciser ces besoins et de développer une (ou plusieurs) infrastructure(s) << légère(s) >> intégrant ces concepts. Cette infrastructure devra pouvoir être déployée sur un réseau de PC connectés à travers l' Internet. Ce travail a une forte dimension technologique, mais conduira à une réflexion approfondie sur certains points: réflexion sur les relations entre critères de cohérence pour la gestion de réplications et critères de correction des modèles de transactions, utilisation de la structure de l'application pour structurer les groupes de communication ... Ces dernières considérations sont approfondies en section dans la définition d'un espace de communication.

Pour conclure cet axe, soulignons également l'intérêt de disposer d'outils de coordination ad hoc. On pense en particulier à la définition d'une métrique de mesure de la divergence. En général, un procédé transmet, de façon asynchrone, un document à un autre procédé au travers d'un espace de coopération. Comme les deux procédés travaillent en parallèle, ils voient des versions différentes des documents de coopération. Avec le temps, leurs vues du même document divergent. Coordonner deux procédés coopérants, c'est aussi contrôler cette divergence pour assurer in fine la << convergence >> vers un document unique. Une telle métrique contribuera à la supervision de la coopération et permettra de tirer une sonnette d'alarme avant que la divergence devienne trop importante et compromette la convergence à terme. Ces mesures peuvent se baser sur le calcul des différences entre objets simples ou complexes, le nombre de lectures sales, le nombre d'opérations non ordonnées ...Ces métriques seront également d'un grand intérêt pour ce qui concerne la conscience de groupe (cf. ).

Communication

Approche et problèmes

Comme introduit précédemment, les apports du projet se situeront sur 3 plans.

Un premier plan concerne l'intégration des mécanismes de communication avec les procédés de coordination de tâches. Les approches explorées jusqu'à présent ont considéré ces deux points de vue de manière séparée et ont donc produit des résultats et des outils indépendants les uns des autres. Au contraire, coordination et communication sont complémentaires et les mécanismes supports doivent permettre leur intégration au sein d'un même environnement et au service des mêmes procédés. En particulier, la structuration des procédés amenée par les modèles de coordination doit pourvoir être utilisée pour organiser et structurer les communications. De même, ces communications peuvent avoir un impact sur la coordination de tâches en étant à l'origine du déclenchement de certaines activités.
Un second plan est lié à l'intégration des différentes dimensions de la communication, au delà d'une simple juxtaposition d'outils répondant de façon isolée et partielle à des besoins qui sont en fait globaux et uniformes. En effet, les besoins en communication à l'intérieur d'un projet coopératif ne sont pas indépendants les uns des autres. Le même contenu de communication doit pouvoir être acheminé de façon synchrone vers certains participants et de façon asynchrone vers d'autres.
Enfin, un problème important est lié au facteur d'échelle : l'essentiel des approches explorées jusqu'ici fonctionnent avec des groupes de petite taille (voire pour des communications point à point) et la quantité d'objets mise en jeu est généralement assez faible. Les cas que nous abordons sont différents, tant dans la taille des groupes et leur dispersion que dans la quantité de documents. Ce facteur d'échelle remet en cause à la fois les mécanismes sous-jacents et les modes d'interactions agents/agents et agents/procédés.

Le projet contribuera à ces différents plans au travers de trois points d'études complémentaires.

l'identification de concepts et de mécanismes permettant de structurer l'espace de coopération et de communication de grand groupe,
la réalisation de mécanismes pour la conscience de groupe adaptés au contexte de la grande échelle,
La modélisation fine de tâches particulières à forte composante de communication, telles que la négociation, la prise de décisions et l'aide à la résolution de conflits.

Mécanismes de structuration de la coopération

Un projet coopératif de grande taille, impliquant de nombreux participants dispersés travaillant sur un grand nombre de documents distribués, a besoin de concepts et de mécanismes pour se structurer et faire face à cette taille. Les modèles de coordination apportent certains concepts, en organisant le projet en activités, en associant des ressources à ces activités et en gérant les enchaînements de ces activités. Ces concepts ne sont pas suffisant en eux-mêmes. D'une part, ils doivent trouver des mécanismes support, et d'autre part il est souvent nécessaire d'apporter de la structuration sur d'autres plans que celui des activités. Notre objectif est d'apporter des mécanismes de structuration de base pouvant être utilisés à des fins diverses :

gestion de groupes de participants complexes : groupes hiérarchisés, multi-appartenances, sous-groupes non disjoints,
organisation de l'accès aux documents,
organisation et contrôle des mécanismes de communication de bas niveau, notamment la diffusion de messages, la notification d'événements, la réplication de données.

De plus, cette structuration doit pouvoir évoluer dynamiquement : il faut pouvoir réorganiser les groupes et gérer leur composition tout au long du déroulement du projet.

Ce type de problèmes est abordé dans le domaine des systèmes distribués, et plus précisément de la communication de groupe []. De nombreux protocoles et systèmes ont été proposés, offrant diverses garanties quant à l'ordre de livraison des messages transmis (livraison garantie, maintien de la causalité, ordonnancement total [,,]). Ces systèmes intègrent un protocole de gestion de la composition du groupe (membership protocol), fonctionnant en général en étroite relation avec le protocole de diffusion de messages. L'objectif est de gérer la composition du groupe, entrées, sorties, exclusion sur panne, de façon à garantir le maintien des propriétés de livraison à tous les membres du groupe. La notion de groupe est donc ici vue non pas comme un concept de structuration mais comme une unité de diffusion et d'affectation de propriétés. Dans le domaine des systèmes coopératifs, le problème est abordé sous l'angle de la gestion de sessions, avec comme objectif principal de mettre en avant des concepts et des métaphores décrivant la constitution d'un groupe. Les approches les plus courantes sont basées sur l'invitation ou la demande d'entrée explicite, ainsi que sur les objets partagés : un groupe et constitué des participants utilisant des artefacts communs. On trouve également des approches plus élaborées comme par exemple celles basées sur la notion de pièce (MUD, DIVA [], TeamRoom []) : un groupe est composé des participants présents dans une pièce virtuelle, on le rejoint et on le quitte en entrant et sortant de la pièce ; celles basées sur << l'aura >> dans les mondes virtuels (par ex. DIVE ou []) : à chaque participant est associé une sphère d'influence et un groupe est constitué de participants dont les sphères se recouvrent partiellement.

Notre approche sera d'étendre la notion de groupe issue des systèmes répartis, en particulier en incluant la notion de sous-groupe et de multi-appartenance, et en dissociant la définition du groupe de son utilisation.

Cette approche rendra plus générale la notion de groupe et permettra son application à plusieurs contextes différents:

organisation de l'accès aux objets partagés : le groupe définit l'esemble des usagers ayant vu sur un ensemble d'objets, indépendamment de la manière utilisée pour y accéder (partage synchrone ou asynchrone notamment),
communication autour des tâches: le groupe définit l'ensemble des usagers impliqués dans une tâche et leur permet ainsi de se mettre en relation ou de diffuser des messages relatifs à la tâche,
contrôle de la réplication des données: le groupe définit l'ensemble des sites où doit être répliqué un ensemble d'objets.

L'introduction de sous-groupes permettra, tout en manipulant un groupe dans son entier, de contrôler plus finement son utilisation dans les contextes ci-dessus en gérant cette utilisation et les propriétés associées de manière séparées pour différents sous groupes. Par exemple, ceci permet de diffuser des messages à un groupe en offrant des garanties de livraison distinctes à différents sous-groupes. L'introduction de la multi-appartenance permettra d'une part de construire des structures transversales aux contextes d'utilisation et d'autre part de construire des structures plus complexes que de simple partitions.

Conscience de groupe

Recréer une conscience de groupe [] est un des points les plus importants à résoudre si l'on veut rendre effectifs et utilisables les systèmes de travail coopératif à distance. La conscience du groupe, disparue du fait de la distance temporelle et/ou géographique des participants et de la médiatisation de leurs interactions est pourtant nécessaire, en particulier pour :

Comprendre et mesurer l'activité et la dynamique du groupe, et donc prévoir son évolution probable,
développer les relations sociales nécessaires à la vie d'un groupe,
situer sa propre action au sein de ce groupe, et donc coordonner ses propres initiatives avec celles des autres.

Habituellement, on distingue différentes dimensions dans la perception et la conscience de groupe :

perception de l'espace de travail : permet de comprendre la position, l'action et l'intention des autres par rapport à la tâche en cours. Elle permet une coordination réelle entre les personnes en offrant à chacun la possibilité de situer son action et ses effets par rapport aux autres participants,
perception de la structure : permet de comprendre l'organisation générale du processus d'entreprise en cours : rôle et responsabilités des intervenants, composition et états des groupes, position des groupes dans un contexte plus large, interactions entre groupes,
perception sociale et informelle : permet d'appréhender les relations et interactions sociales se développant au sein du groupe. Elle complète les précédentes en les replaçant dans un contexte plus large et moins organisé.

De nombreux travaux ont déjà été réalisés dans ce domaine, avec une prédominance assez marquée pour les applications synchrones de taille réduite (éditeurs coopératifs, réunions virtuelles et vidéoconférences, tableaux électroniques). Ces approches consistent en général à matérialiser en temps réel les opérations effectuées par les différents intervenants sur l'interface de chacun.

Par contre, peu de résultats sont aujourd'hui disponibles concernant des applications complexes intégrant indifféremment des communications synchrones et asynchrones, des procédures formalisées et des échanges très informels, des collaborations explicites ou au contraire implicites, et mettant en jeu des groupes de taille plus importante (typiquement de 10 à quelques centaines de participants) manipulant des quantités importantes de documents.

Les apports du projet dans le domaine des mécanismes support à la conscience de groupe se situeront sur deux plans. Le premier plan concerne la prise en compte des différentes dimensions de la communication et de la coopération (directe/indirecte (cf. annexe ), synchrone/asynchrone (cf. annexe ), formelle/informelle) dans le conscience de groupe. L'objectif est d'obtenir des mécanismes et des métaphores d'interface capable de supporter ces différentes dimensions de façon uniforme. En particulier, les approches synchrones, comme par exemple [,,] paraissent difficilement capables de supporter des cas asynchrones. Le second plan concerne le facteur d'échelle. Dans le cas d'un processus coopératif de grande taille, l'état à un instant donné que les différents participants doivent percevoir et comprendre est en lui-même un objet très complexe : objets versionnés nombreux et reliés, tâches diverses dans différents états et interdépendantes, participants impliqués dans de multiples groupes et tâches avec parfois des rôles différents Faire comprendre l'évolution de cet état ainsi que les causes de cette évolution nécessite la mise en $\oe$ uvre de mécanismes et de métaphores d'interfaces capables de mettre en relation les participants avec les événements les concernant en évitant la surcharge, capables de structurer et d'identifier les informations pertinentes et capables de synthétiser ces informations de manière à les rendre facilement et rapidement apréhendables.

Notre approche sera de privilégier le cas asynchrone, puisqu'il s'agit à la fois du cas où les résultats sont les moins nombreux et du cas probablement le plus fréquent dans notre contexte. Dans un premier temps, nous aborderons surtout la conscience de groupe liée à la perception de l'espace de travail, pour la compléter ensuite avec les autres dimensions.

Notre idée est de baser ces mécanismes sur l'idée de métrique introduite en et étendues pour rendre compte de l'état de l'espace commun et de l'implication des différents participants dans les diverses activités en cours. La mesure de la distance entre deux versions d'un même objet, qui peut s'appliquer à diverses situations, est encore une fois fort pertinente. Elle peut permettre la perception rapide du travail d'un autre sur un objet partagé, perception de l'état d'un groupe de personnes par rapport à un version de référence, mesure de l'évolution de l'espace de travail d'un instant à un autre. Nous pensons qu'un grand nombre d'autres métriques peuvent être construites pour mesurer différents paramètres: implication dans les activités, utilisation de différentes ressources, évolution des groupes, distance par rapport à un objectif etc...

L'intéret d'une telle approche est multiple. D'une part, une mesure est par essence même synthétique et donc à même de supporter une utilisation à différentes échelles en représentant de la même manière une mesure portant sur un nombre quelconque d'artefacts. Du point de vue de la mise en oeuvre, cette approche permet également un meilleur passage à l'échelle puisqu'il devient moins impératif de diffuser à l'ensemble des participants l'ensemble des évènements relatifs aux différentes mesures à réaliser. Au contraire, il devient possible de réaliser et diffuser des mesures locales qui sont ensuite agrégées et consolidées par chaque destinataire. Enfin, dans de nombreux cas il est possible de calculer ces mesures de façon incrémentale. Cette propriété facilite l'application de l'approche aux cas synchrones et rend la transition asynchrone/synchrone transparente.

Modélisation des négociations et prises de décisions

Les tâches de décision collective et de résolution de conflit sont inhérentes à tout travail coopératif. En effet, s'il existe des stratégies d'évitement pour les conflits sur les ressources, il n'en est pas de même pour les conflits liés à des différences de perception de la réalité (tâches d'analyse), de divergences sur les priorités attachées aux buts (tâches de conception), ou de divergences sur les choix techniques à retenir (tâches de réalisation), dès lors que le travail est distribué entre plusieurs participants. L'objectif de cette action est de proposer des modèles et de définir des mécanismes permettant d'aider les agents humains à prendre des décisions et à résoudre des conflits.

Cet objectif est supporté par de nombreux travaux dans le domaines du GDSS et du CSCW et nous les étudierons. Ils visent le développement d'outils dédiés, intégrant des protocoles d'argumentation, de négociation, de décision parfois très sophistiqués mais codés en dur (ex: rIBIS, gIBIS citeconklin88a, cognoter, argnoter [], Hermes [], Zeno []). D'autres travaux considèrent le problème sous l'angle de la modélisation explicite des tâches. Un méta-modèle définit les concepts utilisables pour décrire les tâches. On trouve de telles approches en particulier dans le domaine du << requirements engineering >> ([], []). Enfin, quelques travaux orientés modélisation des tâches, définissent en outre des procédés génériques pour certaines tâches courantes (ex: revue inspection [], fusion de points de vue []).

Une première tâche consistera à cataloguer des patrons de coopération où apparaissent explicitement les tâches de décision collective et de résolution de conflits, établissant ainsi un lien entre la modélisation macroscopique (du type workflow) et la modélisation à grain fin des tâches en coopération directe. Ce travail doit s'appuyer bien entendu sur les observations réalisées autour de l'application pilote (cf. ) et en relation avec l'action .

Partant de là, une première approche consiste à intégrer des outils dédiés. Si elle ne peut pas être repoussée, elle ne nous semble pas totalement satisfaisante car peu flexible et couplant peu ou pas du tout les procédés macroscopiques et microscopiques (description des conséquences des décisions sur les produits, homogénéité des rôles aux deux niveaux, etc.) En enrichissant les approches de modélisation << orienté décision >> pour intégrer les aspects avancés des outils dédiés (ex : raisonnement fondé sur une logique d'argumentation pour assister à l'exploration des questions et à la décision), un bien meilleur niveau d'intégration doit pouvoir être obtenu.

D'autre part, la << programmation >> des tâches de décision collective et de résolution de conflit peut être largement facilitée par la fourniture de modèles génériques spécialisables. Les travaux actuels sont à approfondir et à élargir à d'autres tâches, en particulier celles résultant de la coopération indirecte via les produits (cf. ) (fusion, synchronisation, terminaison consensuelle, revue, etc). Enfin, un certain contrôle par les participants de la construction et de l'évolution des modèles et de l'environnement, pendant leur utilisation, semble indispensable. Le support à ce << méta procédé >>, impliquant potentiellement des tâches de décision collective et de résolution de conflits, doit également être étudié.

Dans ce contexte, on s'intéressera plus particulièrement à la négociation qui semble critique dans le contexte des entreprises virtuelles: négociation de procédés, négociation de patrons de coopération. On continuera en cela le travail démarré dans [].

Relations entre coordination et communication

Cette section explique brièvement comment nous pensons faire le lien entre les deux axes de recherche dégagés dans les sections qui précèdent.

Une première remarque, a été faite ci-dessus: la distinction entre coordination et communication n'est pas toujours évidente à faire. Une autre remarque est qu'une application réelle intègre certainement ces deux dimensions. En conclusion de cela, l'intégration des deux dimensions est un préalable à la validation des parties individuelles dans un contexte réaliste. Cela implique trois choses : une analyse des usages commune aux deux axes, un positionnement des activités concernant la coordination par rapport à celles concernant la communication et réciproquement, et une mise en $\oe$ uvre sur une plate-forme commune.

est une tâche commune aux deux dimensions qui concerne l'analyse des usages.

Concernant le positionnement de la coordination par rapport à la communication, plusieurs références aux interactions entre ces deux dimensions sont faites dans le texte :

relations entre tâches transactionnelles et tâches non transactionnelles, réunion de chantier électronique pour assembler des fragments de procédés, utilisation de métriques, infrastructure commune ... dans ,
relation formel/informel dans la conscience de groupe, les mécanismes de structuration de la coopération, fusion, synchronisation, terminaison consensuelle de tâches coordonnées, négociation de patrons de coopération dans la modélisation de la négociation et des prises de décision, relation formel/informel, utilisation de métriques dans la conscience de groupe ... dans .

Le dernier point qui permettra l'intégration des deux dimensions est le développement sur une plate-forme commune. Plutôt que de définir une architecture, nous préférons énoncer des principes directeurs:

1.: Les utilisateurs doivent pouvoir continuer à travailler avec leurs outils habituels (Autocad, Teamware flow ...) typiquement avec des PC connectés à Internet,
2.: on réutilisera les acquis de l'équipe (COO et DISCOO pour les modèles de transaction avancés, DOTS pour la négociation et l'argumentation, Tua Motu pour la gestion de fichiers versionnés, SmallEiffel pour les interfaces de programmation de protocoles ... (cf. )).
3.: on s'appuiera sur les résultats émergeants de la recherche (Perdis [], WebDav [] ...)
4.: on s'appuiera sur les normes (CORBA, SWAP, Workflow Management Coalition, XML, ...).

Définir une architecture physique mettant en $\oe$ uvre l'architecture fonctionnelle de est difficile car il est nécessaire de répondre à de nombreuses questions préalables en fonction des besoins que l'on a déjà mis et que l'on mettra en évidence, du type : quel développement additionnel faut-il encore faire sur les Tua Motu pour les rendre opérationnel ? Qu'est-ce qui manque à WebDav, sachant que l'évolution de WebDav nous échappe ? Qu'est ce que signifie porter un outil sur Perdis ? Jusqu'à quel point un outil comme TeamWare est-il ouvert ? Quel sont les partenaires effectifs (vendeurs de logiciels, checheurs ... ) que l'on peut trouver ? ...

Pour nous aider dans ces choix, nous développons, avec nos collègues architectes du BTP une expérience qui consiste à mettre en $\oe$ uvre le plus de coopération possible tout de suite en réutilisant et en intégrant des outils disponibles.

Plan de travail et résultats attendus

Plan de travail

Etape 1

(mois1 à mois18)

a) Analyse des usages en s'appuyant sur le projet AEE, le projet avec les architectes et la littérature. Mise en évidence de critères de classification des usages (modes de lecture et écriture, mode de consommation des résultats intermédiaires, ...), classification des usages
b) Formalisation des usages par des critères de correction. On s'appuiera a priori sur les formalismes issus du domaine transactionnel (ACTA []). On pourra s'appuyer sur des formalismes de description de comportements plus généraux (Lotos, CSP ...). Une part importante de ce travail consiste à étudier les interactions entre les usages et en particulier les risques d'incohérence.
c) Définition des mécanismes de structuration de l'espace coopératif. Implantation des groupes/sous-groupes dynamiques dans une infrastructure de gestion des documents.
d) Conception d'une infrastructure système pour le déploiement et la mise en $\oe$ uvre des applications. Une contrainte de conception est que les utilisateurs doivent continuer à utiliser leurs outils habituels sans modification. Une autre contrainte est que les utilisateurs puissent coopérer à travers le Web.
e) Etude de cas d'interaction entre coopération structurée et coopération non structurée.
f) Identification des informations nécessaires pour la conscience de groupe de type << espace de travail >> dans le cas asynchrone. Identification des mécanismes sous-jacents. Propositions de métaphores et de modes d'interactions.
g) Définition d'un langage de description de procédés (version 1) (type langage de workflow mais intégrant des opérateurs de coopération).
h) Définition d'une métrique de divergence.

Etape 2

(mois18 à mois36)

a) Conception et réalisation d'outils de génération de protocoles. Il s'agit, partant d'une description de procédés dans le langage V1 de générer un algorithme assurant la cohérence des interactions coopératives des différents partenaires.
b) Spécification d'une interface assurant l'interopérabilité entre systèmes hétérogènes (moteurs de workflow hétérogènes, systèmes de gestion d'objets hétérogènes ...).
c) Prise en compte de la conscience de groupe de type structurelle. Mise en $\oe$ uvre des métaphores proposées en lien avec les mécanismes sous-jacents. Intégration des mécanismes de conscience de groupe dans une infrastructure de gestion de documents.
d) Mise en $\oe$ uvre et expérimentation des mécanismes de structuration pour structurer les groupes de participants et leur ressources, pour organiser les mécanismes de conscience de groupe notification d'événements), et pour structurer la réplication des documents.
e) Réalisation d'une infrastructure de coopération permettant le déploiement des applications et la mise en $\oe$ uve de la coopération. Validation de cette infrastructure et des modèles de coopération développés par le développement d'environnements de coopération. On s'attachera en particulier à montrer comment des environnements existants auraient profité dans leur développement de l'existence de l'infrastructure ECOO. On mettra en évidence également l'intérêt d'une intégration coopération structuré, coopération non structurée.
f) Définition d'un langage de description de procédés (version 2).

Etape 3

(au delà de 36 mois)

a) Evaluation des modèles, outils et de l'infrastructure développée dans des applications réelles.
b) Consolidation de ces modèles, outils et infrastructure.
c) Standardisation, diffusion du travail réalisé.
d) Intégration dans un modèle plus large d'entreprise virtuelle.

Résultats attendus

On peut distinguer entre différents types de résultats:
a) Une analyse des usages courants de coopération et une classification de ces usages.
b) Des modèles formels de coopération sous la forme de critères de correction et de protocoles de synchronisation (en particulier de type transactionnel).
c) Des concepts et des mécanismes de base pour la structuration des groupes coopérants permettant de maîtriser la taille des projets. Ces concepts seront suffisamment génériques et transversaux pour pouvoir être utilisés pour structurer les groupes, l'accès aux ressources, la notification et la communication, la réplication de documents.
d) Des concepts et des mécanismes de conscience de groupe adaptés à l'échelle d'un grand projet de coopération multipartenaire prenant en compte les différentes dimensions de la conscience de groupe ainsi que différents modes de collaboration (synchrone/asynchrone, direct/indirect).
e) Un langage de description de procédés coopératifs, des outils et une infrastructure d'aide à la coopération.
f) Un modèle d'interopérabilité de procédés coopérants.
g) une infrastructure pour mettre en $\oe$ uvre des applications coopératives dans le contexte d'entreprises virtuelles.

Position par rapport l'existant

On peut situer notre approche de différents points de vue, en complément des références faites dans le texte descriptif des actions de recherche :

a) Analyse des usages. Les caractéristiques de notre approche sont, d'une part l'utilisation de l'outil workflw, dans la veine de [] pour mémoriser et analyser les usages, d'autre part l'objectif de spécification de ces usages.
b) Modèles de coopération et systèmes coopératifs. Une première caractéristique est le socle transactionnel de nos modèles. Ensuite, notre approche est orientée vers le support aux projets coopératifs de grande taille. Elle se préoccupe donc principalement de définir des procédés coopératifs plutôt que des outils, adresse explicitement le problème de l'intégration d'approches variées et d'outils différents ainsi que celui du passage à une grande échelle.
c) Modèles de transactions avancés. Notre approche consiste à chercher de nouveaux critères de correction et de nouveaux protocoles plutôt que de relâcher de façon heuristique ceux existants.
d)Workflow. Par rapport à ce domaine, notre approche se caractérise par la prise en compte de la coopération et la formalisation de la notion de cohérence.
e) Infrastructure de coopération. Une première caractéristique est la décision de développer une infrastructure qui permet aux partenaires de continuer à travailler avec leurs propres outils et de s'interconnecter à travers le Web. Une autre caractéristique, qui prolonge ce qui vient d'être dit, est de définir des interfaces d'interopérabilité permettant l'interconnexion de systèmes hétérogènes (moteurs de workflow, systèmes de gestion de la concurrence, ...).

Insertion du projet ECOO dans l'INRIA

Nous pensons que des relations sont à développer sur les thèmes suivants:

l'étude de l'interface entre Mémoires Virtuelles Partagées et transactions coopératives : SIRAC et SOR (Perdis), ADP (critères de cohérence pour MVP), SOLIDOR (relations entre qualité de service et propriétés ACID),
la coordination de tâches : AID, MACSI, PROTHEO et SHERPA,
le déploiement d'application distribuées : RESEDAS et SIRAC,
l'édition coopérative distribuée : c'est une dimension importante de la co-conception et de l'ingénierie simultanée avec OPERA,
les systèmes transactionnels : RODIN (datawarehouse sur Internet) et VERSO (commerce électronique),
processus pour l'électronique embarquée : dans le cadre de l'action de développement INRIA AEE qui implique plusieurs projets INRIA ainsi que l'équipe TRIO du LORIA (cf. ),
les systèmes multi-agents: MAIA.

Actions industrielles en cours

AEE

Le projet AEE (Architecture pour l'Electronique Embarquée) regroupe les constructeurs automobiles français (PSA, Renault), leurs équipementiers (Sagem, Siemens, Valéo), l'Aérospatiale et des chercheurs de l'INRIA, de l'IRCYN et du LORIA

L'objectif général du projet est la définition d'un processus rapide et sûr pour la définition de l'architecture système et le développement des logiciels associés, embarqués à bord des véhicules automobiles. Plusieurs aspects du projet nous intéressent: modèles de communication entre intervenants, modèle d'entreprise virtuelle, ...Le projet a démarré au 1er janvier 1999 pour une durée de 3 ans. C'est une action de développement de l'INRIA (http://aee.inria.fr/).

Usages des téléactivités et impacts sur les organisations et les services - CTI CNET

L'objet de cette étude est de mieux comprendre les principes de la coopération pour la mettre en $\oe$ uvre de façon simple et acceptable par les utilisateurs. Les résultats attendus sont une taxonomie d'usages coopératifs de base et des protocoles de coopération mettant en $\oe$ uvre ces usages par assemblage. Le domaine d'application choisi est celui du BTP.

Le travail se fait en coopération avec une équipe du CNET à Lannion et une équipe du CRAI à Nancy (Centre de Recherche en Architecture et Ingénierie). Le projet a commencé le 1er avril 1998 pour une durée de 30 mois (http://www.loria.fr/equipes/ecoo/cocao/).

Microlor

L'objectif est de réaliser un environnement de développement interactif (compilateur, simulateur et interface graphique pour Windows NT/95/98, documentation et exemples) pour une famille de micro-contrôleurs paramétrables. Le logiciel permettra d'une part de simuler interactivement l'exécution du programme source et d'autre part, une fois le programme source mis au point, produire le binaire correspondant. Le compilateur accepte en entrée des sources d'un sous-ensemble du C ANSI, pour les traduire vers des fichiers objets en langage machine du micro-contrôleur cible. L'architecture interne du micro-contrôleur ainsi que la définition de l'assembleur seront variables selon le modèle choisi et seront renseignées par des paramètres avant la simulation ou la création des fichiers destinations. En mode de simulation interactive, l'utilisateur pourra suivre le déroulement de son programme en visualisant simultanément l'instruction source courante et l'instruction machine correspondante. Le simulateur permettra également d'exécuter le programme source instruction par instruction (mode pas-à-pas), de poser et d'enlever des points d'arrêts, de suivre l'évolution des registres, l'évolution de la pile ainsi que l'évolution de la mémoire.

Nous avons prévu d'appliquer une technique de compilation globale similaire à celle que nous avons déjà utilisée pour le projet SmallEiffel.

Ce projet a débuté en février 1999 pour une durée de 1 an.

Définition de composants de systèmes de gestion de Workflow distribués et flexibles - collaboration XEROX

L'objectif général est d'explorer l'application de modèles de transactions avancés dans les systèmes de gestion de workflow. Les résultats attendus sont la conception et l'implantation de composants d'un gestionnaire de workflows distribués qui gèrent des tâches de longue durée suivant des procédés de collaboration flexibles, en particulier grâce à la gestion de documents versionnés.

Le travail se fait en coopération avec l'équipe << Coordination Technologies >> du Xerox Research Center Europe à Grenoble et se formalisera par le partage d'un post-doctorant.

Manuel Munier, thésard issu de ECOO est en post-doc chez XEROX depuis le 1er mars et pour une durée de 8 mois.

Hitachi

ECOO participe aux discussions en cours entre Hitachi et l'INRIA.

Actions nationales et internationales

Actions régionales

Nous collaborons avec le CRAI (Centre de Recherche en Architecture et Ingénierie) de Nancy dans le cadre d'une CTI CNET.

Claude Godart est membre du conseil scientifique de l'ESSTIN.

L'équipe ECOO est jeune équipe soutenue par la région.

Nous participons au Centre Charles Hermitte (Centre Lorrain de Compétence en Modélisation et Calcul à Haute Performance).

Actions nationales

Gérôme Canals est responsable du groupe de travail << Nouvelles bases de données >> du PRC I3. Les membres du projets participent à des réunions des PRC I3 et ALP.

Nacer Boudjlida a été membre et est membre des comités de programmes d'INFORSID et de BDA.

Claude Godart est membre du Conseil Scientifique du LIL (Laboratoitre Informatique du Littoral) à Calais.

Actions financées par la Commission Européenne

Nous participons au groupe de travail ESPRIT << Promoter >> soutenu par le Réseau d'Excellence ESPRIT << Renoir >>. Les participants sont le LORIA, Imperial College, Politechnico di Milano, les Université de Grenoble, Manchester, Paderborn, Pise et Trondheim.
Un livre écrit dans le cadre de ce working group vient de sortir: << Software Process : Principles, Methodology, Technology >> (LNCS 1500). Des membres du projet ECOO ont participé à l'écriture de 3 chapitres:
<< Coopération control in PSEE >> C. Godart (éditeur, LORIA), N. Belkhatir (IMAG Grenoble), A. Carzaniga (Politechnico di Milano), J. Estublier (IMAG Grenoble), E. Di Nitto (Politechnico di Milano), Jens Janke (Univ. Paderborn), Patricia Lago (Univ. Throndheim), W. Schaeffer (Univ. Paderborn), Hala Skaf (LORIA)
<< Architectural Views and Alternatives >> W. Schaeffer (éditeur, Univ. Paderborn), A. Fuggetta (Politechnico di Milano), C. Godart (LORIA), J. Jahnke (Univ. Paderborn)
<< The human dimension of Software Process >> D. Wastell (éditeur, Univ. Manchester), S. Arbaoui (Univ. Chambéry), J. Lonchamp (LORIA), C. Montagero (Univ. Pise).

Actions Internationales

Nacer Boudjlida est ou a a été membre des comités de programme de: Maghrebian Conference on Artificial Intelligence and Software Engineering (1996,98), 18th International Conference on Conceptual Modelling (1999), Mediterranean International Conference on Computer Science (1999).

Dominique Colnet est membre du comité de programme de TOOLS99.

Claude Godart est ou a été membre des comités de programme de: 10th et 11th Software Engineering and Knowledge Engineering Conference (SEKE98, SEKE99), IEEE symposium << Enterprise Applications and services >> associé à Globecom99, 7th International Conference on Parallel and Distributed Systems (ICPADS2000, section CSCW).

Des membres de l'équipe ont participé au projet Tempus Phare entre l'ESSTIN et l'Université de LODZ à Bielsko Biawa.

Un projet de coopération entre l'Université de Western Sydney et le LORIA est en cours de développement. C. Godart s'est rendu à l'UW Sydney en mars 99, P. Ray (position prof. invité) et V. Varadharajan rendront visite au LORIA en juin 99. Un objectif est de définir un projet entre le CSIRO et l'INRIA ou l'université sur le thème << Entreprises virtuelles >>.

Diffusion des résultats

Logiciels

COO

COO est un atelier de Génie Logiciel construit sur une base de type PCTE. Sa particularité est d'être un des très rares systèmes implantant un modèle de transactions coopératives, de plus sur une base d'objets industrielle. Il se fonde essentiellement sur un gestionnaire d'espaces de travail multi-versionné et hiérarchisé. Une version (incomplète) distribuée à base CORBA a été développée.

DOTS

DOTS (Decision Oriented Task Support) est un environnement générique d'assistance aux tâches collectives à forte composante décisionnelle qui couvre aussi bien le travail asynchrone que le travail occasionnellement synchrone. Il procure 3 formes d'assistance : guidage dans la tâche, assistance à l'argumentation et à la décision, conscience de groupe asynchrone et synchrone. Il est accompagné d'un environnement complet de définition, d'instanciation et de vérification des modèles de tâches. Il est entièrement développé en java.

GNU Eiffel

SmallEiffel est un traducteur Eiffel vers ANSI C et la machine virtuelle Java. Du fait de l'utilisation d'une nouvelle technique d'inférence de types, il est très performant, produit du code performant et détecte statiquement un plus grand nombre d'erreurs que les autres compilateurs Eiffel. Très largement distribué et utilisé, il est << the GNU Eiffel Compiler >>.

Tua Motu

Un Motu est un gestionnaire d'objets augmenté d'une gestion de versions et d'une gestion d'utilisateurs répondant à des besoins mis en évidence pour supporter la coopération. Un Tua Motu est un ensemble de Motus connectés supportant la réplication d'objets et l'organisation de groupes de coopération. L'ensemble est écrit en Java. Plusieurs interfaces de persistance ont été définies.

Enseignement universitaire

Les enseignants chercheurs du projet participent très activement aux formations nancéiennes des universités Henri Poincaré Nancy 1 et Nancy 2 à tous les niveaux, et en particulier en 3ème cycle (ESIAL, ESSTIN, ISIAL, DEA).

Nacer Boudjlida est responsable du DESS informatique, option Ingénierie du logiciel à l'université Henri Poincaré Nancy 1. Il est membre élu de la commission de spécialistes 27 eme section de l'université Henri Poincaré et du conseil de l'UFR STMIA à l'université Henri Poincaré.

Claude Godart est responsable du département informatique de l'ESSTIN. Il a été membre du bureau de la commission de spécialistes 27 ème section de l'université Henri Poincaré et de l'Institut National Polytechnique de Lorraine jusqu'à son détachement à l'INRIA. Il est membre du conseil d'administration de l'ESSTIN.

Jacques Lonchamp est responsable du département informatique de l'IUT A de Nancy 2. Il est membre du bureau la commission de spécialistes 27 ème section de l'université Nancy 2.

Pascal Molli a enseigné dans le cours CODITIEL (UPS CNRS 856) << Génie logiciel pour la modélisation numérique >> qui s'est déroulé en avril 1997 à Mont-Saint Aignan et au cours << Langages et systèmes à objets >> organisé par le SIMPA à Hanoï.

Références

Publications au cours des quatres dernières années

Références

1: H. SKAF. -
<< Une approche hybride pour gérer la cohérence dans les environnements de développement coopératif >>. -
Thèse d'université. Université Henri Poincaré Nancy I, 1997.
munier99aM. MUNIER. -
<< Une architecture pour intégrer des composants de contrôle de la coopération dans un atelier distribué >>. -
Thèse d'université. Université Henri Poincaré Nancy I, 1999.

Références

1: W. SCHAEFFER, J. JANKE, C. GODART, AND W. EMMERICH.
<< Architectural views and alternatives >> . -
In J.C. Derniame and B. Warboys editors, editors, Software Process: Principles, Methodology, Technology. LNCS 1500, 1999.
2: D. WASTELL, S. ARBAOUI, J. LONCHAMP, C. MONTAGERO
<< The human dimension of software processes >> . -
In J.C. Derniame and B. Warboys editors, editors, Software Process: Principles, Methodology, Technology. LNCS 1500, 1999.
zendra97a O. ZENDRA, D. COLNET, AND S. COLLIN. -
Efficient Dynamic Dispatch without Virtual Function Tables. The Small Eiffel Compiler.
ACM SIGPLAN notices, 32(10), 1997.

Références

1: M. BOUCHIKHI, N. BOUDJLIDA,
« Using Larch to specify the Behavior of Objects in Open Distributed Environments »,
in: Maghrebian Conference on Software Engineering and Artificial IntelligenceMCSEAI'98 ,
1998.
boudjlida96b N. BOUDJLIDA. -
<< Environnements logiciels intégrés et bases de données >>. -
Actes du 2ème Forum International d'Informatique Appliquée, pages 130-164, Tunis, 1996
boudjlida97a N.BOUDJLIDA AND O. PERRIN. -
<< Database Versioning and Restructuring >>. -
XII Brazilian Symposium on Database Systems - SBBD '97, Fortaleza, 1997.
bounab95bM. BOUNAB, C. GODART. -
<<An experiment in integrating CAD tools>>. -
In: 3rd International Conference on Computer Integrated Manufacturing, ICCIM'95
Hong Kong, 1995.
bounab95aM. BOUNAB, C. GODART. -
<<A Federated Approach to Tool Integration>>. -
In: 7th International Conference on Advanced Information Systems Engineering, CAiSE'95, LNCS 932. -
Jyvalskyla, 1995.
bouneffa95aM.A. BOUNEFFA AND N. BOUDJLIDA. -
<< Managing Schema Changes in Object-Relationship Databases >>. -
Proceedings of the 14th Object-Oriented and Entity-Relationship Databases International Conference, OO-ER'95, LNCS 1021, pages 113-122, 1995
bouneffa95bM.A. BOUNEFFA AND N. BOUDJLIDA.. -
<< An Assumption Based Schema Integration Approach >>. -
Actes Conférence Internationale sur le Génie Logiciel et ses Applications, pages 469-480, 1995.
canals95aG. CANALS, F. CHAROY, C. GODART, P. MOLLI. -
<<P-Root & Coo : Building a Cooperative Software Development Environment>>. -
In: Proceedings of the 7th Conference on Software Engineering Environments (SEE'95), IEEE Computer Society Press. -
1995.
canals96aG. CANALS, P. MOLLI, C. GODART. -
<<Concurrency control for cooperating software processes>>,-
International Workshop on Advanced Transaction Models and Architecturea (ATMA96),
Goa, India, 1996
canals98bG. CANALS, C. GODART, M. MUNIER, AND S. TATA. -
<< Supporting cooperation in project-enterprises >>. -
In Proceedings of the 1998 International Conference on Enterprise Networking and Computing (ENCOM-98), Atlanta, Georgia, June 1998.
canals98eG. CANALS, C. BOUTHIER, C. GODART, AND P. MOLLI.
<< Tuamotu : Une infrastructure distribuée pour le support des entreprise-projets >>. -
In Actes du Colloque International sur les Nouvelles Technologies de la Répartition (NOTERE'98), Montréal, Québec, Canada, Octobre 1998.
canals98fG. CANALS, P. MOLLI, AND C. GODART.
<< Supporting telecooperative engineering applications using replicated versions >> . -
In T. Tuikka M. Divitini, B.A. Farshian, editor, Proceedings of the IGROUP'98 workshop, Seattle, WA, November 1998.
charoy95bF. CHAROY, P. MOLLI. -
<<Subjectivity and Software Engineering Environment Framework>>. -
In: OOPSLA'95 workshop on Subjectivity in Object Oriented System. -
Austin, TX, October 1995.
collin97aS. COLLIN AND D. COLNET AND O. ZENDRA.-
<<Type Inference for Late Binding. The SmallEiffel Compiler>>.-
Joint Modular Langages Conference (Proceedings of JMLC - Austria).-
Springer-Verlag, LNCS, Vienne, 1997
colnet98cD. COLNET, P. COUCAUD, O. ZENDRA. -
« Compiler Support to Customize the Mark and Sweep Algorithm »,
in: ACM SIGPLAN International Symposium on Memory Management - ISMM'98, Vancouver, British Columbia, Canada , ACM Special Interest Group on Programming Languages (SIGPLAN), ACM Press, p. 154-165,
octobre 1998,
godart95aC. GODART, D. DIETRICH. -
<<Stepwise specification of interactive processes in COO>>. -
In: 4th European Workshop on Software Process Technology, Noordwijkerhout, The Nederlands, LNCS 913
April 1995.
godart95bC. GODART, G. CANALS, F. CHAROY, P. MOLLI. -
<<About some Relationships between Configuration Management, Software Process and Cooperative Work: the COO Environment>>. -
5th Workshop on Software Configuration and Maintenance, Seatle, Washington DC (USA), LNCS 1005
April 1995.
godart96bC. GODART AND G. CANALS AND F. CHAROY AND P. MOLLI AND H. SKAF. -
<< Designing and Implementing COO >>. -
18th International Conference on Software Engineering (ICSE18), Berlin, IEEE Computer Society Press, March 1996
godart99bC. GODART, O. PERRIN ET H. SKAF. -
<<COO: a workflow operator to improve cooperation modeling in virtual enterprises >> . -
9th IEEE RIDE, International Workshop on Research Issues in Data Engineering, Sydney, March 1999
lonchamp95a J. LONCHAMP. -
<<CPCE: A Kernel for Building Flexible Collaborative Process Centered Environments >>. - Software Engineering Environments, Noordwijkerhout, IEEE Computer Society Press, 1995.
lonchamp95b J. LONCHAMP. -
<< Object-Oriented Collaborative Process Modeling >>. - TOOLS Europe'95. Versailles, Prentice-Hall Ed., 1995.
lonchamp96b J. LONCHAMP, F. SEGUIN. -
<< Issue-Based Collaborative Process Modelling >>. -
COOP'96, Second International Conference on the Design of Cooperative Systems, Juan-les-Pins, june 1996.
lonchamp97b J. LONCHAMP AND B. DENIS. -
<< Fine-grained Process Modelling for Collaborative Work Support: Experiences with CPCE >>. -
In 7th Euro Conf. on DSS, Groupware, Multimedia, EC, Mars 1997.
lonchamp97c J. LONCHAMP AND F. SEGUIN. -
<< The Argo Project >>. -
In 9th Int. Conf. on Software Engineering and Knowledge Engineering SEKE'97, IEEE Computer Society Pres, Juin 1997.
lonchamp98bJ. LONCHAMP,
« Process model patterns for collaborative work »,
in: 15th IFIP World Computer Congress - Telecooperation'98 ,
1998. poster.
molli97a P. MOLLI. -
<< COO-Transaction: Enhancing Long Transaction Model with Cooperation >>. -
In 7th Software Configuration Management Workshop (SCM7), LNCS, Boston, USA, May 1997.
munier98aM. MUNIER AND C. GODART. -
<< Cooperation services for widely distributed applications >>. -
In Tenth International Conference on Software Engineering and Knowledge Engineering, 1998.
perrin95aO. PERRIN AND N. BOUDJLIDA. -
<< An Open Approach for Data Integration >>. -
Proceedings of the 2nd International Conference on Object-Oriented Information Systems, OOIS '95, pages 94-98, Dublin, 1995.
skaf96a H. SKAF, F. CHAROY AND C. GODART. -
<< Maintening Consistency of Cooperative Software Development Activities >>. -
6th International Workshop on Foudations of Models and Languages for Data and Objects (Integrity in Databases), Foundation of Information Sustems, 1996
skaf97a H. SKAF, F. CHAROY, AND C. GODART. -
<< An Hybrid Approach to Maintain Consistency of Cooperative Software Development Activities >>. -
In SEKE97 - The Ninth International Conference on Software Engineering and Knowledge Engineering, Juin 1997.
skaf98aHALA SKAF, FRONfont size=-1>COIS CHAROY, AND C GODART.
<< Flexible Integrity Control of Cooperative Applications >> .-
In DEXA Conference, Vienne, 1998.
song97a Y.K. SONG, S.R. INE AND N. BOUDJLIDA. -
<< Software Development Process Modeling System for Telecommunications Software >>. -
Proceedings of the International Conference on Telecommunications, ICT'97, pages 543-548, Melbourne, 1997
2: S. TATA, G. CANALS, AND C. GODART.
<< Specifying interactions in Cooperative applications >> .-
In Eleventh International Conference on Software Engineering and Knowledge Engineering (SEKE'99), Kaiserslautern , Germany, 1999.

Références

[]

colnet98bD. COLNET, P. COUCAUD, O. ZENDRA,
« Eiffel : la puissance de la recherche au service de vos programmes »,
Programmez! , 2, juillet 1998, p. 82-83,
Photocopie de l'article jointe a cette demande.

godart98aC. GODART, V. CHEVRIER,
« Initiation à l'informatique pour les ingénieurs »,
1998, Il s'agit d'un document pédagogique dont la diffusion est possible mais en demandant l'avis à l'un des auteurs auparavant.

molli98aP. MOLLI, L. ANDREY,
« Java Lectures Notes »,
1998.

rossel95A. ROSSEL. -
<<Verrouillage flexible dans un modèle de transactions coopératives et emboitées pour le Génie Logiciel>>. -
In: Mémoire de diplôme ingénieur CNAM. -
1995.

zendra98aO. ZENDRA, D. COLNET, P. COUCAUD,
« SmallEiffel: l'Eiffel à Très Grande Vitesse »,
Programmez! , 3, octobre 1998, p. 64-67.

Autres Références

Références

[]

bernstein87aP.A. BERNSTEIN AND V. HADZILACOS AND N. GOODMAN,
<<Concurrency Control and Recovery in Database Systems >> .-
Addison-Wesley, 1987

cichocki98aA. CICHOCKI AND A. HELA AND M. RUSINKIEWICZ AND D. WOELK. -
<< Worflow and Process Automation >>. - Kluwer Academic, 1998

elmagarmid92A. ELMAGARMID (editor). -
<< Database transaction models for advanced applications >>. - Morgan Kauffman, 1992.

gray93aJ. GRAY AND A. REUTER (editors). -
<< Transaction Processing: Concepts and Techniques >>. - Morgan Kaufmann, 1993

jajodia97a S. JAJODIA AND L. KERSHBERG (editors). -
<< Advanced Transaction Models and Architectures >>. - Kluwer Academic, 1997.

kumar98aV. KUMAR, M. HSU. -
Recovery mechanisms in database systems
Prentice Hall 1998

oszu93aOSZU, DAYAL AND VALDURIEZ (editors). -
<< Distributed Object Management >>. - Morgan Kauffmann, 1993.

Références

[]

guerraoui97a R. GUERRAOUI. -
<<Transactions réparties: Algorithmes, Systèmes et Langages>>. -
Habilitation à diriger des recherche, Université Joseph Fournier, 1997

pacull95a F. PACULL. -
<<Concepts et Mécanismes pour la mise en oeuvre d'un environnement d'édition coopérative sur un réseau à grande échelle >>. -
Ecole Polytechnique Fédérale de Lausanne (EPFL), 1995

suleiman98a M. SULEIMAN. -
<<Sérialisation des opérations concurrentes dans les systèmes collaboratifs répartis >>. -
Université de Montpellier II, 1998

tiakime98a G. TIA-KIME. -
<< Critères de cohérence pour données partagées à support répartis >>. -
Université de Rennes 1, 1988

Références

[]

barghouti91aN. BARGHOUTI AND G. KAISER. -
<< Concurrency Control in Advanced Database Applications >>. -, In ACM Computing Surveys, 23(3), 1991

birman93aKENNETH P. BIRMAN. -
<< he Process Group Approach to Reliable Distributed Computing >>. -, Communications of the ACM, 36(12), 1993

canals94a G. CANALS AND N. BOUDJLIDA AND J.C. DERNIAME AND</