Rapport PDF

Systèmes multi agents
MediMAS
Etude de cas
dans le domaine du E-Health Care
T  B
A R
Septembre 2007
Supervisé par :
Prof. Dr. Jacques P-R
et
Minh Tuan N
Groupe Génie Logiciel
Dr. Patrik F

Département d’Informatique
Université de Fribourg (Suisse)
Remerciements
Je tiens à remercier Nathalie Abbet, qui m’a soutenu durant toutes mes études et en
particulier pendant mon travail de Bachelor.
ii
Résumé
Les systèmes multi-agents prennent une place de plus en plus importante avec une
communauté grandissante. Certains voient dans ces systèmes un concurrent sérieux
des “Web-services” dans de nombreux domaines. Le but de cet travail est de faire une
mise au point de ces technologies.
Une première partie sera consacrée à une introduction théorique. Cette partie présente
les outils de développement ainsi que les méthodologies utilisées dans la conception
d’un système multi-agents.
Une deuxième partie sera consacrée à l’implémentation d’un exemple tiré du domaine
de l’eHealth-Care. Ce domaine se prête bien pour un système multi-agents du fait
qu’il implique beaucoup de tâches répétitives nécessitant l’intervention de plusieurs
acteurs.
Mots clés : Systèmes multi-agents, Ontologie, Jade, Jack, Protégé, GAIA, MaSE, FIPA,
Java, eHealth-Care, eXtreme Programming
iii
Table des matières
1. Introduction 1
1.1. Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Principaux concepts 5
2.1. Notion d’un agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Points de vue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1. Les agents comme design pattern . . . . . . . . . . . . . . . . . . 10
2.4.2. Les agents comme simulation sociale . . . . . . . . . . . . . . . . 11
2.5. Critique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5.1. Différences avec les systèmes distribués . . . . . . . . . . . . . . . 11
2.5.2. Différences avec l’intelligence artificielle . . . . . . . . . . . . . . . 12
3. Méthodologies et Plateformes 13
3.1. Méthodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1. Gaia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.2. MaSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Plateformes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1. JACK Intelligent Agents . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2. Jade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4. eHealth-Care 32
4.1. Situation actuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2. Solution proposée - MediMAS . . . . . . . . . . . . . . . . . . . . . . . . . 39
iv
Table des matières Andreas Ruppen v
5. Implémentation 44
5.1. Ontologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2. Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.3. Comportements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.4. Distribution des comportements aux agents . . . . . . . . . . . . . . . . . 58
5.5. Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6. Utilisation du système 61
6.1. Installation & Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2. Scénario d’exemple avec captures d’écran . . . . . . . . . . . . . . . . . . 62
7. Conclusion 67
A. Diagrammes pour MaSE 70
B. Ontologie pour Jade 74
C. Fiche d’une demande d’analyse 80
D. Acronymes 82
E. Licence de la documentation 84
F. Page web du projet 85
G. CD-ROM 87
Bibliographie 90
Sites Web 92
Index 93
Liste des gures
2.1. Modèle d’un système multi-agents . . . . . . . . . . . . . . . . . . . . . . 6

2.2. Modèle BDI d’un agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Les différents modèles dans Gaia . . . . . . . . . . . . . . . . . . . . . . . 15

3.2. Le modèle des agents dans Gaia . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3. Aperçu de MaSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4. Un diagramme de rôles généré avec agentTool . . . . . . . . . . . . . . . . 20
3.5. Diagramme de tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6. Interaction des différents composants de JACK . . . . . . . . . . . . . . . 23
3.7. JACK tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.8. Vue d’ensemble de JADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.9. JADE Remote Monitoring Agent . . . . . . . . . . . . . . . . . . . . . . . 27
3.10. JADE Dummy Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.11. JADE Introspector Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.12. JADE Sniffer Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.13. JADE DF GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.14. Protégé, un éditeur d’ontologies . . . . . . . . . . . . . . . . . . . . . . . 31
4.1. Fonctionnement actuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2. Système de communication actuel . . . . . . . . . . . . . . . . . . . . . . 35
4.3. Cas normal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4. Cas spécifique 1 : Médecin téléphone au laboratoire et demande le ré-
sultat d’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5. Cas spécifique 2 : Laborantin téléphone au médecin traitant et lui com-
munique le résultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.6. Cas critique : Laborantin téléphone au médecin et l’informe des résultats
obtenus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.7. Système actuel intégrant une solution basée sur un système multi-agents 40
4.8. Cas normal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
vi
Liste des figures Andreas Ruppen vii
4.9. Echange de messages lors d’un résultat critique . . . . . . . . . . . . . . 42

4.10. Communications lorsque des messages périmés sont détectés . . . . . . 43
5.1. Méthodologie utilisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2. Vue d’ensemble de l’ontologie . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3. Les concepts du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.4. Les actions du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.5. Les prédicats du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.6. Aperçu des types des comportements disponibles dans Jade . . . . . . . 52
5.7. La conversation sendResult . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.8. Envoi d’un résultat critique . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.9. Confirmation d’un résultat critique . . . . . . . . . . . . . . . . . . . . . . 55
5.10. Recherche de nouveaux résultats sur le serveur . . . . . . . . . . . . . . . 56
5.11. Recherche de nouveaux résultats avec refus du serveur . . . . . . . . . . 57
5.12. Confirmation d’un résultat . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.1. Lancement de la plateforme . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.2. Communications lors du lancement d’un agent . . . . . . . . . . . . . . . 65
6.3. Interfaces des agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.4. Envoi d’un résultat et enregistrement dans la base de données . . . . . . 66
6.5. Consultation d’un résultat par un médecin . . . . . . . . . . . . . . . . . 66
7.1. Publication, découverte et utilisation d’un service web . . . . . . . . . . 68

7.2. Service web vs. système multi-agents . . . . . . . . . . . . . . . . . . . . . 69
A.1. Diagramme d’hiérarchie des buts . . . . . . . . . . . . . . . . . . . . . . . 70

A.2. Diagramme de tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.3. Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
A.4. Diagramme de classe d’agents . . . . . . . . . . . . . . . . . . . . . . . . . 71
A.5. Diagramme de classe de communications . . . . . . . . . . . . . . . . . . 72
A.6. Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . 73
C.1. Fiche d’une demande d’analyse . . . . . . . . . . . . . . . . . . . . . . . . 81
F.1. Capture d’écran du site du projet . . . . . . . . . . . . . . . . . . . . . . . 86
G.1. Contenu du cdrom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

G.2. Le cdrom du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Liste des tableaux
2.1. Types d’agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Modèle des rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Communications possibles . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1. Comportements et participants . . . . . . . . . . . . . . . . . . . . . . . . 60
viii
Liste des codes source
2.1. Extrait d’une ontologie en Jade . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1. Extrait d’un fichier JAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1. Création d’un agent minimaliste . . . . . . . . . . . . . . . . . . . . . . . 51
5.2. Code source d’un comportement . . . . . . . . . . . . . . . . . . . . . . . 51
B.1. Ontologie pour Jade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
ix
Introduction
1
“Man, the living creature, the creating individual, is always more important than any
established style or system. ”
- Bruce Lee
1.1. Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Avec la croissance rapide d’Internet, la demande d’être connecté et d’avoir accès à ses
documents et à des services a énormément augmenté. Les systèmes multi-agents et les
technologies liées aux agents se sont fortement développés ces dernières années. Cet
article essaie de donner un aperçu de ce qui se fait dans ce domaine. En partant des
bases théoriques de cette nouvelle technologie, le lecteur découvrira quelques outils
connus ainsi que leur utilisation à travers une étude de cas. Cette première partie
situe la problématique et les défis de l’informatique moderne ainsi que les objectifs du
présent travail.
1.1. Problématique
L’informatique s’intéresse depuis toujours à cinq champs d’études, à savoir :
• l’omniprésence (ubiquité),
• l’interconnexion,
• l’intelligence,
• la délégation et
• l’interface homme-machine.
Le terme omniprésence1 prend de plus en plus d’ampleur avec le prix des ordinateurs
qui chute et leur taille qui diminue. Ce que l’on entend par le terme omniprésent est tout
ordinateur situé dans un endroit inhabituel. Un exemple d’ordinateur omniprésent est
1 engl ubiquitous
1
1.1. PROBLÉMATIQUE Andreas Ruppen 2
la voiture. En effet une voiture moderne peut contenir jusqu’à 50 microprocesseurs2 .

Une autre application d’ordinateurs omniprésents est un lave-vaisselle, bien que sa
puce soit très primitive. Il y a quelques années on parlait d’ordinateur personnel.
Le “personnel” exprimait le fait que l’ordinateur appartenait à une seule personne.
Aujourd’hui on se rend compte qu’on ne peut plus parler de l’ordinateur personnel
puisqu’une personne possède en général plusieurs ordinateurs. Cette multiplication
d’ordinateurs ne s’exprime pas uniquement en une multiplication de l’Ordinateur, mais
plutôt en une spécialisation des appareils. Ainsi, tout le monde possède un téléphone
mobile. Il peut être vu comme une sorte d’ordinateur (système d’exploitation, exécute
des programmes, etc.), mais il remplit une fonction très précise (téléphoner).
L’interconnexion est un domaine de recherche active depuis de nombreuses années.
On s’y intéresse depuis les débuts d’ARPANET. Internet en est sûrement le représentant
le plus connu. En effet internet est un système distribué pour documents HTML par
exemple. D’autres systèmes distribués se basent sur Internet par exemple les clients
p2p (Napster, Gnutella). Ces systèmes ont prouvé le succès des systèmes distribués.
De nos jours presque tout le monde est connecté. Des services de stockage de données
sur internet deviennent de plus en plus populaires et montrent qu’il y a un certain
besoin d’avoir accès à ses documents en tous lieux et à n’importe quel moment. Si on
extrapole cette tendance, on peut dire que les systèmes distribués seront la norme dans
quelques années.
Depuis toujours l’homme a essayé de créer la machine à son image. Étant donné
que l’être humain est intelligent, il semble évident qu’il a essayé de donner cette même
intelligence à la machine. D’un point de vue pratique, il s’avère que certains problèmes
sont extrêmement simples à résoudre pour un être humain, alors qu’ils sont difficiles
pour un ordinateur (par exemple, faire une démonstration mathématique simple).
L’intelligence artificielle est donc un point de départ pour trouver des solutions à ce
genre de problèmes. On verra plus loin d’autres applications de l’intelligence artificielle
dans le cadre de développement de systèmes multi-agents.
Les ordinateurs ont une place importante dans notre société. Dans beaucoup de situa-
tions, on pense que l’ordinateur est plus fiable que l’être humain et c’est lui qui prend
les décisions (pilote automatique dans un avion) à la place de l’homme. On lui délègue
notre travail.
Des chercheurs comme le docteur Douglas C. Engelbart se sont déjà penchés sur la
question de l’interface homme-machine et sur la manière l’améliorer. L’augmentation
incessante de la puissance de calcul nous ouvre de nouvelles voies dans ce domaine.
Ainsi, les interfaces deviennent de plus en plus intuitives à utiliser (au moins en
théorie. . .). Ils reflètent la manière dont réfléchit l’homme. Ainsi, on marque le passage
de l’opérateur basculant des interrupteurs sur le tableau de contrôle vers le terminal,
puis vers la fenêtre avec une souris et vers les écrans tactiles et des interfaces plus
évolués que l’on trouve maintenant dans les dernières consoles de jeux par exemple.
L’interconnexion et la distribution forment depuis longtemps le domaine d’intérêt de
nombreux chercheurs. L’approche orientée agents apporte néanmoins d’autres pro-
blèmes qui ne sont ni couverts par l’interconnexion ni par la distribution de systèmes.
En effet dans un système multi-agents il est fort probable que deux agents distincts
ont des intérêts distincts. Pour atteindre leur but, ils doivent coopérer et trouver des
2 Le lecteur intéressé trouvera plus d’information sur [5]
1.2. OBJECTIFS Andreas Ruppen 3
arrangements. Ce domaine de recherche ouvre de toutes nouvelles perspectives. Ainsi

les systèmes multi-agents soulèvent deux problèmes :
• Comment construire des agents autonomes et indépendants ?
• Comment construire des agents capables d’interagir et de coopérer avec d’autres
agents.
Ce n’est donc pas une intelligence artificielle qui importe, mais plutôt un comportement
que l’on pourrait qualifier «d’intelligence sociale».
1.2. Objectifs
Ce travail vise à se familiariser avec les agents et les technologies qui y sont liées. Ceci
comporte plusieurs aspects. Il y a d’un côté les outils et méthodologies (voir chapitre 3)
et de l’autre la théorie des agents (voir section 2.1). La théorie des agents s’intéresse
de près au modèle cognitif des agents. Comprendre la théorie des agents dépasserait
largement le but de ce travail. Le chapitre 2 donne néanmoins un bref aperçu de
quelques notions fondamentales nécessaires pour comprendre ce travail. Une autre
partie est consacrée à l’étude des méthodologies de conception de systèmes multi-
agents. Le chapitre 3 présente plus en détail les méthodologies GAIA (voir section 3.1.1)
et MaSE (voir section 3.1.2). Afin de passer de la théorie à un système multi-agenst
(SMA) concret, il faut un cadriciel3 adapté à la problématique des agents. Certaines
méthodologies disposent de leur propre cadriciel comme c’est par exemple le cas pour
MaSE avec agentTool, d’autres sont plus génériques. La section 3.2 discute plus en
détail de ces cadriciels et en donne quelques exemples. Il est possible de développer
des SMA dans de multiples langages. Il ne faut cependant pas oublier que les outils
orientés objet ne suffisent pas. En effet, les agents demandent une nouvelle approche
orientée agent et du coup de nouveaux outils. Les deux derniers chapitres montrent
comment développer et déployer un SMA réel. Il s’agit de mettre en place un système de
communication pour un hôpital et un laboratoire (en l’occurrence l’hôpital cantonal de
Fribourg et le laboratoire cantonal de Fribourg). Chaque médecin et chaque laborantin
disposent d’un agent. L’agent d’un médecin peut transmettre une demande d’analyse
au laboratoire tandis que l’agent d’un laborantin peut transmettre les résultats d’une
analyse au médecin traitant ou tout autre médecin selon une hiérarchie à définir.
1.3. Conventions
Afin de faciliter la lecture et la compréhension de ce travail, les figures qui ont été
tirées d’autres ouvrages ont été traduites en français et souvent adaptées aux besoins.
La source originale est toujours mentionnée dans une note de bas de page.
Les noms propres sont écrits en italique lorsqu’on fait référence à un produit commer-
cialisé (par exemple GAIA). Cependant des termes plus généraux comme “système
multi-agents” ne sont pas écrits en italique puisqu’ils ne font référence à aucun produit
particulier.
3 engl. framework
1.3. CONVENTIONS Andreas Ruppen 4
Dans le souci le préserver la langue française la majorité des termes informatiques

ont été traduits en français. Il est néanmoins possible que des termes anglais aient été
choisis dans le but d’augmenter la lisibilité. Pour préserver l’aspect du document ces
derniers ne sont ni mis en évidence ni entre guillemets. Il est laissé aux bons soins du
lecteur intéressé de se référer aux notes de bas de page ou entre parenthèses pour les
traductions.
Principaux concepts
2
“Knowledge will give you power, but character respect.”
- Bruce Lee
2.1. Notion d’un agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2. Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Points de vue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1. Les agents comme design pattern . . . . . . . . . . . . . . . . . 10
2.4.2. Les agents comme simulation sociale . . . . . . . . . . . . . . . 11
2.5. Critique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5.1. Différences avec les systèmes distribués . . . . . . . . . . . . . . 11
2.5.2. Différences avec l’intelligence artificielle . . . . . . . . . . . . . . 12
2.1. Notion d’un agent

Comme cités dans l’introduction les cinq champs d’étude majeurs en informatique,
sont :
• l’omniprésence,
• les interfaces homme-machine
Créer des systèmes interconnectés apporte son lot de problèmes qu’une approche
classique non distribuée ne sait résoudre. On rencontre par exemple les problèmes
de synchronisation, ou d’accès à une ressource partagée. Depuis quelques années
déjà on a compris que des systèmes omniprésents et interconnectés sont l’avenir de
l’informatique. Beaucoup de recherches sont menées dans ce domaine. Des solutions
ont été trouvées pour un certain nombre de problèmes d’autres restants toujours sans
5
2.1. NOTION D’UN AGENT Andreas Ruppen 6
solutions. Si on couple un système distribué avec la contrainte que chaque noeud doit
représenter et défendre ses propres intérêts, les choses se compliquent. En effet, il est
fort probable que deux noeuds différents aient des intérêts différents. Ils doivent donc
être capables de coopérer pour trouver un consensus et pouvoir évoluer. Ce type de
problème est assez récent et peu d’efforts ont été investis dans ce domaine jusqu’à
présent. Donc qu’est-ce qu’un agent ? Est-il intelligent ? Autonome ? Peut-il s’adapter ?
Avant de continuer, posons quelques définitions :
[Agent] : Un agent est une entité (physique ou non) autonome capable de communiquer
avec d’autres agents et d’évoluer selon son modèle cognitif dans un environnement
duquel il possède une certaine représentation. Un agent travaille à la place de son
maître. Il doit être capable de comprendre ce qu’il doit faire pour satisfaire les besoins
de son maître.
[Agent logiciel] : On regroupe sous le terme d’agent logiciel tous les agents dont la
base est un programme informatique.
[Système multi-agents] : Un système multi-agents est un système fermé de plusieurs
agents interagissant entre eux. L’interaction se fait généralement par des messages. La
plupart du temps les agents agissent dans l’intérêt de leur maître. Leurs intérêts ne se
chevauchent pas forcément. Il s’agit donc de coordonner leurs actions et de négocier
afin de trouver une solution qui satisfasse tout le monde.
F. 2.1.: Modèle d’un système multi-agents(tiré de [Fer99])
[Modèle cognitif] : Certains agents sont dotés d’une certaine intelligence. Cette intel-
ligence se trouve dans le système cognitif de l’agent. Ce système décrit le processus
de raisonnement de l’agent. Il existe plusieurs modèles pour décrire le comportement
cognitif. Le plus connu est certainement le modèle BDI (croyances — désirs — inten-
tions). Comme son nom l’indique, il part du principe que ce qui fait avancer un agent
ce sont ces croyances et désirs mélangés à son intention.
Wikipedia est un bon exemple d’un système multi-agents. Les agents sont les individus
participant à la richesse de Wikipedia. Le but du système est la création d’une grande
source d’informations. Mais chaque agent à ses propres opinions. C’est pour cela que
certains articles de Wikipedia changent régulièrement et le point de vue exposé varie en
fonction du dernier auteur. Afin de faire évoluer le système malgré ces différences, un
autre type d’agent a été introduit, celui des opérateurs. Pour certains sujets ils doivent
vérifier chaque modification avant d’accepter la publication.
2.2. ONTOLOGY Andreas Ruppen 7
F. 2.2.: Modèle BDI d’un agent (tiré de [HNSP97])
2.2. Ontology
Une ontologie est un ensemble structuré formé de concepts, d’actions et de prédicats.
Les concepts, comme leur nom l’indique, donnent un sens à l’information. Les actions
et prédicats se basent sur le sens que donnent les concepts à l’information. Une action
est une opération. Elle définit en même temps le contenu de l’opération. Si un agent
A envoie une action à un agent B cela exprime le fait que l’agent A aimerait que
l’agent B exécute l’action spécifiée. L’agent B peut avoir besoin d’un certain nombre
d’informations relatives à cette action. Pour que A et B se comprennent il faut que ces
informations respectent un certain ordre. Un prédicat est similaire à une action à la
différence près que la réponse d’un prédicat soit toujours vraie ou fausse alors qu’une
action ne nécessite pas forcément de réponse.
Lorsqu’on définit une ontologie, il est important de procéder dans l’ordre. On ne
peut définir les actions et les prédicats si on n’a pas défini les concepts auparavant.
On retrouve dans les concepts les notions de la programmation orientée objet, à savoir
l’encapsulation et l’héritage. Ceci peut sembler compliqué à première vue, mais s’avère
très performant lorsque l’ontologie devient grande et que des “objets” commencent
à se répéter. L’ontologie est donc la base de toute communication entre agents. Le
listing 2.1 montre une manière de représenter une ontologie.
1 public class h o s p i t a l O n t o l o g y extends Ontology
{
p r i v a t e s t a t i c f i n a l Ontology i n s t a n c e = new h o s p i t a l O n t o l o g y ( ) ;
14
2.2. ONTOLOGY Andreas Ruppen 8
public s t a t i c f i n a l S t r i n g NAME = " h o s p i t a l −o n t o l o g y " ;

16
/ / Concepts
18 public s t a t i c f i n a l S t r i n g ADRESSE = "ADRESSE" ;
20 public s t a t i c f i n a l S t r i n g ADRESSE_STREET = " street " ;
22 public s t a t i c f i n a l S t r i n g ADRESSE_NUMBER = " st r ee t nu m b er " ;
24 public s t a t i c f i n a l S t r i n g ADRESSE_CITY = " city " ;
26 public s t a t i c f i n a l S t r i n g ADRESSE_COUNTRY = " country " ;
/ / Predicates
113 public s t a t i c f i n a l S t r i n g IS_RESULT_READY = " ready " ;
115 public s t a t i c f i n a l S t r i n g IS_RESULT_READY_PATIENT = " patient " ;
117 public s t a t i c f i n a l S t r i n g IS_CRITICAL = " critical " ;
119 public s t a t i c f i n a l S t r i n g IS_CRITICAL_RESULT = " criticalResult " ;
121 / / Actions
public s t a t i c f i n a l S t r i n g SEND_URGENT = " sendUrgent " ;
123
public s t a t i c f i n a l S t r i n g SEND_URGENT_RESULTS = " result " ;
public s t a t i c Ontology g e t I n s t a n c e ( )
173 {
return instance ;
175 }
177 private hospitalOntology ( )

{
179 super (NAME, BasicOntology . g e t I n s t a n c e ( ) ) ;
try
181 {
/ / Concepts
183 t h i s . add (new ConceptSchema (ADRESSE) , Adresse . class ) ;
197 ConceptSchema cs = ( ConceptSchema ) t h i s . getSchema (ADRESSE) ;

cs . add (ADRESSE_STREET, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) , ObjectSchema .
MANDATORY) ;
199 cs . add (ADRESSE_NUMBER, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . INTEGER ) , ObjectSchema .
MANDATORY) ;
cs . add ( ADRESSE_CITY , ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) , ObjectSchema .
MANDATORY) ;
201 cs . add (ADRESSE_COUNTRY, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) , ObjectSchema .
MANDATORY) ;
267 / / Predicates
t h i s . add (new PredicateSchema ( IS_RESULT_READY ) , IsResultReady . class ) ;
269 t h i s . add (new PredicateSchema ( IS_CRITICAL ) , I s C r i t i c a l . class ) ;
271 PredicateSchema ps = ( PredicateSchema ) t h i s . getSchema ( IS_RESULT_READY ) ;

