1

RECHERCHE

Spécification formelle et approche objet pour les applications Workflow Isabelle Attali1, Rémi Bastide2, Mireille Blay3, Anne-Marie Dery3, Philippe Palanque2 1 INRIA, Sophia-Antipolis, BP 93 06902 Sophia-Antipolis Cedex ia@sophia.inria.fr 2 LIS Université Toulouse I, Place Anatole France 31042 Toulouse cedex bastide@cict.fr, palanque@cict.fr 3 Université de Nice- Sophia-Antipolis - CNRS, BP 145 06903 Sophia-Antipolis Cedex blay@essi.fr, pinna@essi.fr

RÉSUMÉ. Cet article traite de la spécification de collecticiels, et plus particulièrement d’applications de type Workflow. Nous présentons trois formalismes issus des modèles à objets, et nous montrons dans quelle mesure ces formalismes peuvent apporter des solutions au problème général de la spécification de la structure et de la dynamique des collecticiels. Les formalismes décrits sont le langage Sophtalk, fondé sur le paradigme multi-agents, le langage FLO qui s’attache à décrire les dépendances comportementales entre objets, et les Objets Coopératifs, langage à objets concurrents fondé sur les réseaux de Petri. La présentation de ces trois approches est étayée par le traitement d’une étude de cas significative, inspirée de celle connue dans la littérature sous le nom de « cas IFIP », qui consiste à définir la structure d’un système informatique permettant la gestion d’un congrès.

ABSTRACT. This paper deals with the specification of groupware applications of the workflow type. We present three formalisms stemming from the object-oriented approach, and we show to which extent these formalisms can offer solutions to the problem of specifying the structure and the dynamics of groupware systems. The formalisms we describe are the Sophtalk language, based on the multi-agent paradigm, the FLO language which aims at describing the behavioural dependencies between objects, and the Cooperative Objects formalism, a concurrent object-oriented language based on Petri nets. The approaches are presented and applied to a significant case study, a variation of the one known as the « IFIP case », which deals with the definition of a software support system for the organisation of a conference.

MOTS-CLÉS : Collecticiel, Spécification formelle, Modèles à objets, Workflow. KEY WORDS : Groupware, Formal specification, Object models, Workflow.

2

1. Introduction

Les applications de type collecticiel peuvent être classifiées suivant deux dimensions [KAR 94] : • une dimension temporelle, qui précise si les interactions entre participants se déroulent dans des intervalles de temps brefs, voire instantanés à l’échelle humaine (on parle alors d’interaction synchrone) ou au contraire si les échanges peuvent s’étaler sur de longues périodes (ce que l’on qualifie d’interaction asynchrone) ; • une dimension spatiale, qui précise si l’application est destinée à permettre la coopération d’utilisateurs physiquement proches (et qui peuvent alors communiquer par d’autres moyens, par exemple la voix) ou au contraire si elle se prête à faire coopérer des utilisateurs distants les uns des autres.

Cet article traite de la spécification des applications Workflow. Ces applications

sont à classifier parmi les collecticiels asynchrones et distants. L’objectif d’une application Workflow est de coordonner le travail d’un groupe d’utilisateurs engagés dans une tâche pouvant s’étaler sur une durée très longue. Les utilisateurs impliqués dans cette tâche communiquent le plus souvent en s’échangeant des documents ou des informations d'autres natures, par des moyens physiques ou électroniques.

La spécification des applications Workflow pose des problèmes particuliers. Elle implique de décrire précisément les agents impliqués dans la réalisation d’une tâche coopérative, la structure des interactions qui unissent ces agents, la nature des informations qu’ils échangent et la dynamique des traitements qui doivent être effectués.

L’objectif du présent article est de définir quels sont les critères qu’une approche de spécification doit remplir pour être appropriée au domaine du Workflow, et de présenter trois approches récentes qui s’attachent à prendre en compte ces critères. Pour déterminer l’ensemble des critères pertinents, nous présentons un état de l’art sur les principaux formalismes dédiés au Workflow (cf. § 2). Ces formalismes sont déjà relativement anciens, et nous semblent manquer de certaines caractéristiques essentielles. Nous présentons ensuite, au travers d’une étude de cas, trois formalismes qui ont en commun le fait d’être issus de l’approche objet : Sophtalk, qui s’attache à décrire l’interface des agents et la structure de leurs interconnexions, FLO dont le but est d’identifier les dépendances comportementales entre objets, et les Objets Coopératifs qui associent approche à objets et réseaux de Petri pour la description de comportements dynamiques complexes (cf. § 3). Nous comparons enfin en section 4 ces trois approches en nous fondant sur les critères identifiés au paragraphe 2.5.

2. Spécification d’applications Workflow

Cet état de l'art décrit un ensemble de formalismes qui ont été utilisés avec succès pour la spécification d’applications Workflow. Parmi de nombreuses approches référencées dans la littérature, nous avons sélectionné les quatre suivantes car elle présentent des caractéristiques spécifiques à la fois au niveau des formalismes

3

utilisés (qui sont soit une adaptation de formalismes existants, soit une proposition de formalismes ad hoc) et de leurs principes de modélisation.

La présentation de ces quatre formalismes nous conduit à identifier un ensemble de critères qui semblent indispensables à une bonne approche de spécification d'applications Workflow (cf. § 2.5). Toutefois ces différentes approches restent éloignées des techniques d'implémentation et aucune d'elles ne propose une structuration par objets. L'étude de cas traitée au paragraphe 3 nous permet d'affirmer que les avantages de l'approche objet sont aussi applicables dans le domaine du Workflow. Dans cette optique, nous présentons trois approches à objets offrant de surcroît les caractéristiques nécessaires à la spécification d'application Workflow.

2.1. Electronic Circulation folders

Le formalisme des Electronic Circulation Folders (ECF, [KAR 90]) a été défini au cours des travaux liés au projet ESPRIT ProMInanD (Extended Office Process Migration with Interactive Panel Displays). Il a depuis été également adopté par deux autres projets ESPRIT : Panda et Astra.

Un ECF est la métaphore électronique d'un outil fréquemment rencontré dans les organisations : le dossier de circulation (Circulation Folder, CF). Il contient des documents arbitraires (mais associés en vue d'une tâche précise) qui doivent être traités par des employés de bureau. L'adresse de ces employés est écrite sur la couverture du dossier. Un service interne de messagerie a pour rôle de transférer les dossiers du trieur de sortie d'un employé vers le trieur d'entrée de l'employé suivant. L'idée de base de l'approche ECF est de conserver le principe des CF (auxquels les employés de bureau sont familiarisés) en l'automatisant, afin de faciliter la transition du fonctionnement manuel au fonctionnement automatique dans une organisation.

Une spécification de migration détermine les chemins de circulation du dossier en termes d'étapes à exécuter pour l'accomplissement de la tâche. La définition d'une étape précise quel employé doit effectuer le travail, quels documents sont manipulés et quels programmes d'application doivent être invoqués à cette fin.

Le formalisme des ECF s'attache particulièrement à donner la possibilité de décrire des déviations par rapport aux migrations prédéfinies et à permettre des traitements d'exceptions. Certaines étapes peuvent être optionnelles, et omises sous certaines conditions. Des contraintes temporelles peuvent également être précisées. Le formalisme des ECF se fonde sur des concepts simples et aisément compréhensibles. Les spécifications produites sont souples, et sont particulièrement bien adaptées pour décrire des tâches où des exceptions nombreuses peuvent se produire. Le degré de formalisation est toutefois assez faible, et le formalisme ne semble pas bien adapté à l'analyse et la validation.

2.2. C-TODOS

Ce formalisme a pour origine le projet ESPRIT TODOS (Automatic Tool for Designing Office Information Systems). C-TODOS (Conceptual TODOS) est un outil destiné à assister la production de spécifications par modélisation conceptuelle [PER 89].

4

Le modèle C-TODOS décrit les aspects statiques (ou structurels) des éléments du système aussi bien que leurs aspects dynamiques (ou procéduraux). L'aspect statique est pris en charge par un modèle de données orienté-objet, incluant les notions de généralisation, d'agrégation, d'association et de référence. Quatre types sont prédéfinis, et servent de base à la modélisation : Document, Objet, Agent et Message. Les concepts de base de l'aspect dynamique sont l'événement et l'action. Une transition dynamique combine un événement et une ou plusieurs actions pour décrire les conséquences d'un stimulus. Le comportement global du système est décrit par des séquences de transitions dynamiques. Un prédicat, associé à chaque type d'événement, permet de conditionner le changement d'état de l'entité à la vérification d'une propriété. Des contraintes de précédence entre états permettent de préciser des séquences légales d'événements, et peuvent également être utilisées dynamiquement pour calculer des requêtes sur l'état dynamique du système. Un grand nombre de procédures de vérification et de validation des modèles sont possibles ; en ce qui concerne l'aspect dynamique, on peut notamment détecter des cycles d'événements, et effectuer des analyses de précédence temporelle. A partir du graphe de précédence, il est possible de construire de manière semi-automatique un automate à états finis pour chaque agent du système. Cet automate permet d'examiner de manière synthétique les séquences d'échanges de messages pour chaque agent.

