La métaphore du dossier B. Lesueur, G. Sunyé1, Z. Guessoum, G. Blain, J-F. Perrot

{bruno.lesueur, zahia.guessoum, gerson.sunye, gilles.blain, jean-francois.perrot}@lip6.fr

htpp://www.lip6.fr/oasis & htpp://www-poleia.lip6.fr/~fortame

Laboratoire d'Informatique de l'Université Paris 6 (LIP6) - Boîte 169 - Université Pierre et Marie Curie (Paris 6) - 4, place Jussieu - 75252 Paris Cedex 05

Résumé : Nous proposons dans cet article une démarche de développement de systèmes d’information, appelée la « métaphore du dossier ». Son objectif est de permettre une prise en compte équilibrée des points de vue des utilisateurs et des informaticiens. Cette démarche est outillée par MétaGen, qui allie la méta-modélisation et l’acquisition de connaissances pour offrir un environnement de développement de haut niveau. Le point de vue des utilisateurs est modélisé selon deux aspects : fonctionnel et organisationnel. Le premier est fondé sur la notion de dossier (vu comme un dépôt de données) et sur les événements et règles de gestion qui agissent sur celui-ci. L’aspect organisationnel décrit les différents utilisateurs du système et leur attribue les responsabilités dégagées lors de l’analyse de la gestion des dossiers. Le point de vue des informaticiens prend en compte l’ensemble des moyens techniques (frameworks, systèmes transactionnels, etc.) nécessaires à la mise en œuvre du système. Notre démarche permet de préserver l’indépendance des «managers», des organisateurs et des implémenteurs, tout en assurant une mise en œuvre opérationnelle. Dans ce cas précis, MétaGen a été utilisé pour engendrer des applications multi-agents distribuées, implémentées en Java ou en Smalltalk. Mots clés : système d’informations, méta-modélisation, multi-agents, modélisation, workflow.

Abstract : In this paper, we propose a development technique for information systems, called “the folder metaphor”. The goal of this technique is to allow a balanced treatment of the viewpoints of users and software engineers. This technique is supported by MétaGen, a tool that combines metamodeling and knowledge acquisition techniques to generate high-level development systems. Two aspects are taken into account to model the user viewpoint: functional and organizational. The first one relies on the notion of folder (view as a data store) and on events and management rules that apply to folders. The organizational aspect allows to describe the various system users and to assign them the skills that were extracted from the folder management analysis. The software engineer viewpoint covers the set of technical resources (frameworks, transactional managers, etc.) that are needed to implement the system. Our technique preserves the independence of managers, organizers and software engineers while insuring a fully operational realization. In this particular case, MétaGen was used to generate multi-agent distributed applications implemented in Java or in Smalltalk.

Keywords : information systems, metamodeling, multi-agents, modeling, workflow.

Catégorie : Chercheur

1 Boursier de la CAPES, Ministère de l’Education, Brésil

1 Introduction Nous proposons ici une démarche pour maîtriser l’automatisation des systèmes d’informations. Cette démarche se veut garante du respect scrupuleux des responsabilités des différents acteurs : managers, organisateurs, informaticiens et programmeurs. Elle s’applique en premier lieu aux processus de gestion des organisations administratives qui sont nos champs privilégiés d’expériences. Nous l’avons appelée « métaphore du dossier » en raison du rôle essentiel qu’y joue l’image familière de la chemise cartonnée. Cette proposition est issue d’un projet de recherche mené dans notre laboratoire depuis le début des années 90 [REVA95] sur l’acquisition, la représentation et l’utilisation des connaissances liées au processus de construction des applications informatiques [BLAI96].

1.1 Cadre de l’étude L’objectif est de fournir aux responsables de la résolution d’un problème administratif, les outils linguistiques les plus précis et les plus proches possibles de la pratique courante des experts du métier concerné. A partir de son énoncé, exempt de surcharges informatiques, on introduira pas à pas les contraintes organisationnelles et technologiques, sous une forme implémentable dans un système informatique. La définition précise des besoins des utilisateurs que doit satisfaire le système-cible émergera donc de la confrontation de l’énoncé initial avec les modalités organisationnelles et technologiques de sa mise en œuvre. La démarche proposée ne se démarque pas radicalement de celles des méthodes classiques en pratique depuis deux décennies. Mais nous les améliorons principalement sur l’articulation entre le point de vue de l’utilisateur et le point de vue de l’implémenteur. Les notations proposées par les méthodes classiques sont, la plupart du temps, mal maîtrisées par les différents experts utilisateurs non informaticiens. Le handicap induit les empêche d’assumer leurs responsabilités en les obligeant à prendre des décisions dans un domaine qui n’est pas le leur. De plus, ces décisions, souvent inadéquates, induisent des choix technologiques précoces et peuvent ainsi gêner fortement les informaticiens pour assumer leurs propres responsabilités. En sens inverse, les notations qui emploient le langage spécifique des métiers entraînent des difficultés d’implémentation souvent insurmontables. Or, tout projet visant à aboutir à un logiciel utilisable doit finalement intégrer les deux points de vue, malgré leurs différences. Dans les démarches «traditionnelles» d’automatisation des systèmes d’informations, cette nécessaire intégration est obtenue en traitant ensemble les deux aspects dès l’analyse. La difficulté induite par cette intégration est résolue la plupart du temps par l’intervention d’un « développeur exceptionnel » [BROO87, CHRI87] qui possède aussi bien les compétences du métier que celles de l’informatique. Cette difficulté était déjà présente dans les premiers efforts du début de l’informatisation, qui s’appliquaient aux aspects les plus formels de la vie des organisations (comptabilité, paye, etc). Elle est encore à l’œuvre dans la plupart des méthodologies actuelles, incluant celles utilisant le paradigme objet comme OMT, [RUMB91] qui maintiennent le primat des représentations informatiques. Elle est devenue aujourd’hui encore plus cruciale, pour exprimer des procédés peu formalisés qui entraînent parfois un usage inédit des outils informatiques en tant que collaborateurs des acteurs du domaine.