ps . add ( IS_RESULT_READY_PATIENT , t h i s . getSchema ( PATIENT ) ) ;
273
ps = ( PredicateSchema ) t h i s . getSchema ( IS_CRITICAL ) ;
275 ps . add ( IS_CRITICAL_RESULT , t h i s . getSchema (RESULT) ) ;
277 / / Actions
t h i s . add (new AgentActionSchema (SEND_URGENT) , SendUrgent . class ) ;
AgentActionSchema as = ( AgentActionSchema ) t h i s . getSchema (SEND_URGENT) ;

290 as . add (SEND_URGENT_RESULTS, ( ConceptSchema ) t h i s . getSchema (RESULT) , ObjectSchema .MANDATORY) ;
2.3. CONTEXTE Andreas Ruppen 9
} catch ( On tol og yEx ce pti on oe )

331 {
oe . p r i n t S t a c k T r a c e ( ) ;
333 }
}
335 }
Listing 2.1: Extrait d’une ontologie en Jade
2.3. Contexte
L’histoire des agents peut être vue comme la rencontre de plusieurs domaines. Les plus
connues sont probablement l’intelligence artificielle distribuée (AID) et la vie artificielle
(AL). L’un se consacre à l’étude de la manière de résoudre des problèmes alors que
l’autre se focalise sur des questions de survie et d’adaptation. On voit déjà que ces
deux domaines sont liés. L’histoire se divise en général en trois parties. La première,
les débuts, tourne autour des travaux de Kornfeld et Hewitt [Hew77] dans les années
septante. Le facteur influant de cette période est certainement l’intelligence artificielle.
Le moyen-âge désigne la deuxième partie qui commence au milieu des années huitante
et qui va jusqu’au début des années nonante. L’élément qui a marqué cette époque est la
vie artificielle. Gasser met en évidence dans ses travaux l’influence de la vie artificielle et
le fait qu’une structure sociale ne peut pas se réduire à un problème de communication.
La troisième période et celle qui perdure encore. Le mouvement commence à prendre
de l’ampleur. Des cadriciels commencent à voir le jour (jade : 2000, jack 2001, visualbots
2006. . .).
Est-ce qu’il faut voir un agent comme une entité intelligente, capable de raisonner et de
résoudre des problèmes seul ou faut-il voir un agent comme quelque chose de primitif,
réagissant directement aux stimuli externes (changements dans l’environnement) ? La
problématique se résume donc autour des tendances : cognitif vs réactif. Les agents
cognitifs sont largement adoptés par les chercheurs du domaine de l’intelligence arti-
ficielle distribuée. Pour eux un agent possède une base de savoir qui contient tout ce
qui est nécessaire pour accomplir sa tâche et pour communiquer avec d’autres agents.
Un agent possède également des intentions qui l’aident à accomplir sa mission. L’autre
tendance adopte les agents réactifs et dit qu’il n’est pas absolument nécessaire qu’un
agent soit intelligent pour que le mouvement de l’ensemble des agents présents donne
l’impression d’intelligence. Les agents réagissent aux stimulus externes sans prendre
en considération un but ou une stratégie quelconque. Un exemple souvent cité est
celui d’une fourmilière. Même si une fourmi seule ne peut pas être considérée comme
étant intelligente le mouvement de l’ensemble des fourmis dans une fourmilière donne
l’impression d’intelligence.
Le tableau 2.1 résume la discussion ci-dessus et montre les quatre types d’agents
possibles. Un agent cognitif a un comportement télémonique s’il tente d’accomplir des
buts fixes. Si par contre un agent possède une idée précise de son environnement, mais
n’a pas de but concret on appelle son comportent réflexe. De tels agents peuvent servir
à d’autres agents pour se renseigner sur l’état actuel de l’environnement. Un agent
réactif a aussi un but. On départage les deux catégories selon la source de motivation.
2.4. POINTS DE VUE Andreas Ruppen 10
Agent cognitif Agent réactif

Comportement télémoniquea intentionnel pulsionnel
Comportement réflexe modules tropique
T. 2.1.: Types d’agents

a granddictionaire.com : Relatif aux structures comportementales commandées par un objectif
On dit qu’il a un comportement télémonique si la source de motivation est interne.

Dans le cas contraire l’agent a un comportement réflexe, d’où leurs noms.
Un système multi-agents (SMA) est un système composé de plusieurs agents qui
interagissent dans le but d’accomplir une mission. Cette mission peut être globale, c’est-
à-dire une même mission pour tout le système ou bien individuelle. Un exemple de
mission globale est la résolution d’une tâche qui se subdivise en sous-tâches tandis que
l’étude de cas eHealth-Care1 est un exemple d’un système multi-agents avec missions
individuelles. Le domaine des SMA est l’étude des interactions entre ces agents.
2.4. Points de vue

L’étude de systèmes multi-agents est un champ d’étude interdisciplinaire. Au cours
de cette introduction, on a déjà rencontré plusieurs domaines de l’informatique clas-
sique. On a ainsi rencontré les systèmes distribués à travers le déploiement des agents,
l’intelligence artificielle à travers le modèle cognitif et la communication. Il n’est donc
pas étonnant que plusieurs points de vues soient possibles. Dans ce qui suit, on va
rencontrer deux grands points de vues.
2.4.1. Les agents comme design pattern

Des recherches ont montré que la caractéristique la plus importante d’un programme
complexe est l’interaction. En effet dès qu’un programme quitte le stade d’un petit
script simple il commence à interagir avec d’autres programmes, bibliothèques et res-
sources. Il s’avère très difficile de créer des programmes corrects qui font intervenir des
composants dynamiques utilisant des protocoles de coordination complexes. La diffi-
culté augmente avec le degré de complexité des protocoles et le degré de dynamisme
des composants. Néanmoins il s’avère qu’énormément d’applications réelles possèdent
justement cette caractéristique, d’où la nécessité de développer des techniques et des
outils qui guident le développeur et permettent de modéliser des systèmes où l’inter-
action est la norme. Dans cette optique on pourrait même s’imaginer que la notion
même de calcul devienne un processus d’interaction. La tendance est aujourd’hui aux
systèmes de plus en plus omniprésents et interconnectés. Il faut des outils pour déve-
lopper ce type de système. Le développement de paradigmes capables d’exploiter la
puissance de tels systèmes est probablement le plus gros challenge du 21e siècle pour
l’informatique. Il paraît que justement les agents sont d’excellents candidats pour un
tel paradigme.
1 voir section 4
2.5. CRITIQUE Andreas Ruppen 11
2.4.2. Les agents comme simulation sociale

On a déjà vu à plusieurs reprises que le développement de systèmes multi-agents est
un domaine interdisciplinaire. On y trouve notamment les aspects de l’intelligence
artificielle et une certaine notion d’individu. Cette notion est à la base même d’un
système multi-agents puisque, comme le stipule la définition ci-dessus, chaque agent
a ses propres croyances et buts. De là à faire des simulations de comportement social,
il n’y a qu’un seul pas à franchir. En effet les technologies multi-agents apportent une
approche nouvelle et intéressante à ce problème. Un exemple d’une telle utilisation
de systèmes multi-agents est le projet EOS (Doran et Palmer, 1995 [DP95]). Le but de
ce dernier était de voir comment le comportement social émerge dans une société du
paléolithique dans le sud de la France. Le but n’était pas de simuler directement ces
sociétés, mais plutôt de comprendre les facteurs déterminants dans l’établissement des
structures sociales. On n’en est bien sûr pas encore au point où il nous serait possible
de prédire le comportement de l’humanité comme le décrit Isaac Asimov dans son
livre Fondation [Asi00]. En effet, la psychohistoire relève de la pure science-fiction.
2.5. Critique
Le domaine des systèmes multi-agents est tellement vaste et englobe tellement de
disciplines qu’il y a des gens qui restent sceptiques. Il y a des voix qui se lèvent disant
qu’au final ce n’est rien d’autre que de l’intelligence artificielle, ou d’autres encore
qui disent que les systèmes multi-agents sont un domaine des systèmes distribués. En
réalité les deux points de vues sont justes.
2.5.1. Différences avec les systèmes distribués

Les systèmes distribués forment depuis longtemps l’objet de recherches intenses. Ses
propriétés ont été analysées et étudiées sous tous les angles. Partant de la définition
ci-dessus d’un système multi-agents il paraît clair qu’il forme un sous-ensemble des
systèmes distribués. C’est pour cette raison que certains doutent qu’il soit nécessaire
de traiter les systèmes multi-agents à part. Ils pensent qu’ils ne présentent pas assez de
différences avec un système distribué classique pour justifier une séparation entre les
deux domaines. En effet le développeur qui ne demande pas conseil à un spécialiste des
systèmes distribués va inévitablement rencontrer des problèmes déjà résolus comme
l’accès à des ressources partagées, les verrous mortels, etc. Les systèmes multi-agents
possèdent néanmoins deux grandes différences avec les systèmes classiques.
Un agent peut être vu comme entité autonome qui est capable de raisonner, de prendre
des décisions et d’agir en fonction de ses croyances. Ces décisions sont prises de manière
indépendante dans le sens qu’aucun agent ne peut décider à la place d’un autre agent
ce qu’il doit faire. Les problèmes liés à la synchronisation et à la coordination persistent,
mais sont décalés. Contrairement à des systèmes classiques où la synchronisation est
définie avant de lancer le système, il faut des moyens plus dynamiques pour les
systèmes multi-agents.
L’autre différence concerne les échanges entre les entités du système. Dans un sys-
tème multi-agents tous les échanges peuvent être qualifiés d’économiques, terme à com-
2.5. CRITIQUE Andreas Ruppen 12
prendre dans le sens d’un échange où les partenaires sont auto-intéressés. Dans un
système distribué, tous les noeuds participent à l’accomplissement du but du système.
Les noeuds eux-mêmes ne possèdent pas d’envies ou d’intérêts personnels. Dans un
système multi-agents ce n’est pas le cas. Chaque agent défend d’abord ses propres
intérêts.
2.5.2. Différences avec l’intelligence artificielle

Les systèmes multi-agents sont fortement liés avec le domaine de l’intelligence artifi-
cielle. Il est courant de dire que l’étude de systèmes multi-agents est un des nombreux
domaines de l’intelligence artificielle. Selon le point de vue que l’on adopte, on peut
aussi affirmer le contraire. De plus en plus on choisit une position intermédiaire. On
définit le but de l’intelligence artificielle comme la construction d’un agent intelligent2 .
On identifie souvent l’intelligence artificielle avec les composants de l’intelligence (ie.
la capacité d’apprendre, de comprendre et de faire des plans). Un agent doit bien sûr
intégrer ces capacités. On est donc amené à dire que pour résoudre le problème des
agents on doit d’abord résoudre tous les problèmes de l’intelligence artificielle. En effet
on peut croire que pour construire un agent intelligent il faut d’abord résoudre le pro-
blème de l’apprentissage, le problème de raisonnement, le problème de planification,
etc. Il n’en est point. Le développement d’un agent intelligent c’est nonante-neuf pour
cent de génie logiciel et un pour cent d’intelligence artificielle. Quand on développe
un agent, on se base certes sur les technologies de l’intelligence artificielle sans pour
autant faire appel à tous ses domaines.
2 Ilest important de se rappeler qu’un agent est une entité quelconque. Ainsi, un robot peut être un
agent.
Méthodologies et Plateformes
3
“If you spend too much time thinking about a thing, you’ll never get it done. ”
- Bruce Lee
3.1. Méthodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1. Gaia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.2. MaSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Plateformes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1. JACK Intelligent Agents . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2. Jade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
En général on peut décomposer le développement d’un logiciel en plusieurs étapes.

En XP1 par exemple les étapes sont, dans l’ordre : choix des stories, création des
tests, implémentation, refactoring. On peut dire de manière générale qu’il y a quatre
phases dans le développement d’un logiciel. On peut résumer ces phases comme suit :
(i) planification, (ii) analyse, (iii) design et (iv) implémentation.
3.1. Méthodologies
Le développement de systèmes multi-agents est un domaine encore relativement nou-
veau. Néanmoins, il existe déjà beaucoup de méthodologies que l’on peut suivre. Toutes
ces méthodologies ont cependant un point faible : elles ne sont pas assez générales.
Chaque méthode s’applique très bien à un champ de SMA défini, mais pas en dehors.
Il y a des méthodes qui sont spécialisées dans la conception d’agents cognitifs, il y
en a d’autres qui sont plutôt spécialisées dans le domaine des agents réactifs. A côté
de cela il y a une troisième catégorie de méthodes : ce sont les méthodes qui sont
accompagnées d’un cadriciel. MaSE en est un exemple.
1 eXtreme Programming
13
3.1. MÉTHODOLOGIES Andreas Ruppen 14
3.1.1. Gaia
Le nom Gaia vient de “Generic Achitecture for Information Availability”. Elle a été dé-
veloppée par Michael Wooldridge, Nich Jennings et David Kinny (voir aussi [Woo04] et
[WJK00]). Gaia se veut assez générale pour s’appliquer à une large palette de situations,
facile à comprendre et simple à mettre en oeuvre. Dans le but d’atteindre ces objectifs
Gaia n’est pas liée à une plateforme, ni à un langage de communication. Pour que Gaia
soit la méthode adaptée au développement d’un agent il faut, selon ses concepteurs
qu’elle ait les caractéristiques suivantes :
• On peut supposer que les agents ont un comportement coopératif. Les buts communs
au système auront toujours une priorité supérieure aux buts individuels.
• L’organisation et la nature des relations entre agents sont statiques et n’évoluent pas
avec le système.
• Les agents peuvent être de natures hétérogènes, c’est-à-dire, qu’ils peuvent provenir
de cadriciels différents utilisant des langages distincts.
• Les services et capacités d’un agent sont statiques et n’évoluent pas dans le temps.
• Le nombre de types d’agents est relativement petit (≤ 100).
• Un agent a besoin d’une quantité importante de ressources.
Gaia exclut donc d’office des systèmes dans lesquels il y a des agents avec des interac-
tions variables. Elle exclut aussi des systèmes avec beaucoup d’agents légers comme
c’est le cas par exemple pour des simulations.
Dans Gaia il y a deux niveaux d’abstractions :
• un macro-niveau qui s’occupe des relations et des communications entre les agents
et
• un micro-niveau qui se concentre plus en détail sur un agent individuel.
Gaia essaie durant l’analyse de faire émerger des modèles concrets à partir de concepts.
C’est pour cette raison que durant toutes les phases de la méthode les deux niveaux
seront toujours présents.
Le but de Gaia est de fournir à un développeur tous les outils nécessaires afin de créer
un concept du système tellement complet qu’il peut être implémenté directement.
Pour arriver à ce stade, il faut parcourir plusieurs étapes qui partent des spécifications
et deviennent de plus en plus conceptuelles. La méthode peut être divisée en deux
grandes phases : la phase d’analyse et la phase de conception. La phase d’analyse
est décomposée en deux sous-phases : (i) le modèle des rôles et (ii) le modèle des
interactions. La phase de conception est composée de trois étapes, à savoir : (i) le
modèle des agents, (ii) le modèle des services et (iii) le modèle des relations. La
méthode présuppose une phase d’établissement des spécifications du système. Chaque
phase réduit considérablement le nombre de problèmes auxquels le modèle peut être
appliqué. A la fin le modèle ne doit plus que s’appliquer au problème spécifié ou à des
problèmes très proches. La figure 3.1 résume cette situation et montre les interactions
entre les différents modèles décrits.
Le but de la phase d’analyse est de se faire une vue d’ensemble du système. On
comprend un système à travers son organisation. Cette dernière peut s’exprimer à
travers des rôles ou des fonctions et leur interaction. Cette manière paraît naturelle
puisque dans tout système réel on peut identifier des rôles et des interactions. Ainsi
dans une université par exemple il y a des étudiants, des professeurs, un recteur, etc. . ..
Il est tout aussi naturel d’assigner plusieurs rôles à un agent. Pour reprendre l’analogie
F. 3.1.: Les différents modèles dans Gaia
avec l’université, on peut s’imaginer un étudiant qui occupe un poste de sous-assistant.

Il fait donc partie à la fois du corps enseignant et des étudiants. Toujours en se basant
sur cet exemple on arrive à concevoir qu’un rôle est défini par quatre attributs :
• ses protocoles,
• ses activités,
• ses permissions et
• ses responsabilités.
Les responsabilités déterminent les buts du rôle. Ce sont les responsabilités qui font
évoluer un rôle. Afin d’exécuter ses responsabilités, un rôle a toujours des permissions
qui lui permettent de puiser dans certaines ressources. Les activités sont des calculs
internes. Elles ne nécessitent aucune interaction avec d’autres agents. Afin de pouvoir
communiquer avec d’autres agents, il a besoin de protocoles qui définissent la forme
de la communication. On voit donc que cette phase d’analyse est subdivisée en deux :
d’une part, elle s’occupe des rôles d’autre part elle prend soin des interactions.
Le modèle des rôles définit les rôles principaux du système. Son but est de raffiner
les attributs de chaque rôle. Ses propriétés sont rassemblées dans une table comme
celle de la table 3.1. On y indique une courte description, puis les quatre attributs :
activités, responsabilités, permissions et protocoles. Les activités qui expriment les
responsabilités peuvent être combinées en utilisant des opérateurs comme “.” pour
une séquence, “|” pour l’opérateur ou et les opérateurs standards pour la cardinalité
(*,+).
Il y a certainement des interactions entre les rôles définis ci-dessus. Pour chaque
interaction qui peut avoir lieu entre deux rôles, un protocole de communication doit
être établi. Ce protocole ne définit pas le contenu concret des messages, mais plutôt
quelques attributs généraux :
• Le but de la communication.
• L’expéditeur et le destinataire.
• Les informations nécessaires durant l’échange.
• Les activités à exécuter par l’initiateur.
Il se peut que l’identification de rôles et l’établissement des modèles de rôles et des
modèles des interactions ne réussissent pas du premier coup. C’est pour cela que Gaia
prévoit un raffinement itératif du processus d’analyse. Une fois que l’on a établi les
Rôle : P
Description :
Personne engagée par l’université, touchant un salaire mensuel. Doit
assurer 1 à 2 cours et faire de la recherche en parallèle.
Protocoles et activités :
boire café, enseigner, corriger exercices, faire de la recherche
Permissions :
• changer : évaluation d’un étudiant
• lire : documents internes
Responsabilités :
• Survie : P = (boire café . corriger exercices . enseigner .
recherche )
• Sécurité : nombre de collaborateurs > 0
T. 3.1.: Modèle des rôles
modèles des interactions, il est possible de raffiner les modèles des rôles ce qui implique
peut-être un ajustement des modèles des interactions.
Le but d’un processus de conception est de traduire les concepts abstraits de la phase
d’analyse en modèle de bas niveau. Gaia se veut indépendante d’un cadriciel ou d’un
langage donné il ne s’agit donc pas de se retrouver avec du code. Le but est plutôt de
générer trois autres modèles, à savoir : le modèle des agents, le modèle des services et
le modèle des connaissances qui permettront un traitement ultérieur efficace avec des
méthodes connues comme la programmation orientée objet. Si l’on veut l’objectif de
Gaia est de définir la manière selon laquelle les agents doivent interagir pour accom-
plir les buts communs et quelles sont les conditions nécessaires pour chaque agent.
De quelle manière un agent individuel remplit sa mission n’est plus du domaine de
Gaia. C’est justement cette séparation qui permet à Gaia de rester indépendante d’une
implémentation. Voyons à présent d’un peu plus près les trois modèles générés par
cette phase du développement.
Le premier modèle est le modèle des agents. Son rôle est de documenter les types
d’agents qui surviennent dans le système final. Un type d’agent est composé d’un ou
de plusieurs rôles du modèle des rôles de la phase d’analyse. Pour des questions de
performance il est souvent souhaitable de regrouper plusieurs rôles dans un même
agent. Ceci est notamment le cas lorsque l’instance d’un agent consomme beaucoup
de ressources. De l’autre côté, il ne faut pas surcharger un type d’agent. Il est inutile
de regrouper des rôles qui sont complètement disjoints. Il faut donc faire attention à la
fois à l’efficacité du système et à sa cohérence. A côté du type, le modèle précise aussi
le nombre d’instances qui peuvent être présentes simultanément dans le système. Ceci
peut varier d’un à n avec tous les sous-ensembles possibles. La figure 3.2 montre à quoi
ressemble le modèle d’agents. Les types d’agents forment les racines des arbres alors
que les feuilles représentent les rôles incorporés par l’agent. Gaia ne gère pas l’héritage
des types d’agents. Ceci vient du fait que Gaia présuppose un système avec peu de
types d’agents. Il ne fait donc pas de sens d’introduire l’héritage.
F. 3.2.: Le modèle des agents dans Gaia
Le deuxième modèle est le modèle des services. Il définit quels services sont associés
à quels rôles et quelles sont ses propriétés. Un service correspond à une fonction ou
une méthode en terme de programmation classique. Il y a néanmoins une différence
majeure. Un service n’est pas forcément exécuté lors de la réception d’une demande
alors qu’un appel de fonction a toujours pour résultat l’exécution de cette dernière.
Chaque interaction du modèle des interactions définie dans la phase d’analyse va
se retrouver ici sous forme d’un service. Afin de définir un service, il faut spécifier
quelques propriétés. Ce sont notamment :
• les paramètres d’entrée (input),
• les valeurs de sortie (output) et
• les pré- et postconditions
L’entrée et la sortie du service découlent directement du modèle des interactions. Les
pré- et postconditions sont importantes afin de garantir les conditions de sécurité
mentionnées dans le modèle des rôles.
Le troisième modèle est le modèle des connaissances. Il permet de spécifier l’ensemble
des communications possibles dans le système. Il est fait d’un graphe orienté où les
agents sont représentés par les sommets du graphe et les communications par les arêtes.
Le modèle ne spécifie pas le type de message, ni quand et comment il est envoyé.
Comme tous les autres modèles, son but n’est pas de donner une implémentation,
mais plutôt de fournir un outil qui permet de détecter des erreurs dans la structure des
communications et de les corriger. Il est possible dans certains cas qu’il faille repasser
par une itération de la phase d’analyse pour corriger ces erreurs et donc revoir les
modèles des agents et des services.
3.1.2. MaSE
MaSE est le nom d’une méthodologie développée en 2001 par DeLoach, Wood et
Sparkman [DWS01]. Son nom veut dire “Multiagent Systems Engineering”. Comme
Gaia (voir aussi la section 3.1.1) cette méthodologie se veut très générale afin de s’appli-
quer à une multitude de cas. MaSE ne fait pas de suppositions sur l’architecture, ni sur
les canaux de communications, ni sur l’implémentation. MaSE voit un agent comme un
objet. Ces objets ne sont pas forcément intelligents. Cette méthode permet de s’adapter
à des modifications du système et des spécifications en proposant un suivi de près
(engl. change traking) à travers les étapes. Ceci étant possible grâce à des phases de
développement itératives. MaSE propose son propre outil de développement agent-
Tool2 un outil interactif et graphique. MaSE peut être vu comme une abstraction en
dessus de l’orienté objet. Contrairement à des objets avec des méthodes simples, les
agents peuvent communiquer pour coordonner leurs efforts afin d’atteindre leurs buts
individuels et aussi les buts généraux. Le développement d’un SMA avec MaSE est
divisé en deux grandes phases chacune sous-divisée en étapes. La figure 3.3 en donne
un aperçu. Les paragraphes qui suivent vont détailler de plus près ces étapes.
F. 3.3.: Aperçu de MaSE
Le but de la phase d’analyse est de produire un ensemble de rôles dont les tâches
spécifient ce que le système doit accomplir et les conditions générales du système.
On entend par “rôle” une entité qui remplit une certaine mission. Chaque rôle doit
accomplir ou aider le système à accomplir les buts définis dans la spécification du
système. Pour définir ces rôles, on fait appel aux schémas UML plus précisément aux
cas d’utilisation. Cette phase est divisée en trois étapes :
2 voir aussi [4].
1. définir une hiérarchie des buts,