Le langage de spécification de la dynamique est formel, et il dispose d'une représentation textuelle et d'une représentation graphique. Plutôt que d'indiquer le parcours d'un document entre différents employés, la description est centrée sur le document, et indique les messages que ce document fait parvenir aux employés, à la suite d'événements reçus par le document lui-même.

2.3. OSSAD

Le langage utilisé dans la méthode OSSAD (issue du projet ESPRIT OSSAD#285) pour la description de la structure d'une organisation bureautique consiste en une classe de réseaux de Petri (RdP) appelés Réseaux d'Automates Superposés (SA-nets), et de l'interprétation associée à cette classe [SIM 88].

Un SA-net est un graphe bipartite, dont les nœuds sont des places et des transitions connectées par des arcs orientés. La restriction fondamentale apportée par cette classe de réseaux au formalisme générique des RdP est que chaque transition doit avoir le même nombre d'arcs entrants et sortants. Un SA-net peut être vu comme le résultat de la composition d'éléments de base, qui sont des machines à états non déterministes. L'ensemble des places qui appartiennent à ces éléments de base doivent être une partition de l'ensemble des places du réseau. Les SA-nets mettent à profit les résultats théoriques obtenus sur les RdP, aussi bien en ce qui concerne leur analyse statique que leur exécution. En particulier, chaque composant de base du SA-net doit avoir une et une seule place marquée pour tout marquage accessible du réseau.

Bien que les fondements théoriques du formalisme (Réseaux de Petri, machines à états) soient très formels, l'interprétation qu'il est nécessaire d'ajouter au diagramme est trop peu formalisée pour qu'on puisse espérer la prendre en compte complètement pour effectuer des analyses, des vérifications ou pour simuler un modèle. On peut

5

notamment regretter que le modèle de RdP utilisé ne soit pas un modèle de haut niveau (avec des jetons colorés ou typés), ce qui permettrait de tracer le flux des documents entre les intervenants d'une procédure. D'autre part, le fait de se limiter à des automates à états non déterministes pour décrire le comportement d'un rôle bureautique paraît très restrictive : l'activité d'un employé de bureau est fréquemment de nature non séquentielle, mettant en jeu du parallélisme de traitement et des synchronisations qui ne sont pas exprimables par des automates. Des versions plus récentes du formalisme se sont affranchies de cette limitation [DUM 90], [NUR 96].

2.4. Form Flow Model

L'unité principale de modélisation dans cette technique [LAD 80] est le formulaire. Les formulaires sont des données structurées, alors que les stations de travail sont des unités de traitement. Chaque station du modèle dispose d'un ensemble de trieurs d'entrée et de trieurs de sortie, où des formulaires sont déposés. La tâche d'une station est de prendre un formulaire dans un des trieurs d'entrée, de déterminer vers quel trieur de sortie ce formulaire doit être routé, d'effectuer une opération déterminée par le couple trieur d'entrée / trieur de sortie et enfin de déposer le formulaire dans le trieur de sortie sélectionné. Un Form Flow Model peut également être considéré comme un réseau de files d'attentes, afin d'analyser ses performances en termes de comportement en régime continu. Dans cette interprétation, chaque formulaire devient une tâche (job) et chaque station devient un serveur avec une seule file d'attente correspondant à l'ensemble de ses trieurs d'entrée.

Le formalisme dispose d'une représentation graphique simple et lisible. Au niveau théorique, le modèle est équivalent à un graphe dirigé de trieurs d'entrée, de trieurs de sortie et d'arcs de routage. Le caractère formel de la technique permet de profiter de techniques d'analyse, autorisant notamment l'énumération des routages possibles pour un document, ou la détection de cycles éventuels dans le graphe de routage. En annotant les arcs du modèle par leur fréquence d'utilisation et leur temps moyen de traitement, la fréquence et le temps moyen de traitement d'un routage donné peuvent être calculés.

Le Form Flow Model est puissant, descriptif et relativement bien formalisé. il semble toutefois mal adapté si on souhaite traiter des problèmes de synchronisation : on ne peut pas exprimer dans ce modèle le fait que plusieurs formulaires différents doivent être présents à la fois dans une station pour être traités ensemble, ni que le routage d'un formulaire peut dépendre de données présentes dans un autre formulaire.

2.5. Critères de comparaison

Nous nous sommes efforcés, en analysant les formalismes présentés au paragraphe 2, de dégager un ensemble de critères pertinents pour comparer les approches Sophtalk, FLO et Objets Coopératifs. Nous avons écarté certains critères que l’on rencontre fréquemment dans la littérature, tels que le temps d’apprentissage ou le coût de spécification, car nos trois formalismes sont issus de travaux de

6

recherche récents, et nous ne disposons pas encore de données d’évaluation qui ne peuvent être produites que par une utilisation « industrielle » de l’approche.

Cet effort se place dans la lignée d’autres travaux portant sur la comparaison d'approches de modélisation. [ABO 92] traite de la structuration des propriétés des systèmes interactifs. Les auteurs, toutefois, n’évaluent pas les formalismes qui pourraient être utilisés pour garantir ou vérifier de telles propriétés, au contraire du présent article. [BRU 95] propose également une étude comparative de formalismes de spécification. Cette démarche est proche de la nôtre, mais nous évaluons les formalismes dans la perspective spécifique de leur application au Workflow, alors que [BRU 95] les compare suivant des critères propres aux systèmes interactifs en général. Les critères pertinents pour ces deux points de vues sont donc différents.

Nous avons identifié un ensemble de critères qui nous paraît à la fois être

suffisamment complet et offrir des dimensions d’évaluation orthogonales : certains critères portent sur le pouvoir d’expression du formalisme (sa capacité à exprimer de manière concise et complète les aspects pertinents d’un problème) ; d’autres portent sur l’outillage théorique propre au formalisme (techniques d’analyse et de validation associées, capacité à raisonner sur les structures de causalité ou les aspects temporels d’un système) ; d’autres enfin sont relatifs aux possibilités de mise en œuvre du formalisme pour la réalisation de systèmes réels, et non pas seulement pour leur modélisation abstraite.

Les critères que nous avons retenus sont les suivants :

Critères liés au pouvoir d’expression

• Dimension structurelle : le formalisme offre-t-il des primitives permettant de structurer les modèles, par exemple en employant des techniques de décomposition hiérarchique ou de structuration par objets ? • Dimension dynamique : quels sont les concepts utilisés par le formalisme pour décrire le comportement du système ? Permet-il de décrire aisément les notions de concurrence, de synchronisation ?

Critères liés à l’outillage théorique

• Niveau de formalité : le formalisme est-il suffisamment bien défini pour permettre l'expression et la preuve de propriétés sur les spécifications ? • Aspects temporels : le formalisme se prête-t-il à une description du temps "quantitative" (dates et durées), ou qualitative (causalité, séquence d'événements) ? Le formalisme permet-il d'analyser ces aspects temporels, par exemple pour réaliser une prédiction de la performance globale du système ou du temps nécessaire à l'exécution d'une action complexe ?

Critères liés à la mise en œuvre du formalisme

• Exécutabilité : les spécifications ont-elles un caractère exécutable, de manière à permettre d'envisager le prototypage ? Le formalisme est-il de nature à être implémenté ? • Evolutivité du modèle : dans quelle mesure le formalisme facilite-t-il la modification incrémentale d’un modèle lorsque les spécifications du système

7

changent ? Quel est l’impact d’un tel changement sur l’architecture globale du système ? Le modèle peut-il être modifié dynamiquement pendant l’exécution ? • Protocole de communication : quel type de communication peut-on décrire entre deux composants actifs du système ? (par exemple synchrone/asynchrone, par diffusion ou dirigé, client/serveur, ...) • Architecture : à quel type d'architecture logicielle le formalisme se prête-t-il ? (répliquée, centralisée, hybride [KAR 94]) • Interface utilisateur : le formalisme permet-il de décrire l’interaction du système avec ses utilisateurs, par exemple en termes de sa représentation externe ou de la structure du dialogue homme-machine ?

3. Etude de cas

L’étude de cas que nous avons choisie est librement inspirée de celle connue dans la littérature sous le nom de « IFIP case ». Cette étude a servi de référentiel commun pour une conférence de l'IFIP [OLL 86], destinée à la comparaison de méthodes de conception de systèmes d’information et bien antérieure au concept même de Workflow. Cette étude, par son caractère asynchrone, distribué et coopératif se prête bien à une modélisation de type Workflow.

On considère une partie de l’organisation d’une conférence scientifique avec comité de lecture. Les aspects scientifiques de la conférence sont gérés par un comité de programme, dont le rôle est d’enregistrer les articles reçus, de distribuer ces articles aux membres du comité afin qu’ils soient évalués, de collecter les évaluations des lecteurs, de statuer sur le sort des articles en fonction des évaluations reçues et de transmettre les évaluations et le résultat final (acceptation ou refus de l’article) aux auteurs.

Les paragraphes suivants présentent un traitement de cette étude de cas par les formalismes Sophtalk, FLO et Objets Coopératifs.

3.1. Solution par Sophtalk