Nos travaux ont débouché sur la construction d’un outil logiciel, appelé MétaGen, qui permet la mise en œuvre de cette démarche à travers des outils de méta-modélisation et de traitement des connaissances. Dans ce cadre, la « métaphore du dossier » est le résultat d’une série d’expériences menées avec des partenaires industriels, dans le cadre de projets de fin d’étude du DESS «Génie des Logiciels Applicatifs»2 et dans celui de contrats de recherche. Nous l’avons formulée originellement dans le monde de l’assurance. Elle a sous-tendu notre participation à un projet européen Esprit dans le domaine bancaire, et nous l’utilisons actuellement pour définir la gestion technique d’un hôpital.

1.2 Notre proposition Notre outil permet de trancher le dilemme entre l’utilisation des langages métiers et celle des langages informatiques en séparant les deux aspects utilisateur et implémenteur à travers un processus contractuel d’élaboration d’un méta-modèle. Ce méta-modèle permet aux prescripteurs et aux informaticiens de se mettre d’accord sur des notations et sur leurs sémantiques. L’aspect utilisateur et l’aspect implémenteur seront ensuite reliés par une opérationnalisation des connaissances des informaticiens sous forme de règles de traduction de ces notations en programmes exécutables. En réunissant l’interprétation de l’ensemble des connaissances dans le produit final, notre approche apporte ainsi un progrès substantiel à la résolution de ce problème d’intégration d’expertises multiples. Notamment nous décomposerons l’expression des choix des prescripteurs par la définition des aspects fonctionnels dans un premier temps, suivie de la définition des aspects organisationnels. Pour cela, nous reprenons les techniques développées dans le domaine des systèmes multi-agents, qui dès l’origine [GASS92] se sont préoccupés de la dualité entre structure et organisation. Ces techniques ont atteint aujourd’hui un degré d’opérationnalité suffisant pour entrer dans des logiciels complexes comme MétaGen. Plus précisément, nous utilisons ici le framework multi-agents DIMA [GUES96] conjugué avec la technique standard KQML [FINI94]. Nous avons déjà utilisé la même approche avec succès dans le projet européen FIBOF [LESU98].

La métaphore du dossier permet de convertir une description de l’application envisagée en une implémentation abstraite qui peut s’incarner soit directement en DIMA (tournant en Smalltalk ou en Java), soit au prix d’un peu de codage, dans le cadre d’un système transactionnel classique. Pour réaliser une application à l’aide de notre technique, il convient de fournir séparément le modèle fonctionnel et le modèle organisationnel, au moyen des éditeurs de modèles spécialisés que propose MétaGen. Le lien entre les deux modèles est effectué automatiquement par MétaGen, ainsi que la transformation du modèle global en implémentation abstraite. Just click the button… Pour présenter nos arguments relatifs à la métaphore du dossier, nous croyons utile de donner une idée de la démarche générale du système MétaGen dans laquelle elle s’inscrit. Cette démarche étant relativement complexe, nous commençons par l’exemple de la conception d’une application très simple qui formera la deuxième partie. La troisième partie est consacrée à une discussion générale de MétaGen et la « métaphore du dossier » occupe la quatrième partie.

2 Université Pierre et Marie Curie (Paris VI)

2 MétaGen : Un exemple simple

2.1 Le problème posé Imaginons un utilisateur désireux d’évaluer les différentes possibilités qui lui sont offertes au sujet d’un emprunt : étant donné un capital emprunté, une durée de remboursement et un taux d’intérêt, quel est le montant des mensualités ? Ce problème peut se traduire de manière très simplifiée par le système d’équations suivant :

Figure 1 : système d’équations de l’utilisateur (1) Notre utilisateur, au fait des agréments que proposent les interfaces graphiques, souhaite que la machine affiche le résultat de ses calculs sous une forme commode à interpréter, à savoir un système de règles à curseurs (sliders) réunies dans une fenêtre interactive comme celle-ci :

Figure 2 : la fenêtre de l’application (2) Le problème posé est donc de convertir (1) en (2). Notons que cette tâche n’est pas simple, en raison de toutes les informations qui restent implicites tant dans la donnée du système d’équations initial que dans la fenêtre censée l’opérationnaliser. L’essentiel de la tâche d’analyse-conception est précisément d’expliciter cet implicite. La figure suivante montre à gauche (3) ce que l’utilisateur a en tête lorsqu’il pense à son système d’équations, et à droite (4) ce que l’informaticien chargé de l’implémentation voit derrière la fenêtre qu’il doit réaliser. Le diagramme (4) ne représente pas une réalisation complètement codée. C’est un schéma “abstrait” faisant intervenir des composants standard qui apparaissent dans toutes les boîtes à outils d’interfaces graphiques. Il est compréhensible par tout spécialiste d’interfaces homme-machine, et implémentable de manière plus ou moins directe selon la plate-forme qui sera retenue pour la réalisation finale (OpenWin en C, Swing en Java, ou Visual en Smalltalk). Le but de MétaGen est précisément de fournir un cadre dans lequel on pourra formuler à la fois la demande (3) et la proposition de réponse (4), et plus précisément, de manière à déduire automatiquement (4) de (3).

Interet = capital * taux. Somme = capital + interet. Mensualite = somme / nbmensualite

Figure 3 : schéma général de la démarche

2.2 Le méta-modèle utilisateur Commençons par le côté “utilisateur”. L’idée de base est de se placer au niveau du langage dans lequel l’utilisateur formule sa demande. Nous préférons parler de méta-modèle plutôt que de langage, terme chargé de trop de connotations. Nous considérons que la demande de l’utilisateur est un modèle de l’application qu’il vise, et que pour la formuler, il a besoin d’un cadre conceptuel qui prend naturellement le nom de méta-modèle. En cela nous nous conformons à un usage bien établi ces dernières années en Génie Logiciel [BUBE88, PREM95].

Figure 4 : le système d’équations vu comme un graphe