2. appliquer les cas d’utilisation et
3. raffiner les rôles.
La première étape essaie à partir des spécifications du système d’en extraire les buts à
accomplir et de les structurer. Il est à noter que ces buts représentent les buts globaux
du système et non les buts individuels de chaque agent. Cette phase est commune
à tout développement de logiciel. Afin d’y arriver, il faut d’abord identifier les buts
globaux puis dans un deuxième temps les structurer.
MaSE essaie d’extraire les buts globaux à partir de spécifications du système en généra-
lisant et en cachant les détails trop spécifiques au système. Ceci permet de se concentrer
sur l’essentiel du système. Ces buts doivent décrire les aspects critiques du système
tout en restant assez abstraits. Cette abstraction permet une certaine indépendance des
spécifications du système. En effet les buts et aspects critiques sont moins sensibles aux
changements des spécifications que la description détaillée des activités nécessaires
pour accomplir une certaine tâche.
Une fois ces buts identifiés il s’agit de les structurer. Cette hiérarchie sera le fondement
de toute la phase d’analyse qui suit. La structuration de buts se fait avec un diagramme
d’hiérarchie des buts3 . Voir aussi la figure A.1. Il se présente sous forme d’un graphe
orienté, dirigé sans cycles. Afin d’établir ce diagramme il faut organiser les buts, les
identifier, les trier et les mettre en relation. Le diagramme d’hiérarchie des buts reflète
exactement cette organisation. On peut résumer cette tâche en deux sous-tâches :
(i) établir un ordre des buts qui correspond à leur importance et (ii) diviser les buts
complexes en buts plus simples. Les buts peuvent être de natures différentes. On
distingue quatre types de buts :
• Les buts sommaires : ils généralisent des buts en un but plus général de niveau supé-
rieur qui n’existe pas forcément dans les spécifications. Ces buts permettent de mieux
comprendre un système. Souvent le but de plus haut niveau est un but sommaire.
• Les buts non fonctionnels : ce sont des buts annexes qui ne sont pas directement liés
aux buts globaux et qui ne sont pas indispensables à la réalisation de ces derniers.
• Les buts combinés : ils combinent des buts similaires au niveau supérieur.
• Les buts partitionnés : sont des buts qui peuvent être divisés en sous-buts. Pour
atteindre un but partitionné, il faut atteindre tous les sous-buts.
La deuxième étape identifie un ensemble de rôles et d’interactions à partir de cas
d’utilisation et de diagrammes de séquence. Les cas d’utilisation sont utilisés pour mo-
déliser les scénarios pouvant intervenir dans le système. Les diagrammes de séquence
modélisent les événements qui se produisent entre les rôles constituant le système.
Cette étape se compose donc de deux pas :
• création des diagrammes cas d’utilisation, et
• création des diagrammes de séquence.
Les cas d’utilisation définissent des événements susceptibles d’intervenir dans le sys-
tème. Ces cas d’utilisation sont dérivés des spécifications du système. Si ces cas d’utili-
sation font découvrir de nouveaux buts, il faut retourner à la première étape et inclure
ces derniers dans l’analyse. MaSE prône les cas d’utilisation positifs et négatifs. Un
cas d’utilisation positif reflète une interaction souhaitée tandis qu’un cas d’utilisation
négatif met en évidence un comportement erroné et non souhaité du système. Il est
3 traduction libre de [DWS01]
clair qu’il est impossible de faire un cas d’utilisation pour chaque situation possible,
mais ces derniers sont néanmoins un outil performant.
Les diagrammes de séquence montrent les messages qui passent entre les rôles pré-
cédemment identifiés. Le passage d’un diagramme de cas d’utilisation vers un dia-
gramme de séquence est relativement simple. Les rôles sont représentés par des boîtes
tandis que les messages sont modélisés par des flèches entre les rôles. Chaque événe-
ment dans un cas d’utilisation est traduit par une flèche qui met en relation les rôles
participant à l’évènement. L’axe du temps est l’axe vertical dans le sens que plus une
flèche apparaît tard dans le diagramme plus l’événement associé est jeune.
La dernière étape est le raffinement des rôles. C’est aussi la dernière étape de la phase
d’analyse. Cette étape transforme les buts du système et les diagrammes de séquence en
rôles et en tâches associées. Cette transformation se fait en deux pas : (i) l’établissement
d’un modèle de rôles et (ii) la définition du diagramme de tâches4 , spécifique à chaque
rôle. Le modèle des rôles contient les rôles, leurs tâches et les interactions. Les rôles
sont plus agréables pour travailler et sont à la base des définitions des classes d’un
agent. Un modèle des rôles est représenté dans un diagramme de rôles. La figure 3.4
F. 3.4.: Un diagramme de rôles généré avec agentTool (tiré de [4])
montre un tel diagramme. Ce diagramme a été généré avec agentTool. agentTool et le

cadriciel qui accompagne MaSE. Il se trouve que la version actuelle n’est plus sous
développement actif. Cependant, une nouvelle version est en voie de développement.
Cette dernière se présentera sous forme d’un plug-in pour Eclipse [2].
Pour chaque rôle les tâches sont décrites dans un diagramme de tâches qui ressemble
à une machine à états finis (engl. finite state machine). Il y a un état de départ et un
état d’arrivée. Entre ces deux il y a des états transitoires. Ce diagramme est surtout
utilisé pour spécifier (i) les détails dont une tâche est composée et (ii) les événements
4 voir aussi la figure A.2
qui permettent de changer d’état. Un tel événement peut être interne, c’est-à-dire, issu
d’une autre tâche d’un même rôle ou généré par un rôle différent. Dans le dernier
cas on l’appelle externe. La figure A.2 montre un tel diagramme avec quatre états
intermédiaires.
F. 3.5.: Diagramme de tâches (tiré de [4])
Cette étape termine la phase d’analyse. Les buts du système ont été identifiés et les
rôles créés. Le développeur est libre durant toute la phase d’analyse d’avancer et de
reculer dans les différentes étapes comme bon lui semble. En effet il s’avère utile par
moments de retourner à la phase précédente, de l’améliorer pour simplifier les phases
suivantes. La deuxième phase s’occupe de la conception du système.
La phase de conception se décompose en quatre étapes. Ces étapes sont :
1. Création des agents.
2. Définition des communications.
3. Assemblage.
4. Conception du système.
La figure 3.3 montre les liens qu’il y a entre les différentes étapes de cette phase et de
la précédente. La première étape associe les rôles à des types d’agents. La deuxième
étape définit les communications tandis que durant la troisième étape l’agent reçoit sa
structure interne et son intelligence. La quatrième étape s’occupe du déploiement des
agents.
La première étape définit les classes d’agents et leurs conversations. Une classe d’agent
est une sorte de structure vide (template) pour un agent. On introduit un niveau
d’abstraction encore plus élevé. Auparavant on a défini les rôles à partir des tâches.
Maintenant il s’agit de définir quel agent joue quel(s) rôle(s). Un agent peut jouer
plusieurs rôles. Si par exemple il y a une forte communication entre deux rôles, il peut
être avantageux de les faire jouer uniquement par un seul agent. Une fois les rôles
attribués aux agents il faut définir les conversations entre eux. Pour ce faire, on met
3.2. PLATEFORMES Andreas Ruppen 22
les classes d’agents et les communications dans un diagramme appelé diagramme de

classes d’agents5 . Il s’agit d’un diagramme de classes UML à deux différences près :
• Les attributs et méthodes d’un agent sont les rôles et
• Les relations entre agents sont les conversations.
Cette étape introduit donc une abstraction à deux niveaux : d’un côté les rôles qui sont
une abstraction des buts et de l’autre les agents qui considèrent les communications et
ressources sans se soucier des buts du système.
La deuxième étape construit les conversations entre les agents. L’étape précédente a
identifié les conversations sans pour autant en spécifier les détails internes. C’est le
but de cette étape. Pour y parvenir, on dessine deux diagrammes, appelés diagramme
de classe de communication6 . L’un est pour l’émetteur, l’autre pour le récepteur. Ces
diagrammes ressemblent à un diagramme d’une machine à états finis. Y sont définis les
protocoles de coordination. Si un agent reçoit un message, il regarde s’il appartient à
une communication en cours. Si c’est le cas, cette communication change d’état, sinon
il compare le message à toutes les conversations possibles auxquelles l’agent peut
participer et s’il en trouve une il interprète le message comme le début d’une nouvelle
communication. Chaque tâche qui crée une communication externe établie au moins
une conversation.
La première étape a défini les agents et les conversations sans se soucier de leurs struc-
tures internes. La deuxième étape a construit les conversations. La troisième étape va
donc s’occuper de l’assemblage des agents. On entend par là qu’elle définit la vie inté-
rieure des agents, à savoir l’architecture de l’agent et les composants de l’architecture.
On définit un composant d’architecture comme un ensemble d’attributs et de mé-
thodes. MaSE exige que chaque activité des diagrammes de classe de communication
doit figurer comme opérateur dans un des composants d’architecture.
La dernière étape fait une esquisse du système final. Elle doit définir les propriétés
suivantes :
• le nombre maximal d’agents, par type d’agent,
• une stratégie de déploiement.
Pour faire ceci, elle s’appuie sur des diagrammes de déploiement7 classiques à une
différence près : les rectangles représentent les agents et les liaisons entre ces rectangles
font référence aux conversations. Tous les agents qui se trouvent au même endroit
physique sont entourés d’une ligne pointillée.
3.2. Plateformes
Pour développer efficacement des agents, il faut disposer d’outils convenables. On a vu
qu’un agent est une entité capable de communiquer. Cette capacité de communiquer
doit être implémentée à un moment donné. On sait aussi qu’une manière de créer des
agents est basée sur ce que l’on appelle les comportements (engl. behaviors). Il serait
donc judicieux de disposer de ces bases de manière générique ce qui a pour avantage de
normer certaines choses. La communication en est un très bon exemple. Si cette dernière
est normée, des agents provenant de plusieurs développeurs peuvent communiquer
5 La figure A.4 en donne un exemple.
6 La figure A.5 montre un tel diagramme.
7 La figure A.6 montre un tel diagramme..
F. 3.6.: Interaction des différents composants de JACK (tiré de [Wei06])
sans autre. Le développement agent apporte une nouvelle abstraction par rapport à
une approche classique. C’est un nouveau point de vue et une stratégie innovante pour
résoudre des problèmes. On peut tirer beaucoup de parallèles avec le développement
orienté objet (OO). Même avant l’apparition des langages comme java, intégrant l’objet
comme base, il était possible de faire une programmation orientée objet en créant les
objets à la main. On peut transposer cette réflexion sur les agents : il est possible de
développer des agents sans IDE adapté, mais c’est plus efficace de disposer d’outils
adaptés. Cette section va en présenter deux : Jade et JACK. On en a déjà rencontré
d’autres dans la section 3.1.2 puisque quelques méthodologies proposent leur propre
plateforme (agentTool).
3.2.1. JACK Intelligent Agents

JACK [9] est une plateforme pour le développement d’agents intelligents. Elle est
spécialisée dans le développement d’agents cognitifs basés sur un modèle BDI et
d’agent d’équipe. JACK est commercialisé par Agent Oriented Software Pty. Ltd.. Si
l’on désire utiliser JACK pour un projet il faut acquérir une licence. Néanmoins, il existe
une version d’évaluation qui fonctionne pendant 60 jours ce qui devrait permettre
d’évaluer la plateforme. Pour un usage académique on peut contacter Agent Oriented
Software Pty. Ltd.. En général ils mettent à disposition gratuitement des licences pour
l’enseignement ou des projets de recherche.
JACK est basé sur Java, mais rajoute à ce dernier une nouvelle couche, la couche agent.
Cette dernière se présente sous forme de trois modules : (i) JACK Agent Language (JAL)
(ii) JACK Agent Compiler et (iii) JACK Agent Kernel. La figure 3.6 montre l’interaction
de ces composants.
JACK Agent Language est le langage dans lequel les agents sont effectivement program-
més. C’est une extension des classes de Java. Cette extension fournit le même gain de
confort qu’apportait C++ à l’époque à C. Cette extension se fait donc sur trois niveaux :
(i) les classes et interfaces (ii) la syntaxe et (iii) la sémantique. Elle rajoute 6 nouvelles
constructions à Java. Il faut voir ces constructions comme les classes pour la program-
mation OO. L’utilisation de ces constructions est très proche de celle d’une classe Java
(héritage, implémentation. . .). Ces nouvelles constructions sont :
• agent : Ce concept modélise l’agent en soi. Il est utilisé pour définir son comportement
(behavior). Ceci inclut ses capacités, ses stratégies pour accomplir sa mission et les
moyens de communication.
• capability : Ce concept permet de créer les croyances, les intentions et les stratégies
de l’agent.
F. 3.7.: JACK tools (tiré de [Wei06])
• beliefset : Il modélise les croyances de l’agent en se basant sur un modèle relationnel

générique. Il est important de noter que les croyances de l’agent ne correspondent
pas forcément à la situation réelle de son environnement.
• view : Ce concept permet d’accéder à toutes sortes de ressources. Ces ressources
peuvent aussi être les beliefsets.
• event : Représente les événements et les messages au travers desquels l’agent est
incité à exécuter une certaine action. Ces événements et messages peuvent aussi bien
être externes qu’internes.
• plan : Les plans d’un agent sont l’analogue des fonctions. Les plans décrivent com-
ment réagir à des events. Tout le savoir-faire de l’agent est décrit dans les plans et
dans les capabilities.
Puisque Java ne propose pas les outils de haut niveau nécessaires pour créer des agents
JACK étend la syntaxe de Java. En plus de cela il est nécessaire de rajouter une syntaxe
pour les concepts ci-dessus. JACK étend les capacités de Java sur trois plans :
• le class definition level : Met à disposition des classes nécessaires pour créer des agents,
des plans et des événements par héritage.
• le declaration level : Met à disposition les outils pour identifier les relations entre les
classes ci-dessus.
• le statement level : Met à disposition des outils spécifiques pour travailler sur des
données spécifiques du langage JACK.
Le JACK Agent Compiler traduit le code source écrit en JACK Agent Language (JAL) en
JAVA pur. Les fichiers *.java ainsi créés peuvent ensuite être compilés à l’aide de la
Java Virtual Machine. Le JACK Agent Compiler peut être lancé en ligne de commande.
Après avoir traduit les fichiers *.jal en *.java, il appelle le Java Compiler pour créer
les fichiers *.class. Afin de lancer le système, il faut programmer une classe main()
qui crée les instances des agents.
1 agent MyAgent extends Agent
{
3 # handles event MyEvent ;
#uses p l a n MyPlan ;
5 # p o s t s event MyEvent myEventRef ;
7 MyAgent ( S t r i n g name )
{
9 super ( name ) ;
}
11
public void method1 ( S t r i n g exampleMessage )
13 {
/ / Java code t o do something u s e f u l
15
// I n t h i s example , we i l l u s t r a t e how t o p o s t an event from
17 // w i t h i n an agent .
// The p o s t i n g method w i l l be discussed i n t h e s e c t i o n on events .
19 // I n t h i s case , t h e p o s t i n g method t a k e s a s i n g l e argument o f
// type S t r i n g .
21 // Note t h a t myEventRef has been d e c l a r e d e a r l i e r i n t h e agent .
23 postEvent ( myEventRef . myPostingMethod ( exampleMessage ) ) ;

}
25 }
Listing 3.1: Extrait d’un fichier JAL
Lorsque l’on exécute des agents, le JACK Agent Kernel est appelé pour les tâches spé-
cifiques aux agents. L’utilisation de ce noyau est complètement transparente pour le
programmeur.
JACK est livré avec un environnement de développement appelé JACK Development
Environment (JDE) permettant le développement aisé d’un MAS. La figure 3.7 montre
l’ensemble des outils fournis.
On voit qu’il y a des outils pour le développement en soit (Graphical Editor pour les
reasonning methods, Design Tool pour l’ensemble du système), des outils pour com-
piler le code source (Compiler Utility, pendant graphique de la commande JackBuild)
et des outils pour le débogage (Agent Tracing Controller). Tous ces outils font un usage
intense des fonctionnalités drag-n-drop des GUIS.
Vu que la plateforme est spécialisée dans le développement d’agents dits intentionnels
(voir tableau 2.1), elle n’a pas été retenue pour la suite du document. De plus, la
plateforme ne supporte pas de standard de communication comme FIPA [8].
3.2.2. Jade
JADE (Java Agent DEvelopment Framework) [1] est un cadriciel pour le développe-
ment d’agents respectant le standard d’interopérabilité entre agents, FIPA. JADE est
développé par Telecom Italia Lab (Tilab) en collaboration avec l’université de Parme.
Tilab est la branche responsable de la promotion et de la mise en oeuvre des nouvelles
technologies du groupe télécom Italia. JADE trouve ses origines en 2000 et est dispo-
F. 3.8.: Vue d’ensemble de JADE (tiré de [Wei06])
nible depuis sous la GNU Lesser General Public License (LGPL). Depuis mars 2003
Tilab et Motorola essayent de promouvoir et d’adopter JADE dans le domaine de la
télécommunication mobile comme un standard de-facto pour les applications agents.
Tout le monde (aussi bien des particuliers que des entreprises) est invité à soutenir le
développement de JADE.
On voit sur la figure 3.8 l’ensemble des outils qui sont fournis avec JADE. Ces outils
sont également des agents et sont :
• Le Remote Monitoring Agent (cf. figure 3.9) permet l’administration des agents.
Il est possible de superviser aussi bien des plateformes locales que des plateformes
distantes. Il est possible de superviser n’importe quel type de plateforme du moment
qu’elle respecte le standard FIPA. Via son GUI il est possible de créer des agents
aussi bien sur plateforme locale que sur une plateforme distante à condition qu’un
conteneur soit démarré sur la plateforme choisie. Il est en outre possible de créer et
de fermer des conteneurs entiers et de fermer toute la plateforme. Une autre tâche
du Remote Monitoring Agent est la gestion des migrations des agents puisqu’en
principe un agent mobile peut changer de conteneur/plateforme.
• Le Dummy Agent (cf. figure 3.10) permet à un développeur d’interagir directement
avec ses agents en envoyant et en recevant des messages. Cet agent permet l’analyse
de conversations. Le Dummy Agent est utilisé pour la validation d’un agent avant
son intégration dans le MAS. Via son GUI il est possible de créer, de modifier et
F. 3.9.: JADE Remote Monitoring Agent
d’envoyer des messages ACL. De plus, il permet de visualiser les messages reçus
des autres agents. Une autre fonctionnalité du GUI est l’enregistrement sur un fichier
et le chargement depuis un fichier de messages.
• Le Introspect Agent (cf. figure 3.11) permet la surveillance du cycle de vie d’un
agent, de ses messages envoyés et reçus. Il affiche en temps réel les messages en
suspens, liés à l’échange actuel. Cet agent est surtout utilisé pour le débogage et la
validation d’un agent. Le GUI permet aussi de ralentir l’exécution de l’agent et de
définir des breakpoints.
• Le Sniffer Agent (cf. figure 3.12) surveille et affiche les messages échangés sur une
plateforme. Il est possible de surveiller autant d’agents que l’on désire du moment
qu’ils se trouvent sur une même plateforme. Chaque message envoyé ou reçu par un
agent surveillé est affiché dans le GUI. Il est ensuite possible d’afficher son contenu
et de l’enregistrer.
• Le Socket Proxy Agent joue le rôle de liaison bidirectionnelle entre une plateforme
JADE et une connexion TCP/IP. Le but est de transformer un message ACL qui
doit être transmis via une communication MTS en une chaîne ASCII. Cette dernière
doit ensuite être envoyée via un socket. De l’autre côté le socket proxy agent doit
aussi être capable de transformer une chaîne de caractères ASCII en message ACL.
Cette technique joue un rôle important en présence de systèmes tournant derrière
un pare-feu.
• Le Directory Facilitator Agent (cf. figure 3.13) s’occupe de l’enregistrement des
agents. Via son interface graphique, l’utilisateur peut regarder les descriptions
d’agents. Il peut les modifier ou chercher des agents selon certains critères. De plus,
il est possible d’enregistrer et de désinscrire des agents. La plateforme permet de
coupler plusieurs DF existant sur des machines différentes afin de créer un réseau
de pages jaunes. Les manipulations autorisées sont les mêmes pour un DF distant
que pour un DF local.
• Le Agent Management System Agent est responsable de l’enregistrement des
agents. Il contrôle l’accès à la plateforme. Cet agent s’occupe de l’authentification
des agents et leur accorde des droits d’utilisation du système.
D’après les développeurs de JADE, son but est de simplifier le développement de sys-
tèmes multi-agents tout en respectant une certaine conformité à travers un nombre de
F. 3.10.: JADE Dummy Agent
services systèmes et agent respectant les standards FIPA. Les standards FIPA incluent :
un service de nommage, un directory facilitator et le transport des messages. JADE
investis beaucoup dans la compatibilité avec les standards FIPA. On les retrouve dans
tous les composants majeurs du système notamment dans la communication. En effet
JADE utilise un système de message passing dans lequel les messages respectent la
norme FIPA ACL. D’autres composants de base comme le Agent Management System
(AMS) et le Directory Facilitator (DF) respectent également ce standard.
La plateforme d’agents de JADE peut-être distribuée sur plusieurs machines. Elle ne
nécessite qu’une seule instance de la machine virtuelle Java (JVM) sur chaque machine
indépendamment du nombre de clients. Chaque JVM peut être vue comme un conte-
neur d’agents possédant un environnement d’exécution complet. Cette architecture
permet à plusieurs agents de tourner en même temps sur une même machine. AMS
et DF font partie de l’équipement de base d’une plateforme d’agents. Ils se trouvent
dans un même conteneur appelé Main Container. Ce dernier est relié à tous les autres
conteneurs.
L’architecture de communication est très efficace. JADE crée pour chaque agent une
queue de messages entrants. Un agent possède plusieurs méthodes pour accéder à sa
queue comme par exemple avec un blocage, un timeout ou avec des patterns. Tout le
modèle de communication FIPA a été implémenté dans JADE. Ceci inclut : les proto-
coles d’interaction, les enveloppes, ACL, le content language, les ontologies et proto-
coles de transport. Dans JADE il faut différencier deux méthodes de communication
agent-agent :
• une communication interne à la pateforme qui utilise MTS. Cette communication
fait appel à RMI et
F. 3.11.: JADE Introspector Agent
• une communication entre plateformes d’agents qui fait appel à IIOP. Cette commu-
nication correspond à l’implémentation de CORBA dans Java.
D’autres méthodes de transport existent dans JADE comme HTTP et il est facile de
rajouter de nouvelles méthodes en étendant les interfaces MTP et IMTP de JADE.
JADE peut être vu comme un middleware s’insérant entre les agents et Java. De ce
fait JADE étend les classes de Java en rajoutant une bibliothèque d’une taille d’environ
350 classes. Ces dernières sont utiles pour le développement d’agents et proposent
des fonctionnalités bien précises. Il existe ainsi des classes pour créer le squelette d’un
agent ou pour définir une ontologie ou encore pour mettre en oeuvre des compor-
tements dont les plus importants sont sans doute jade.proto.AchieveREInitiator
et jade.proto.AchieveREResponder qui correspondent à la réalisation de protocoles
de type request du standard FIPA. En utilisant ces protocoles l’initiateur peut conclure
à partir des réponses reçues si oui ou non sa requête a eu l’impact voulu. Le pa-
quet jade.core.behaviors contient d’autres comportements importants comme :
OneShotBehavior, SequentialBehavior et WakerBehavior. Afin de combler le manque
d’intelligence de ses agents, JADE propose une interface vers JESS [10]. Si on utilise
JESS, on peut voir un agent JADE comme un moule qui a pour rôle de garantir la com-
patibilité avec les standards FIPA tandis que JESS s’occupe de la partie qui concerne la
prise de décision.
JADE permet l’utilisation de content languages (langages de contenu) et d’ontologies.
Les content languages sont utilisées pour décrire le contenu d’un message. Les codes
fournis par JADE sont SL et LEAP. Mais il est possible d’étendre les possibilités de
JADE en rajoutant d’autres langages. Un codec est un objet Java qui transforme une
information en objets Java et vice-versa. JADE comprend aussi les ontologies. Il existe
des classes particulières pour la création d’ontologies. Il est possible de les combiner.
Leur création dans JADE peut être assez fastidieuse. C’est pour cela qu’il est conseillé
d’utiliser des outils comme Protégé [11] qui permettent de générer toutes les classes
F. 3.12.: JADE Sniffer Agent
F. 3.13.: JADE DF GUI
associées à une ontologie à partir d’un modèle.