Le formalisme Sophtalk ([JAC 93], [JAC 93b]) permet de décrire l’intégration d’agents distribués communiquant de manière asynchrone. En effet, Sophtalk permet de modéliser les services offerts par les agents et leur activité en tant que clients d'autres agents en les encapsulant dans des interfaces de communication (que nous appelons nœuds) définies par un ensemble de ports d’entrée et un ensemble de ports de sortie (voir figure 1). Les ports d’entrée représentent des événements potentiels que l’agent pourra recevoir, et auxquels il devra réagir (services). Les ports de sortie représentent des événements que l’agent pourra émettre vers ses clients. La correspondance entre les ports d’entrée d’un nœud et le comportement de l’agent qu’il encapsule est réalisée par des fonctions d’entrée, qui décrivent la réaction de l’agent à la réception d’un événement donné. En revanche, l’émission d’un événement sur un port de sortie est décrite dans le code des fonctions d’entrée sous la forme de l’appel à une primitive d’envoi, st-emit.

8

ports d’entree

ports de sortieAgent

Figure 1. Encapsulation d’un agent

On fait coopérer des agents en les plongeant dans un même réseau. Automatiquement, les ports de même nom sont connectés sur un même bus logiciel, dans la lignée des outils d’intégration tels que SoftBench [CAG 89] ou ToolTalk [SUN 93], qui permettent d’encapsuler des agents dans des interfaces de communication. Cette approche permet la communication inter-processus au sein d'une architecture distribuée. Le générateur d’environnements de programmation Centaur [BOR 88] [JAC 92] est organisé suivant une architecture distribuée (interface homme-machine, serveurs syntaxiques et sémantiques) fondée sur la communication par événements de Sophtalk.

Les communications sont réalisées par diffusion asynchrone. Un agent ignore qui

lui a envoyé un événement donné, et lui-même émet vers l’environnement sans s’adresser à un agent particulier. De plus, deux événements émis dans un certain ordre peuvent arriver dans un ordre quelconque. Enfin, on peut structurer les réseaux de manière hiérarchique de façon à restreindre la diffusion à des sous-réseaux. Pour permettre des communications privées, il faut prévoir que pour un message diffusé sur le réseau, seuls écouteront les agents susceptibles d’attendre ce message et de réagir. Dans notre cas, nous disposons d’un paramètre supplémentaire identifiant le destinataire supposé du message. Les autres agents, qui recevront aussi le message, n’auront pas de réaction.

CPA

...

cfp

Res1 Res2

Figure 2. Configuration d'un réseau

La figure 2 illustre la configuration des réseaux, dans le cas simple où un agent

(un comité de programme CPA) émet un événement sur le bus cfp (un appel à communications) à destination de tous les chercheurs du domaine (Res1, Res2, ...). L’ajout d’un nouveau nœud dans le réseau (un nouveau chercheur dans le domaine), est réalisé automatiquement, par connexion au bus logiciel, sans perturbation des autres agents.

9

3.1.1. Aspects méthodologiques

Notre approche méthodologique de modélisation des applications Workflow avec Sophtalk consiste à identifier les agents ainsi que les événements significatifs dans le contrôle global de l’application.

Deux approches de modélisation sont possibles : • Avec une approche globale, on construit un réseau unique dans lequel chaque agent est connecté à l’ensemble des bus, même si les informations circulant sur ce bus ne le concernent pas ; par exemple, un auteur n’a pas à écouter les avis d’un lecteur sur un article. • Avec une approche structurée, on construit autant de sous-réseaux que d’interactions privilégiées entre les différents agents ; par exemple, en raison de l’anonymat des lecteurs, il n’existe pas d’interaction entre les lecteurs et les auteurs, ce qui peut être modélisé par le fait que lecteurs et auteurs appartiennent à des réseaux distincts.

Les avantages de cette deuxième approche sont nombreux. Tout d’abord, elle permet une conception incrémentale, par raffinements successifs. Il est plus facile de concevoir et de mettre au point des nœuds et des réseaux qui ne traitent qu’un aspect des interactions à la fois. De plus, elle n’interdit pas les émissions entre sous-réseaux distincts. L’encapsulation d’un même agent dans des nœuds de réseaux différents doit être vue non pas comme une perte d’identité mais comme l’éclairage d’une facette particulière de cet agent. En effet, toutes les fonctions d’entrée sont regroupées dans un même module qui décrit la classe de l’agent. Ce module peut en outre contenir des données partagées, ce qui permet de traiter des préconditions sur les réactions (par exemple, conjonction ou disjonction d’événements).

Enfin, le partage d’agents par des réseaux distincts, tout en facilitant la conception de l’application, n'a d'incidence ni sur sa complexité ni sur ses performances lors de la mise en œuvre.

3.1.2. Modélisation de l'étude

Le modèle Sophtalk de l'étude de cas comporte quatre classes d’agents : Comité_de_Programme, Horloge, Auteur et Lecteur. Parmi les événements significatifs, on peut citer la soumission d’un article, l’avis du comité de programme, le choix des articles à évaluer pour un lecteur, etc. Chaque événement sera matérialisé dans la suite par un bus logiciel. Pour l’application qui nous intéresse, on encapsule l’agent Comité_de_Programme dans 3 nœuds distincts, qui nous permettent de construire des sous-réseaux modélisant l’interaction du Comité_de_Programme avec Auteur, Lecteur et Horloge.