Dans le cas présent, le système d’équations se définit comme un graphe d’expressions (3 dans la Figure 3, voir aussi Figure 4), qui est le modèle utilisateur (MU). Ce graphe représente un calcul sous forme de « Data-Flow ». On retrouvera donc des arcs qui supportent tantôt les opérandes, en tant que variables origines, tantôt le résultat de l’opération. L’organisation de ces concepts graphiques s’exprime classiquement sous une forme également graphique par un diagramme entité-association étendu [JEUL88, KELL96] dans le formalisme PIR3, décrit par [SAHR95] (Figure 5). Ce diagramme constitue ce que nous appelons le méta-modèle utilisateur (en abrégé, MMU). Il exprime sous une forme précise le jeu de concepts dans lequel s’exprime la demande. Il est dûment représenté en machine et manipulable comme le montre la Figure 5.

(4) (3)

Interet = capital * taux. Somme = capital + interet. Mensualité = somme / nbmensualité

(1)

(2)

Figure 5 : le méta-modèle utilisateur

Mais il n’est compréhensible et contrôlable sous cette forme que par un praticien de l’entité-association. Aussi va-t-il être présenté à l’utilisateur sous un autre aspect, celui de l’éditeur de modèles (voir Figure 4) qui le met en œuvre. En effet, la sémantique du MMU se définit en partie par les contraintes syntaxiques qu’il impose aux graphes (alias modèles) qu’il est censé définir. Un éditeur spécialisé, appelé éditeur de modèles, tel que celui représenté en Figure 4, est construit à partir du MMU par l’intermédiaire d’un outil appelé méta-éditeur. L’éditeur de modèle garantit la conformité au MMU des objets qu’il construit. Il en fixe également l’apparence visuelle (icônes pour les nœuds, couleurs pour les arcs), grâce aux spécifications fournies au méta-éditeur.

2.3 Le méta-modèle implémenteur Les notions mises en jeu dans la solution informatique s’organisent en un graphe (Figure 6), que l’on nomme le modèle implémenteur (MI).

Figure 6 : le modèle implémenteur Comme on peut le constater, la structure graphique du modèle utilisateur, dans ce cas précis, se retrouve pratiquement à l’identique dans le modèle implémenteur. Ce dernier comporte trois sortes d’informations :

• des informations provenant directement du modèle utilisateur sans besoin de transformation (p. ex. relations d’incidence entre nœuds et arcs) ;

• des informations élaborées à partir du modèle utilisateur et traitées en vue de leur implémentation (p. ex. une variable qui n’est pas résultat sera reliée à un slider et à un label, tandis qu’une variable résultat ne sera liée qu’à un label.) ;

• des informations strictement liées à la réalisation informatique, et qui ne figurent pas explicitement dans le modèle utilisateur (p. ex. la fenêtre d’interaction elle-même, et son nom).

On voit ainsi apparaître une transformation graphique qui fait passer du modèle utilisateur au modèle implémenteur (Figure 7).

Figure 7 : la correspondance MU - > MI

Pour définir cette transformation, qui est évidemment le cœur du processus, nous employons un moyen puissant, à savoir une base de règles du premier ordre, à la manière d’un système expert (comme suggéré dans la Figure 7). En effet, il s’agit bien de mobiliser l’expertise de l’implémenteur sur le problème qui lui est posé par la demande de l’utilisateur. En l’occurrence, ces règles sont assez évidentes, mais c’est loin d ‘être toujours le cas. Encore faut-il pouvoir les écrire ! Pour cela nous avons besoin de spécifier la structure du modèle implémenteur, ce qui se fait, comme précédemment, par un diagramme entité-association étendu qui constitue le méta-modèle implémenteur, en abrégé MMI (Figure 8).

Figure 8 : le méta-modèle implémenteur

3 MétaGen : discussion

3.1 Les deux faces Notre système comporte ainsi deux faces : une orientée vers les utilisateurs, l’autre vers les implémenteurs. D’une part, la logique de l’expert du domaine, exprimée dans le méta-modèle utilisateur, doit être gardée séparée des contraintes d’implémentation. Par exemple, nous n’essayons pas d’apprendre la modélisation objet aux experts du domaine comme Fowler [FOWL97, p.3] voudrait le faire : nous préférons créer un «langage» (méta-modèle) dédié au domaine, conforme aux prescriptions des experts. Une fois ce cadre défini et validé, la spécification des applications (aboutissant au modèle utilisateur) peut se faire sous la seule responsabilité des représentants des utilisateurs, ainsi que l’évolution et la maintenance de ces spécifications, ce qui encore plus important. D’autre part, nous mettons en évidence une double expertise en matière d’implémentation. D’abord dans le choix de la technologie adéquate aux applications envisagées (matérialisée par le méta-modèle implémenteur) et dans sa mise en œuvre (matérialisée par la base de règles qui effectue la transformation du modèle utilisateur vers le modèle implémenteur). Ensuite dans le choix de la plate-forme de réalisation. Cela permet de coller à l’évolution des techniques (qui peut aller jusqu’à un changement de plate-forme) sans impliquer les utilisateurs. C’est sur cette base qu’on définit la transformation qui traduit les modèles utilisateur en modèles implémenteur. Cette transformation n’est pas toujours triviale et dépend fortement du domaine traité. Notre système met à disposition l’équipement nécessaire [SUNY97] pour la spécifier en traduisant les connaissances de l’expert en implémentation. Lors de la construction du MMU, l’expert du domaine et l’expert implémenteur se concertent. Ce dernier, ayant connaissance de la palette des MMI envisageables, peut assurer que les demandes de l’expert du domaine restent réalisables. La pierre de touche en la matière est fournie par l’écriture de la base de règles, qui donne une expression complète aux intuitions de l’implémenteur. Notre schéma à deux faces et à double niveau nous permet ainsi de garder le monde de l’utilisateur et le monde de l’implémenteur séparés, tout en maintenant un lien sémantique opérationnel du premier vers le second. Notons que cette formalisation de l’accord entre l’expert du domaine et l’informaticien permet la contractualisation de leur relation, au sens juridique du terme.