Le JADE Security Plugin est responsable de la sécurité. L’ensemble de JADE et de ce
plug-in est appelé JADE-S (JADE Secure Agent Platform). Le concept de sécurité se base
sur les mécanismes de SUN JDK 1.4, en particulier le Java Authentication and Authoriza-
tion Service (JAAS), le Java Cryptography Extension (JCE) et le Java Secure Socket Extension
(JSSE). Ces outils permettent d’authentifier l’utilisateur de chaque composant. Il est
ensuite possible d’accorder des droits par composant. Afin de garantir qu’un compo-
sant ne dépasse pas les droits qui lui sont accordés, il reçoit un certificat d’identité issu
d’une autorité de certification.
Dans JADE un agent est normalement implémenté comme un thread. Néanmoins, il
existe des situations où ce modèle n’est pas adapté (pensons par exemple aux compor-
tements parallèles). En plus des fonctionnalités de multithread offertes par Java, JADE
propose des fonctionnalités supplémentaires. Il est par exemple possible de réveiller
un certain thread à un moment donné (WakerBehavior). JADE propose ici une solution
peu encombrante et efficace.
Pour la suite du document et pour implémenter le problème posé à la section 4 notre
F. 3.14.: Protégé, un éditeur d’ontologies
choix s’est porté sur JADE pour plusieurs raisons. La première est celle du langage.
Bien qu’il existe d’autres frameworks qui se basent sur Java, l’intégration de JADE est
très réussi. Un autre point est l’intégration avec des appareils mobiles. Comme on le
verra l’application présentée à la section 4.2 a pour but de maximiser la disponibilité
des médecins. Il devient donc indispensable de pouvoir travailler avec des appareils
de type PDA. JADE propose une intégration de LEAP (Lightweight Extensible Agent
Platform) qui permet de faire tourner des agents sur des plateformes mobiles. De plus
JADE propose toutes les fonctionnalités nécessaires pour réaliser une implémentation
de l’application proposée dans la section 4.2. Puisque les agents vont agir comme des
boîtes aux lettres, il s’agit plutôt d’agents réactifs. On n’a donc pas besoin de modèles
cognitifs compliqués.
eHealth-Care
4
“A goal is not always meant to be reached, it often serves simply as something to aim
at.”
- Bruce Lee
4.1. Situation actuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2. Solution proposée - MediMAS . . . . . . . . . . . . . . . . . . . . . . . 39
Le terme d’eHealth-Care ou e-Health Care a pris beaucoup d’ampleur ces dernières an-
nées. Une partie est certainement un effet “hype” mais en dehors de ça les technologies
autour de l’eHealth-Care apportent une vraie valeur. Tout comme les systèmes multi-
agents, le domaine de l’ eHealth-Care est vaste et englobe plusieurs sous domaines
comme la télémédecine ou la fiche de patient électronique1 . Certains de ces domaines
englobent de nouveau un certain nombre de sous-domaines. Ainsi la télé-médecine
se compose de la téléconsultation, de la téléopération, de la télépathologie, etc. Ils ont
cependant un point commun, ce sont tous des systèmes distribués. On y rencontre
donc beaucoup des problèmes étudiés dans les systèmes distribués. Certains de ces
domaines nécessitent un système temps réel. La téléopération par exemple ne serait
pas assez fiable dans un système où les commandes envoyées par le médecin arrivent
n’importe comment. Ceci se résume donc à des systèmes distribués synchrones. Le
paragraphe 2.4.1 a mis en évidence l’utilité des systèmes multi-agents comme design
pattern pour les systèmes distribués. De là à appliquer ce pattern dans le domaine de
l’eHealth-Care il n’y a qu’un pas à franchir. Il s’avère que l’approche agent est assez
performante, du moins d’un point de vue de conception de système.
Le reste de ce chapitre ainsi que le chapitre suivant montre à l’aide d’un exemple com-
ment implémenter concrètement un système multi-agents dans un contexte eHealth-
Care. La solution a été mise en place en collaboration avec l’hôpital cantonal de Fri-
bourg. Le but du système est de faciliter la communication entre l’hôpital cantonal et
le laboratoire cantonal tout en gardant une trace des communications faites afin de
1 Voir par exemple la carte santé au Canada
32
4.1. SITUATION ACTUELLE Andreas Ruppen 33
garantir le bon fonctionnement du système. Dans un premier temps, on explique le

fonctionnement actuel. On met en évidence les problèmes et les points faibles de cette
situation et on essaye de trouver un système plus performant. La seule contrainte pour
le futur système est qu’il doit s’intégrer de façon complètement (ou presque) transpa-
rente dans le système actuel. En d’autres mots, le but principal est de fournir un système
accessible à tous sans formation coûteuse. Dans la deuxième partie on élabore une so-
lution possible, le but étant de trouver un modèle simple se basant sur un système
multi-agents et qui satisfait tous les critères de sécurité, de fiabilité et de traçabilité.
Dans la section 2.1 on a déjà rencontré un système multi-agents formé d’êtres humains.
On a donc compris qu’un ensemble d’êtres humains peut être vu comme un système
multi-agents. Quel-est alors l’intérêt de remplacer ce système par un système multi-
agents formé exclusivement d’agents logiciels ? La raison est que l’erreur est humaine.
En effet on verra plus tard dans ce chapitre que la situation actuelle souffre de beaucoup
de faiblesses. C’est pour combler ces derniers qu’un système multi-agents basé sur des
agents logiciels semble être un bon point de départ. Ces agents feront exactement la
même chose que font déjà les médecins, laborantins, etc., mais de manière plus fiable.
4.1. Situation actuelle

Le laboratoire cantonal de Fribourg est responsable des analyses pour l’hôpital cantonal
de Fribourg. Un médecin peut faire une demande d’analyse sur un certain nombre de
prélèvements au moyen d’une fiche de demande d’analyse. L’annexe C montre une
telle fiche. Le laboratoire cantonal se charge ensuite de faire les analyses demandées et
de communiquer les résultats au médecin traitant. Le laboratoire est formé de plusieurs
entités comme l’hématologie, la chimie ou la microbiologie. Chaque département fait
ses analyses et communique ses résultats indépendamment. On voit sur la figure 4.1
F. 4.1.: Fonctionnement actuel (tiré de [Ngu07])

le fonctionnement actuel. Il se compose de quatre entités pouvant intervenir dans les

communications. Ce sont les patients, les médecins, les laborantins et les cadres du
laboratoire. Le tableau 4.1 montre les conversations qui ont lieu dans le système. Pour
médecin → patient Le médecin informe le patient du résultat d’analyse

laborantin → médecin Le laborantin communique ses résultats au médecin
médecin → laborantin Le médecin fait une demande d’analyse
*→ cadre →* Le chef est informé d’un comportement anormal et
prend des mesures
T. 4.1.: Communications possibles
faire tourner un hôpital, d’autres postes existent, par exemple le poste du concierge ou
encore le poste de réceptionniste. Ces postes ne représentent cependant aucun intérêt
pour le système puisqu’ils ne participent pas de manière directe au suivi d’un patient.
On remarque sur le schéma que chaque personne, peu importe sa fonction dans l’hô-
pital, peut communiquer avec une autre sans que cela soit synchronisé d’une manière
ou d’une autre. Le schéma 4.1 présente un système distribué avec une information
partagée (l’analyse). Le schéma met en évidence qu’il n’existe aucun mécanisme qui
protège cette information. Il se peut donc que le résultat arrive plusieurs fois par des
voies diverses chez le médecin traitant. C’est le cas le moins grave. Il se peut aussi que
le résultat d’une analyse se perde dans les communications. Impossible alors de savoir
à quel moment le résultat s’est perdu et qui en est le responsable. Le schéma met entre
autres en évidence qu’il y a deux moyens de communication : (i) les communications
via le système informatique pour les cas normaux et (ii) les communications par télé-
phone pour les cas spécifiques et critiques. Ce sont ces derniers qui nous intéressent.
Les cas spécifiques regroupent toutes les situations où le résultat n’est pas (encore)
introduit quand le médecin essaie d’y accéder. Les cas critiques regroupent les situa-
tions où une intervention rapide auprès du patient est nécessaire. Un cas est considéré
comme étant critique si au moins un des résultats l’est. Actuellement quand un tel cas
se présente toutes les conversations qui s’en suivent passent par les téléphones. Aucun
contrôle n’est donc possible sur ce qui a été communiqué, à qui et à quel moment. Ces
informations peuvent cependant être cruciales. Dans le cas d’un dysfonctionnement,
il est important de pouvoir en isoler la cause afin de l’éliminer pour que la situation ne
se reproduise plus. Il est clair qu’une telle situation n’est pas favorable dans un milieu
où les erreurs coûtent souvent des vies humaines.
On va maintenant examiner tous les cas spécifiques et critiques qui peuvent surgir.
Pour les définir il est plus simple d’établir ce qu’est le cas normal, ce qu’il contient et
d’en prendre le complément. Comme évoqué plus haut,le système de communication
actuel est formé de deux couches : le système informatique et le téléphone. Dans la
figure 4.2, la couche du système informatique est éclatée en deux couches, une pour le
système informatique en général et l’autre pour mettre en évidence la partie WinDmlab.
C’est ce système qui est normalement utilisée pour communiquer les résultats. D’un
côté, les laborantins l’utilisent pour remplir la base de données alors que de l’autre
côté les médecins peuvent consulter les résultats. La troisième couche est celle de la
communication directe par téléphone. La figure 4.2 montre où se situent les différents
cas d’utilisation. Le cas normal se trouve donc dans la couche WinDmlab alors que
tous les autres cas sont dans la couche la plus haute. Il y a deux sortes de cas dans cette
F. 4.2.: Système de communication actuel (tiré de [Ngu07])
couche (i) les cas spécifiques, ce sont des cas normaux dégénérés et (ii) le cas critique
c’est le cas lorsque le résultat d’une analyse met en évidence un danger imminent pour
le patient. On remarque que le patient, bien que nécessaire au système, ne participe
pas de manière directe à ces communications. Ceci implique que le dernier bout de la
transmission d’un résultat (c’est-à-dire le bout médecin → patient) échappe au système.
Pour la transmission d’un résultat, il n’y a donc pas d’autre alternative que celle de
faire confiance au médecin de bien transmettre les résultats obtenus. On verra dans le
chapitre suivant une manière de responsabiliser le médecin dans cette tâche.
Regardons à présent de plus près le cas normal. La figure 4.3 montre le diagramme
d’activité correspondant. Lorsqu’un médecin désire consulter les résultats d’une ana-
lyse, il accède à la base de donnée via WinDmlab et cherche le dossier correspondant
au patient. Si les résultats sont disponibles, il peut les consulter et soigner le patient en
fonction des résultats obtenus, sinon il doit attendre et réessayer plus tard. Si cepen-
dant les résultats ne sont toujours pas disponibles au bout de quelques essais, il doit
entreprendre d’autres mesures. On se trouve alors dans un des cas spécifiques. On voit
que le cas normal est assez bien sécurisé. Le système de base de donnée est capable
garder une trace de qui accède à quelle information à quel moment. On voit donc que
le système permet à tout moment de voir chez qui est la responsabilité d’une analyse
(chez le laborantin s’il n’a pas encore introduit les résultats dans la base de donnée,
chez le médecin si les résultats sont disponibles).
Voyons donc ce qui se passe lorsque le médecin essaie plusieurs fois d’accéder aux
résultats d’un patient, mais que ces résultats restent indisponibles. Il s’agit du premier
cas spécifique. La figure 4.4 montre le diagramme d’activité. La première chose qu’on
constate est qu’il est sensiblement plus compliqué que le cas normal. Ceci vient des
boucles et des nombreux aiguillages. Autre point qu’on remarque c’est que le cas spé-
F. 4.3.: Cas normal (tiré de [Ngu07])
cifique 1 peut mener à un autre cas spécifique. Vu qu’il s’agit d’un cas spécifique, la
communication se fait via le téléphone. Le médecin appelle le laboratoire et demande le
laborantin responsable. Si ce dernier est disponible (nonante-neuf pour cent de chance)
le médecin lui demande le résultat. Si le laborantin a déjà fait l’analyse, il peut lui com-
muniquer les résultats et le médecin peut soigner le patient en fonction. Si par contre le
laborantin n’a pas encore fait l’analyse, on se trouve dans le cas spécifique 2. Il se peut
que le médecin appelle au mauvais moment et le laborantin responsable est indispo-
nible (un pour cent de chance). Dans ce cas deux possibilités s’offrent au médecin : (i) il
rappelle plus tard ou (ii) après k essais il téléphone au cadre du laboratoire. Quand
le médecin essaie d’appeler le chef du laboratoire, deux situations se présentent : (i) le
cadre du laboratoire est disponible, ou (ii) il est absent. Dans le premier cas, le médecin
peut informer le cadre du laboratoire de la situation et ce dernier s’occupe d’éclaircir la
situation et d’informer le médecin. Dans le deuxième cas, le médecin n’a pas d’autres
choix que d’attendre et de rappeler plus tard. On se rend compte qu’il n’existe aucun
contrôle nulle part sur ce qui a déjà été fait ou pas. De plus, le système ne dispose
d’aucune sécurité. Si une personne reste injoignable ou oublie de rappeler, cela peut
avoir de graves conséquences.
On a vu que si le laborantin n’a pas encore effectué l’analyse lorsque le médecin traitant
appelle on se trouve dans le cas spécifique 2. Ce deuxième cas spécifique est similaire au
premier à la différence que cette fois c’est le laborantin qui appelle le médecin traitant.
La figure 4.5 montre le cas d’utilisation de cette situation. Vu que le résultat n’est pas
disponible au moment où le médecin appelle le laborantin promet de faire l’analyse
et de l’informer tout de suite des résultats obtenus. Supposons alors que l’analyse soit
terminée et que tous les résultats trouvés soient dans les normes. Le laborantin essaie
alors de joindre le médecin traitant. Le même choix qu’au cas spécifique 1 se pose :
soit le médecin est disponible et le laborantin lui communique les résultats soit il est
F. 4.4.: Cas spécifique 1 : Médecin téléphone au laboratoire et demande le résultat

d’analyse (tiré de [Ngu07])
indisponible. Dans le premier cas, le laborantin a terminé son travail et le médecin peut
traiter le patient en fonction des résultats trouvés. Dans le deuxième cas, le laborantin
doit essayer de rappeler plus tard. Au bout d’un certain nombre d’essais infructueux, le
laborantin appelle directement le cadre du laboratoire. Si le cadre n’est pas disponible,
le laborantin n’a d’autres choix que de patienter et de rappeler plus tard. Si par contre
le cadre du laboratoire est disponible, le laborantin peut lui communiquer les résultats.
Le cadre prend alors la responsabilité d’agir en fonction, d’informer le médecin traitant
et surtout de s’assurer que le patient soit informé et traité en conséquence. On rencontre
les mêmes problèmes que ceux discutés précédemment. Il n’y a aucun suivi des actions
entreprises. Personne ne peut garantir chez qui se trouve actuellement la responsabilité
pour un certain résultat.
A côté du cas normal avec les deux cas spécifiques, il y a le cas critique. On désigne
un cas comme critique lorsque l’analyse a obtenu des résultats qui demandent une
intervention rapide auprès du patient. La procédure standard n’est certainement pas
adaptée ici. On ne peut pas simplement enregistrer les résultats dans la base de données
et espérer que le médecin traitant les verrait à temps. La figure 4.6 montre le diagramme
du cas d’utilisation associé. Le point de départ est le laborantin qui vient de terminer
une analyse. Si les résultats sont normaux, il les rentre dans la base de données et le
F. 4.5.: Cas spécifique 2 : Laborantin téléphone au médecin traitant et lui communique
le résultat (tiré de [Ngu07])
médecin pourra les consulter. Si au moins un des résultats est critique, le laborantin doit
entrer les résultats dans la base de données et en informer le médecin traitant. Comme
toujours la communication passe par le téléphone. Il se peut donc que le médecin ne
soit pas disponible. Le cas échéant, le laborantin peut essayer de rappeler plus tard.
Si au bout de quelques essais il n’arrive toujours pas à joindre le médecin, il s’adresse
directement au cadre du laboratoire. Comme avant cette communication passe par
le téléphone. Si le cadre n’est pas disponible, il n’a d’autres choix que d’attendre
et de réessayer plus tard. S’il arrive à atteindre le cadre du laboratoire, il peut lui
communiquer les résultats. Le cadre prend alors la responsabilité de la transmission
de ces résultats. C’est à lui d’entreprendre les mesures nécessaires pour que le patient
obtienne un traitement adapté suite aux résultats trouvés.
On a vu dans cette section comment fonctionne la communication entre les différentes

entités. On a aussi découvert des failles de sécurité qui peuvent dans le pire des cas
coûter des vies humaines. Afin de limiter les dégâts, la section suivante va proposer une
solution possible. Une des contraintes est qu’elle soit facile d’utilisation et qu’elle doive
essayer de limiter les cas où des interlocuteurs ne sont pas disponibles. Cependant,
on sait qu’une chaîne est aussi solide que son maillon le plus faible, c’est-à-dire l’être
humain.
4.2. SOLUTION PROPOSÉE - MEDIMAS Andreas Ruppen 39
F. 4.6.: Cas critique : Laborantin téléphone au médecin et l’informe des résultats
obtenus (tiré de [Ngu07])
4.2. Solution proposée - MediMAS

Dans cette section on propose une solution aux problèmes soulevés à la section pré-
cédente. Bien évidemment, d’autres solutions existent. Néanmoins comme on le verra
au chapitre 5 la solution proposée fonctionne, est facile à mettre en place et est exten-
sible. La section 4.1 à montré le détail des communications qui sont possibles dans
le système. Le but n’est pas de remplacer ces conversations par de nouvelles, mais
de les rendre plus fiables et plus simples. Dans toutes ces communications les parties
prenantes peuvent être vues comme des agents. Il paraît donc logique de garder cet
aspect dans le système final. Il suffit donc de faire exécuter ces tâches répétitives par
une entité logicielle. Quoi de plus naturel que de choisir un agent logiciel ? Dans le
but de limiter les conséquences d’un oubli, la majorité des conversations se font uni-
quement entre agents. Le téléphone représente le dernier recours et est signe d’une
situation dégénérée qui ne devrait pas arriver. La figure 4.7 montre à quoi pourrait
ressembler ce système. On a évoqué le problème de confiance et de responsabilité à la
section 4.1. Il est donc utile de disposer d’un mécanisme qui garantisse qu’un agent a
bien délivré une certaine information à son maître et que celui-ci a pris connaissance
de cette information. Un moyen simple, mais efficace consiste à utiliser des accusés de
réception. Un médecin ou laborantin doit acquitter chaque message. Ces accusés de
réception sont enregistrés dans une base de données centrale. En cas de problème il
suffit de consulter cette base de données pour trouver à quel moment le message s’est
perdu. Un autre but de la solution est d’augmenter la disponibilité des interlocuteurs.
En effet un médecin n’est pas toujours devant son ordinateur pour traiter des résultats
entrants. C’est pour cela que le médecin dispose d’un groupe d’agents déployés sur
plusieurs machines comme PDA, téléphone mobile ou thin client. Il peut ainsi réagir
à partir de n’importe lequel de ces postes. Il doit donc être capable de répondre à
un résultat depuis n’importe quel agent. Les autres agents doivent être mis à jour en
conséquence. Les agents qui sont déployés sur des engins mobiles ne communiquent
pas directement avec le serveur, mais passent par l’agent principal du médecin. Ce
passage par un proxy permet de synchroniser les multiples agents d’un médecin.
Dans la section précédente, on a identifié les scénarios possibles du système. Il s’agit
donc maintenant de donner une solution à chacun de ces scénarios. Même si le cas
normal fonctionne en principe très bien on va quand même le modifier pour avoir un
système homogène. Il est important que toutes les communications suivent un même
protocole sans quoi il devient très compliqué de tracer les messages. Commençons
donc par analyser le cas normal. Comme dit précédemment toutes les communications
passent par des agents. Ceci implique que chaque entité qui auparavant participait à
un quelconque échange possède un agent qui le fait maintenant à sa place.
F. 4.7.: Système actuel intégrant une solution basée sur un système multi-agents (tiré
de [Ngu07])
On a vu précédemment qu’on peut distinguer plusieurs niveaux de communications.