Chaque agent est encapsulé dans un nœud Sophtalk qui décrit son interface de communication (interactions possibles avec les autres agents). A chaque port d'entrée est associée une fonction d'entrée qui décrit l'action à la réception de cet événement. En particulier, le Comité_de_Programme, agent central de l'application, a des interactions avec des nœuds de la classe Horloge, la classe Auteur et la classe Lecteur. Dans la suite, nous décrivons chacune des interfaces (ports d'entrée et de sortie), puis nous montrons comment configurer un réseau Sophtalk pour modéliser l'application.

L'ensemble des nœuds identifiés, ainsi que leurs ports d'entrée-sortie, sont illustrés en figure 3.

10

Figure 3. Les nœuds de l'étude de cas

Agent Horloge

Le rôle de la classe Horloge est d'interagir avec le Comité_de_Programme, et à sa demande, pour lui rappeler les différentes dates limites. On définit une Horloge avec un port d'entrée (remind) et un port de sortie (alarm) (cf. figure 3).

Sur réception du message remind contenant une date et un sujet (date limite de soumission, de choix des articles et de retour des avis lecteurs), l'horloge émet un message d'alarme à la date donnée. Ce message est écouté par le Comité_de_Programme seulement.

Agent Auteur

L'Auteur interagit avec le Comité_de_Programme. Lors de la soumission d'un article, de la réception de l'accusé de réception, ou de l'avis sur l'article (émis par Horloge), le Comité_de_Programme émet un événement sur le port rappel, ce qui permet une diffusion globale sur le réseau gérant les interactions avec les lecteurs. (cf. figure 3). Un Auteur n'a pas d'interaction directe avec les autres agents (il ne communique ni avec Horloge, ni avec Lecteur).

Agent Lecteur

Un Lecteur interagit avec le Comité_de_Programme lors de l'identification des lecteurs (cf. figure 3). Le Lecteur doit ensuite choisir trois articles parmi tous ceux qui ont été soumis (port choix_article). A la date convenue, le Comité_de_Programme affecte les articles aux lecteurs (port affectation). Enfin, le Lecteur transmet ses avis pour chaque communication avec le message avis_article. Des messages de rappel sont émis par le Comité_de_Programme si les choix ou les avis ne sont pas arrivés dans les délais impartis.

Chaque Auteur et chaque Lecteur a un identifiant propre (par exemple son adresse électronique) qui sera utile dans la suite pour modéliser les communications privées entre Comité_de_Programme et Auteur.

Agent Comité_de_Programme

Cet agent interagit avec tous les agents décrits plus haut, et est encapsulé dans trois nœuds qui privilégient chacun une interaction particulière.

11

Configuration des réseaux

Suivant une approche modulaire, nous modélisons l'activité de tous les agents par trois réseaux distincts : • communication Comité_de_Programme - Horloge, • communication Comité_de_Programme - Auteurs, • communication Comité_de_Programme - Lecteurs.

CP

CPL

CPH

...

...

CPA

Aut1 Aut2

Lec1 Lec2

Horloge

net_cpl

net_cpa

net_cph

Figure 4. Modélisation de l'application

Avant de configurer un réseau, il faut d'abord créer les agents en instanciant les nœuds. Nous avons entièrement modélisé l'application en Sophtalk en définissant un réseau avec un Comité_de_Programme, deux Auteurs, deux Lecteurs, et une Horloge (des instances des classes correspondantes). Nous disposons d'un script qui décrit tout le processus de coopération entre les différents agents (figure 4).

3.1.3. Evolutivité du modèle

Un des intérêts majeurs de l’approche Sophtalk est de pouvoir, à moindre coût, modifier l’architecture du réseau global. Nous détaillons ici quelques exemples de modifications de l’application. • Ajout d’un nœud Lecteur: dès son inclusion dans le réseau, le nœud est automatiquement opérationnel (connecté aux bus). • Ajout d’une facette du Comité_de_Programme, (par exemple, l’organisation de la conférence (actes, réservations, etc.) nécessite l’ajout d’un nouveau sous-réseau décrivant les interactions entre le Comité_de_Programme et ses interlocuteurs pour l’organisation (éditeur, hôtels, etc.). • Ajout d’un bus Inscription: les nœuds encapsulant des agents susceptibles de s’inscrire à la conférence devront avoir un nouveau port de sortie ; le nœud encapsulant le Comité_de_Programme devra également avoir un nouveau port

12

d’entrée (ainsi qu’une fonction d’entrée traitant l’événement). Enfin, l’émission de l’événement Inscription devra être ajouté au code des agents concernés.

3.2. Solution par FLO

L’objectif du langage FLO (First-class Links between Objects, [DUC 93], [DUC 95]) est d’introduire explicitement dans un langage à objets des dépendances comportementales inter-objets au lieu de les exprimer par des valeurs actives, des accesseurs, des attributs ou des méthodes. Nous pensons que les communications inter-objets doivent être clairement exprimées, et que le code spécifique à leur gestion doit rester indépendant du code des objets. Il est en effet important de faciliter l’ajout ou le retrait dynamique de dépendances entre objets.

Smalltalk80 [GOL 83], [DUG 90] introduit la notion d’objets dépendants, paradigme particulièrement utilisé pour implémenter le modèle MVC (Model-View-Controller) [KRA 88]. Ainsi en Smalltalk, il est possible d’exprimer que l’exécution d’un message sur un objet implique l’exécution d’un autre message sur un objet dit dépendant. Cependant, à moins de vouloir réagir à un changement de valeur, ces mécanismes réactifs doivent être prévus au niveau des classes et le concept d’entité « dépendance » n’est pas inclus dans ce modèle. Les systèmes de maintien de cohérence à base de contraintes expriment quant à eux des dépendances en termes de contraintes sur des variables. Lorsque la valeur d’une variable contrainte est modifiée, un algorithme de propagation de contraintes se charge de rétablir la cohérence du système en modifiant les valeurs d’autres variables. La programmation par contraintes implique ainsi une connaissance de la structure des objets, ce qui va à l’encontre des principes de l’encapsulation et donc de l’évolutivité des applications. Or, toutes les dépendances ne s’expriment pas naturellement en terme de modifications de valeurs d’attributs, en particulier dans le cadre des interfaces graphiques.

FLO permet de décrire les dépendances dans des classes d’objets et de maintenir la cohérence inter-objets en contrôlant l’envoi de message. L’interactivité est décrite en terme de réactions automatiques aux messages et de conditions sur les comportements des objets. L’idée force de cette approche est d’imposer une expression plus claire de la structure des communications inter-objets et de permettre au code nécessaire à leur gestion de rester indépendant du code des objets eux-mêmes.

FLO a été utilisé pour exprimer les contrôleurs PAC [FOR 94]. Sa sémantique est décrite en sémantique naturelle dans l’environnement Centaur [BOR 88] afin de déterminer des propriétés telles que la reconnaissance de cycles et la terminaison à partir des descriptions FLO.

3.2.1. Aspects méthodologiques

L’utilisation de FLO dans le cadre du Workflow s’avère appropriée pour décrire la collaboration entre les participants en terme de dépendances appelées dans la suite gestionnaires de dialogue. Ces gestionnaires unissent les objets qui collaborent. Ils n’existent que pendant la durée du dialogue et ont pour but de modifier momentanément le comportement des participants en réagissant à l’exécution de certaines tâches (décrites par les méthodes des classes) ou en les interdisant.

13

3.2.2. Modélisation de l’étude

Dans la modélisation FLO de l’étude de cas, trois sortes de participants ont des rôles spécifiques : Auteur, Comité de programme et Lecteur. Chaque rôle est décrit par une classe dont les méthodes modélisent les services offerts par ce type de participant. Le modèle se compose de trois classes : Auteur, Lecteur et Comite_de_programme. Les méthodes de ces classes portent le même nom que les ports d'entrée des agents Sophtalk correspondant. Nous ne détaillons pas ce point dans cette partie afin de focaliser la présentation de FLO plutôt sur la coopération entre participants.

En mettant l’accent sur la coopération dans la modélisation FLO, les données partagées par les participants tels que l’Article et les Avis n’apparaissent pas en terme d’entité ou d’agent. Elles sont uniquement référencées (références uniques : adresses ou numéros) par les différents protagonistes. L’étude de cas est centrée en fait sur deux types de collaboration : celle entre un auteur et un comité de programme et celle entre un lecteur et un comité de programme.

Interaction Auteur - Comité_de_Programme

Lorsqu’un auteur soumet un article à un comité de programme, il entre alors dans une phase de dialogue avec le comité de programme. Une instance du gestionnaire de dialogue, décrit en figure 5, contrôle alors ce dialogue. Une instance du gestionnaire est créée dynamiquement pour chaque auteur X qui soumet à un comité de programme Y. Détaillons les principales réactions aux tâches du comité de programme, décrites dans le gestionnaire Auteur_CP de la figure 5.

Lorsque le comité de programme reçoit une soumission (cf. (c) figure 5 et figure 6), il effectue la tâche correspondante (enregistrement de la soumission, association d’un numéro, choix des lecteurs) puis le gestionnaire se charge d’émettre un message qui en accuse réception à l’auteur. Lorsque le comité de programme a pris la décision finale quant à l’acceptation ou au rejet des différents articles soumis, en réaction, chaque auteur est prévenu de l’avis par un message décision précisant le mot de passe et l’adresse où il pourra consulter les avis des lecteurs qui lui sont destinés (cf. (d) figure 5 et figure 6). Auteur_CP( Auteur, CP)%Informations propres au dialogue (a)

(numero, password, adresse)%Informations héritées par l’auteur (b)

adresse(Auteur) = adresse,numero-com(Auteur) = numero,password(Auteur) = password

Controle% Contrôle sur le comportement des objets (c)

soumission(CP, id-auteur, titre, auteurs, resume, motcles, ps)-->numero = Resaccuse-reception(Auteur, CP, Res)% Res désigne le résultat de la soumission

% (d)decision-finale(CP, Formulaire) -->

password = password(CP, numero, Auteur),adresse = adresse_avis(CP, Auteur),decision(Auteur, CP)

Figure 5. Définition d’un gestionnaire Auteur_CP

14

Une telle collaboration génère de nouvelles données (un numéro d’enregistrement, un mot de passe et une adresse) qui ont comme durée de vie le temps accordé au dialogue. Ces données (cf. (a) figure 5 et figure 6 sont donc naturellement stockées au niveau de chaque instance de gestionnaire du dialogue Auteur_CP et accessibles directement par l’auteur le temps du dialogue (cf. (b) figure 5). Le gestionnaire de dialogue a alors la charge de capturer certains messages adressés à l’auteur ou au comité de programme, afin soit de déclencher les réactions décrites en (c) et (d) figure 5, soit de déterminer les comportements effectifs correspondants (b).

Auteur

Auteur_CP numéro adresse password (a)

(c) (d)Comité de Programme

Décision

Soumission Décision-finale

Accusé-réceptionEnvoi de message

Envoi de messagedéclenché parAuteur_CP

Garde

Participant

Gestionnaire

Figure 6. Gestion du dialogue entre Auteur et Comité: Auteur_CP

Interaction Lecteur - Comité_de_Programme

On peut modéliser de deux façons différentes la collaboration entre lecteur et comité de programme : une collaboration individuelle ou une collaboration de groupe. La première permet de décrire le dialogue du comité de programme avec chacun des lecteurs tandis que la seconde, reliant le comité de programme à un ensemble de lecteurs, privilégie l’unité du comité de lecture. En particulier, un tel gestionnaire pourrait aider à la collaboration d’un groupe de lecteurs pour accorder le statut final aux articles litigieux. Dans ces deux modélisations, le dialogue s’installe entre un lecteur et le comité de programme dès que ce dernier décide de la composition du comité de lecture. Il y a alors création soit d’un ensemble de gestionnaires Lecteur_CP, soit d’un seul gestionnaire Lecteur_CPs qui joue le rôle de coordonateur entre les différents lecteurs.

L’étude de cas est limitée, aussi nous ne présentons pas le traitement des articles en litige et nous donnons seulement quelques caractéristiques du gestionnaire Lecteur_CP (figure 7), dont le comportement est schématisé en figure 8.

15

Lecteur_CP( Lecteur, CP)%Informations propres au dialogue (a)

(avis, liste_numéros)%Informations héritées par le comité de programme (b)

réception_avis(CP,numéro_com,note,confiance,....) = ....code....Controle% Contrôle sur le comportement des objets (c)

valide_liste_communications(Lecteur, liste_numéros,CP) /choix(CP, id_lecteur, liste_numéros)-->

acceptation(Lecteur)alarm(CP,‘deadline_avis’) -->

... rappel(Lecteur, ‘deadline_avis’)

Figure 7. Définition d’un gestionnaire Lecteur_CP

On peut distinguer plusieurs phases de dialogue : le choix par le lecteur d’un ou

de plusieurs articles à évaluer à partir d’une liste communiquée par le comité, la réception des avis par le comité et l’éventuel rappel du comité pour obtenir les avis.

L'envoi du message Choix (cf (c) figure 8) par un lecteur au comité de programme, signale la liste des articles choisis par le lecteur. La réception de ce message entraîne automatiquement un accusé de réception (acceptation des choix) seulement si le lecteur n'est pas un des auteurs des articles choisis. L'action relative à Choix et sa réaction sont conditionnées par une garde dans FLO.

La notion d'avis existe uniquement de par la collaboration entre des lecteurs et un

comité de programme. Aussi nous avons choisi de la représenter par une donnée du gestionnaire ainsi que la méthode reception-avis qui se charge de collecter chaque avis. Le message reception-avis peut être reçu le temps de la collaboration par le comité de programme (cf (b) figure 7).

Lorsque la date limite de réception des avis est atteinte, le comité de programme reçoit d'une horloge un message alarm de fin de réception des avis. Si tous les avis ne sont pas arrives, un message rappel est adressé au lecteur.

Lorsqu’un lecteur communique ses choix au comité de programme, ceux-ci ne

sont acceptés que si le lecteur n’est pas l’auteur de l’article choisi (cf. (a) figure 8). La décision (acceptation ou refus) est dans ce cas conditionnée.

Lecteur

Lecteur_CP avis réception-avis

(a)

(c)

(b)

Comité de Programme

rappel

choixréception-avis

acceptationEnvoi de message

Envoi de messagedéclenché parLecteur_CP

Garde

Participant

Gestionnaire

alarm Figure 8. Gestion du dialogue par le gestionnaire Lecteur_CP

16

3.2.3. Evolutivité du modèle

Examinons plusieurs aspects dynamiques de cette étude de cas : l’instauration de nouveaux gestionnaires de dialogue, l’ordonnancement des actions de dialogue, et un contrôle des collaborations inter-participants.

Supposons que, au moment où le comité de programme envoie la décision finale à l’auteur, on veuille en informer également le lecteur. Pour prendre en compte cet aspect du dialogue, il suffit d’ajouter au niveau de la collaboration entre le comité de programme et le lecteur une réaction au message decision_finale. Ceci peut être effectué soit en modifiant le gestionnaire Lecteur_CP, soit en créant une sous-classe de ce gestionnaire qui définisse cette nouvelle réaction. La distinction entre la tâche «effectuer la décision finale» et les effets de bord concernant le dialogue (informer l’auteur et les lecteurs) est doublement importante. Elle permet bien sûr d’isoler les points de collaboration entre les participants mais aussi d’ajouter facilement de nouveaux gestionnaires de dialogue vers d’autres participants sans avoir à changer les tâches de ces derniers. La gestion des réactions multiples (mettre à jour les avis ou informer l’auteur) à un message (avis) repose sur un algorithme de propagation paramétré et donc redéfinissable en FLO. A priori, il ne faut rien supposer au niveau formel sur l’ordre dans lequel s’effectuent ces dialogues. L’implémentation actuelle de FLO est synchrone ; toutes les réactions sont déclenchées en séquence. Dans cette modélisation, le rôle d’auteur et celui de lecteur sont distincts. Les gestionnaires de dialogue étant eux-mêmes des objets, on peut exprimer simplement l’exclusion ou la simultanéité entre gestionnaires. On pourrait donc exprimer qu’un lecteur ne peut pas être également auteur d’une soumission en modélisant une relation d’exclusion (cf. figure 9) entre les gestionnaires Auteur_CP et Lecteur_CP.

De tels gestionnaires permettent d’interdire automatiquement la mise en place de

certaines collaborations entre participants ou au contraire de favoriser la création automatique de certains dialogues par déduction. Ils sont décrits par des réactions portant sur la création de gestionnaires et sur les mécanismes de déclenchement des réactions, faisant ainsi usage de l'aspect méta-descriptif de FLO. exclusion(GD1, GD2)% On ne peut pas créer un gestionnaire GD1 entre O1 et O2 si% il existe déjà un gestionnaire GD2 entre O1 et O2not (exist-Link(GD2, 01, O2) |

create(GD1, O1, O2)

% Déclaration d’exclusion entre les% gestionnaires Auteur_CP et Lecteur_CPexclusion(Auteur_CP, Lecteur_CP)

Figure 9. Définition de l’exclusion en FLO

Pour accepter qu’un auteur puisse être également lecteur, il suffirait d’identifier le rôle Auteur-Lecteur par la définition d’une nouvelle classe décrivant à la fois les tâches d’un Auteur et celles d’un Lecteur. Ainsi, un Auteur-Lecteur pourra dynamiquement collaborer de façon différente avec le comité de programme selon le gestionnaire de dialogue qui les unira.

17

3.3. Solution par les Objets Coopératifs

Le formalisme des Objets Coopératifs (OC) est un formalisme générique dédié à la modélisation des systèmes concurrents [BAS 89], [BAS 92]. La caractéristique principale des Objets Coopératifs réside dans le fait que le comportement des objets et leur coopération sont modélisés dans le cadre de la théorie des Réseaux de Petri (RdP) de haut niveau.

L’objectif des Objets Coopératifs est de permettre d’employer efficacement les concepts des langages à objets dans le domaine des systèmes concurrents et distribués. On souhaite notamment disposer d’une notation concise, complète et non ambiguë permettant de décrire les aspects concurrents de systèmes complexes, de telle sorte qu’il soit facile d’exprimer la concurrence aussi bien entre les objets qu’à l’intérieur même des objets. La modélisation de la concurrence est prise en compte dans le formalisme par l’utilisation des réseaux de Petri de haut niveau. La spécification d’une classe d’objets coopératifs contient son interface (c’est-à-dire la signature des méthodes qu’elle offre) et son comportement. Ce comportement est décrit par un ObCS (Object Control Structure) qui définit la structure de contrôle interne des instances de la classe. Les ObCS sont décrits par des réseaux de Petri, et permettent de décrire la disponibilité des services en fonction de l'état interne de l'objet, et les changements d’état produits par l'exécution des services.

Bien entendu, même dans un système distribué, les aspects purement séquentiels et algorithmiques conservent une très grande importance. Les OC ne cherchent pas à se substituer aux langages à objets classiques pour décrire ces aspects. Au contraire, les OC peuvent être considérés comme un langage hôte pour un langage à objets tel que Eiffel, C++ ou Java. L’implémentation actuelle des OC est faite en C++, et la suite de cette section utilisera les notations propres à ce langage. L’intégration entre OC et C++ est réalisée de la manière suivante :

Les ObCS sont décrits par des réseaux de Petri (RdP) de haut niveau, ce qui signifie que les jetons peuvent être porteurs d’information, au lieu d’être des entités sans dimension comme dans les RdP classiques. Dans les OC, la valeur des jetons est un n-uplet de valeurs typées, ces valeurs pouvant représenter : • N’importe quel type du langage C++ (type natif, instance de classe ou pointeur polymorphe) ; • Une référence vers un autre OC du système.

De même, les transitions du réseau contiennent une partie précondition et une

partie action, qui peuvent manipuler les jetons impliqués dans le franchissement. L’action d’une transition peut dès lors être de deux sortes : • Un bloc de code C++, qui s’exécute séquentiellement et en exclusion mutuelle avec les autres transitions de l’ObCS. Ce bloc de code peut manipuler les objets C++ impliqués dans le franchissement, appeler leurs méthodes, créer dynamiquement de nouveaux objets C++, etc. Ceci permet une intégration facile des OC avec des bibliothèques de classes existantes, et assure leur interopérabilité avec des approches plus traditionnelles. Nous décrivons par exemple dans [BAS 95] la manière d’intégrer les OC dans un environnement de type User Interface Management System (UIMS). • Une invocation entre objets coopératifs, qui s’exécute de manière concurrente et non bloquante pour le client et le serveur de l’appel. Lors d’une invocation entre

18

objets coopératifs, la sémantique de la communication entre objets est décrite en restant dans le cadre de la théorie des réseaux de Petri, ce qui permet de caractériser formellement le comportement d'un système d'objets qui communiquent, le comportement de chacun des objets du système étant lui-même décrit par son ObCS.

3.3.1. Aspects méthodologiques

Dans le cadre de cette étude, nous avons structuré l'utilisation des Objets Coopératifs autour d’un principe directeur : la modélisation d'un document comme une entité active. L'intelligence des documents est exprimée en les considérant comme des objets actifs, qui font appel aux utilisateurs comme des ressources nécessaires à l'accomplissement de leur tâche. Le but poursuivi par un document est de parvenir à faire remplir ses différents champs par différents acteurs de l’application coopérative.

Les Objets Coopératifs communiquent par invocation de services, suivant un protocole de type client/serveur. Dans notre optique de modélisation, les documents sont essentiellement des clients : ils réclament des services à leur environnement, et obtiennent en retour la valeur de leurs attributs.

L'activité d'un document en tant que serveur est beaucoup plus limitée : elle se limite la plupart du temps à offrir à son environnement la consultation de ses attributs publics.

Dans la plupart des domaines d'application où les Objets Coopératifs ont été utilisés (temps réel [BAS 89], productique, interface homme/machine [PAL 95a]) les objets que l'on rencontre ont fréquemment une activité cyclique, qui se traduit par la présence de composantes répétitives dans leur ObCS. Dans le domaine du Workflow, au contraire, on souhaite que les procédures administratives se terminent effectivement. Il est donc nécessaire de mettre en évidence dans les ObCS des objets un marquage particulier qui permet de spécifier simplement quand le cycle de vie de l'objet s'est achevé. Nous avons introduit à cette fin la notion de place de terminaison, représentée graphiquement par un cercle grisé. Par convention, l'activité du document s'achève lorsqu'une place de ce type reçoit un jeton. Plusieurs terminaisons sont en général possibles pour le cycle de vie d’un document. L’activité du document démarrera donc par la transition d'instanciation, représentée graphiquement par la transition Create initialement franchissable, et se terminera par le marquage d’une place de terminaison.

3.3.2. Modélisation de l’étude

La solution par les Objets Coopératifs est centrée sur la description des articles. La classe Article décrit de manière détaillée le cycle des vie des articles soumis à la conférence. Ce sont les instances de la classe Article qui vont gérer l’essentiel de la dynamique du système, en interagissant avec les auteurs, les lecteurs et le comité de programme. Les aspects temporels sont pris en compte par la description d’une classe Horloge. [SIB 91] propose une autre solution à la même étude, plus orientée sur les aspects organisationnels.

La classe Horloge

La modélisation par Objets Coopératifs de la classe Horloge est très proche de la spécification Sophtalk donnée en 0. On constate seulement que le port d’entrée

19

Rappel est représenté comme un service offert par l’objet, alors que le port de sortie Alarme est représenté comme une transition d’invocation, c’est-à-dire une transition dont l’action est l’appel d’une méthode pour un objet associé à une de ses variables d’entrée. Il est nécessaire de faire figurer dans les paramètres du service Rappel l’identité de l’objet qui invoque ce service, afin que l’objet Horloge puisse disposer de cette information pour rappeler son client après le délai demandé.

La classe décrite en figure 10 illustre également la syntaxe des arcs temporisés : un jeton déposé dans la place Dates n’est disponible pour le franchissement de la transition en sortie qu’après l’expiration du laps de temps indiqué par le paramètre [délai].

class HorlogeServicesRappel <ClockClient client, int délai, string sujet>;ObCS

Rappel Dates

<client, délai, sujet>

<client, délai, sujet>

client.Alarme(sujet)

<client, délai, sujet>

[délai]

Figure 10. La classe d’Objet Coopératif Horloge

La classe Article

La classe Article représente l’essentiel de la modélisation par OC de l’étude de cas. L’ObCS décrit en figure 11 permet d’illustrer certaines conventions syntaxiques, introduites pour faciliter la description des applications de type Workflow. • Places attributs : l'état d’un objet coopératif à un instant donné est décrit uniquement par le marquage de son ObCS à cet instant. Ceci contraste avec la majorité des langages à objets, où l’état d’un objet est donné par la valeur de ses attributs et par la valeur des variables locales aux méthodes en cours d’exécution. Lorsqu’on modélise par OC, on se rend compte que certaines places des ObCS jouent le rôle d’attributs, en ce sens qu’une fois renseignée, leur valeur est conservée, tout en étant accédée ou modifiée par de nombreuses transitions. Pour faciliter leur représentation graphique, on ne représente pour ces places que le moment où la valeur de l’attribut est initialement renseignée, par un arc en provenance d’une transition. On s’abstient ensuite de connecter ces places par des arcs d’entrée-sortie à toutes les transitions qui utilisent leur valeur. En figure 11, les places Auteur, Titre, Conf, Texte, L1, L2, L3, et Avis_final sont des places-attributs, qui modélisent en fait les variables d’instances de l’OC Article. • Arcs de vidage : il est fréquemment nécessaire d’effectuer un traitement sur tous les jetons contenus dans une place, quel que soit leur nombre. C’est le cas dans cet exemple quand, à l’approche de la date limite de réception des avis, on doit rappeler

20

à l’ordre tous les lecteurs n’ayant pas encore remis leur évaluation de l’article (Transition T5). [PAL 92] décrit en détail une construction permettant de modéliser ceci par réseau de Petri, sous la forme d’une macro. Graphiquement, cette macro est représentée par un arc à flèche double, comme celui qui relie la place Attente_Avis à la transition T6.

class ArticleServicesCreate <Personne auteur, string titre, Conference conf>;Alarme <string sujet>;Avis <Lecteur lecteur, string avis>;Rappel <ClockClient client, int délai, string sujet>;ObCS

Create

<auteur, titre, conf>

Auteur

Conf

Titre

Horloge.alarme(this, conf.Limite_réception, "Limite_réception"); Horloge.alarme(this, conf.Limite_avis - 5, "Rappel_avis"); Horloge.alarme(this, conf.Limite_avis, "Limite_avis")

texte = Auteur.Redige()

<sujet>

sujet == "Limite_réception"

Alarme

Texte

<L1, L2, L3> = Conf.Comité.Reçoit(Texte);

Attente avis

L1

L3

L2sujet ==

"Rappel_Avis"

Alarme Lecteur.Relance(this)

<sujet>

<sujet>

Alarme

sujet == "Limite_Avis"

Avis

Avis

Avis_final = Conf.Comité.Avis(A1, A2, A3);Avis_final

Trop tard

Terminé

<L1>, <L2>, <L3>

<lecteur, avis><lecteur>

<lecteur>

<avis>

<a1, a2, a3>

"Pas d'avis"

T1

T2

T3

T4

T5

T6

T7

T8

T9

Figure 11. La classe d'Objet Coopératif "Article"

Un Article reçoit à sa création l'identité de son auteur, la conférence à laquelle il est destiné et son titre (transition T1). Il utilise ensuite une instance de la classe Horloge pour positionner les délais d'alarme qui lui sont nécessaires (transition T2).

21

Il réclame ensuite à l'Auteur la rédaction du texte, en se plaçant en position de client de celui-ci (transition T3). Si le texte arrive dans les délais, l'article se transmet lui-même au Comité_de_Programme (transition T5), et reçoit en retour l'identité de ses lecteurs. L'article gère ensuite l'interaction avec les lecteurs, en les rappelant à l'ordre à l'approche de la date limite (transition T6) et en recueillant leurs avis (transition T7). Il faut noter la possibilité qu'un ou plusieurs lecteurs ne fournissent pas leur avis dans les temps, ce qui est signalé par la valeur spéciale "pas d'avis". L'avis final sur l'article est fourni par le comité de programme en fonction des avis des lecteurs (transition T9).

3.3.3. Evolutivité du modèle

En contrepartie de son caractère formel et des possibilités d'analyse qu'il offre, le formalisme des Objets Coopératifs se montre certainement plus rigide que les approches Sophtalk et FLO. Il est par exemple exclu de pouvoir modifier dynamiquement le comportement d'une classe ou d'une instance à l'exécution, sauf à se priver de toute possibilité de validation du système.

Cependant le formalisme hérite des avantages classiques de l'approche objet, et notamment du polymorphisme : il est facile de dériver une nouvelle classe d'OC, qui modifie ou étend le comportement de sa classe parent. L'analyse des ObCS permettra alors de vérifier la compatibilité des comportements des deux classes vis à vis de la hiérarchie d'héritage.

4. Comparaison des approches

Dans cette partie, nous établissons une synthèse et une comparaison des trois formalismes : Sophtalk, FLO et les Objets Coopératifs à partir des critères donnés au paragraphe 2.5.

Indépendamment de ces critères, un premier point important se dégage de

l’exploitation de ces formalismes sur cette étude de cas : la différence de méthodologie adoptée face au problème à formaliser. • La méthodologie Sophtalk repose essentiellement sur la description du comportement propre à chaque agent relativement aux événements significatifs dans le contrôle global du problème à formaliser. Un soin particulier est aussi porté au choix de la configuration des réseaux décrivant la globalité du problème ou des sous-problèmes. • La méthodologie de modélisation en FLO consiste à isoler les phases de collaboration entre participants et à les exprimer en terme de gestionnaire de dialogue. Une instance d’un gestionnaire de dialogue est définie pour la durée d’une phase de dialogue. Aussi, elle contient naturellement les données qui ont une durée de vie relative au dialogue décrit et se charge de transmettre aux participants de nouveaux comportements le temps du dialogue. • Les OC mettent plutôt l’accent sur la description d’entités actives en accordant de l’intelligence aux documents qui circulent dans le système. Cette approche permet de centraliser la description de la dynamique de l'application dans un petit nombre d'entités actives.

22

Le fait que les méthodologies FLO et OC soient diamétralement opposées semble être une conséquence de la spécificité de chacun de ces formalismes. Lorsque la modélisation peut être centrée sur la collaboration comme en FLO de par la puissance d’expression des gestionnaires de dialogue, les données partagées (article et avis) sont cantonnées à un rôle passif. Par contre si l’effort de formalisation porte sur la description des objets comme dans les OC, il est effectivement naturel de leur accorder plus d’autonomie dans la description du problème. Sophtalk, qui met plutôt l’accent sur la description des événements en entrée et sortie, pourrait être utilisé en suivant l’une ou l’autre de ces méthodologies.

Reprenons pour chacun des formalismes les critères de comparaison qu’ils prennent en considération. Ces informations sont également synthétisées en figure 12, qui illustre pour chacun des formalismes la façon dont ils sont pris en compte.

4.1. Prise en compte des critères en Sophtalk

• Dimension structurelle : la dimension structurelle de Sophtalk repose sur une structuration par objets, dans laquelle on décrit pour chaque objet à la fois des aspects service (événements reçus) et client (événements envoyés). • Dimension dynamique : conforme aux modèles à objets : création d’objets, ajouts d’objets à un réseau. La concurrence est inhérente au formalisme, en revanche les synchronisations doivent être décrites explicitement. • Niveau de formalité : avant tout langage de programmation, Sophtalk ne permet pour l’instant aucune vérification sur les cycles éventuels dans les émissions d’événements par exemple. Il est difficile dans une classe associée à un agent, de discerner le code décrivant la tâche propre de l’agent du code décrivant les communications entre agents. En particulier, la réactivité réception - émission est noyée dans le code Le_Lisp des fonctions d’entrée. Une intégration des caractéristiques de FLO à Sophtalk pourrait pallier ce problème. • Aspects temporels : Sophtalk n’intègre pas d’aspects temporels quantitatifs (dates ou durées). Il n’est fait aucune hypothèse sur le temps nécessaire à l’exécution d’une action complexe. • Exécutabilité : basée sur Le_Lisp, une description Sophtalk peut être interprétée et compilée. L’encapsulation des agents permet d’obtenir un mécanisme d’intégration indépendant du langage hôte de chaque agent. Le système Sophtalk fournit des outils de trace des événements sur le réseau, en espionnant les messages, sans altérer le comportement du réseau. • Evolutivité du modèle : les modifications sont facilement réalisables, certaines de manière dynamique (ajout d’un nœud ou d’un sous-réseau). • Protocole de communication : en Sophtalk, les agents sont distants et la communication est réalisée par diffusion asynchrone. • Architecture : distribuée ou répliquée ; les agents sont encapsulés par des nœuds (éventuellement distants) et la cohérence des données est assurée par envoi de messages. • Interface utilisateur : Sophtalk a déjà été utilisé pour décrire les aspects contrôle des interfaces utilisateur dans le cadre du système Centaur.

23

4.2. Prise en compte des critères en FLO

• Dimension structurelle : la dimension structurelle de FLO est la dimension structurelle des langages à objets dans lesquels on a ajouté une dimension supplémentaire : l’expression de dépendances inter-objets. Ces dépendances, spécifiées dans les gestionnaires de dialogue, sont des objets indépendants qui permettent de déclencher automatiquement des dialogues entre participants en réaction à une tâche d’un des participants. Les tâches des participants ne sont jamais altérées par une collaboration. Un gestionnaire de dialogue décrit une collaboration qui peut être instaurée entre différents participants et les participants peuvent intervenir dans des phases différentes de collaboration sans subir de modifications. De plus le mécanisme d’héritage entre gestionnaires permet de facilement spécialiser certaines collaborations. • Dimension dynamique : La dynamique de la collaboration entre objets (participants) est prise en charge au niveau des gestionnaires de dialogue qui automatisent la réactivité et l'interdiction des messages • Niveau de formalité : une définition de la sémantique naturelle, en Centaur, d’une partie de ce formalisme (réaction) permet déjà de faire une analyse des éventuels cycles dans les enchaînements du dialogue. Cette partie de l’environnement FLO profite de travaux tels que ceux présentés dans cet article qui nous permettent de faire évoluer le formalisme et l’environnement de travail (outils de simulation, de déverminage, de vérification). • Aspects temporels : la signification par défaut de l’opérateur « –> » est la séquentialité : la tâche est réalisée puis une action de dialogue est déclenchée. Pour certaines modélisations, nous avons déjà introduit l’opérateur « <– » qui permet de débuter par le dialogue et ensuite de traiter la tâche. Nous envisageons également d’intégrer l’opérateur « // » lorsque la réaction de dialogue ne dépend pas du résultat de la tâche et pourrait être déclenchée en parallèle. • Exécutabilité : le passage en FLO entre une modélisation et un prototypage est immédiate puisque FLO est avant tout un langage de programmation implémenté en CLOS. De par l’implémentation actuelle, l’application reste un prototype. • Evolutivité du modèle : cette dimension est illustrée dans la partie 0. En plus de la dynamique inhérente aux langages à objets, l’évolution est en particulier facilitée par le fait que FLO est totalement réflexif et donc extensible. Il permet de définir de nouveaux opérateurs lorsque nécessaire. Une modélisation FLO du dialogue peut sembler trop rigide de par les définitions strictes des dialogues. Cependant la facilité de création et de définition des gestionnaires permet d’offrir si nécessaire une palette de gestionnaires correspondant à des nuances dans le dialogue et de créer la bonne instance de gestionnaire selon les besoins. • Protocole de communication : la communication est synchrone. L’ordonnancement du dialogue peut être plus précis en ajoutant des automates comme données locales d’un gestionnaire de sorte que les réactions dépendent de l’état de l’automate. Dans l’implémentation actuelle, les objets ne sont pas distants. • Architecture : une classe correspond à chaque participant et les gestionnaires de dialogue gèrent la cohérence des données et la coopération inter-participants.

24

• Interface utilisateur : FLO a déjà été utilisé pour décrire les interactions entre une application et son interface graphique. Cet aspect peut être exploité pour formaliser une partie des aspects interfaces d’une application coopérative.

4.3. Prise en compte des critères dans les Objets Coopératifs

• Dimension structurelle : comme Sophtalk et FLO, les Objets Coopératifs s'appuient sur les concepts structurant des langages à objets classiques. La notion d'héritage est étendue au comportement des objets, et on peut vérifier qu'une classe est une spécialisation correcte d'une autre par analyse de leurs ObCS. • Dimension dynamique : les réseaux de Petri sont particulièrement bien adaptés à la modélisation de comportements dynamiques complexes. Parallélisme et synchronisation s'expriment de manière naturelle dans les ObCS. • Niveau de formalité : la plupart des résultats d'analyse disponibles pour les réseaux de Petri sont conservés par les Objets Coopératifs. On peut notamment vérifier des propriétés de vivacité, et le caractère borné des ObCS. • Aspects temporels : les réseaux de Petri ont été conçus initialement pour décrire les structures de causalité dans l’évolution temporelle des systèmes. Ils ont été étendus pour prendre en compte des aspects temporels « quantitatifs » et on peut analyser la performance d’un système décrit par réseaux de Petri temporisés. • Exécutabilité : les Objets Coopératifs sont exécutables, par interprétation de leur ObCS. Un interprète distribué utilisant la technologie CORBA [OMG 91] est en cours de construction. • Evolutivité du modèle : un des avantages de l’approche Objet est de produire des composants fortement cohérents et faiblement couplés, ce qui minimise l’impact des changements de spécifications sur l’architecture du système. Les Objets Coopératifs conservent ces caractéristiques, mais ne permettent pas de changer dynamiquement la structure du système ou d’introduire de nouvelle classes pendant l’exécution. Bien entendu, le nombre des instances et la structure des relations qu’elles entretiennent peuvent évoluer dynamiquement, par le jeu de l’instanciation dynamique et de l’échange de références entre objets. • Protocole de communication : la communication entre objets est asynchrone, de type client-serveur. Certaines variantes, comme l'envoi de message unidirectionnel, sont disponibles, mais le formalisme n'inclut pas de primitives de diffusion. • Architecture : les Objets Coopératifs se prêtent à une architecture distribuée, ou des objets distants coopèrent. • Interface utilisateur : les Objets Coopératifs ont été étendus pour permettre la modélisation d'interfaces dirigées par événements, sous le nom de Interactive Cooperative Objects (ICO) [PAL 95a].

4.4. Tableau récapitulatif

La figure 12 synthétise le niveau de prise en compte par nos formalismes des critères énoncés en 2.5.

Les trois formalismes présentés ont en commun leur dimension structurelle qui repose sur la structuration par objets et leur exécutabilité, car ils peuvent être vus

25

comme des langages de programmation. Cependant leur philosophie est différente : Sophtalk met l’accent sur la formalisation des interfaces des agents, FLO sur celle de la communication inter-agents et les Objets Coopératifs sur le comportement de chaque agent.

Cette section a présenté la position de trois formalismes à objets par rapport à un

ensemble de critères déterminés au moyen d'une étude détaillée. Ce travail peut être mis à profit pour évaluer l'adéquation d'une autre notation par rapport aux caractéristiques de ce type d’applications. Les trois formalismes qui ont été étudiés peuvent servir de points de référence pour des recherches portant aussi bien sur la comparaison de formalismes existants que sur la mise au point de nouveaux formalismes.

Sophtalk FLO Objets

Coopératifs Dimension Structurelle

Par objets et hiérarchique

Par objets et hiérarchique

Par objets et hiérarchique

Dimension Dynamique

Décrite dans le code des méthodes

Décrite dans les gestionnaires de dialogue

Réseau de Petri communicants

Niveau de formalité

Langage de programmation

Détection de propriétés (pour les réactions)

Mathématique, nombreux résultats d’analyse.

Aspects temporels Qualitatif Qualitatif Quantitatif et qualitatif

Exécutabilité Prototypage, outils de mise au point

Prototype Par interprétation des réseaux

Evolutivité du modèle

Importante Extensibilité de FLO

Impossible pendant l’exécution

Protocole de Communication

Asynchrone par diffusion

Synchrone Asynchrone, client/serveur

Architecture Distribuée ou répliquée

Réseau d'objets et de gestionnaires de dialogue

Distribuée, non répliquée

Interface Utilisateur

Utilisé pour la modélisation du contrôle

Prise en compte par les Gestionnaires de Dialogue

Pris en compte par les ICO

Figure 12. Tableau récapitulatif

5. Conclusion

Le travail présenté ici a été mené par trois groupes différents, ce qui a permis d'avoir une vision plus large et plus complète du domaine de la spécification d'applications Workflow. De plus, les études ont été menées suffisamment en détail pour que des prototypes soient réalisés. Ils ont permis de tester et de valider les

26

approches, mais aussi de mettre en évidence leurs particularités, leurs avantages et leurs points faibles.

Le formalisme Sophtalk est apparu comme un outil de description de collecticiels

permettant l'intégration d'agents distribués et communiquant de manière asynchrone. L'aspect dynamique des configurations de réseaux Sophtalk convient particulièrement au domaine des collecticiels. Enfin, le manque d'abstraction du contrôle par rapport aux fonctionnalités des objets compromet toute analyse statique (terminaison, déterminisme, confluence ...).

Le formalisme FLO présente l'avantage de séparer communication et comportements, et ce faisant il conduit à une programmation qui diffère des approches traditionnelles. A l'inverse, le formalisme des Objets Coopératifs en les mêlant présente une très grande puissance de contrôle telle que l'expression d'alternatives, de parallélisation de certaines actions et est plus conforme à une approche traditionnelle de la programmation par objets.

Le formalisme des Objets Coopératifs hérite de toutes les techniques d'analyse des réseaux de Petri et permet de vérifier certaines propriétés des collecticiels ainsi décrits : présence ou absence de cycles, terminaison, caractère borné, vivant ou réinitialisable des modèles [PAL 95b]. Un aspect des collecticiels est l'accès à des données partagées : les Objets Coopératifs paraissent mieux adaptés à ce genre de spécification (synchronisation, exclusions).

Il semble que ces formalismes puissent à terme se compléter : l'intégration à Sophtalk d’un mécanisme de gestion automatique des réactions à des envois de message emprunté à FLO rendrait plus explicite la liaison entre les ports d'entrée et de sortie d'un nœud. FLO quant à lui pourrait gagner dans sa structuration en intégrant la notion de port de sortie. D'autre part, un rapprochement entre FLO et les Objets Coopératifs pourrait apporter au premier une plus grande puissance de contrôle et au second une simplification de l'expression du dialogue. En fonction des domaines d'application, une modélisation déclarative ou une modélisation fondée sur l'état peuvent paraître préférables. C'est cette complémentarité des trois formalismes que l'on souhaite approfondir dans le futur, afin d'aboutir à la conception d'un formalisme dédié à la spécification d'applications Workflow.

6. Remerciements

Cet article a été rendu possible par les travaux effectués au sein du Groupe de Recherche GT-SCOOP du Pôle de Recherches Coordonnées (PRC) Communication Homme-Machine (CHM). L'étude de cas traitée ici a été retenue parmi d'autres pour servir de référentiel commun à une réunion du groupe, qui s'est tenue à Sophia Antipolis le 10 Février 1995. Les auteurs du présent article y ont exposé leur vision du problème, et ont par la suite décidé d’approfondir ensemble ces travaux avec pour objectif d’arriver à une spécification complète de l’étude de cas, ce qui a permis d’évaluer à la fois l’adéquation des formalismes au domaine, leur pouvoir d’expression et leur complémentarité.

Les auteurs remercient les lecteurs anonymes de la revue TSI, dont les rapports de lecture ont grandement contribué à l’amélioration du fond et de la forme de cet article.

27

7. Bibliographie

[ABO 92] ABOWD G., COUTAZ J., NIGAY L. « Structuring the Space of Interactive System Properties ». Engineering for Human-Computer Interaction, p. 113-128, J. Larson & C. Unger (Eds.), Elsevier Science Publishers B.V. (North-Holland), 1992.

[BAS 89] BASTIDE R., SIBERTIN-BLANC C. « Conception par objets de systèmes parallèles » Actes du 2° Congrès Le Génie Logiciel et ses applications, EC2, Toulouse 1989.

[BAS 92] BASTIDE R. Objets Coopératifs : Un formalisme pour la modélisation des systèmes concurrents, thèse de doctorat de l'Université Toulouse III, 1992.

[BAS 95] BASTIDE R, PALANQUE P. « A Petri net based environment for the design of event-driven interfaces ». Proceedings of the ATPN'95 conference on Applications and Theory of Petri nets, Torino, Italy, 1995.

[BOR 88] BORRAS P, CLEMENT D, DESPEYROUX T, INCERPI J, KAHN G, LANG B, PASCUAL V. « Centaur, the system », Proceedings. of ACM SIGSOFT’88, Boston 1988.

[BRU 95] BRUN P., BEAUDOUIN-LAFON M. « A Taxonomy and Evaluation of Formalisms for the specification of Interactive Systems », People and Computers X, Proceedings of the HCI’95 Conference, p.197-212, Cambridge University Press, 1996.

[CAG 89] GAGAN M. « HP SoftBench : an architecture for a new generation of software tools », Softbench technical notes series, 1989.

[DUC 93] DUCASSE S, FORNARINO M. « A Protocol for managing Dependencies between Objects by controlling Generic Function Invocation ». OOPSLA93 workshop on Object-Oriented Reflection and Metalevel Architectures. Washington, 1993.

[DUC 95] DUCASSE S, FORNARINO M, PINNA A.M. « A Reflective Model for First Class Dependencies ». Proceedings of OOPSLA95 Conference, p. 265-280, 1995.

[DUG 90] DUGERDIL P. Smalltalk-80, Programmation par objets. Collection informatique. Presses Polytechniques et universitaires romandes, 1990.

[DUM 90] DUMAS P, CHARBONNEL G, La méthode OSSAD, Tomes I et 2, ISBN : 2-7081-1209-0, Les éditions des organisations, Paris 1990.

[FOR 94] BLAY-FORNARINO M., PINNA-DERY A.M. « Dépendances comportementales et modéle PAC ». Actes des rencontres IHM 1994, Lille, 1994.

[GOL 83] GOLDBERG. A, ROBSON D. SMALLTALK-80: The language and its implementation. Addison-Wesley, Xerox Palo Alto Research Center, 1982.

[JAC 92] JACOBS I. « The Centaur 2.0 Manual ». INRIA Sophia-Antipolis. 1992. [JAC 93] JACOBS I, BERTOT J. « The Sophtalk Tutorial », INRIA Technical report n° 149,

1993. [JAC 93b] JACOBS I, MONTAGNAC F, BERTOT J, CLÉMENT D, PRUNET V, « The Sophtalk

Reference Manual », INRIA Technical report n° 150, 1993. [KAR 90] KARBE B, RAMSPERGER N, WEISS P. « Support of Cooperative Work by Electronic

Circulation Folders ». Proceedings. of ACM Conference on Office Information Systems, SIGOIS Bulletin vol. 11, n° 23, p. 109-117 ACM / New York 1990.

[KAR 94] KARSENTY A, « Le collecticiel : de l’interaction homme-machine à la communication homme-machine-homme », Technique et Science Informatique, numéro spécial Interfaces Homme-Machine, vol. 13, n° 1, p. 105-127, 1994.

[KRA 88] KRASNER G, POPE S. « A Cookbook for using the Model View Controller User Interface paradigm in Smalltalk-80 ». JOOP p. 26-49, 1988.

[LAD 80] LADD I, TSICHRITZIS D.C. « An Office Form Flow Model », Proceedings of the AFIPS National Computer Conference (Anaheim, Calif, May 1980) AFIPS Press, Reston, Va., p. 533-539, 1980.

[NUR 96] NURCAN S. « Analyse et Conception de Systèmes d'Information Coopératifs », Technique et Science Informatique, vol.15, n° 9, 1996.

28

[OLL 86] OLLE T.W, SOL H.G, Verrijn-Stuart A.A. (Eds.) Information Systems design methodologies, North Holland, 1986.

[OMG 91] THE OBJECT MANAGEMENT GROUP, Common Object Request Broker : Architecture and Specification, OMG document n° 91.12.1, 1991.

[PAL 92] PALANQUE P. Modélisation par Objets Coopératifs Interactifs d'interfaces homme-machine dirigées par l'utilisateur, thèse de doctorat de l'Université Toulouse I, 1992.

[PAL 95a] PALANQUE P, BASTIDE R. « Spécifications formelles pour l'ingénierie des interfaces homme-machine ». Technique et Science Informatique, vol.14, n° 4, p. 473-500, 1995.

[PAL 95b] PALANQUE P, BASTIDE R. « Formal Specification and Verification of CSCW using the Interactive Cooperative Object Formalism », Proceedings of HCI'95, Huddersfield, UK, 1995.

[PER 89] PERNICI B, BARBIC F, FUGINI M.G, MAIOCHHI R, RAMES J.R, ROLLAND C. « C-TODOS : An Automatic Tool for Office System Conceptual Design ». ACM Transactions on Office Information Systems, vol. 7, n° 4, p. 378-419, ACM / New York 1989.

[SIB 91] SIBERTIN-BLANC C. « Cooperative Objects for the Conceptual Modeling of Organizational Information Systems. » Proceedings of IFIP TC8 Working Conference on the Object Oriented Approach in Information Systems, Quebec City, Canada. F. van Assche et al. (Eds) Elsevier Science Publishers, 1991

[SIM 88] SIMONE C. « Identification and Estimation of Parameters for a Computer-based Organization », Proceedings of IFAC Identification and System Parameter Estimation, Neijing, PRC, 1988.

[SUN 93] SUNSOFT, The Tooltalk service, an inter-operability solution, Englewood Cliffs : Prentice Hall, 1993.