3.2 Le côté utilisateur Le MMU relève d’un processus d’acquisition de connaissances qui reprend les techniques d’interview et d’itération sur les choix des dénotants, de même nature que l’élaboration de modèles conceptuels dans les méthodes classiques comme Merise [ROCH83] ou Remora [FOUC78]. Ce processus se fait en deux étapes selon un cycle en spirale. D’abord, on détermine l’organisation minimale de concepts, propriétés et associations, etc. qui sont nécessaires pour décrire le monde de l’expert du domaine, sous la contrainte constante du rasoir d’Ockham. Cet univers est ensuite visualisé à travers l’éditeur de modèles, permettant alors à l’expert d’exercer sa critique et de relancer ainsi le cycle suivant de la spirale. En effet l’expérience montre combien l’aspect graphique et le choix des bons raccourcis sont

importants pour une utilisation correcte dans la modélisation d’applications. L’éditeur de modèles représente en fait une partie de la sémantique du méta-modèle, l’autre partie étant fournie par la base de règles qui l’opérationnalise.

3.3 Le côté implémenteur Le MMI reflète la structure sous-jacente à l’application en mettant en œuvre toute les techniques disponibles, ce qui, en pratique, se ramène souvent au choix d’une collection de «frameworks», chacun étant consacré à une des facettes de l’application (interface, répartition, base de données …). Pour chacun d’eux, il fixe un but et exprime les règles d’usage qui gouvernent son utilisation dans ce but, (cf. [REV96]). Une des difficultés dans l’interopération de «frameworks», réside dans la «glu» qui doit les relier [NIER95]. Dans notre démarche, c’est au niveau du MMI que le problème est posé et peut être résolu. Les «design patterns» offrent une voie dans ce sens [SUNY99]. D’un MMI à un autre, on retrouve souvent des pans entiers en commun (p. ex. la boîte à outils pour l’interface graphique se reproduit presque sans changement). Ceci conduit à construire une bibliothèque de MMI génériques mais partiels, que l’on pourra choisir et intégrer lors de la construction du MMI global.

3.4 MétaGen : réalisations Le système MétaGen a, dans ses débuts, été principalement utilisé pour traduire des bases de données relationnelles en bases de données objets [MISS98, SAHR98]. Du point de vue des applications finalisées, il a été utilisé pour construire un logiciel d’œnologie sur commande du Cemagref [AGAB97] ; une autre application commandée par le Cemagref est en cours sur la représentation du circuit de la viande bovine. Il a également servi de base à différents projets d’étudiants dans les domaines de la gestion de risque, de la réassurance, de la gestion hospitalière. Son application la plus récente (1998) incorpore dans son MMI le framework multi-agents, DIMA. Cette version a été validée comme partie d’un projet européen franco-espagnol dédié à la banque et au domaine financier [LESU98]. La « métaphore du dossier », que nous présentons ici, fait partie de cette dernière phase.

4 Description de la métaphore du dossier

4.1 Présentation générale Au niveau fonctionnel, on décrit les procédures administratives en se référant à l’état de certains «dépôts» (repository) d’information, appelés dossiers. Des événements extérieurs introduisent des messages. Le contenu de chaque message est distribué sur plusieurs dossiers et modifie ainsi leur état. Si l’état d’un dossier satisfait certaines conditions, une action a lieu, qui fera également varier l’état du dossier et pourra, le cas échéant, provoquer un nouvel événement. Les paires correspondantes (condition, action) sont appelées règles de gestion [voir HERB95, ODEL94]. La structure spécifique d’un dossier dépend de la procédure auquel il appartient, mais elle est toujours vue comme une construction arborescente de dossiers (racine), de chemises (nœuds) et de pièces (feuilles). Les opérations modifiant l’état sont restreintes à la création ou à la suppression de pièces et de chemises, et au déplacement de pièces d’une chemise à

une autre. La modification d’un document donné est effectuée par sa destruction et sa re-création sous sa forme modifiée. Signalons que cette reconstruction met en œuvre des opérateurs considérés comme disponibles – mais que leur déclenchement et la supervision de leur exécution peuvent être plus ou moins complexes et nécessiter des mécanismes sophistiqués (p. ex. la réalisation d’un bilan). Les conditions des règles de gestion sont également très restreintes : présence ou absence de certaines pièces, comparaisons de valeurs extraites des pièces. Notons que la notion répandue de «règle événement/condition/action» (ECA) n’est pas adéquate ici, puisque le déclenchement n’est pas directement lié à l’événement mais à l’état atteint par un dossier, qui représente la somme (ou l’enregistrement) des événements passés [voir p. ex. KAPP96]. Au niveau organisationnel, les compétences des personnes viennent au premier plan. L’ensemble des types d’événements et des conditions des règles de gestion définissent les capacités qui sont nécessaires pour appliquer une procédure administrative donnée. Par exemple, dans le domaine de l’assurance, évaluer la responsabilité dans un accident requiert un savoir faire légal qui n’est pas nécessaire pour vérifier que l’adresse d’un plaignant n’a pas changé. Ces capacités seront distribuées sur tout le personnel sous la forme d’un diagramme work-flow, selon un procédé à présent bien outillé [LEI97]. Ce diagramme introduit la notion de circulation de dossiers, qui n’apparaît pas dans le niveau fonctionnel et qui doit également être modélisé. Par exemple, quand un employé d’assurance reçoit la déclaration d’un sinistre banal comme un «bris de glace», il crée, en premier lieu, un nouveau sous-dossier dans le dossier du plaignant pour stocker les pièces relatives au sinistre (date de réception, lieu, objet de risque mis en cause). Un ensemble de règles de gestion va alors être activé (sous la responsabilité du gestionnaire de sinistres), et une procédure de vérification du dossier va être lancée (pour savoir si l’objet de risque est couvert par le contrat d’assurance). Dans le cas d’une réponse négative, un autre ensemble de règles de gestion sera appliqué pour produire une lettre de refus au plaignant (i.e. le dossier sera renvoyé du gestionnaire de sinistres à l’employé responsable). Dans le cas d’une réponse positive, un nouvel événement sera déclenché qui mettra à jour le dossier (lequel qui sera transmis à la comptabilité). Nous allons maintenant expliquer comment les niveaux organisationnel et fonctionnel sont modélisés dans notre système. Nous présentons, tout d’abord, le méta-modèle utilisateur, exemple typique d’une modélisation à deux niveaux.