On les voit sur la partie supérieure de la figure 4.8. Le niveau le plus haut est comme
avant la communication par téléphone. Comme mentionné avant il n’y a que les cas
où une situation dégénère que le téléphone est nécessaire. C’est ici que vit le système
multi-agents. Toutes les communications se passent normalement à ce niveau. Le der-
nier niveau est resté inchangé. Il englobe toujours le système informatique actuel de
l’hôpital.
Le cas normal est le plus simple à traiter. Le laboratoire envoie les résultats vers un
serveur (en fait, c’est un agent qui joue le rôle de serveur). Ces résultats sont ensuite
enregistrés dans une base de données. Quand le médecin désire vérifier si de nouveaux
résultats sont disponibles il lui suffit d’interroger le serveur (Task 1). Ce dernier répond
en envoyant tous les résultats disponibles. L’agent du médecin transmet ces résultats
à son tour vers les le médecin. Le médecin doit confirmer la réception des résultats. De
nouveau la confirmation ne s’adresse pas directement au serveur, mais plutôt à l’agent
du médecin. C’est lui qui se charge de transmettre la confirmation au serveur. On se
rend vite compte que les cas spécifiques n’existent plus. Même si une personne est
occupée son agent est toujours disponible et répond à sa place.
F. 4.8.: Cas normal(tiré de [Ngu07])
Le seul cas qui reste est donc le cas critique. Tout comme avant il est insuffisant d’en-
voyer les résultats au serveur et d’attendre jusqu’à ce que le médecin les consulte. Les
résultats critiques prennent donc un parcours légèrement différent. Ils sont toujours
envoyés au serveur (Task 1), mais avec une autre priorité. En parallèle, les résultats sont
directement envoyés au médecin traitant (1.2). Vu qu’il s’agit d’un message prioritaire,
le médecin n’a que très peu de temps pour confirmer la bonne réception des résultats.
S’il oublie d’envoyer une confirmation, le système le remarque et prend des mesures
pour s’assurer qu’une personne compétente s’occupe des résultats. Cette sécurité in-
troduit un nouveau cas qui n’existait pas avant. La figure 4.9 montre le parcours d’un
message contenant des résultats critiques.
Le dernier cas traite donc de ce qui se passe lorsqu’un résultat dans la base de données
est périmé. On entend par là qu’il n’a pas été confirmé dans un délai donné. Comme
évoqué plus haut il y a deux sortes de messages, l’une pour des résultats non critiques
avec un certain délai et l’autre pour des résultats critiques avec un délai relativement
court. Si un message dépasse son délai, le système part du principe qu’il n’a pas été
pris en compte quelque part. La figure 4.10 montre alors les messages échangés lorsque
le serveur trouve des messages périmés. Les résultats sont envoyés une deuxième
fois au médecin, mais vu qu’il y a vraisemblablement un problème avec ce médecin
(en vacances) ou avec son agent (en panne) il envoie aussi un message au cadre du
F. 4.9.: Echange de messages lors d’un résultat critique (tiré de [Ngu07])
laboratoire cantonal ainsi qu’à l’agent du laboratoire. Le système est fait de telle manière
qu’on peut créer une hiérarchie de responsabilités. Une alerte monte ainsi à chaque
fois qu’elle reste non confirmée d’un niveau. Ceci ne donne toujours pas de garantie
mathématique que chaque message soit traité, cependant la probabilité qu’un message
se perde et tellement faible, qu’on peut admettre que le système est sûr.
On voit que toutes les communications passent par le serveur. Il existerait d’autres
moyens de communiquer sans passer par un serveur, mais puisqu’un des buts est de
garder une trace de toute conversation il est inévitable de passer par un serveur. De
plus, le passage par un serveur central permet de recueillir les accusés de réception et
d’entreprendre des mesures si des messages restent non accusés. Normalement un seul
serveur devrait suffire pour traiter toutes les communications puisque les messages
sont peu nombreux (il ne s’agit pas de la dernière version de skype ou MSN et les
utilisateurs ne sont pas des ados) et de petite taille.
F. 4.10.: Communications lorsque des messages périmés sont détectés (tiré
de [Ngu07])
Implémentation
5
“As you think, so shall you become.”
- Bruce Lee
5.1. Ontologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2. Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.3. Comportements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.4. Distribution des comportements aux agents . . . . . . . . . . . . . . . 58
5.5. Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
On a exposé dans le chapitre précédent le système informatique de l’hôpital cantonal

de Fribourg ainsi que du laboratoire cantonal. On a vu qu’à l’heure actuelle il y a deux
niveaux de communication, un par le biais d’une base de données et l’autre par le
téléphone. Le but était de trouver une solution complètement informatisée qui gère
aussi bien les situations normales que les situations exceptionnelles. Rappelons-nous
les deux situations exceptionnelles qu’on a rencontrées. La première touche la commu-
nication par téléphone et apparaît lorsque le récepteur est indisponible. La deuxième,
bien qu’elle touche aussi à la communication téléphonique, est d’un autre genre. Il
s’agit des résultats urgents qui nécessitent une intervention rapide auprès du patient.
Afin de combler ces failles nous avons présenté une solution basée sur un système
multi-agents. On a remarqué que le premier cas n’existe plus (du moins tant que l’on
admet qu’un médecin ne parte pas en vacances avec des analyses encore suspendues)
et même s’il existe encore de rares situations où un médecin reste injoignable on verra
plus loin que le système s’en occupe pour trouver une autre solution. La deuxième
situation exceptionnelle existe toujours, mais on verra que notre solution propose un
mécanisme astucieux pour éviter le pire.
Dans ce chapitre on va discuter de l’implémentation concrète de la solution étudiée pré-
cédemment. Cette étape est importante pour prouver la faisabilité et aussi la justesse du
modèle. Dans la section 3.2 on a survolé plusieurs plateformes pour le développement
d’un agent logiciel. Le choix a été porté sur Jade pour plusieurs raisons. Jade est basé
sur Java. Pour travailler, il suffit de mettre les archives jar dans la variable classpath.
44
Andreas Ruppen 45
Un autre argument en faveur de Jade est sa licence. En effet il est publié sous licence
LGPL. En plus des arguments d’ordre religieux (licence, langage de programmation),
Jade est parfaitement adapté au problème. En effet Jade intègre les ontologies et les
communications entre les agents peuvent être cryptées. Les agents n’ont pas besoin
d’être intelligents. Il s’agit d’un système avec des agents purement réactifs.
On a discuté plusieurs méthodologies à la section 3.1. Cependant, après analyse, il
s’avère qu’aucune de ces méthodologies n’est vraiment adaptée au problème et à
la plateforme choisie. D’autant plus si on choisi de baser l’implémentation sur une
ontologie. Il a donc fallu développer une nouvelle méthodologie adaptée à nos besoins.
Les sections qui suivent donnent un aperçu de l’implémentation. En même temps ces
sections décrivent aussi, de manière implicite, la méthodologie utilisée dans le cadre de
l’implémentation. La méthodologie utilisée s’inspire de celles discutées à la section 3.
La figure 5.1 schématise la méthodologie utilisée. Le développement d’un SMA se fait
en quatre étapes avec un raffinement itératif de l’ontologie, des rôles et des agents.
F. 5.1.: Méthodologie utilisée

5.1. ONTOLOGIE Andreas Ruppen 46
5.1. Ontologie
Dans Jade chaque concept, action ou prédicat est représenté par une classe. L’ensemble
formé des concepts, actions et prédicats est l’ontologie du système. Les attributs d’un
concept, d’une action ou d’un prédicat sont les attributs de la classe. Pour accéder à ces
attributs il faut deux méthodes par attribut, l’une pour le lire l’autre pour le modifier.
Écrire une ontologie est donc un travail long et fastidieux. Un changement dans la
structure implique généralement des ajustements dans plusieurs fichiers. Il vaut donc
mieux réfléchir deux fois avant de commencer à programmer.
Pour soutenir le développeur dans cette tâche source d’erreurs de runtime difficiles à
détecter plusieurs logiciels existent. Ils sont plus ou moins performants et chacun a sa
spécificité. Le plus connu est certainement Protégé qui est développé à l’université de
Stanford. Le point fort de Protégé est qu’il existe un plugin qui permet l’exportation
d’une ontologie vers Jade.
Regardons à présent de plus près l’ontologie qu’on a créée pour l’hôpital (le code
source de l’ontologie se trouve en annexe B). L’ontologie est certes sommaire puisque
beaucoup d’autres concepts existent dans le milieu hospitalier. Néanmoins, l’ontologie
présentée possède suffisamment de concepts pour permettre au système de fonction-
ner correctement. La figure 5.2 montre une vue d’ensemble du système. Les nuages
représentent les concepts tandis que les flèches entre les nuages montrent l’association
entre ces différents concepts. Vu qu’une ontologie représente en quelque sorte le vo-
F. 5.2.: Vue d’ensemble de l’ontologie (tiré de [Ngu07])
cabulaire du système, il est naturel d’y inclure les objets concrets. Autrement dit, la
figure 5.2 contient également des instances pour chaque concept. Il est ainsi possible
de parler par exemple du médecin Dr. P ou d’un certain laborantin. Tous les concepts
n’ont pas été retenus pour le système final. Des fois il était possible de simplifier la
structure. Ainsi, on peut s’imaginer que l’agent d’un infirmier et d’un médecin est le
même. Dans notre modèle une personne peut consulter uniquement les analyses pour
lesquelles elle a fait la demande. On peut donc même dire que l’infirmier est en dehors
du système puisqu’il ne fera jamais une demande d’analyse. Le même raisonnement
s’applique au concept de groupe de service. Bien que notre système incorporera une
certaine notion de “groupe de service” il n’est pas nécessaire de créer un concept cor-
respondant. Comme règle on peut dire que les concepts doivent contenir tout ce qui est
directement nécessaire au système. Par exemple, on voit qu’une demande d’analyse
ne contient aucun concept d’une éprouvette alors que tout le monde est d’accord sur
le fait que des éprouvettes font partie d’une analyse médicale. Ceci vient justement du
fait que le système ne contient pas directement d’éprouvettes et ne peut interagir avec
celles-ci.
Les bases étant claires on peut se consacrer plus en détail à l’étude des trois composants
d’une ontologie. Commençons par les concepts. La figure 5.3 résume les concepts
identifiés dans le système. Contrairement à la figure 5.2 la figure 5.3 ne contient plus
les instances des différents concepts. En effet Jade ne gère pas les instances. Chaque
concept est accompagné des attributs qui le qualifient. Un attribut peut être un type
F. 5.3.: Les concepts du système
simple comme une chaîne de caractère ou un nombre ou il peut être composé. On

trouve un tel attribut par exemple chez le concept Person. Une personne possède des
attributs de type chaîne de caractères et un attribut Adress. Si on regarde de plus
près on voit que ce dernier fait référence au concept Adress. Le schéma présente une
particularité. Le concept Caregiver possède un attribut Person. Ceci n’est pas tout à fait
juste. L’attribut exprime ici que le concept Caregiver hérite du concept Person. Il faut
donc lire le schéma comme suit : si le premier attribut porte le nom d’un concept, on
exprime un lien d’héritage sinon on exprime un attribut du type indiqué. On retrouve
ces structures d’héritage et d’encapsulation aussi au niveau des classes Java.
Souvent quand on analyse un système on se trouve face à une explosion de concepts.
Il est important de les trier et de ne garder que ceux qui sont intéressants pour le
système. Aussi il ne faut pas abuser des attributs et se limiter à ceux qui sont utiles
au système. Si l’ontologie devient vraiment très grande ou si l’ontologie couvre des
domaines distincts, il est possible de créer plusieurs ontologies et de les lier. Ainsi, on
aurait pu créer une ontologie pour le personnel et une ontologie pour les analyses,
résultats et autres.
La figure 5.3 montre trois types de personnes : les médecins, les laborantins et les
patients. La phase d’analyse (cf chapitre 4) a montré que ce sont les parties prenantes
du système. Les médecins et laborantins sont des entités actives tandis que le patient est
une entité passive. On a constaté que le patient ne participe pas directement au système.
Néanmoins, on doit le modéliser puisque le patient est l’élément central d’une analyse.
Il s’avère que les entités actives posséderont chacune leur propre agent. Dans cette
discussion on a oublié une entité : les superviseurs ou cadres. Il n’existe pas de concept
propre à un cadre. Cependant le concept Person fera amplement l’affaire puisqu’un
cadre ne possède pas plus d’attributs intéressants qu’une personne ordinaire.
Le concept d’une analyse médicale comporte une particularité. En réfléchissant, on se
rend compte que les concepts pour modéliser un résultat et une demande d’analyse sont
assez similaires. La seule différence entre ces deux concepts est la présence de valeurs
numériques pour les libellés dans le résultat. On a donc créé un concept abstrait d’une
analyse qui comporte tous les champs intéressants sauf la liste avec les analyses à
effectuer. A côté de cela il existe un autre concept qui modélise un seul type d’analyse.
Chaque analyse à effectuer peut être identifiée à l’aide d’une combinaison de type et
de libellé. En plus de ces deux champs, elle contient encore un résultat numérique. A
partir de ces deux concepts (Analysis et Code of analysis) on peut créer les deux concepts
Ask for Analysis et Result en héritant du concept Analysis.
Une fois les concepts bien identifiés, on peut définir les actions et prédicats. Les deux
sont importants, car c’est à travers les actions et prédicats que les conversations se
font. L’avantage est que l’action à exécuter est implicite dans la demande. On n’a pas
besoin d’un concept pour simuler ce que l’on demande. D’ailleurs, introduire un tel
concept serait contradictoire avec ce qu’on vient de voir. Le concept d’action n’a rien à
voir avec l’hôpital qu’on essaie de simuler. Le même principe s’applique aux prédicats
puisqu’une action et un prédicat sont très semblables. Les deux indiquent au récepteur
du message ce qu’on aimerait qu’il fasse (on aimerait qu’il le fasse puisqu’un agent
n’est pas un objet, donc il peut rejeter une demande. Pour rappel : un agent fait quelque
chose parce qu’il en a envie, un objet parce qu’on le lui demande).
La figure 5.4 montre les différentes actions qui existent dans le système. Les actions
découlent directement de l’analyse du système. Tout comme les concepts une action
comporte toujours un nom et des attributs. Le nom permet d’identifier l’action. On
verra dans la section 5.2 que les actions sont étroitement liées aux comportements. Il se
peut qu’une action ne contienne aucun argument. Le récepteur dispose peut-être déjà
de toutes les informations nécessaires pour traiter la demande (par exemple une action
qui demande l’heure).
Chaque cycle commence avec une demande d’analyse d’un médecin. Bien que dans le
cas concret de l’hôpital cantonal les demandes ne passent pas par le système des agents,
on a décidé d’ajouter cette action puisqu’elle apporte une certaine valeur pédagogique.
Une demande d’analyse se fait sur la base d’un formulaire de demande d’analyse. Ce
formulaire est reflété dans le concept Ask for Analysis. C’est le seul attribut d’une
demande d’analyse. Une demande est toujours faite par un médecin. Le laboratoire
la traite ensuite et fait les analyses nécessaires. Si tous les résultats sont normaux, ils
sont envoyés. L’action sendResult s’en charge. Pour ce faire, elle a besoin des résultats.
Afin d’optimiser les performances du système, on indique aussi le nom et le prénom
du patient concerné, mais ceci n’est pas indispensable au bon fonctionnement du
système. Si un résultat critique est détecté, le médecin traitant doit en être informé
le plus vite possible. L’action sendUrgent prend tous les résultats trouvés jusque-là,
y compris le résultat critique et les expédie. Cette deuxième action est nécessaire
puisqu’un résultat urgent est traité quelque peu différemment (voir section 5.2). Une
des grandes différences est que la durée de vie d’un résultat critique est plus petite.
C’est-à-dire qu’il sera plus vite “périmé”. Quand un médecin désire consulter les
résultats disponibles, il peut lancer l’action getResults. Afin d’identifier quelle analyse
le médecin désire consulter, il faut indiquer le numéro d’identification d’une analyse
(NLAB). Puisque ce numéro est unique, on peut ensuite trouver les résultats associés
dans la base de données et les renvoyer. Chaque résultat envoyé doit être confirmé.
La personne qui confirme un résultat accepte ainsi d’en prendre la responsabilité. On
a vu dans le chapitre 4 qu’il existe deux types de résultats : ceux qui sont urgents et
les autres. Le délai pour les résultats urgents est donc plus petit que pour les résultats
normaux. Le serveur vérifie régulièrement s’il y a des résultats périmés dans la base
de données. Pour faire cela, il dispose d’une action qui s’appelle giveUnconfirmed. Si
cette action renvoie une liste non vide alors une alerte doit être lancée pour chaque
résultat trouvé. Une Alert comporte un type pour indiquer si les résultats concernés
sont urgents ou non et le résultat.
F. 5.4.: Les actions du système

5.2. AGENTS Andreas Ruppen 50
Ces alertes sont un point critique du système. En effet pour minimiser la probabilité
qu’un résultat soit oublié dans la base de données ou perdu il faut envoyer des alertes
jusqu’à ce que quelqu’un s’en occupe. Il serait assez peu efficace d’alerter tout le temps
la même personne parce que si elle n’a pas répondu la première fois il est peu probable
qu’elle le fasse la deuxième fois. Pour contourner ce problème et aussi pour simuler
les groupes de service qu’on trouve sur la figure 5.2, la base de données du personnel
permet de monter une hiérarchie. Si un médecin ne répond pas, on essaie tous les
membres du groupe de service. Si aucun membre ne répond, on informe le médecin
responsable de ce groupe de service. Les médecins responsables sont de nouveaux
regroupés et ainsi de suite. Ce système n’exclut pas la possibilité que personne ne
s’occupe d’une alerte. La probabilité de cette situation décroît cependant avec la taille
du personnel.
Une fois que l’on a identifié les concepts, défini les actions il reste les prédicats. La
figure 5.5 montre les prédicats qui découlent eux aussi de l’analyse du système. Pendant
la construction du système, il s’avère cependant que l’on peut se passer de certains de
ces prédicats. Il est en effet plus efficace de demander un résultat et de renvoyer une liste
vide que de vérifier d’abord si un résultat est disponible et le cas échéant demander ce
résultat. En ce qui concerne les prédicats isCritical et isNormal ils ne sont pas utilisés dans
l’implémentation actuelle. L’idée derrière ces prédicats est la suivante : le laborantin
peut demander à un autre agent si une certaine valeur mesurée est normale ou critique
pour un type d’analyse donnée. L’implémentation de cet agent n’a pas été retenue
puisqu’il sort clairement du cadre initial.
F. 5.5.: Les prédicats du système
5.2. Agents
Maintenant que l’on a identifié les actions, on peut définir les comportements. Les
comportements c’est ce qui fait évoluer un agent. Un agent est un concept abstrait,
une sorte d’enveloppe. A travers la discussion de la section 5.1 on peut conclure que
le système sera composé de quatre agents :
• Caregiver agent
• Server agent
• Laboratory agent
• Manager agent
5.3. COMPORTEMENTS Andreas Ruppen 51
Un agent est une enveloppe vide qui utilisée pour regrouper les comportements qu’il
devra posséder plus tard. Jade propose une classe Agent de laquelle toute classe repré-
sentant un agent doit hériter. Dès lors la création d’un agent dans Jade est très simple.
Le listing 5.1 montre comment créer un agent minimaliste. Il est formé de deux mé-
thodes setup() et takeDown(). La première est lancée au démarrage d’un agent quant à
la deuxième, elle est faite le ménage avant que l’agent se termine.
1 import j a d e . core . Agent ;
import j a d e . core . AID ;
3
public class ExampleAgent extends Agent {
5 / / Put agent i n i t i a l i z a t
protected void setup ( ) {
7 .
.
9 .
}
11
/ / Put agent clean −up o p e r a t i o n s here
13 protected void takeDown ( ) {
.
15 .
.
17 }
}
Listing 5.1: Cration d’un agent minimaliste
5.3. Comportements
Les comportements c’est ce qui anime un agent. Les comportements sont l’équivalent
des rôles rencontrés dans les sections 3.1.1 et 3.1.2. Les comportements exécutent les
actions et prédicats afin de remplir leur mission. Jade propose sa propre approche
pour implémenter les comportements. Le listing 5.2 montre comment créer un com-
portement basique. Ce comportement hérite directement de la classe Behavior mis à
disposition par JADE.
public class ExampleBehavior extends Behaviour {
2 public void a c t i o n ( ) {
while ( t r u e ) {
4 .
.
6 .
}
8 }
10 public boolean done ( ) {

return true ;
12 }
}
Listing 5.2: Code source d’un comportement
D’autres comportements existent déjà dans Jade et chacun à son utilité pour une cer-
taine situation.On dispose ainsi d’un one-shot behavior. C’est un comportement qui est
exécuté exactement une fois. On peut l’utiliser par exemple au démarrage de l’agent
pour s’annoncer auprès des autres agents. Un autre comportement intéressant est le
Ticker behavior ou le Waker behavior. Le premier simule un comportement répétitif qui
doit être répété après un intervalle x. Le Waker behavior est similaire, mais il s’exécute à
un moment donné (par exemple après 10 secondes ou après 4 jours). En principe il ne
s’exécute qu’une seule fois. Mais il est tout à fait possible qu’il se reprogramme pour un
réveil ultérieur. L’avantage c’est qu’on peut avoir des intervalles non réguliers. Souvent
l’accomplissement d’une tâche nécessite l’accomplissement de plusieurs sous-tâches.
Le comportement adapté à cette situation est Sequential behavior. Les comportements
les plus importants sont probablement SimpleAchieveReInitator et SimpleAchieveReRes-
ponder. Une fois lancés, ces deux comportements tournent en principe jusqu’à la fin
de vie de l’agent. Il faut s’imaginer le SimpleAchieveReResponder comme un comporte-
ment qui écoute en continu une certaine file de messages entrants et réagit s’il reçoit
un nouveau message. Ces comportements agissent donc comme client-serveur. C’est
pour cette raison qu’il faut plutôt les comprendre comme un protocole d’interaction.
Au lancement de SimpleAchieveReResponder on l’associe généralement à un template
qui filtre les messages entrants. Plusieurs communications peuvent tourner en paral-
lèle sans s’interférer. La figure 5.6 donne une idée plus précise des comportements
disponibles dans Jade.
F. 5.6.: Aperçu des types des comportements disponibles dans Jade (tiré de [BCTR05])
Bon nombre de comportements dans notre système nécessitent de communiquer. Le

moyen le plus simple d’analyser ces comportements est de regarder les diagrammes
de séquences associés. Ils se lisent comme des diagrammes standards à l’exception que
les flèches ne sont pas des appels de méthodes, mais de comportements. Les boîtes
regroupent à chaque fois les comportements appartenant au même agent. En effet, il
est important de noter qu’une communication entre deux comportements se trouvant

