Explorer les Livres électroniques
Catégories
Explorer les Livres audio
Catégories
Explorer les Magazines
Catégories
Explorer les Documents
Catégories
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
Groupe Génie Logiciel
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
D. Acronymes 82
E. Licence de la documentation 84
G. CD-ROM 87
Bibliographie 90
Sites Web 92
Index 93
Liste des gures
vi
Liste des figures Andreas Ruppen vii
viii
Liste des codes source
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
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
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.
[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
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
/ / Predicates
113 public s t a t i c f i n a l S t r i n g IS_RESULT_READY = " ready " ;
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 }
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 ) ;
277 / / Actions
t h i s . add (new AgentActionSchema (SEND_URGENT) , SendUrgent . class ) ;
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
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.
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 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
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
3.1. MÉTHODOLOGIES Andreas Ruppen 15
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
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.
3.1. MÉTHODOLOGIES Andreas Ruppen 17
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-
3.1. MÉTHODOLOGIES Andreas Ruppen 18
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.
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].
3.1. MÉTHODOLOGIES Andreas Ruppen 19
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
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.
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
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..
3.2. PLATEFORMES Andreas Ruppen 23
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).
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 .
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-
3.2. PLATEFORMES Andreas Ruppen 26
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
3.2. PLATEFORMES Andreas Ruppen 27
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
3.2. PLATEFORMES Andreas Ruppen 28
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
3.2. PLATEFORMES Andreas Ruppen 29
• 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
3.2. PLATEFORMES Andreas Ruppen 30
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
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
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
4.1. SITUATION ACTUELLE Andreas Ruppen 35
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é-
4.1. SITUATION ACTUELLE Andreas Ruppen 36
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
4.1. SITUATION ACTUELLE Andreas Ruppen 37
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
4.1. SITUATION ACTUELLE Andreas Ruppen 38
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.
F. 4.6.: Cas critique : Laborantin téléphone au médecin et l’informe des résultats
obtenus (tiré de [Ngu07])
à 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])
à 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.
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
4.2. SOLUTION PROPOSÉE - MEDIMAS Andreas Ruppen 42
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.
4.2. SOLUTION PROPOSÉE - MEDIMAS Andreas Ruppen 43
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
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.
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-
cabulaire du système, il est naturel d’y inclure les objets concrets. Autrement dit, la
5.1. ONTOLOGIE Andreas Ruppen 47
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
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à
5.1. ONTOLOGIE Andreas Ruppen 49
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.
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.
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 }
}
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 }
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
5.3. COMPORTEMENTS Andreas Ruppen 52
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])
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
réveille il vérifie dans la base de données si quelqu’un s’est occupé du résultat critique
5.3. COMPORTEMENTS Andreas Ruppen 55
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
• Type : SimpleAchieveReResponder
4. acceptResult : enregistre un nouveau résultat dans la base de données.
• Type : SimpleAchieveReResponder
5. acceptUrgentResult : enregistre un nouveau résultat urgent dans la base de don-
nées.
• Type : SimpleAchieveReResponder
6. sendAlert : envoie des alertes pour les résultats périmés.
• Type : SimpleAchieveReInitiator
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
• Type : SimpleAchieveReInitiator
2. sendUrgentResult : envoie un résultat urgent. Le serveur saura ainsi qu’il doit le
traiter différemment.
• Type : SimpleAchieveReInitiator
3. acceptAlert : quand le serveur détecte un résultat périmé il en informe aussi le
laboratoire qui a fait l’analyse.
• Type : SimpleAchieveReResponder
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.
• Type : SimpleAchieveReResponder
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
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
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.
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.
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
[ java ] 10 s e p t . 2007 0 2 : 52 : 2 4 j a d e . core . BaseService i n i t
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
[ java ] 10 s e p t . 2007 0 2 : 52 : 2 4 j a d e . core . BaseService i n i t
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
[ java ] 10 s e p t . 2007 0 2 : 52 : 2 4 j a d e . core . BaseService i n i t
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
6.2. SCÉNARIO D’EXEMPLE AVEC CAPTURES D’ÉCRAN
Andreas Ruppen 64
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.
6.2. SCÉNARIO D’EXEMPLE AVEC CAPTURES D’ÉCRAN
Andreas Ruppen 65
67
Andreas Ruppen 68
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
70
Andreas Ruppen 71
(a) Emmeteur
(b) Récepteur
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 ( ) ;
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 " ;
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
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 ) ;
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 ) ;
ObjectSchema .MANDATORY) ;
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 }
80
Andreas Ruppen 81
BDI Beliefs-Desires-Intentions
DAI Distributed AI
DF Directory Facilitator
82
Andreas Ruppen 83
OO Orienté Objet
PAI Parallel AI
SA Sniffer Agent
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
87
Andreas Ruppen 88
90
Bibliographie Andreas Ruppen 91
92
Index
Conventions, 3
eHealth-Care, 32
Méthodologie, 13, 44
Objectifs, 3
Problématique, 1
Utilisation du système, 61
93