4.2 La structure fonctionnelle La structure fonctionnelle est naturellement séparée en deux : la structure statique décrit les dossiers, chemises et pièces, et la structure dynamique décrit les événement et les règles.

4.2.1 La structure statique Elle est simple à définir : elle concerne les relations entre les concepts de dossier, de chemises et de pièces. La Figure 9 montre le système de notations qui est utilisé pour cela. Les nœuds représentent les concepts, les relations entre ces concepts sont représentées par des liens libellés avec leur noms (e.g. est_composée_de) et une paire d’entiers indiquant les contraintes de cardinalité.

Figure 9 : le méta-modèle de la structure fonctionnelle Ainsi on peut lire dans la Figure 9 : Un dossier est fait d’un certain nombre de chemises (au moins une) ; une chemise est faite d’un nombre quelconque de chemises et/ou un certain nombre de pièces, etc. Notons que cette structure se prête à une transformation vers un schéma de base de données relationnelle (voir paragraphe 4.4.3).

4.2.2 La structure dynamique Elle définit comment les dossiers sont affectés par les événements et les règles. Quand un événement survient, le message qu’il contient (qui peut prendre la forme d’un simple appel téléphonique) est criblé pour déterminer quels sont les dossiers affectés et dans quelles chemises les pièces extraites du message seront placées. Le déclenchement des règles est logiquement disjoint de l’occurrence de l’événement. La Figure 10 présente la notation pour les événements et la Figure 11 la partie « règle ».

Figure 10 : traitement d’un événement Un crible dans la Figure 10 représente la connaissance qui est nécessaire pour sélectionner le dossier qui recevra l’information convoyée par le message. Cette information est écrite dans

de nouvelles pièces selon une classification de types définie et stockée dans les données. Ces nouvelles pièces créées sont placées dans les chemises indiquées par le crible.

Figure 11 : Règles de gestion Les règles de gestion (Figure 11) spécifient comment les dossiers et leur subdivisions sont modifiés selon l’état qu’ils ont atteint. Les règles apparaissent comme des paires (ensemble condition/action). Les états possibles d’un dossier sont catégorisés par leur nom, dont deux sont implicites (vide et clos). Chaque dossier possède une liste de ces noms d’état pertinents. Quand elle est appliquée, une condition d’une règle mettra à jour la qualification applicable au dossier. En fonction de cette qualification, la règle lancera (ou pas) l’action. Comme annoncé plus haut (en 4.1), l’action peut prendre seulement trois formes : créer, supprimer ou déplacer une pièce, mais ces opérations peuvent mettre en jeu des calculs complexes qui sont hors du champ de notre modélisation

4.2.3 Un exemple Nous illustrons l’utilisation du méta-modèle du dossier en montrant le modèle particulier d’un type de contrat d’assurance simple concernant le sinistre «bris de glace». Nous le montrons tel qu’il apparaît dans l’éditeur graphique de modèles (cf. 2.2), résultat de l’adaptation du méta-modèle au vocabulaire et aux habitudes conceptuelles des professionnels de l’assurance. Même pour cet exemple simple, la structure générale est passablement complexe : nous ferons donc appel à la capacité qu’à l’éditeur de modèles de cacher certaines parties de la structure et de choisir des vues prédéfinies.

Figure 12 : structure statique, l’éditeur de modèle «sinistre bris de glace»

La Figure 12 montre la structure statique de notre contrat. Le dossier, ses quatre chemises (ainsi que la sous-chemise «prime»), et les pièces diverses sont indiqués par des icônes choisies par l’utilisateur. L’éditeur de modèles nous a permis de ne présenter que les liens est_composé_de pour visualiser la structure du dossier «contrat».

Figure 13 : structure dynamique, une partie du modèle «sinistre bris de glace»

La Figure 13 montre la structure dynamique de notre contrat. Nous notons qu’un second dossier entre en ligne de compte. Ce second dossier est celui du client et il a une structure différente. De plus, trois nouvelles icônes apparaissent : Sinistre bris de glace qui est une abréviation pour un cas particulier «événement et message», et Crible sinistre bris de glace avec Par nom et Client forment le crible associé à cet événement.

4.3 Structure organisationnelle Pour représenter une organisation comprenant des personnes, il convient d’abord de représenter ces personnes elles-mêmes et leurs interactions. Pour ce faire, nous utilisons le paradigme multi-agents [FERB97, GASS92] : à chaque personne nous assignerons un agent la représentant ; le work-flow évoqué en 4.1 sera codé via les liens qu’entretient chaque agent ; et la circulation des données sera prise en charge par le processus d’interaction entre agents. Nous utilisons une notation générale pour décrire une forme d’agents cognitifs et interactifs qui a été déjà utilisée dans de nombreux projets au sein de notre laboratoire

Dossier

Chemise

Pièce

Evénement

Crible

Définition du crible

[DURA96, LESU98]. La même notation nous servira de nouveau pour le méta-modèle implémenteur en 4.4.2. Notre agent a la faculté de délibérer et d'interagir avec les autres agents. Les langages d'interaction traitent essentiellement la manière de décrire des actes de communications. En effet, plusieurs normalisations de la communication ont été proposées. Parmi elles, KQML est considéré comme un standard [FINI94]. Il est fondé sur la théorie des actes de langage et il permet de coder explicitement les actes illocutoires en termes de types de message ou "performatifs". Nous avons utilisé KQML pour exprimer des règles d'interaction entre agents. Les opérations de communication de nos agents consistent en envoi et réception de courriers qui suivent le standard KQML. Le contenu d’un courrier est toujours un événement (au sens du modèle fonctionnel). Quant à sa capacité d’action, elle se représente par un catalogue d’actions possibles, dont chacune active une ou plusieurs règles de gestion (au sens du modèle fonctionnel). On introduit la notion de compétence regroupant des actions élémentaires et des envois de courrier, pour représenter les choix qu’aura à effectuer l’opérateur humain. Dans le cas d’un agent purement logiciel, les compétences se réduisent à une seule action ou à un seul envoi de courrier. A leur tour, les compétences se regroupent en activités de manière à donner une vision synthétique du comportement de l’agent. Tout ce discours se résume dans le diagramme entité-association suivant :