dans le même agent n’implique pas les mêmes interactions que si les comportements
se trouvent dans deux agents différents. L’association des comportements à des agents
fera l’objet de la section 5.4.
La première communication qui a lieu dans le système suit la fin d’une analyse. Après
avoir effectué une analyse, le laboratoire doit transmettre les résultats au serveur. Deux
cas se présentent ici. Le premier est le plus fréquent il s’agit de celui où toutes les valeurs
d’une analyse sont normales. Un résultat est considéré comme étant normal si sa valeur
se trouve dans un intervalle prédéfini. Dans ce cas dès que l’analyse est terminée, les
résultats sont envoyés à la base de données. Pour des raisons de sécurité, l’agent du
laboratoire n’a pas un accès direct à la base de données. Ceci vaut pour tous les agents
sauf celui du serveur. Le fait d’envoyer les résultats d’une analyse implique donc une
communication entre l’agent du laboratoire et l’agent du serveur. La figure 5.7 montre le
détail de cette conversation. L’agent du laboratoire en est l’initiateur. La conversation
se base sur le protocole SimpleAchieveReInitiator - SimpleAchieveReResponder. Ceci est
nécessaire puisque du côté du serveur le comportement doit toujours être en attente
de nouveaux messages. Le serveur accepte les résultats transmis et se charge de les
enregistrer dans la base de données. Une fois que les résultats y sont enregistrés, il en
F. 5.7.: La conversation sendResult
informe l’agent du laboratoire (ceci fait partie du protocole et le termine) et il rajoute

une entrée dans la base de données où sont stockés les logs des conversations1 . On
voit dans ce log que l’agent serveur a reçu des résultats et les a bien enregistrés dans
la base de données. Il est important d’écrire ce log tout à la fin puisqu’il se peut
que l’enregistrement des résultats dans la base ne réussisse pas. On voit aussi sur la
figure 5.7 que le comportement sendResults se termine quand toutes les opérations du
côté du serveur se sont terminées alors que le comportement acceptResults de l’agent
serveur continu de tourner.
Le deuxième cas qui peut se présenter durant une analyse aie qu’un résultat trouvé
n’est pas normal. Souvent un tel résultat nécessite une intervention rapide auprès du
1 Les activités de log ne représentent aucun intérêt pédagogique et ne figurent donc pas sur les figures.
patient. Il est donc primordial d’en informer le médecin traitant le plus vite possible.
Ce comportement est de loin le plus compliqué du système. En effet vu qu’il s’agit
d’une situation potentiellement dangereuse pour le patient il faut s’assurer à tout prix
que le résultat soit lu par une personne compétente et le patient traité en fonction.
C’est aussi le seul comportement qui autorise des conversations directes entre les
différents agents sans passer par le serveur. Cependant, les messages qui sont envoyés
directement aux agents intéressés sont toujours envoyés au serveur en même temps.
On peut voir ces messages directs comme des bonus. Si ces messages sont perdus ou si
le médecin responsable ne répond pas, ce même message est toujours enregistré dans
la base de données et lui parviendra par la voie normale. Si toutefois un des messages
supplémentaires arrive chez le médecin celui-ci peut commencer à traiter le patient
tout de suite. Le temps de réaction du système est donc fortement réduit ce qui est
bénéfique pour le patient.
Examinons donc de plus près ce comportement. Le laboratoire trouve un résultat
anormal. Comme vu précédemment l’agent du laboratoire envoie le résultat au serveur.
Une copie de ce message est directement envoyée au médecin traitant. On peut partir
du principe que la probabilité qu’il le reçoit et la traite est grande. Envoyer le message
directement au médecin réduit donc le temps de réaction.
Le comportement du côté serveur qui réceptionne le message n’est plus le même
qu’avant. En effet les résultats critiques nécessitent un traitement différent. Tout comme
avant le message est accepté et enregistré dans la base de données. En plus d’enregistrer
le message dans la base de données un autre comportement est lancé, isUrgentConfir-
med. Il s’agit d’un Waker behavior puisque ce comportement doit vérifier au bout d’un
certain temps que le résultat a été traité par un médecin. Une fois ce comportement
programmé le serveur envoie un message d’information à l’agent du laboratoire qui
termine la conversation. Comme précédemment l’agent du serveur doit écrire le log
dans la base de données correspondante. Quand le comportement isUrgentConfirmed se
F. 5.8.: Envoi d’un résultat critique
réveille il vérifie dans la base de données si quelqu’un s’est occupé du résultat critique
et l’a confirmé. Si c’est le cas, le comportement s’arrête. Si par contre personne n’a
encore confirmé le résultat, il en informe le médecin traitant, le laboratoire ainsi que le
cadre du laboratoire. C’est la tâche du comportement sendAlert. La figure 5.8 montre
schématiquement comment fonctionne ce comportement. isUrgentConfirmed vérifie de
nouveau au bout d’un laps de temps assez court si le résultat a été traité et s’arrête le
cas échéant. Si personne ne s’est occupé du résultat, d’autres alertes sont envoyées à
d’autres médecins. Les médecins sont organisés par groupes de travail. Chaque groupe
possède un chef et les chefs sont à leur tour regroupés. On peut ainsi facilement créer
une hiérarchie. Le système envoie des alertes jusqu’à ce que quelqu’un s’en occupe.
La seule manière d’arrêter les alertes est d’envoyer une confirmation à l’agent du ser-
veur. C’est la tâche du comportement confirmUrgentResult. Ce comportement doit être
initié par un médecin (ou un cadre). Tous les médecins peuvent confirmer un résul-
tat urgent. Le laboratoire par contre n’a pas ce droit. Informer le laboratoire est juste
une sécurité supplémentaire. Quand le laboratoire reçoit une alerte pour un résultat
critique, c’est au laborantin de décider quelles mesures il doit prendre. Ces mesures
dépendront d’un protocole interne au laboratoire. Une des mesures possibles serait par
exemple d’appeler le cadre du laboratoire. La figure 5.9 montre la conversation pour
confirmer un résultat critique. Elle fait intervenir deux comportements : confirmUrgen-
tResult pour l’émetteur et checkResultAsTreated pour l’agent du serveur. C’est donc à
nouveau une conversation qui se fait avec l’agent du serveur. L’émetteur envoie un
F. 5.9.: Confirmation d’un résultat critique
simple message avec le numéro d’identification de l’analyse. Le serveur marque alors

le résultat correspondant dans la base de données comme étant traité. Ensuite l’agent
du serveur répond à l’émetteur en informant qu’il a bien traité sa requête. Ce message
clôt la conversation. A la fin il écrit dans la base de données des logs l’identité de l’agent
qui a confirmé le résultat ainsi que l’heure et l’analyse concernée. On remarque que
les comportements du côté serveur continuent de tourner alors que celui de l’émet-
teur s’arrête. Cette conversation est basée sur le protocole SimpleAchieveReInitiator -
SimpleAchieveReResponder.
L’agent d’un médecin vérifie régulièrement si de nouveaux résultats sont disponibles

et les télécharge le cas échéant à la manière d’un client de mail. Vu que l’agent d’un
médecin n’a pas d’accès direct à la base de données, cette vérification nécessite une
conversation avec l’agent du serveur. La figure 5.10 montre que cette vérification se
fait en deux étapes. La première demande si de nouveaux résultats sont disponibles
et la deuxième les télécharge. Le comportement searchResult est astucieux. Vu que la
F. 5.10.: Recherche de nouveaux résultats sur le serveur

recherche de nouveaux résultats se fait en deux étapes on va utiliser Sequential behavior.
Mais ce comportement ne permet pas de se lancer régulièrement. Il faut donc l’encap-
suler dans un comportement Ticker behavior. Tout ce que ce premier comportement fait
est d’appeler le comportement doSearchResults qui est du type Sequential behavior. Ce
dernier se fait ensuite en deux pas : askForResult et getResult.
La figure 5.11 montre ce qui se passe lorsque le serveur refuse de servir l’agent de
médecin. Un refus peut par exemple survenir si l’agent du serveur n’arrive pas à se
connecter sur la base de données. Dans ce cas il ne peut servir la requête et donc la
refuse. On trouve le même diagramme de séquence s’il n’y a pas de nouveau résultats
disponibles, à la différence près que l’agent du serveur ne répond pas avec un REFUSE,
mais qu’il renvoie simplement une liste vide. L’agent du médecin sait dans ce cas qu’il
n’y a pas de nouveaux résultats et le comportement s’arrête. On remarque cependant
que les comportements du côté serveur continuent de tourner. Cette conversation est
basée sur le protocole SimpleAchieveReInitiator - SimpleAchieveReResponder.
Une fois qu’un médecin a été chercher les résultats, il peut traiter ses patients. Pour
s’assurer, qu’il en fasse ainsi le système dispose d’une sécurité. La base de données est
balayée chaque heure et on cherche des résultats qui ne sont pas encore confirmés et
plus vieux qu’un temps donné. Si de tels résultats sont trouvés, la même procédure
d’alerte que celle expliquée plus haut est lancée. Pour éviter cela, le médecin doit confir-
mer qu’il a bien reçu et pris connaissance des résultats. Il s’engage ainsi à communiquer
ces résultats au patient et en prend la responsabilité. Cette confirmation se fait avec
une conversation entre l’agent du médecin et l’agent du serveur. La figure 5.12 montre
F. 5.11.: Recherche de nouveaux résultats avec refus du serveur
le diagramme de séquence de la conversation. L’agent du médecin envoie un message
F. 5.12.: Confirmation d’un résultat
contenant le numéro d’identification de l’analyse à l’agent du serveur. Celui-ci accepte

le message et marque l’analyse concernée dans la base de données comme étant traitée.
Si cette transaction réussit, il en informe le médecin avec un message. Ce message clôt
la conversation. A la fin il logue cette conversation dans la base de données des logs.
On peut ainsi retracer les responsabilités pour une analyse donnée. De plus, on voit
que le comportement du côté serveur continue de tourner. Cette conversation est basée
sur le protocole SimpleAchieveReInitiator - SimpleAchieveReResponder.
A côté des comportements exposés ci-dessus, il y a encore les comportements internes
qui ne communiquent pas. Ces comportements font des tâches de maintenance. Ainsi,
5.4. DISTRIBUTION DES COMPORTEMENTS AUXRuppen
Andreas AGENTS 58
l’agent du serveur possède un comportement qui cherche régulièrement des résultats

périmés dans la base de données. Si de tels résultats sont trouvés, l’agent lance le
comportement sendAlert. Il a déjà été traité en même temps que le comportement
sendUrgent. C’est le seul comportement actif de cet agent. Ceci vient du fait que ce
comportement est toujours lancé par un autre comportement. Il représente en quelque
sorte la partie active du comportement.
5.4. Distribution des comportements aux agents

Il s’agit maintenant d’associer à chaque agent ses comportements. Un médecin doit
pouvoir consulter les résultats d’une analyse, confirmer ces résultats et répondre à des
alertes. De plus, il doit envoyer des demandes d’analyses. Or comme évoqué plus haut
les demandes d’analyses ne passent pas par le système multi-agents, mais par un autre
système qui fait partie du système informatique actuel. Pour accomplir les tâches ci-
dessus, l’agent du médecin (ou Caregiver agent) possède donc les cinq comportements
suivants :
1. searchResult : Vérifie en intervalles réguliers la présence de nouveaux résultats.
• Type : Ticker behavior.
• lance le comportement suivant :
– doSearchResult : S’occupe de la vérification de la présence de nouveaux ré-
sultats. Cette vérification se fait en deux étapes.
– Type : Sequential behavior
– rajoute les sous-comportements
– askForResults : demande une liste de résultats disponibles.
– getResult : télécharge le résultat donné.
2. checkResultAsTreated : permet d’envoyer une confirmation pour un résultat.
• Type : SimpleAchieveReInitiator
3. cofirmUrgentResult : permet d’envoyer une confirmation pour un résultat critique.
4. acceptUrgentResult : reçoit et traite les messages entrants urgents.
• Type : SimpleAchieveReResponder
5. acceptAlert : reçoit les alertes envoyées par le serveur pour des résultats non-
confirmés.
Le serveur (ou Server agent) joue essentiellement un rôle passif. Pour la plupart des
conversations, il est le destinataire. C’est pour cela que la majorité de ses compor-
tements sont du type SimpleAchieveReResponder. Le serveur a ainsi besoin des huit
comportements suivants :
1. sendListOfAvailableResults : Envoie une liste contenant les numéros d’identifica-
tion des résultats disponibles.
2. serveResult : envoie le détail des résultats d’une analyse.
3. checkResultAsTreated : marque un résultat dans la base de données comme étant
traité.
5.5. BILAN Andreas Ruppen 59
4. acceptResult : enregistre un nouveau résultat dans la base de données.
5. acceptUrgentResult : enregistre un nouveau résultat urgent dans la base de don-
nées.
6. sendAlert : envoie des alertes pour les résultats périmés.
7. isUrgentConfirmed : vérifie si un résultat urgent a été confirmé dans les délais.
• Type : Waker behavior
8. getUnconfirmedResults : cherche dans la base de données tous les résultats périmés
pour envoyer des alertes.
• Type : Ticker behavior
Le laboratoire (ou Laboratory agent) doit être capable d’envoyer des résultats dans la
base de données. Vu qu’il n’a pas un accès direct à la base de données, il envoie tous
ses résultats à l’agent serveur qui s’occupe du reste. Pour faire ceci, il dispose des trois
comportements suivants :
1. sendResult : envoie les résultats d’une analyse
2. sendUrgentResult : envoie un résultat urgent. Le serveur saura ainsi qu’il doit le
traiter différemment.
3. acceptAlert : quand le serveur détecte un résultat périmé il en informe aussi le
laboratoire qui a fait l’analyse.
Finalement, il reste l’agent du cadre du laboratoire (ou Manager agent). Cet agent
répond uniquement aux alertes pour les résultats périmés.
1. acceptAlert : accepte les alertes entrantes.
Le tableau 5.1 résume les comportements du système. Ils sont classés par agent et on
trouve sur une même ligne les participants de chaque communication avec le nom
du comportement respectif. Le comportement qui initie la conversation est marqué
en gras. Certains comportements ne figurent pas sur le tableau. C’est notamment le
cas pour les comportements vides. Demander au serveur les résultats disponibles par
exemple est un comportement qui se subdivise en plusieurs sous-comportements. De
l’autre côté, c’est aussi un comportement qui doit s’exécuter régulièrement. Vu que
les comportements dans Jade sont des classes il est impossible d’hériter de plusieurs
comportements en même temps. La seule solution est donc d’emboîter plusieurs com-
portements avec les caractéristiques désirées.
5.5. Bilan
Avec les agents et les comportements exposés ci-dessus il est possible de créer un
système fonctionnel. Certes il n’est pas complet il lui manque par exemple les interfaces
5.5. BILAN Andreas Ruppen 60
Doctor Server Laboratory Manager

askForResults sendListOfAvailableResults
getResults serveResults
checkResultsAsTreated
checkResultsAsTreated
confirmUrgentResults
acceptResults sendResults
acceptUrgentResults acceptUrgentResults sendUrgentResults
acceptAlert sendAlert acceptAlert acceptAlert
T. 5.1.: Comportements et participants
utilisateur pour entrer les résultats d’une base de données. A la section 4.2 il a été
mentionné qu’un médecin dispose de plusieurs appareils mobiles et fixes et qu’il
peut travailler sur chacun de ces appareils de manière totalement transparente. Le
système tel qu’il est expliqué ci-dessus n’intègre pas encore cette possibilité. On se rend
cependant vite compte qu’il faudrait apporter peu de changements pour implémenter
cette fonctionnalité. En effet au lieu de communiquer directement avec le serveur les
agents du médecin devraient passer par son agent principal. Cet agent joue le rôle d’un
proxy pour les autres agents du médecin. Les autres contraintes du système ont toutes
été respectées.
Une autre limitation se trouve au niveau de l’envoi des résultats. Normalement chaque
département du laboratoire cantonal devrait pouvoir envoyer ses résultats de manière
indépendante. Si on désire un tel système, il y a un prix à payer. Deux solutions sont
envisageables :
1. soit le médecin confirme chaque résultat d’une analyse ce qui peut être fastidieux,
2. soit c’est le système que gère la collecte des résultats indépendants et il ne rend
disponibles les résultats d’une analyse uniquement lorsqu’ils sont tous présents
dans la base de données.
La deuxième solution exige une connaissance de la demande d’analyse et donc du
nombre de résultats qu’il doit recevoir avant de rendre accessibles les résultats d’une
analyse. Or le système ne dispose pas de cette information puisque les demandes se
font toujours sur papier.
Beaucoup de soin a été apporté aux alertes. Les alertes sont envoyées simultanément
aux cadres du laboratoire et aux médecins. Pour les deux groupes, il existe une hiérar-
chie, selon laquelle le système essaie de contacter les médecins et cadres du laboratoire.
Il devient alors très peu probable qu’un résultat soit perdu.
En plus de ce système d’alerte, le serveur écrit chaque action dans une base de données.
Il est alors possible de retracer à tout moment le parcours d’un résultat et d’en désigner
le responsable. Si par exemple un médecin reçoit un résultat critique et le confirme,
mais n’informe jamais son patient et que ce dernier succombe à sa maladie on saura
alors que ce médecin n’a pas fait son travail.
Utilisation du système
6
“A wise man can learn more from a foolish question than a fool can learn from a wise
answer.”
- Bruce Lee
6.1. Installation & Configuration . . . . . . . . . . . . . . . . . . . . . . . . 61

6.2. Scénario d’exemple avec captures d’écran . . . . . . . . . . . . . . . . 62
Puisque le système est basé sur un cadriciel, sa mise en route nécessite quelques
manipulations supplémentaires. Il ne suffit pas de compiler et lancer le code source.
En effet pour que le système fonctionne la plateforme doit déjà tourner. De plus,
les différents agents font appel à un fichier de configuration. Ce fichier contient les
informations qui distinguent une instance d’une autre.
6.1. Installation & Configuration

L’installation et la configuration sont basées sur Ant. L’utilisation de Ant facilite la
tâche de mise en route du système. Cependant, Ant nécessite quelques ajustements
afin de bien fonctionner. Le fichier build.properties contient une variable libs.dir qu’il
faut adapter afin qu’elle pointe vers le répertoire qui contient le répertoire jade (et
qui lui contient les binaires pour Jade). Ce changement suffit pour faire fonctionner la
compilation et la mise en route du système. D’autres targets (junit, src2ltx, etc.) font
appel à d’autres bibliothèques. Le cd-rom contient toutes les dépendances nécessaires
pour faire tourner tous les targets. Il suffit de les placer dans le répertoire vers lequel
point la varibale libs.dir. Il est ensuite possible de compiler le projet. Ceci se fait avec
Ant.
1 ruppena@gandalf : H o s p i t a l > a n t compile
Le résultat de cette commande devrait ressembler à
61
6.2. SCÉNARIO D’EXEMPLE AVEC CAPTURES D’ÉCRAN
Andreas Ruppen 62
1 B u i l d f i l e : b u i l d . xml
3 init :
[ mkdir ] Created d i r : / Users / ruppena / Documents / Textdocuments / UniFr3 / Bachelor / e c l i p s e / H o s p i t a l / b i n
5
compile :
7 [ j a v a c ] Compiling 65 source f i l e s t o / Users / ruppena / Documents / Textdocuments / UniFr3 / Bachelor / e c l i p s e /
Hospital / bin
[ j a v a c ] / Users / ruppena / Documents / Textdocuments / UniFr3 / Bachelor / e c l i p s e / H o s p i t a l / s r c / h o s p i t a l /
o n t o l o g y / h o s p i t a l O n t o l o g y . j a v a : 9 : warning : [ d e p r e c a t i o n ] h o s p i t a l . o n t o l o g y . a c t i o n s .
SendConfirmation i n h o s p i t a l . o n t o l o g y . a c t i o n s has been deprecated
9 [ j a v a c ] i m p o r t h o s p i t a l . o n t o l o g y . a c t i o n s . SendConfirmation ;
[ javac ] ^
11 [ j a v a c ] / Users / ruppena / Documents / Textdocuments / UniFr3 / Bachelor / e c l i p s e / H o s p i t a l / s r c / h o s p i t a l /
database / DummyAccess . j a v a : 1 7 0 : warning : [ d e p r e c a t i o n ] g e t S u p e r i o r ( j a v a . l a n g . S t r i n g ) i n h o s p i t a l .
database .DB has been deprecated
[ javac ] p u b l i c i n t g e t S u p e r i o r ( S t r i n g NLAB)
13 [ javac ] ^
[ j a v a c ] / Users / ruppena / Documents / Textdocuments / UniFr3 / Bachelor / e c l i p s e / H o s p i t a l / s r c / h o s p i t a l /
database / SQLiteAccess . j a v a : 3 9 1 : warning : [ d e p r e c a t i o n ] g e t S u p e r i o r ( j a v a . l a n g . S t r i n g ) i n h o s p i t a l
. database .DB has been deprecated
15 [ javac ] p u b l i c i n t g e t S u p e r i o r ( S t r i n g NLAB)
[ javac ] ^
17 [ j a v a c ] / Users / ruppena / Documents / Textdocuments / UniFr3 / Bachelor / e c l i p s e / H o s p i t a l / s r c / h o s p i t a l /
o n t o l o g y / h o s p i t a l O n t o l o g y . j a v a : 3 3 2 : warning : [ d e p r e c a t i o n ] h o s p i t a l . o n t o l o g y . a c t i o n s .
SendConfirmation i n h o s p i t a l . o n t o l o g y . a c t i o n s has been deprecated
[ javac ] t h i s . add ( new AgentActionSchema (SEND_CONFIRMATION) , SendConfirmation .
class ) ;
19 [ javac ] ^
[ j a v a c ] 4 warnings
21
BUILD SUCCESSFUL
Si la compilation passe, on peut lancer l’application. Afin que les agents puissent
tourner, il faut d’abord démarrer la plateforme puis les agents l’un après l’autre. Il est
à noter que le Serveragent doit être le premier agent lancé sur la plateforme. Ceci vient
du fait que tous les autres agents ont besoin du serveur pour s’enregistrer auprès du
Directory Facilitator Agent avec leur numéro personnel. Le fichier build.xml propose
plusieurs targets pour lancer la plateforme et les agents.
• run-jade : lance la plateforme.
• run-server : lance l’agent serveur.
• run-caregiver : lance l’agent médecin.
• run-laboratory : lance l’agent laborantin.
• run-manager : lance l’agent cadre.
• run-init : lance la plateforme et l’agent serveur.
• run-clients : lance les agents médecin, laborantin et cadre.
On voit donc que la méthode à préféré pour lancer l’application est de d’abord lancer
run-init puis une fois la plateforme démarrée run-clients.
La section 4.2 à mis en évidence que l’agent serveur communique avec une base de
données. Le système est fait de telle sorte qu’il supporte plusieurs types de bases de
données. Cependant actuellement le seul type qui fonctionne se base sur sqlite3. Il est
donc indispensable d’avoir installé les binaires de sqlite3.
6.2. Scénario d’exemple avec captures d’écran

Voyons à présenter le déroulement du démarrage du système suivi d’un envoi d’un
résultat et sa consultation par un médecin. Avant de lancer le système, il faut remettre
Andreas Ruppen 63
les bases de données à zéro (si on le souhaite). Ceci se fait avec la commande suivante :
ruppena@gandalf : H o s p i t a l > rm h o s p i t a l . db
2 ruppena@gandalf : H o s p i t a l > s q l i t e 3 h o s p i t a l . db < h o s p i t a l . s q l i t e
ruppena@gandalf : H o s p i t a l > rm l o g g e r . db
4 ruppena@gandalf : H o s p i t a l > s q l i t e 3 l o g g e r . db < l o g g e r . s q l
Comme méntionné dans la section précedente il faut tout d’abord démarrer la plate-
forme et l’agent serveur. La méthode préférée est d’utiliser la commande qui lance les
deux à la fois.
ruppena@gandalf : H o s p i t a l > a n t run − i n i t
2 B u i l d f i l e : b u i l d . xml
4 init :
6 compile :
8 run − i n i t :
[ java ] 10 s e p t . 2007 0 2 : 52 : 2 3 j a d e . core . Runtime b e g i n C o n t a i n e r
10 [ java ] INFO : −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
[ java ] T h i s i s JADE3 . 4 − r e v i s i o n 5874 o f 2006/03/09 1 4 : 1 3 : 1 1
12 [ java ] downloaded i n Open Source , under LGPL r e s t r i c t i o n s ,
[ java ] a t h t t p : / / j a d e . t i l a b . com /
14 [ java ] −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
[ java ] 10 s e p t . 2007 0 2 : 52 : 2 4 j a d e . core . BaseService i n i t
16 [ java ] INFO : S e r v i c e j a d e . core . management . AgentManagement i n i t i a l i z e d
18 [ java ] INFO : S e r v i c e j a d e . core . messaging . Messaging i n i t i a l i z e d
20 [ java ] INFO : S e r v i c e j a d e . core . m o b i l i t y . A g e n t M o b i l i t y i n i t i a l i z e d
22 [ java ] INFO : S e r v i c e j a d e . core . event . N o t i f i c a t i o n i n i t i a l i z e d
[ java ] 10 s e p t . 2007 0 2 : 52 : 2 4 j a d e . core . messaging . MessagingService boot
24 [ java ] INFO : MTP addresses :
[ java ] h t t p : / / g a n d a l f : 7 7 7 8 / acc
26 [ java ] 10 s e p t . 2007 0 2 : 52 : 2 4 j a d e . core . A g e n t C o n t a i n e r I m p l j o i n P l a t f o r m
[ java ] INFO : −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
28 [ java ] Agent c o n t a i n e r Main−Container@JADE−IMTP : / / g a n d a l f i s ready .
[ java ] −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
La figure 6.1 montre l’interface de contrôle de la plateforme. On voit sur cette image
qu’il y a quatre agents dans le conteneur principal de la plateforme, à savoir le AMS
agent, le RMA agent, le DF agent et le Server agent.
La figure 6.2 montre les communications qui ont lieu lors du lancement d’un agent. La
première communication est entre l’agent et le DF agent. L’agent cherche ainsi l’adresse
du Server agent. On voit que l’agent essaie ensuite de contacter le serveur afin qu’il lui
indique son numéro d’identification personnel (qui est dans la base de données). Une
fois que l’agent connaît son numéro d’identification personnel, il peut s’enregistrer
dans les pages jaunes.
Les agents médecins et laborantins disposent d’une interface primitive, mais suffisante
pour tester les fonctionnalités des bases du système. L’interface de l’agent médecin
ressemble à un client mail tandis que celle de l’agent laborantin ne contient que deux
boutons permettant d’envoyer un résultat et un résultat critique respectivement. L’in-
terface de l’agent médecin est divisée en trois parties. La partie inférieure permet
d’afficher le détail d’une analyse. La partie supérieure gauche contient toutes les ana-
lyses du médecin tandis que la partie supérieure droite affiche les alertes auxquelles le
médecin devrait répondre.
Voyons à présent ce qui se passe lorsqu’un laborantin envoie les résultats d’une analyse.
Les résultats sont envoyés vers l’agent serveur qui les enregistre dans une base de
Andreas Ruppen 64
F. 6.1.: Lancement de la plateforme
données (figure 6.4). Si tout se passe bien l’agent serveur informe l’agent laborantin
du bon déroulement de l’enregistrement des résultats dans la base de données. Le
médecin peut maintenant consulter ces résultats en appuyant sur le bouton Fetch de
son client. De plus, l’agent médecin vérifie dans un intervalle régulier si de nouveaux
résultats sont disponibles et les télécharge le cas échéant (figure 6.5). Le médecin peut
maintenant transmettre les résultats de l’analyse au patient et confirmer le traitement
des résultats auprès de l’agent serveur.
Andreas Ruppen 65
F. 6.2.: Communications lors du lancement d’un agent
F. 6.3.: Interfaces des agents

Andreas Ruppen 66
F. 6.4.: Envoi d’un résultat et enregistrement dans la base de données
F. 6.5.: Consultation d’un résultat par un médecin

Conclusion
7
Rappelons-nous des cinq champs d’étude de l’informatique qu’on a rencontrés dans
l’introduction. Il s’agit de
• l’omniprésence,
• l’interface homme-machine.
On a également constaté un besoin croissant d’interconnexion de la part des utilisa-
teurs. Ces utilisateurs nomades demandent à leurs appareils d’être de plus en plus
intelligents avec des interfaces toujours plus intuitives. L’utilisateur moderne délègue
beaucoup de tâches à des ordinateurs, d’où un besoin croissant pour des ordinateurs
omniprésents (le réfrigérateur qui se remplit automatiquement, la luminosité de l’ap-
partement qui s’adapte aux besoins de son propriétaire, etc.). Mais si on y réfléchit
bien est-ce que nous ne disposons pas déjà d’une technologie qui sait répondre à ces
critères ? La première chose à laquelle on pense quand on évoque les termes ci-dessus
est internet. Ce n’est pas pour rien qu’internet rencontre un tel succès. Il est donc tout
naturel de développer des solutions qui se basent sur internet pour répondre aux di-
vers besoins des utilisateurs. Des telles solutions existent et tout le monde en a entendu
parler tellement c’est devenu à la mode. Il s’agit bien entendu des services web (engl.
web service). Mais qu’est-ce qu’un service web ? On regroupe sous le terme de service
web une technologie qui permet à des applications de communiquer indépendamment
des langages dans lesquels ils sont écrits et des plateformes sous-jacentes. Un service
web est souvent une sorte d’interface accessible par un réseau (souvent internet) qui
permet d’exécuter un programme sur la machine qui propose le service web. Il s’agit
donc d’une communication client-serveur. Le client et le serveur utilisent un dialecte
de XML appelé SOAP pour communiquer. A côté de la communication entre le client
et le serveur, les services web spécifient des protocoles pour la recherche et la décou-
verte de services (WSDL). La figure 7.1 montre l’interaction des différents composants
nécessaires à la publication et découverte d’un service web.
Aurait il été possible d’implémenter une solution pour l’hôpital, entièrement basée
sur des services web. La réponse est clairement oui. On pourrait s’imaginer que la
machine qui a accès à la base de données publie des services web : un pour le personnel
soignant qui leur permet de consulter des résultats et un autre pour le laboratoire qui
leur permet d’entrer des résultats. Le système répond à tous les critères discutés dans
la partie d’analyse. Ainsi il est “sûr” puisqu’ une authentification avant l’utilisation
67
Andreas Ruppen 68
F. 7.1.: Publication, découverte et utilisation d’un service web(tiré de [3])
des services web est possible. De plus, il s’intègre parfaitement dans les différents
environnements de travail. On pourrait s’imaginer une solution qui se base sur internet
et HTML. L’utilisation devient alors très simple (puisque réduite au parcours d’un site
web). De plus, il est possible de manipuler les données depuis plusieurs postes de
travail.
On peut alors se demander à quoi servent les agents. N’est-ce pas tout simplement une
approche plus compliquée de ce que proposent déjà les services web ? La réponse ici
est non. Il est en effet possible dans certains cas d’implémenter une solution basée sur
des services web ou des agents sans différences majeures. Il est aussi possible de faire
des services web dotés d’une intelligence artificielle. Un service web peut faire appel
à un autre service web. Un service web peut publier les services qu’il propose dans
un annuaire. Les services web sont distribués. Toutefois, ceci n’est pas suffisant pour
concurrencer les agents. Car comme on l’a évoqué dans l’introduction ce qui importe
pour un agent ce n’est pas son intelligence artificielle à proprement parler, mais plutôt
une “intelligence sociale”. Rappelons-nous la grande différence entre un agent et un
objet : un agent exécute une action parce qu’il le désire, un objet parce qu’on le lui
demande. On peut comprendre cette “intelligence” comme suit : soient deux tas de
foin et deux mulets reliés par une corde. Les deux mulets ont faim et doivent manger.
Cependant, la corde est trop courte pour permettre aux deux de manger en même
temps. Les deux mulets vont tirer sur la corde, chacun de leur côté sans qu’aucun des
deux ne parvienne à sa fin. Si les deux mulets étaient cependant dotés d’une intelligence
sociale, ils auraient peut-être trouvé une solution. . .
Malgré la critique ci-dessus ce travail montre comment utiliser un système multi-
agents. La lecture linéaire donne en plus la méthodologie qui a été utilisée pour mo-
déliser le système avant son implémentation. D’autres manières de procéder dans
la modélisation existent et chacune a ses avantages et désavantages. Du fait que les
systèmes multi-agents sont une technologie encore récente il y a beaucoup de change-
ments dans ces approches. Ainsi, des travaux se font afin de porter la méthodologie
Andreas Ruppen 69
F. 7.2.: Service web vs. système multi-agents
de l’eXtreme Programming aux agents. En effet, il est possible d’utiliser le “dummy

agent” pour faire des tests unitaires. Cependant, la collecte des résultats des tests est
encore très fastidieuse1 . Avec les méthodologies, les cadriciels évoluent aussi. Alors
que JADE est un cadriciel complet pour le développement des agents il reste d’assez
bas niveau, surtout si on le compare à d’autres comme Jack qui propose plus d’outils
et de fonctions. Peut-être qu’un jour on aura l’équivalent de Java pour les agents. Un
langage universel parfaitement adapté à la problématique.
La partie de l’implémentation prend une place importante dans ce travail. Elle permet
d’expliquer certains choix et de montrer à l’aide d’un exemple des concepts. L’appli-
cation finale qui résulte de cette implémentation est fonctionnelle et possède toutes
les fonctionnalités importantes. Beaucoup d’aspects ont cependant été négligés dans
l’implémentation puisqu’ils ne représentaient aucun intérêt pédagogique. Ainsi, les
problèmes liés à la sécurité des transmissions ou à l’authentification n’ont pas été abor-
dés du tout. Aussi il manque à l’application des GUIS pour les laborantins et pour
les cadres du laboratoire. De même, l’interface du médecin est très rudimentaire et
nécessiterait un petit coup pour la rendre plus agréable à l’utilisation.
1 Le lecteur intéressé trouvera plus d’informations dans [CKvSL06]

Diagrammes pour
A
MaSE
F. A.1.: Diagramme d’hiérarchie des buts
F. A.2.: Diagramme de tâches
70
Andreas Ruppen 71
F. A.3.: Diagramme de séquence
F. A.4.: Diagramme de classe d’agents

Andreas Ruppen 72
(a) Emmeteur
(b) Récepteur
F. A.5.: Diagramme de classe de communications

Andreas Ruppen 73
F. A.6.: Diagramme de déploiement

Ontologie pour
B
Jade
1 public class h o s p i t a l O n t o l o g y extends Ontology

{
3
/∗
5 ∗ Le nom des champs e s t u t i l i s e pour r e t r o u v e r l e s g e t t e r e t s e t t e r s . A i n s i
∗ s i l ’ on d e f i n i t un champ ADRESSE_STREET = " s t r e e t a b c " dans l a c l a s s e
7 ∗ Adresse i l f a u t a v o i r un champ q u i s ’ a p p e l l e s t r e e t a b c e t deux methodes :
∗ g e t S t r e e t a b c e t s e t S t r e e t a b c . Sinon j a d e ne t r o u v e pas l e s g e t t e r s e t
9 ∗ setters .
∗/
11 p r i v a t e s t a t i c f i n a l long serialVersionUID = − 5202910996193407799L ;
13 p r i v a t e s t a t i c f i n a l Ontology i n s t a n c e = new h o s p i t a l O n t o l o g y ( ) ;
15 public s t a t i c f i n a l S t r i n g NAME = " h o s p i t a l −o n t o l o g y " ;
17 / / Concepts
public s t a t i c f i n a l S t r i n g ADRESSE = "ADRESSE" ;
19
public s t a t i c f i n a l S t r i n g ADRESSE_STREET = " street " ;
21
public s t a t i c f i n a l S t r i n g ADRESSE_NUMBER = " st r ee t nu m b er " ;
23
public s t a t i c f i n a l S t r i n g ADRESSE_CITY = " city " ;
25
public s t a t i c f i n a l S t r i n g ADRESSE_COUNTRY = " country " ;
27
public s t a t i c f i n a l S t r i n g DEPARTEMENT = "DEPARTEMENT" ;
29
public s t a t i c f i n a l S t r i n g DEPARTEMENT_ADRESSE = " departementadr " ;
31
public s t a t i c f i n a l S t r i n g LABORATORY = "LABORATORY" ;
33
public s t a t i c f i n a l S t r i n g LABORATORY_DEPARTMENT = " labodepartement " ;
35
public s t a t i c f i n a l S t r i n g LABORATORY_ADRESSE = " laboadr " ;
37
public s t a t i c f i n a l S t r i n g PERSON = "PERSON" ;
39
public s t a t i c f i n a l S t r i n g PERSON_ADRESSE = " adresse " ;
41
public s t a t i c f i n a l S t r i n g PERSON_LASTNAME = " lastname " ;
43
public s t a t i c f i n a l S t r i n g PERSON_FIRSTNAME = " firstname " ;
45
public s t a t i c f i n a l S t r i n g PERSON_TELEHPONE = " phonenumber " ;
47
public s t a t i c f i n a l S t r i n g PERSON_BIRTHDAY = " birthday " ;
49
public s t a t i c f i n a l S t r i n g PERSON_TYPE = " type " ;
51
public s t a t i c f i n a l S t r i n g PATIENT = " PATIENT " ;
74
Andreas Ruppen 75
53
public s t a t i c f i n a l S t r i n g PATIENT_PID = " pid " ;
55
public s t a t i c f i n a l S t r i n g PATIENT_SEX = " sex " ;
57
public s t a t i c f i n a l S t r i n g PATIENT_AGE = " age " ;
59
public s t a t i c f i n a l S t r i n g CAREGIVER = "CAREGIVER" ;
61
public s t a t i c f i n a l S t r i n g CAREGIVER_BEEPER = " beeper " ;
63
public s t a t i c f i n a l S t r i n g CAREGIVER_FUNCTION = " function " ;
65
public s t a t i c f i n a l S t r i n g CAREGIVER_HOSPITAL = " hospital " ;
67
public s t a t i c f i n a l S t r i n g LABORATORY_ASSISTENT = "LABORATORYASSISTENT" ;
69
public s t a t i c f i n a l S t r i n g LABORATORY_ASSISTENT_FUNCTION = " f u n c t i o n " ;
71
public s t a t i c f i n a l S t r i n g LABORATORY_ASSISTENT_LABORATORY = " l a b o r a t o r y " ;
73
public s t a t i c f i n a l S t r i n g SUPERIOR = "SUPERIOR" ;
75
public s t a t i c f i n a l S t r i n g SUPERIOR_PRIORITY = " priority " ;
77
public s t a t i c f i n a l S t r i n g ANALYSIS = " ANALYSIS " ;
79
public s t a t i c f i n a l S t r i n g ANALYSIS_ISURGENT = " urgent " ;
81
public s t a t i c f i n a l S t r i n g ANALYSIS_DATE = " date " ;
83
public s t a t i c f i n a l S t r i n g ANALYSIS_NLAB = " nlab " ;
85
public s t a t i c f i n a l S t r i n g ANALYSIS_INDICATIONS = " indications " ;
87
public s t a t i c f i n a l S t r i n g ANALYSIS_PATIENT = " patient " ;
89
public s t a t i c f i n a l S t r i n g ANALYSIS_CAREGIVER = " caregiver " ;
91
public s t a t i c f i n a l S t r i n g DE_ANALYSIS = "DEANALYSIS" ;
93
public s t a t i c f i n a l S t r i n g DE_ANALYSIS_RESULTS = " codeOfAnalysis " ;
95
public s t a t i c f i n a l S t r i n g RESULT = "RESULT" ;
97
public s t a t i c f i n a l S t r i n g RESULT_LABORATORY_ASSISTANT = " laboratoryassistant " ;
99
public s t a t i c f i n a l S t r i n g RESULT_ANALYSIS = " listofrecodedanalyse " ;
101
public s t a t i c f i n a l S t r i n g CODE_OF_ANALYSIS = "CODEOFANALYSIS" ;
103
public s t a t i c f i n a l S t r i n g CODE_OF_ANALYSIS_TYPE = " type " ;
105
public s t a t i c f i n a l S t r i n g CODE_OF_ANALYSIS_LITTERAL = " litteral ";
107
public s t a t i c f i n a l S t r i n g RE_CODE_OF_ANALYSIS = "RECODEOFANALYSIS" ;
109
public s t a t i c f i n a l S t r i n g RE_CODE_OF_ANALYSIS_VALUE = " value " ;
111
/ / Predicates
113 public s t a t i c f i n a l S t r i n g IS_RESULT_READY = " ready " ;
115 public s t a t i c f i n a l S t r i n g IS_RESULT_READY_PATIENT = " patient " ;
117 public s t a t i c f i n a l S t r i n g IS_CRITICAL = " critical " ;
119 public s t a t i c f i n a l S t r i n g IS_CRITICAL_RESULT = " criticalResult " ;
121 / / Actions
public s t a t i c f i n a l S t r i n g SEND_URGENT = " sendUrgent " ;
123
public s t a t i c f i n a l S t r i n g SEND_URGENT_RESULTS = " result " ;
125
Andreas Ruppen 76
public s t a t i c f i n a l S t r i n g SEND_RESULT = " sendResult " ;

127
public s t a t i c f i n a l S t r i n g SEND_RESULT_RESULTS = " result " ;
129
public s t a t i c f i n a l S t r i n g SEND_RESULT_PATIENT_LASTNAME = " lastname " ;
131
public s t a t i c f i n a l S t r i n g SEND_RESULT_PATIENT_FIRSTNAME = " f i r s t n a m e " ;
133
public s t a t i c f i n a l S t r i n g GIVE_UNCONFORMED_RESULTS = " unconfirmed " ;
135
public s t a t i c f i n a l S t r i n g GET_RESULT = " getResult " ;
137
public s t a t i c f i n a l S t r i n g GET_RESULT_PATIENT_NLAB = "NLAB" ;
139
public s t a t i c f i n a l S t r i n g SEND_CONFIRMATION = " sendConfirmation " ;
141
public s t a t i c f i n a l S t r i n g SEND_CONFIRMATION_RESULTS = " result " ;
143
public s t a t i c f i n a l S t r i n g ASK_FOR_ANALYSIS = " askForAnalysis " ;
145
public s t a t i c f i n a l S t r i n g ASK_FOR_ANALYSIS_ANALYSIS = " analysis " ;
147
public s t a t i c f i n a l S t r i n g ALERT = " alert " ;
149
public s t a t i c f i n a l S t r i n g ALERT_TYPE = " type " ;
151
public s t a t i c f i n a l S t r i n g ALERT_RESULT = " result " ;
153
public s t a t i c f i n a l S t r i n g SEND_AVAILABLE_LIST = " SENDAVAILABLELIST " ;
155
public s t a t i c f i n a l S t r i n g SEND_AVAILABLE_LIST_CAREGIVER = " c a r e g i v e r " ;
157
public s t a t i c f i n a l S t r i n g SEND_AVAILABLE_LIST_NLABS = "NLAB" ;
159
public s t a t i c f i n a l S t r i n g CHECK_RESULT_AS_TREATED = "CHECKRESULTASTREATED" ;
161
public s t a t i c f i n a l S t r i n g CHECK_RESULT_AS_TREATED_NLAB = " nlab " ;
163
public s t a t i c f i n a l S t r i n g SEND_PID = "SENDPID" ;
165
public s t a t i c f i n a l S t r i n g SEND_PID_PERSON = " person " ;
167
public s t a t i c f i n a l S t r i n g SEND_PID_PID = " pid " ;
169
public s t a t i c f i n a l S t r i n g SEND_PID_PRIORITY = " priority " ;
171
public s t a t i c Ontology g e t I n s t a n c e ( )
173 {
return instance ;
175 }
177 private hospitalOntology ( )

{
179 super (NAME, BasicOntology . g e t I n s t a n c e ( ) ) ;
try
181 {
/ / Concepts
183 t h i s . add (new ConceptSchema (ADRESSE) , Adresse . class ) ;
t h i s . add (new ConceptSchema (DEPARTEMENT) , Departement . class ) ;
185 t h i s . add (new ConceptSchema (LABORATORY) , L a b o r a t o r y . class ) ;
t h i s . add (new ConceptSchema (PERSON) , Person . class ) ;
187 t h i s . add (new ConceptSchema ( PATIENT ) , P a t i e n t . class ) ;
t h i s . add (new ConceptSchema (CAREGIVER) , C a r e g i v e r . class ) ;
189 t h i s . add (new ConceptSchema (LABORATORY_ASSISTENT) , L a b o r a t o r y A s s i s t e n t . class ) ;
t h i s . add (new ConceptSchema (SUPERIOR) , S u p e r i o r . class ) ;
191 t h i s . add (new ConceptSchema ( ANALYSIS ) , A n a l y s i s . class ) ;
t h i s . add (new ConceptSchema ( DE_ANALYSIS ) , DeAnalysis . class ) ;
193 t h i s . add (new ConceptSchema (CODE_OF_ANALYSIS) , CodeOfAnalysis . class ) ;
t h i s . add (new ConceptSchema (RESULT) , R e s u l t . class ) ;
195 t h i s . add (new ConceptSchema (RE_CODE_OF_ANALYSIS) , ReCodeOfAnalysis . class ) ;
197 ConceptSchema cs = ( ConceptSchema ) t h i s . getSchema (ADRESSE) ;

Andreas Ruppen 77
cs . add (ADRESSE_STREET, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) , ObjectSchema .

MANDATORY) ;
199 cs . add (ADRESSE_NUMBER, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . INTEGER ) , ObjectSchema .
MANDATORY) ;
cs . add ( ADRESSE_CITY , ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) , ObjectSchema .
MANDATORY) ;
201 cs . add (ADRESSE_COUNTRY, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) , ObjectSchema .
MANDATORY) ;
203 cs = ( ConceptSchema ) t h i s . getSchema (DEPARTEMENT) ;