Figure 14 : le méta-modèle organisationnel

A partir de ce méta-modèle, la création du modèle organisationnel va consister dans un premier temps en la définition de différentes catégories d’agents : dans notre exemple du traitement du « sinistre bris de glace », on distingue la personne du courrier, qui traitera l’arrivée de la lettre concernant l’accident et en fera part à un actuaire, qui traitera effectivement la demande. Suivant le traitement qui s’ensuivra, une secrétaire enverra une lettre de refus à l’assuré ou bien une comptable établira l’ordre de remboursement. La figure suivante montre une partie de la définition du type d’agent «actuaire». Dans un deuxième temps nous complétons le modèle organisationnel en décrivant les règles d’interaction entre ces différents agents en utilisant les «performatifs» KQML. Ainsi s’exprime la répartition des tâches sur l’ensemble des catégories de personnel existant.

Figure 15 : une partie du modèle de l’agent actuaire

4.4 Implémentation Conformément aux principes de MétaGen, le versant «implémentation» de la métaphore du dossier sépare les choix de conception de la réalisation exécutable. Les choix de conception traduisent une expertise en matière de programmation multi-agents issue de toute une tradition au laboratoire. Nous allons en résumer les points principaux.

4.4.1 Principe de la conception L’application est organisée autour d’une base de données centrale. Celle-ci est constituée d’informations de trois ordres : des valeurs (nombre ou chaîne de caractères), des références et des fac-similé de documents authentiques. Cette base est manipulée par des transactions émanant d’un réseau de postes de travail qui sont, en principe, servis par certains des personnels de l’entreprise. En fonction des responsabilités de ces personnels, on est amené, pour des raisons de sécurité, à établir différentes catégories de postes. A chacune de ces catégories correspond une interface graphique d’interaction (G.U.I.) qui lui est particulière. Comme nous le verrons au paragraphe suivant, cette interface sera modélisée comme un agent à part entière. En outre notre environnement comporte une bibliothèque de traitements spécialisés, qui correspondent aux calculs évoqués en 4.1. Nous avons donc à modéliser quatre mécanismes : d’une part le fonctionnement de la base de données et celui du réseau, d’autre part les interactions base de données / réseau et réseau / utilisateur humain (l’accès à la bibliothèque se faisant directement). Nous choisissons de représenter notre application comme un système multi-agents. Ce choix répond à une intuition assez naturelle, nous verrons par la suite qu’il s’avère adéquat. Il permet de ramener le fonctionnement de l’ensemble du système à une circulation de messages (interactions entre agents). Ces messages ont une structure uniforme sur tout le système (en l’occurrence, le format KQML). Quant aux agents eux-mêmes, il y en aura de deux sortes, ceux qui sont les interlocuteurs des opérateurs humains sur leur poste de travail, et les «agents de service» chargés d’effectuer des tâches totalement automatiques. Ces «agents de service» constituent une

couche intermédiaire au dessus de la plate-forme d’exécution : en particulier ils sont chargés de la communication avec le système de sécurité.

4.4.2 Précisions sur la conception Nous employons le «framework» DIMA [GUES98] qui nous a déjà servi pour le méta-modèle organisationnel. Ce framework est issu des travaux du Laboratoire d’Informatique de Paris 6 suivant les principes posés par Jacques Ferber [FERB97] et développé à travers plusieurs plate-formes. La plate-forme DIMA offre un environnement générique pour le développement des systèmes multi-agents. Elle permet de créer des agents de différentes granularités (agents réactifs, agents cognitifs au sens de Ferber) conçus d’une façon modulaire. L’architecture d’agents DIMA comprend trois niveaux :

• Un niveau «compétence» : organisation logique d’actions élémentaires (telles que : envoi de message, changement d’état interne, etc) interprétable en termes cognitifs (p. ex. recherche d’un dossier en réponse à un événement).

• Un niveau «comportement» : défini comme l’organisation logique de compétences (p. ex. communication / interaction et délibération).

• Un niveau «méta-comportement» : constitué par un module de supervision représenté par un ATN (Augmented Transition Network). Cet ATN « pilote » les différents comportements de l’agent.

Par exemple, l’agent DIMA interlocuteur de l’actuaire du paragraphe 4.3 sera doté d’un comportement délibération muni de plusieurs dizaines de compétences parmi lesquelles

• réponse à une sollicitation (déclaration de sinistre «bris de glace»), • réponse à une sollicitation (déclaration de sinistre …), • traitement d’un remboursement, • etc.

Notons que les compétences de l’actuaire en présence de deux déclarations l’une de sinistre “bris de glace” et l’autre de sinistre “incendie”, ne sont pas les mêmes, car les suites à donner sont différentes (nécessité ou non d’enquête). Les flux d’événements sont pris en compte par un agent d’interface distinct de l’agent de traitement. La dissociation des compétences de communication et des compétences de traitements permet de maîtriser efficacement la variabilité des supports de présentation de l’information (poste de travail, web, minitel, …). La base de données sera « enveloppée » dans un agent de service particulier. Dès lors, sa nature exacte compte assez peu. Dans nos expérimentations, nous avons opté pour un S.G.B.D. relationnel (Oracle, Sybase…), dont la « langue maternelle » est SQL. Le schéma correspondant est engendré sans difficulté à partir de la structure fonctionnelle (partie du modèle utilisateur) : la littérature fournit le moyen de convertir la structure hiérarchique en structure relationnelle, et les règles de gestion en requêtes. L’agent «enveloppe» sera chargé de traduire en SQL les messages qui lui parviendront, sous réserve qu’ils figurent dans une liste issue du modèle fonctionnel. Le cadre permettant de décrire les agents (méta-modèle) se représente comme un diagramme entité-association étendu, partie du méta-modèle implémenteur :