cs . add (DEPARTEMENT_ADRESSE, ( ConceptSchema ) t h i s . getSchema (ADRESSE) , ObjectSchema .MANDATORY) ;
205
cs = ( ConceptSchema ) t h i s . getSchema (LABORATORY) ;
207 cs . add (LABORATORY_ADRESSE, ( ConceptSchema ) t h i s . getSchema (ADRESSE) , ObjectSchema .MANDATORY) ;
209 cs = ( ConceptSchema ) t h i s . getSchema (PERSON) ;

cs . add (PERSON_ADRESSE, ( ConceptSchema ) t h i s . getSchema (ADRESSE) , ObjectSchema .MANDATORY) ;
211 cs . add (PERSON_FIRSTNAME, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) , ObjectSchema .
MANDATORY) ;
cs . add (PERSON_LASTNAME, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) , ObjectSchema .
MANDATORY) ;
213 cs . add (PERSON_TELEHPONE, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) , ObjectSchema .
MANDATORY) ;
cs . add (PERSON_BIRTHDAY, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . INTEGER ) ) ;
215 cs . add (PERSON_TYPE, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) , ObjectSchema . OPTIONAL )
;
217 cs = ( ConceptSchema ) t h i s . getSchema ( PATIENT ) ;

cs . addSuperSchema ( ( ConceptSchema ) t h i s . getSchema (PERSON) ) ;
219 cs . add ( PATIENT_AGE , ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . INTEGER ) , ObjectSchema . OPTIONAL
);
cs . add ( PATIENT_PID , ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . INTEGER ) , ObjectSchema . OPTIONAL
);
221 cs . add ( PATIENT_SEX , ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) ) ;
223 cs = ( ConceptSchema ) t h i s . getSchema (CAREGIVER) ;

225 cs . add (CAREGIVER_BEEPER, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) ) ;
cs . add (CAREGIVER_FUNCTION, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) ) ;
227 cs . add ( CAREGIVER_HOSPITAL , ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) ) ;
229 cs = ( ConceptSchema ) t h i s . getSchema (LABORATORY_ASSISTENT) ;

231 cs . add (LABORATORY_ASSISTENT_FUNCTION, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) ,
ObjectSchema .MANDATORY) ;
233 cs . add (LABORATORY_ASSISTENT_LABORATORY, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) ,
ObjectSchema . OPTIONAL ) ;
235
cs = ( ConceptSchema ) t h i s . getSchema (SUPERIOR) ;
237 cs . addSuperSchema ( ( ConceptSchema ) t h i s . getSchema (PERSON) ) ;
cs . add ( SUPERIOR_PRIORITY , ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . INTEGER ) , ObjectSchema .
MANDATORY) ;
239
cs = ( ConceptSchema ) t h i s . getSchema ( ANALYSIS ) ;
241 cs . add ( ANALYSIS_DATE , ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . INTEGER ) , ObjectSchema .
OPTIONAL ) ;
cs . add ( ANALYSIS_CAREGIVER , ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . INTEGER ) , ObjectSchema .
OPTIONAL ) ;
243 cs . add ( ANALYSIS_INDICATIONS , ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) , ObjectSchema .
OPTIONAL ) ;
cs . add ( ANALYSIS_ISURGENT , ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology .BOOLEAN) , ObjectSchema .
OPTIONAL ) ;
245 cs . add ( ANALYSIS_NLAB , ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) , ObjectSchema .
OPTIONAL ) ;
cs . add ( ANALYSIS_PATIENT , ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . INTEGER ) , ObjectSchema .
OPTIONAL ) ;
247
cs = ( ConceptSchema ) t h i s . getSchema ( DE_ANALYSIS ) ;
249 cs . addSuperSchema ( ( ConceptSchema ) t h i s . getSchema ( ANALYSIS ) ) ;
cs . add ( DE_ANALYSIS_RESULTS , ( ConceptSchema ) t h i s . getSchema (CODE_OF_ANALYSIS) , 1 , ObjectSchema .
UNLIMITED ) ;
251
cs = ( ConceptSchema ) t h i s . getSchema (RESULT) ;
Andreas Ruppen 78
253 cs . addSuperSchema ( ( ConceptSchema ) t h i s . getSchema ( ANALYSIS ) ) ;

cs . add (RESULT_LABORATORY_ASSISTANT, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . INTEGER ) ,
255 ObjectSchema .MANDATORY) ;
cs . add ( RESULT_ANALYSIS , ( ConceptSchema ) t h i s . getSchema (RE_CODE_OF_ANALYSIS) , 1 , ObjectSchema .
UNLIMITED ) ;
257
cs = ( ConceptSchema ) t h i s . getSchema (CODE_OF_ANALYSIS) ;
259 cs . add ( CODE_OF_ANALYSIS_LITTERAL , ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) ) ;
cs . add (CODE_OF_ANALYSIS_TYPE, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) ) ;
261
cs = ( ConceptSchema ) t h i s . getSchema (RE_CODE_OF_ANALYSIS) ;
263 cs . addSuperSchema ( ( ConceptSchema ) t h i s . getSchema (CODE_OF_ANALYSIS) ) ;
cs . add (RE_CODE_OF_ANALYSIS_VALUE, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) ,
267 / / Predicates
t h i s . add (new PredicateSchema ( IS_RESULT_READY ) , IsResultReady . class ) ;
269 t h i s . add (new PredicateSchema ( IS_CRITICAL ) , I s C r i t i c a l . class ) ;
271 PredicateSchema ps = ( PredicateSchema ) t h i s . getSchema ( IS_RESULT_READY ) ;

ps . add ( IS_RESULT_READY_PATIENT , t h i s . getSchema ( PATIENT ) ) ;
273
ps = ( PredicateSchema ) t h i s . getSchema ( IS_CRITICAL ) ;
275 ps . add ( IS_CRITICAL_RESULT , t h i s . getSchema (RESULT) ) ;
277 / / Actions
t h i s . add (new AgentActionSchema (SEND_URGENT) , SendUrgent . class ) ;
279 t h i s . add (new AgentActionSchema (GIVE_UNCONFORMED_RESULTS) , GiveUnconfirmedResults . class ) ;
t h i s . add (new AgentActionSchema (SEND_RESULT) , SendResult . class ) ;
281 t h i s . add (new AgentActionSchema (GET_RESULT) , GetResult . class ) ;
t h i s . add (new AgentActionSchema (SEND_CONFIRMATION) , SendConfirmation . class ) ;
283 t h i s . add (new AgentActionSchema ( ASK_FOR_ANALYSIS ) , A s kF o rA n al y si s . class ) ;
t h i s . add (new AgentActionSchema (ALERT) , A l e r t . class ) ;
285 t h i s . add (new AgentActionSchema ( SEND_AVAILABLE_LIST ) , S e n d A v a i l a b l e L i s t . class ) ;
t h i s . add (new AgentActionSchema (CHECK_RESULT_AS_TREATED) , CheckResultAsTreated . class ) ;
287 t h i s . add (new AgentActionSchema ( SEND_PID ) , SendPid . class ) ;
289 AgentActionSchema as = ( AgentActionSchema ) t h i s . getSchema (SEND_URGENT) ;

as . add (SEND_URGENT_RESULTS, ( ConceptSchema ) t h i s . getSchema (RESULT) , ObjectSchema .MANDATORY) ;
291
as = ( AgentActionSchema ) t h i s . getSchema (SEND_RESULT) ;
293 as . add (SEND_RESULT_RESULTS, ( ConceptSchema ) t h i s . getSchema (RESULT) , ObjectSchema .MANDATORY) ;
as . add ( SEND_RESULT_PATIENT_FIRSTNAME, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) ,
295 ObjectSchema . OPTIONAL ) ;
as . add (SEND_RESULT_PATIENT_LASTNAME, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) ,
297 ObjectSchema . OPTIONAL ) ;
299 as = ( AgentActionSchema ) t h i s . getSchema (GET_RESULT) ;

as . add ( GET_RESULT_PATIENT_NLAB , ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) ,
303 // as = ( AgentActionSchema ) getSchema (SEND_CONFIRMATION) ;

// as . add ( SEND_CONFIRMATION_PATIENT,
305 // ( ConceptSchema ) getSchema ( PATIENT ) , ObjectSchema .MANDATORY) ;
// as . add (SEND_CONFIRMATION_RESULTS,
307 // ( ConceptSchema ) getSchema (RESULT) , ObjectSchema .MANDATORY) ;
309 as = ( AgentActionSchema ) t h i s . getSchema ( ASK_FOR_ANALYSIS ) ;

as . add ( ASK_FOR_ANALYSIS_ANALYSIS , ( ConceptSchema ) t h i s . getSchema ( DE_ANALYSIS ) , ObjectSchema .
MANDATORY) ;
311
as = ( AgentActionSchema ) t h i s . getSchema (ALERT) ;
313 as . add (ALERT_TYPE, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) , ObjectSchema . OPTIONAL ) ;
as . add (ALERT_RESULT, ( ConceptSchema ) t h i s . getSchema (RESULT) , ObjectSchema .MANDATORY) ;
315
as = ( AgentActionSchema ) t h i s . getSchema ( SEND_AVAILABLE_LIST ) ;
317 as . add ( SEND_AVAILABLE_LIST_CAREGIVER , ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . INTEGER ) ,
319 as . add ( SEND_AVAILABLE_LIST_NLABS , ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) , 0 ,
ObjectSchema . UNLIMITED ) ;
321
as = ( AgentActionSchema ) t h i s . getSchema (CHECK_RESULT_AS_TREATED) ;
323 as . add (CHECK_RESULT_AS_TREATED_NLAB, ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) ,
Andreas Ruppen 79
325
as = ( AgentActionSchema ) t h i s . getSchema ( SEND_PID ) ;
327 as . add (SEND_PID_PERSON, ( ConceptSchema ) t h i s . getSchema (PERSON) ) ;
as . add ( SEND_PID_PID , ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . INTEGER ) , ObjectSchema .
OPTIONAL ) ;
329 as . add ( SEND_PID_PRIORITY , ( PrimitiveSchema ) t h i s . getSchema ( BasicOntology . STRING ) , ObjectSchema .
OPTIONAL ) ;
} catch ( On tol og yEx ce pti on oe )
331 {
oe . p r i n t S t a c k T r a c e ( ) ;
333 }
}
335 }
Listing B.1: Ontologie pour Jade

C
Fiche d'une demande d'analyse
80
Andreas Ruppen 81
F. C.1.: Fiche d’une demande d’analyse

D
Acronymes
ACL Agent Communication Language
API Application Programming Interface
BDI Beliefs-Desires-Intentions
DAI Distributed AI
DPS Distributed Problem Solving
DF Directory Facilitator
FIPA Foundation for Intelligent Physical Agents
GPL GNU General Public License
GUI Graphical User Interface
IAD Intelligence Artificielle Distribuée
IDE Integrated Development Environment
IIOP Internet Inter-ORP
82
Andreas Ruppen 83
J2EE Java 2 Platform, Enterprise Edition
LGPL GNU Lesser General Public License
MaSE Multiagent System Engineering
MAS Multi-Agent System
OO Orienté Objet
PAI Parallel AI
RMI Remote Method Invocation
SA Sniffer Agent
SMA Système multi-agents

Licence de la documentation
E
Copyright (c) 2007 Andreas Ruppen.
Permission est accordée de copier, distribuer et/ou modifier ce document selon les
termes de la Licence de Documentation Libre GNU (GNU Free Documentation Li-
cense), version 1.2 ou toute version ultérieure publiée par la Free Software Foundation ;
sans Sections Invariables ; sans Textes de Première de Couverture, et sans Textes de
Quatrième de Couverture.
La Licence de Documentation Libre GNU (GNU Free Documentation License) est
disponible sur [6] et une traduction française “non-officielle” est mise à disposition sur
[7].
84
Page web du projet
F
La page web officielle de ce projet est : http://diuf.unifr.ch/softeng/student-projects/
completed/ruppen/index.html. Sur cette page vous trouverez :
• Une brève description du projet.
• Le code source et le fichier Ant.
• Les exécutables.
• Le code source et le pdf de la présente documentation.
La figure F. F.1 montre une capture d’écran de la page d’accueil du projet.
85
Andreas Ruppen 86
F. F.1.: Capture d’écran du site du projet

CD-ROM
G
Sur le cdrom G.2 se trouve :
• Le code source, le fichier Ant et les exécutables
• Les librairies de JADE
• La source et le pdf de la présente documentation.
La figure F. G.1 montre le contenu du cdrom.
Le contenu du cdrom peut également être téléchargé depuis le site du projet (voir F).
87
Andreas Ruppen 88
|--build.properties //properties file for ANT

|--build.xml //build file for ANT
|--caregiver.xml //configuration file for the caregiver agent
|-- doc
| ‘-- javadoc //API of the application.
|--hospital.sqlite //the database
|--laboratory.xml //configuration file for the laboratory agent
|--logger.sql //the logging database
|-- rapport //Binaries (pdf, ps, etc.) and
| |-- appendix //sources of this document
| |-- codes //and of the presentation.
| |-- figures //Sources of the figures.
| ‘-- chapters
| |-- introduction
| |-- chapter1
| |-- chapter2
| |-- chapter3
| |-- chapter4
| |-- chapter5
| ‘-- conclusion
|--reports //reports (checkstyle, junit, etc. )
| ‘--checkstyle //checkstyle report
|--server.xml
|--src //source of the application
| ‘--hospital
| |--agents
| |--behaviors
| |--database
| |--interfaces
| |--ontology
| |--utils
|--superior.xml //configuration file for the superior agent
|-- software //this work.
|-- libs //libs necessary to run the application
‘-- jade //jade binaries
F. G.1.: Contenu du cdrom

Andreas Ruppen 89
F. G.2.: Le cdrom du projet

Bibliographie
[Asi00] Isaac Asimov. Le Cycle De Fondation, Tome 1 : Fondation. Gallimard, Paris,

2000.
[BCT+ 06] Fabio Bellifemine, Giovanni Caire, Tiziana Trucco, Giovanni Rimassa, and
Roland Mungenast. Jade Administrator’s Guide. TILAB and CSELT and
JADE, February 2006.
[BCTR05] Fabio Bellifemine, Giovanni Caire, Tiziana Trucco, and Giovanni Rimassa.
Jade Programmer’s Guide, November 2005.
[Cai03] Giovanni Caire. Jade Tutorial - Jade Programming For Beginners. TILAB,
December 2003.
[CC04] Giovanni Caire and David Cabanillas. Jade Tutorial - Application-Defined
Content Languages And Ontologies. CSELT and TILAB, November 2004.
[CKvSL06] Roberta Coelho, Uir&#225 ; Kulesza, Arndt von Staa, and Carlos Lucena.
Unit testing in multi-agent systems using mock agents and aspects. In
SELMAS ’06 : Proceedings of the 2006 international workshop on Software engi-
neering for large-scale multi-agent systems, pages 83–90, New York, NY, USA,
2006. ACM Press.
[DP95] J. Doran and M. Palmer. The EOS project : Integrating two models of
paeleolithic social change. In N. Gilbert and R. Conte, editors, Artificial
Societies : The Computer Simulation of Social Life, pages 103–125. UCL Press :
London, 1995.
[DWS01] Scott A. DeLoach, Mark F. Wook, and Clint H. Sparkman. Multiagnet sys-
tems engineering. International Journal of Software Engineering and Knowledge
Engineering, 11(3) :231–258, 2001.
[Fer99] Jacques Ferber. Multi-Agent Systems—An Introduction to Distributed Artifical
Intelligence. Addison-Wesley, 1999.
[Hew77] Carl Hewitt. Viewing control structures as patterns of passing messages.
Technical Report AIM-410, MIT Artificial Intelligence Laboratory, Decem-
ber 6 1977.
[HNSP97] Huhns, Michael N., Singh, and Munindar P., editors. Readings in Agents.
Morgan Kaufmann Publishers, 1997.
[Ngu07] Minh Tuan Nguyen. Notes des recherche, 2007.
90
Bibliographie Andreas Ruppen 91
[Wei99] Gerhard Weiss. Multiagent Systems : A Modern Approach to Distributed Arti-

ficial Intelligence. MIT Press, Cambridge, 1999.
[Wei06] Gerhard Weiss. Agentenorientierte Softwareentwicklung : Methoden Und Tools.
Springer, Berlin, 2006.
[WJK99] Michael Wooldridge, Nicholas R. Jennings, and David Kinny. A metho-
dology for agent-oriented analysis and design. In Oren Etzioni, Jörg P.
Müller, and Jeffrey M. Bradshaw, editors, Proceedings of the Third Internatio-
nal Conference on Autonomous Agents (Agents’99), pages 69–76, Seattle, WA,
USA, 1999. ACM Press.
[WJK00] Michael Wooldridge, Nicholas R. Jennings, and David Kinny. The gaia
methodology for agent-oriented analysis and design. Autonomous Agents
and Multi-Agent Systems, 3(3) :285–312, 2000.
[Woo04] Michael Wooldridge. An introduction to multi-agent systems. J. Artificial
Societies and Social Simulation, 7(3), 2004.
Sites Web
[1] Jade- Java Agent DEvelopment Framework. http://jade.tilab.com/ (dernière

consultation le 04 septembre 2007).
[2] The Eclipse Project. http://www.eclipse.org/ (dernière consultation le 30 août
2007).
[3] Webservices. http://en.wikipedia.org/wiki/Image:Webservices.png (der-
nière consultation le 22 juillet 2007).
[4] Website of agenttool. http://macr.cis.ksu.edu/projects/agentTool/
agentool.htm (dernière consultation le 04 juillet 2007).
[5] How stuff works. http://auto.howstuffworks.com/car-computer.htm (der-
nière consultation le 10 juillet 2007).
[6] Free Documentation Licence (GNU FDL). http://www.gnu.org/licenses/fdl.
txt (dernière consultation le 30 juillet 2005).
[7] Licence de Documentation Libre GNU (GNU Free Documentation License).
http://www.idealx.org/dossier/oss/gfdl.fr.html (dernière consultation le
12 janvier 2006).
[8] The foundation for intelligent agents (fipa). http://www.fipa.org/ (dernière
consultation le 25 mai 2007).
[9] Agent Manual : JACK Intelligent Agents Agent Manual. http://www.
agent-software.com/shared/demosNdocs/Agent_Manual_WEB/index.html
(dernière consultation le 25 mai 2007).
[10] Jess, the rule engine for the java platform. http://herzberg.ca.sandia.gov/
jess/ (dernière consultation le 28 mai 2007).
[11] The protégé ontology editor and knowledge acquisition system. http://protege.
stanford.edu/ (dernière consultation le 28 mai 2007).
92
Index
Conventions, 3
eHealth-Care, 32
Méthodologie, 13, 44
Objectifs, 3
Problématique, 1
Utilisation du système, 61
93

Langue

Rapport PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport PDF

Titre original :

Transféré par

Droits d'auteur :

Formats disponibles

Systèmes multi agents

Groupe Génie Logiciel

A. Diagrammes pour MaSE 70

B. Ontologie pour Jade 74

C. Fiche d’une demande d’analyse 80

F. Page web du projet 85

2.1. Modèle d’un système multi-agents . . . . . . . . . . . . . . . . . . . . . . 6

3.1. Les différents modèles dans Gaia . . . . . . . . . . . . . . . . . . . . . . . 15

4.1. Fonctionnement actuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.9. Echange de messages lors d’un résultat critique . . . . . . . . . . . . . . 42

5.1. Méthodologie utilisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.1. Lancement de la plateforme . . . . . . . . . . . . . . . . . . . . . . . . . . 64

7.1. Publication, découverte et utilisation d’un service web . . . . . . . . . . 68

A.1. Diagramme d’hiérarchie des buts . . . . . . . . . . . . . . . . . . . . . . . 70

C.1. Fiche d’une demande d’analyse . . . . . . . . . . . . . . . . . . . . . . . . 81

F.1. Capture d’écran du site du projet . . . . . . . . . . . . . . . . . . . . . . . 86

G.1. Contenu du cdrom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

2.1. Types d’agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1. Modèle des rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1. Communications possibles . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.1. Comportements et participants . . . . . . . . . . . . . . . . . . . . . . . . 60

2.1. Extrait d’une ontologie en Jade . . . . . . . . . . . . . . . . . . . . . . . . . 9

la voiture. En effet une voiture moderne peut contenir jusqu’à 50 microprocesseurs2 .

arrangements. Ce domaine de recherche ouvre de toutes nouvelles perspectives. Ainsi

Dans le souci le préserver la langue française la majorité des termes informatiques

2.1. Notion d’un agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1. Notion d’un agent

F. 2.1.: Modèle d’un système multi-agents(tiré de [Fer99])

F. 2.2.: Modèle BDI d’un agent (tiré de [HNSP97])

public s t a t i c f i n a l S t r i n g NAME = " h o s p i t a l −o n t o l o g y " ;

20 public s t a t i c f i n a l S t r i n g ADRESSE_STREET = " street " ;

22 public s t a t i c f i n a l S t r i n g ADRESSE_NUMBER = " st r ee t nu m b er " ;

24 public s t a t i c f i n a l S t r i n g ADRESSE_CITY = " city " ;

26 public s t a t i c f i n a l S t r i n g ADRESSE_COUNTRY = " country " ;

115 public s t a t i c f i n a l S t r i n g IS_RESULT_READY_PATIENT = " patient " ;

117 public s t a t i c f i n a l S t r i n g IS_CRITICAL = " critical " ;

119 public s t a t i c f i n a l S t r i n g IS_CRITICAL_RESULT = " criticalResult " ;

177 private hospitalOntology ( )

197 ConceptSchema cs = ( ConceptSchema ) t h i s . getSchema (ADRESSE) ;

271 PredicateSchema ps = ( PredicateSchema ) t h i s . getSchema ( IS_RESULT_READY ) ;

AgentActionSchema as = ( AgentActionSchema ) t h i s . getSchema (SEND_URGENT) ;

} catch ( On tol og yEx ce pti on oe )

Listing 2.1: Extrait d’une ontologie en Jade

Agent cognitif Agent réactif

T. 2.1.: Types d’agents

On dit qu’il a un comportement télémonique si la source de motivation est interne.

2.4. Points de vue

2.4.1. Les agents comme design pattern

2.4.2. Les agents comme simulation sociale

2.5.1. Différences avec les systèmes distribués

2.5.2. Différences avec l’intelligence artificielle

En général on peut décomposer le développement d’un logiciel en plusieurs étapes.

F. 3.1.: Les différents modèles dans Gaia

avec l’université, on peut s’imaginer un étudiant qui occupe un poste de sous-assistant.

T. 3.1.: Modèle des rôles

F. 3.2.: Le modèle des agents dans Gaia

F. 3.3.: Aperçu de MaSE

1. définir une hiérarchie des buts,

F. 3.4.: Un diagramme de rôles généré avec agentTool (tiré de [4])

montre un tel diagramme. Ce diagramme a été généré avec agentTool. agentTool et le

F. 3.5.: Diagramme de tâches (tiré de [4])