Figure 16 : la partie multi-agents du méta-modèle implémenteur

4.4.3 Choix pour la réalisation L’application doit évidemment être répartie sur au moins un serveur et plusieurs postes de travail. Il peut y avoir plusieurs serveurs intermédiaires pour accélérer l’accès à l’information. Le nombre de postes peut être de l’ordre de la centaine. Ce type d’application existe depuis longtemps et possède un acquis (technique transactionnelle, gestion des interactions avec l’utilisateur à travers une interface de type IBM-3270). Il n’y a pas d’obstacle majeur pour obtenir une réalisation exploitant ces acquis à partir de notre modèle implémenteur : en effet les problèmes de répartition se règlent d’une façon standard en raison des contraintes du système ; pour la traduction des comportements d’agents, on a suffisamment d’informations issues du modèle fonctionnel pour les compiler en séquences d’écrans. Notre approche s’applique donc à cette technologie bien connue et fiable notamment en présence d’architecture de «mainframe». D’autre part, on assiste à l’expansion de systèmes distribués sur des réseaux de micro-ordinateurs pour lesquels on s’oriente vers des architectures multi-agents : chaque articulation du système y est représentée sous la forme d’agents logiciels à l’autonomie plus ou moins prononcée. Cela permet d’améliorer un niveau de maintenabilité de l’application et sa résistance aux changements, au prix d’une légère baisse des performances, le terminal n’étant plus passif mais actif. Nous avons conduit deux expériences, en utilisant les deux implémentations disponibles de DIMA, en Smalltalk et en Java. Comme d’usage en programmation par objets, les «agents» du modèle implémenteur sont en fait des classes dont les instances sont installées sur les différents postes de travail : les instances des agents interlocuteurs, grâce à leur interface, sont alors prêtes à dialoguer avec les personnels chargés de leur mise en œuvre.

Les deux solutions (transactionnelle et multi-agents) sont fonctionnellement équivalentes, l’informaticien devra choisir l’une ou l’autre lors de l’analyse de la situation pour savoir quelle est la plate-forme la plus adaptée. Le fait d’avoir un modèle implémenteur «abstrait» nous permet, non seulement de choisir la technologie adéquate mais également d’en changer, sans pour autant remettre en cause le modèle utilisateur. Une troisième solution, à envisager, serait d’utiliser des progiciels comme les Enterprise Resource Planning utilisés dans l’industrie, et de générer tout ou partie du paramétrage de ces outils en fonction des modèles utilisateurs. Le méta-modèle implémenteur correspondant aurait alors pour rôle d’identifier les différents paramètres et les valeurs à leur donner.

5 Conclusion L’élaboration de la «métaphore du dossier» provient de plusieurs expériences dans le milieu de la gestion administrative. Par cette approche, nous voulons donner à chacun la possibilité de discourir sur son domaine sans empiéter sur la responsabilité des autres participants du projet informatique. Ainsi, nous générons les outils nécessaires pour que les différents utilisateurs expriment leur désir, à travers des modèles. Dans la «métaphore du dossier», on sépare ce qui est du ressort de l’organisateur de ce qui est du ressort du concepteur de procédures. La dichotomie entre le modèle organisationnel et le modèle fonctionnel a été appliquée avec succès dans le cadre d’un projet européen : FIBOF, concernant la mise en place d’une application gérant les produits bancaires depuis leur création jusqu’à la gestion des contrats issus de ces produits. La description fonctionnelle, a fait, pour sa part, l’objet d’une étude, appliquée au domaine de l’assurance (gestion d’un sinistre bris de glace) à l’occasion d’un atelier européen sur la méta-modèlisation. Le deux méta-modèles ont été ainsi validés séparément. Nous menons actuellement une autre série d’expériences pour valider la démarche dans son ensemble. De plus, nous comptons faire évoluer les deux méta-modèles. Notamment la partie interaction du méta-modèle multi-agents va évoluer pour prendre en compte les derniers travaux dans ce domaine, en utilisant ACL (Agent Communication Language), descendant de KQML. La version décrite dans cet article est actuellement appliquée à la gestion du plateau médico-technique dans un hôpital. Ce système est chargé de traiter du point de vue administratif les demandes d’examens de toutes sortes émanent des services de consultations. Ces demandes s’adressent à l’ensemble des laboratoires de l’hôpital et prennent en compte les dossiers médicaux des patients. Les événements primaires à traiter sont les demandes d’examens. Ces demandes intéressent souvent plusieurs laboratoires, le résultat d’un même prélèvement (p. ex. sanguin) devant être analysé suivant plusieurs points de vue. Chaque laboratoire suit sa propre procédure et fournit une fiche d’analyse communiquée au médecin et portée au dossier du malade. Notons que le processus peut être complexe en raison de règles comme : Si un échantillon arrivant à un laboratoire est mal préparé, il est renvoyé au demandeur. Si le résultat d’une analyse se trouve dans une zone critique alors un examen complémentaire est lancé. Cette brève description suffit à montrer que la «métaphore du dossier» s’applique au moins du point fonctionnel.

Depuis l’émission de la demande jusqu’à la réception de la feuille d’analyse, les différentes tâches doivent être réparties entre les médecins, les laborantins, les secrétaires médicales et les patients. Cette répartition des rôles est la fonction du modèle organisationnel, qui sera transformé en système multi-agents. Il est prévu de faire tourner le système dans un hôpital parisien sur un réseau de postes de travail, en prenant appui sur la technologie CORBA en interaction avec une base de données centrale sous SQL Server. Nous attendons de notre système qu’il s’adapte à l’évolution de l’hôpital. Le système peut devoir évoluer de deux façons : par adjonction ou suppression d’un agent particulier pour tenir compte de changements dans les personnels disponibles, et par mise à jour du modèle suivie de regénération du système pour tenir compte de modifications dans l’organisation ou dans la fonction (p. ex. suite à l’acquisition d’un nouvel appareil). La dissociation entre les modèles fonctionnel et organisationnel permet d’effectuer le minimum de changements lors de ces modifications. La métaphore du dossier, présentée dans cet article, bien qu’elle reste à valider dans sa globalité, nous paraît fournir un outil d’ores et déjà utilisable dans la conception des systèmes d’information.

6 Références [AGAB97] Agabra, J., Alvarez I. and Brezillon P., Contextual knowledge based system:

A study and design in oenology, in First International and Interdisciplinary Conference on Modeling and Using Context, (CONTEXT-97), Rio de Janeiro, 1997, 1, pp. 351-362.

[BLAI96] Blain, G. and F. Beugniet, Technologie objet et méta-modélisation, in Colloque RPO, Montpellier 1996.

[BROO87] Brooks, F.P., No Silver Bullet, IEEE Computer 1987, p. 10-19. [BUBE88] Bubenko, J.A., A Method Engineering Approach to Information Systems

Development, in IFIP WG8.1 Working Conference on Information Systems Development Process 1988.

[CHRI87] Christiansen, D., On good designer, IEEE Spectrum, 1987 p. 25. [DURA96] Durand, R. and Z. Guessoum, Stratégies-types et modélisation du processus

concurrentiel : exemple d'application des systèmes multi-agents, in Conférence internationale sur le management, Paris 1996.

[FERB97] Ferber, J., Systèmes Multi-agents, Interéditions, Paris 1997. [FERB97] Ferber, J. and O. Gutknecht, Aalaadin : a meta-model for the analysis and

design of organizations, in multi-agent systems, Technical report, LIRMM 97189, Montpellier 1997.

[FINI94] Finin, T and R. Fritzson, KQML - a language and protocol for knowledge and information exchange, in Proc. 13th Int. Distributed Artificial Intelligence Workshop, Seattle 1994, pp. 127-136.

[FOUC78] Foucaut, O. and C. Rolland, Concepts for Design of an Information System Conceptual Schema and its Utilization, in the REMORA Project, in 4th International Conference on Very Large Data Bases, Berlin 1978.

[FOWL97] Fowler, M., Analysis Patterns - Reusable Object Models, Addison-Wesley 1997.

[GASS92] Gasser, L. and M.N. Avouris, Distributed Artificial Intelligence, Kluwer 1992.

[GUES96] Guessoum, Z., Un environnement opérationnel de conception et de réalisation de systèmes multi-agents, Thèse, Université Pierre et Marie Curie, Paris 1996.

[GUES98] Guessoum, Z., DIMA : Une plate-forme de conception et de réalisation de systèmes multi-agents en Smalltalk, L'Objet (Paris) 3, 1997 pp. 393-409.

[HERB95] Herbst, H., A Meta-Model for Business Rules, in Systems Analysis, in Advanced Information Systems Engineering (CAiSE'95), Jyväskylä, Finland 1995.

[JEUL88] Jeulin, P. and P. Sauge, GRAPHTALK: La maîtrise de la qualité, in La revue du Génie Logiciel, Paris 1988.

[KAPP96] Kappel, G., S. Ransch-Schott, W. Retschitzegger, and M. Sakkinen, A Transaction Model For Handling composite Events, in Advances in Databases and Information Systems (ADBIS'96), Moscou 1996

[KELL96] Kelly, S., K. Lyytinen and M. Rossi, MetaEdit+ A Fully configurable multi-user and multi-tool CASE and CAME environment, in CAiSE'96, Heraklion 1996.

[LEI97] Lei, Y. and M.P. Singh, A comparison of Workflow Metamodels, in Entity-Relationship (ER'97) Los Angeles 1997.

[LESU98] Lesueur, B., N. Revault, G. Sunyé, and M. Ziane, Using the MétaGen Modeling and Development Environment, in the FIBOF-Esprit Project, in ECOOP'98-Automating the Object-Oriented Software Development Workshop, Bruxelles 1998.

[MISS98] Missaoui, R., H. Sahraoui and R. Godin, Migrating to an Objetct-oriented Database using Semantic clustering and Transformation rules, à paraître dans Knowledge and Data Engineering, 1998.

[NIER95] Nierstrasz, O., L. Dami, Component oriented software technology, in Oriented object software composition, Prentice Hall 1995.

[ODEL94] Odell, J.J., Specifying requirements using rules, in Journal of Object-Oriented Programming, 1994.

[PREM95] Premerlani, W., Metamodeling, in TOOLS Europe 95 Tutorials, Versailles 1995.

[REV96] Revault, N., Principes de méta-modélisation pour l'utilisation de canevas d'applications à objets (MétaGen et les frameworks), Thèse, Université Pierre et Marie Curie, Paris 1996.

[REVA95] Revault, N., H. Sahraoui, G. Blain, and J.-F. Perrot, A Metamodeling Technique: The MétaGen System, in TOOLS 16, Versailles 1995, pp. 127-139.

[ROCH83] Rochfeld, A. and H. Tardieu, MERISE, An Information System Design and Development Methodology, Information & Management, 1983, p. 143-159.

[RUMB91] Rumbaugh, J., et al., Object-Oriented Modeling and Design, Prentice Hall 1991.

[SAHR95] Sahraoui, H., Application de la méta-modelisation à la génération des outils de conception et de mise en œuvre des bases de données, Thèse, Université Pierre et Marie Curie, Paris 1995.

[SAHR98] Sahraoui H., N. Revault, G. Blain, and J.-F. Perrot, Un outil pour la conception des base de données à objets, Technique et Science Informatique (TSI), 17, 1998.

[SUNY99] Sunyé, G., Développement d'applications à l'aide de patrons de conception, in Langages et Modèles à Objets, in LMO'99 (Hermès, Paris), Villefranche s/ mer 1999.

[SUNY97] Sunyé, G., H. Sahraoui, B. Lesueur, and G. Blain, Chroniques d'implémentation d'un méta-outil en Smalltalk, L'Objet (Paris), 3, 1997, pp. 411-427.