REPUBLIQUE DEMOCRATIQUE DU
CONGO
ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE
INSTITUT SUPERIEUR PEDAGOGIQUE
B.P. 854 BUKAVU
SECTION : SCIENCES COMMERCIALES, ADMINISTRATIVES
ET INFORMATIQUE
MODELISATION D'UN SYSTEME MULTI-AGENTS :
APPLICATION A LA REUNION D'ATTRIBUTION DES CHARGES HORAIRES AU DEPARTEMENT
D'INFORMATIQUE DE GESTION
DEPARTEMENT D'INFORMATIQUE DE GESTION
Présenté par
Jean-Marie MUNGUAKONKWA Biringanine
Mémoire présenté et défendu
en vue de
l'obtention du diplôme de licencié en
pédagogie appliquée.
Option : Informatique de Gestion
Année universitaire 2009-2010
Directeur : Ass. Dieudonné KYENDA
S.
EPIGRAPHE
« L'oeil ne voit que la surface des choses.
»
Obiwan Kenobi (enseignant, Jedi)
« Le système ne voit que la surface des
composants. »
Programmeur anonyme.
« Le monde change si vite, et nous courrons tous
derrière pour le rattraper. Alors, comment peut-on avoir la plus petite
idée de ce qui va se passer ? »
pr. Grant (paléontologue du jurassique)
« La vie trouve toujours un chemin, c'est parfois dur,
c'est parfois pénible, mais enfin... c'est comme ça.
»
pr. Malcolm (Mathématicien chaoticien)
DEDICACE
A MES PARENTS :
DEOGRATIAS BIRINGANINE NSIBULA
ET
CONCILIE MASAWA M'MPALIZA
Jean-Marie MUNGUAKONKWA Biringanine
REMERCIEMENT
A l'éternel Dieu Tout Puissant qui nous a
assisté tout au long de notre formation académique.
Je tiens à remercier l'Assistant KYENDA SULIKA
Dieudonné d'avoir bien voulu diriger ce travail et de m'avoir
donné de précieux conseils qui m'ont permis de recadrer ma
recherche.
Je ne manque pas de remercier le personnel enseignant et
administratif de l'ISP/Bukavu et particulièrement ceux du
département d'Informatique et Gestion.
Je remercie mes parents, qui m'ont toujours soutenu dans mes
études. Mes pensées vont également vers mes frères
NSHOKANO BIRINGANINE, ANDRE MAYELE et mes soeurs Aimé BIRINGANINE,
Orthence BIRINGANINE, Yvettes BIRINGANINE et Odila BIRINGANINE.
Je tiens à remercier mes oncles paternels et maternels
KAMUNTU NSIBULA, PASCAL NSIBULA, JC OMBENI, Achille ITEGWA pour leurs
soutiens.
Je remercie également mes compagnons de lutte :
ISHARA KIBASOMBA, Lucien MUBALAMA, Olivier MULONGESHA, Albert MULUMEODERWA,
Bulongo TUKILINABO, Augu MUNVA.
Je tiens à exprimer toute ma gratitude et mon
amitié à Eric KABALA NGIMBI, Danny BIRINGANINE, Alain OMBENI,
PAPA JEAN MASEMO, Alain NTAMBUKA, TUZO NKINZO, les gars la lutte
continue ! Mes pensés vont également vers tous les amis
SHABANI MUKELE, BAHAVU BIHANGO RUBEN, MULUMEODERHWA SAGE, MWEZE MUGISHO BOB,
Alain MBUME Mupaya, FRANCO HESHIMA, SAFARI MUNGANGA, DANNY MILENGE, JHOPATY
MPADU, JUSTIN BYAMUNGU, MWATI NGENDO FABRICE.
Que ceux qui ne sont pas cités nominalement dans ce
travail ne se sentent pas oubliées mais qu'ils sachent que nous les
portons à coeurs.
Jean-Marie MUNGUAKONKWA Biringanine
LISTE DES ACRONYMES
ACL : Agent Communication Language
AFNOR : Association Française de Normalisation
API : Application Programming Interface
BD : Base de Données
CFP : Call For Proposal
CV : Curriculum Vitae
Dpt : Département
E/S : Entrée/ Sortie
FIPA : Foundation of Intelligent Physical
Agents
GUI : Graphic User Interface
HTTP : Hyper Text Transport Protocol
IA : Intelligence Artificielle
IBM : International Business Machine
JDBC : Java Data Base Connectivity
KQML : Knowledge Query and Manipulation Language
PC : Personnel Computer
SGBD : Système de Gestion des Bases de
Données
SMA : Système Multi-agents
UML : Unified Modeling Language
RESUME
Les systèmes multi-agents constituent aujourd'hui une
nouvelle technologie pour la conception et le contrôle de systèmes
complexes. Un système multi-agents est un système composé
d'entités logicielles ou matérielles autonomes appelées
agents. L'approche multi-agents repose sur plusieurs théories et
concepts qui trouvent leurs origines dans plusieurs disciplines tels que la
sociologie, la psychologie, les systèmes réparties, le
génie logiciel.
Nous avons posé comme hypothèse directrice, la
proposition d'un langage et d'un protocole de communication pour assurer
l'interopérabilité entre agents participant à la
réunion d'attribution des charges horaires. L'implémentation
d'une application client-serveur pour la gestion des réunions
virtuelles d'attributions des charges horaires au Département
d'Informatique de Gestion.
La démarche que nous avons adoptée consiste
à étudier d'abord les principaux protocoles d'interaction, plus
particulièrement les protocoles d'interaction standardisés par
FIPA. Cette étude consiste à analyser le fonctionnement de
quelques protocoles pour identifier les données que doit
spécifier un développeur afin de l'intégrer à
l'agent. Nous avons beaucoup plus mis l'accent sur le protocole Contract-net
qui nous a permis de modéliser les réunions virtuelles
d'attributions des charges horaires au Département d'Informatique de
Gestion. Grâce à cette étude nous avons pu intégrer
les concepts d'agents intelligents aux réunions virtuelles au sein du
Département d'Informatique de Gestion.
Cette étude nous a amené à
implémenter une application client-serveur grâce auquel le chef
de Département, peut planifier ou organiser une réunion
virtuelle envoyant un message en broadcast à tous les membres du
Département d'Informatique de Gestion. Ces derniers répondent
à ce message dans un délai bien précis de peur de voir
leur désidérata refusé.
Notre hypothèse a été validée
à partir l'intégration du protocole FIPA Contract net dans les
réunions virtuelles d'attributions des charges horaires, départ
le rôle du Manager et du participant. Mais aussi à
l'implémentation de l'application ci-haut cité.
INTRODUCTION
La croissance explosive des domaines d'application tels que le
commerce électronique, la gestion des connaissances, les systèmes
coopératifs, l'informatique point-à-point, mobile ou cognitive
change profondément et irréversiblement nos vues sur
l'ingénierie logicielle et les systèmes eux-mêmes. Les
systèmes multi-agents constituent aujourd'hui une nouvelle technologie
pour la conception et le contrôle de systèmes complexes.
Un système multi-agents est un système
composé d'entités logicielles ou matérielles autonomes
appelées agents. L'approche multi-agents repose sur plusieurs
théories et concepts qui trouvent leurs origines dans plusieurs
disciplines tels que la sociologie, la psychologie, les systèmes
réparties, le génie logiciel.
Les notions d'autonomie, d'interaction sociale, de
négociation, de planification et de décision deviennent
essentielles à de tels composants logiciels. Les systèmes doivent
également être fonctionnels sur différents types de
plateformes logicielles ou matérielles, sans devoir être
recompilés, en ne possédant qu'une information minimale quant
à l'environnement opérationnel et ses utilisateurs. Ces nouvelles
donnes, à leur tour, nécessitent de nouveaux concepts, outils et
technologies pour la conception et la gestion de ce type de système.
I.1. PROBLEMATIQUE
A la clé du succès du concept de
« virtuel », qui se manifeste dans la profusion des
expressions image virtuelle, entreprise, travail virtuel, etc. se trouve le
fulgurant développement des technologies de l'information et de la
communication. Ce développement a pris une dimension de mythe dans la
« société de l'information
communication ».
Cette recherche concerne avant tout les systèmes
multi-agents dits communiquants, c'est-à-dire dont les agents
interagissent par messages asynchrones, en utilisant un langage de
communication de haut niveau. Plus précisément, elle se focalise
sur les systèmes conversationnels, pour lesquels la principale
unité de structuration de l'interaction est la conversation.
Elle traite de la modélisation de ces systèmes
essentiellement d'un point de vue génie logiciel.
Nous définissons pour l'instant une conversation comme
une séquence de messages cohérents et interdépendants
entre eux, échangés dans le but de réaliser une
tâche collective. Chaque conversation est régie par un protocole
d'interaction, qui regroupe un ensemble de contraintes sur les échanges
de messages possibles, et comprend une sémantique propre1(*).
Pendant notre séjour au Département
d'Informatique de Gestion en particulier et à l'ISP en
général. Nous avons eu à parler avec le chef de
Département d'Informatique de Gestion qui dans l'exercice de ces
fonctions nous a relevé les difficultés rencontrées
relatives aux différentes réunions d'attributions des charges
horaires. Soit au début ou à la fin d'une année
académique.
Normalement, la fonction enseignante englobe non seulement les
activités d'enseignement de recherche, d'encadrement des
étudiants et du personnel scientifique, mais aussi la participation aux
réunions du conseil de département2(*).
Malgré le temps consacré à
l'organisation et la tenue des réunions d'attributions des charges
horaires. Ces réunions se tiennent pour la plupart de fois les
week-ends dans l'esprit de rencontrer l'emploi de temps de tous les membres du
département d'Informatique de Gestion. Il a été
remarqué :
1. Absences justifiées ou non des certains membres du
Département ;
2. Retards exagérés dans le dépôt
des désidératas des enseignants. Ce qui fait que certains
enseignants accusent le Département de lui avoir imposé une
charge horaire ou carrément n'avoir pas tenu compte de leurs
désidératas ;
3. Le Corum d'enseignant membre qui participe à cette
réunion n'a jamais dépassé 75 %. Pourtant la
participation à ces réunions est obligatoire.
Cette situation crée un climat de suspicion qui ne
favorise pas l'harmonie entre le Département et ses membres.
Dans le souci d'assurer une bonne tenue de ces réunions
d'attributions des charges horaires, se dégage un besoin de
créer une réunion virtuelle pour permettre à tous les
membres du Département où qu'ils soient d'envoyer au moment voulu
leurs désidératas. En supposant que chaque membre doit pouvoir
disposer d'un minimum pour l'accès à l'internet.
Après avoir observé et parlé à
certains membres et le chef de Département lui-même, des
questions suivantes restent pendantes : Comment créer une salle
des réunions virtuelles ou des espaces d'interactions entre le
Département et ses membres où qu'ils soient ? Quel model et quel
Protocol de communication d'agent intelligent utilisé ?
L'objectif de ce travail est de :
- Modéliser les réunions d'attribution des
charges horaires au Département d'Informatique et Gestion ;
- Permettre d'imiter le plus possible le déroulement de
réunions classiques de travail d'attribution des charges
horaires ;
- Créer une salle de réunion virtuelle et
d'espace.
Pour ce faire notre tâche consistera d'abord à
modéliser les interactions dans un système multi-agents
c'est-à-dire proposer un modèle et un Protocol de communication
à utiliser ; ensuite concevoir à l'aide d'outils d'analyse
systématique une base de données et l'implémenter
à l'aide du système de gestion de base de données, enfin
déployer cette base de données sous l'architecture
client-serveur.
Cependant, dans ce travail les interventions des utilisateurs
se feront en mode mono-média (textuel seulement).
I.2. HYPOTHESES
Considérant les problèmes évoqués
ci-haut, nous avons pensé à la proposition d'un langage et
d'un protocole de communication qui assurerait
l'interopérabilité entre agents participant à la
réunion d'attribution des charges horaires; à la mise en place
d'une base de données, qui une fois connectée (à l'aide
d'un nom de login et d'un mot de passe mémorisé par le serveur),
un utilisateur aurait la possibilité de :
· Planifier une réunion virtuelle d'attribution
des charges horaires (choix d'un nom, définition du sujet, date de
début et durée prévue, ordre du jour) dont il devient
l'organisateur ;
· Présenter et envoyer au Département
les désidératas de sa charge horaire ;
· Collecter toutes les propositions des membres du
Département ;
· Etablir une charge horaire de chaque
enseignant ;
· Consulter les détails d'organisation d'une
réunion (tous les utilisateurs) ;
I.3. ETAT DE LA QUESTION
Des nombreuses réalisations sur les réunions
virtuelles ont déjà fait objet des plusieurs recherches
notamment : le net meeting, Yahoo Messager, le forum de discussion, le
Groupware, le « wolkflow », les e-mails, etc. Toutes ces
réalisations s'inscrivent dans le cadre des systèmes
multi-agents conversationnels dans l'idée d'offrir à un
utilisateur un espace de travail virtuel.
En effet, dans le cadre de notre travail, nous nous sommes
intéressés à la modélisation d'un système
multi-agents: applications aux réunions d'attribution des charges
horaires.
Vu que les réunions virtuelles, ont déjà
été abordées par plusieurs chercheurs et organisations
internationales, nous avons orienté notre travail à la
modélisation des réunions d'attribution des charges horaires au
Département d'Informatique de Gestion.
I.4. METHODOLOGIE DU
TRAVAIL
Dans le cadre de notre travail nous avons fait recours
à l'UML (Unified Modeling Language) qui nous a permis de décrire
l'analyse, la conception et l'implantation du système.
Nous avons fait également recours à la
méthode comparative qui nous a permis de comparer le langage de
communication KQML et le langage FIPA-ACL.
Pour rendre ces méthodes possibles nous avons fait
recours aux techniques suivantes :
- La technique documentaire : cette technique nous a
permis d'exploiter les différentes documentations (ouvrages et articles)
traitées par différents auteurs et chercheurs en rapport avec le
problème que nous souhaitons résoudre.
- La technique d'entretien et d'interview que j'ai eue avec
le chef de Département d'Informatique de Gestion et certains enseignants
membres. Cette technique m'a permis de m'acquérir du problème
qu'il y a au niveau des réunions d'attribution des charges horaires.
Ensuite mettre la lumière sur la mise en place d'une réunion
virtuelle.
- Technique de navigation sur internet : cette technique
nous a permis de faire des recherches sur internet dans différents sites
web et moteur de recherche, ce qui a élargi notre champ de recherche.
I.5. JUSTIFICATION DE
CHOIX DU SUJET
Personnellement, j'avais le goût d'aborder ce
domaine d'intelligence Artificielle, car ma dissertation du premier cycle
était orienté dans ce domaine, plus particulièrement dans
la branche reconnaissance de forme. J'ai senti l'intérêt
d'aborder les systèmes multi-agents et particulièrement les
agents orientés client-serveur dans une base des données, car
on a tendance aujourd'hui à dépasser le monde des logiciels
monopostes (basés dans une seule machine isolée) vers les
logiciels orientés client-serveur où on a la possibilité
d'échanger les informations.
En plus, je voulais aborder ce domaine de réunion
virtuelle qui jusque là n'a pas fait objet de beaucoup de recherches
dans notre Département. Une façon pour nous d'ouvrir la porte
aux autres chercheurs et de leurs disponibiliser un soubassement et une
documentation à cette fin.
I.6. DELIMITATION DU
SUJET
Notre étude se limitera d'abord à la
proposition d'un langage et d'un Protocole de communication entre agents
intelligents et à la mis en place d'une application de gestion des
réunions virtuelles d'attribution des charges horaires au
Département d'Informatique de Gestion. Ensuite l'implémenter
à l'aide du système de gestion de base de données, enfin
déployer cette base de données sous l'architecture
client-serveur.
CHAP. 1. HISTOIRE DE
L'INTELLIGENCE ARTIFICIELLE
1.1. HISTOIRE
3.1.1. Origines scientifiques de l'IA
Interrogeons brièvement les origines philosophiques et
scientifiques de l'intelligence artificielle pour faire ressortir l'importance
épistémologique de cette discipline.
L'intelligence artificielle prend ses sources dans la
philosophie grecque du 5e siècle avant Jésus-Christ3(*). L'idée a progressivement
émergé que l'esprit est constitué par l'opération
d'un système physique.
Pour PLATON, l'homme, grâce aux mathématiques,
peut comprendre l'univers. Entre le monde des Idées, des
réalités intelligibles, et le monde sensible, celui des
apparences, les entités mathématiques constituent des
intermédiaires.
On attribue à ARISTOTE (384-322 avant J.-C.)
la mécanisation de la pensée par le biais des syllogismes. En
effet, le syllogisme permet de générer mécaniquement une
conclusion vraie si les prémisses sont vraies. Sa méthode est
exposée dans un ouvrage intitulé Organon4(*).
Plus proche de notre ère, René DESCARTES5(*) (1596-1650) étudie
l'esprit en tant que système physique. Cependant, le philosophe
français établit une distinction entre esprit et matière.
Devant le problème du libre arbitre, DESCARTES opte pour un compromis.
Une partie de l'esprit serait en dehors de la matière,
libérée des lois de la physique. Le point de convergence de
l'esprit et de l'âme, la partie immatérielle, serait la glande
pinéale. Ainsi DESCARTES venait-il de fonder la doctrine du dualisme.
Celle du matérialisme, par contre, développe la thèse
selon laquelle seule la matière existerait. L'esprit et le cerveau
seraient soumis aux lois de la nature, c'est-à-dire du monde
physique.
Dans cette même approche, Wilhelm LEIBNIZ (1646-1716) a
cherché à construire une machine capable de raisonner. Selon ce
philosophe et mathématicien, le monde est issu des calculs de Dieu.
Cette idée apparaît déjà d'une manière
embryonnaire chez les Grecs, plus particulièrement chez les
Pythagoriciens pour qui l'univers est un ouvrage mathématique.
Cependant les progrès de la médecine
vont ouvrir la voie à d'autres manières numériques de
reproduire la pensée artificiellement.
Ceux-ci ont également joué un rôle dans la
réflexion sur l'esprit. Les progrès concernant la
compréhension anatomique du cerveau ont orienté une approche de
l'intelligence artificielle, le numérique ou neuronal. En 1795 Pierre
CABANIS (1757-1808), professeur d'hygiène et de médecine
clinique, déclare que le cerveau est l'organe de la pensée. En
1861, Paul BROCA travaille sur le cas d'un patient souffrant d'aphasie,
Leborgne. Pour ce médecin, les grandes facultés de l'esprit
(parole, vision) correspondent aux grandes régions du cerveau.
RAMON Y CAJAL, en 1911, affirme que le neurone est le
composant structurel du cerveau. Par la suite, la recherche en neurosciences et
ses découvertes ont donné naissance au connexionnisme,
c'est-à-dire à la possibilité de créer un
modèle informatique, numérique et non symbolique, du
fonctionnement du cerveau humain. La fin des années quarante a vu le
développement de ce modèle.
C'est en 1947 que McCULLOCH et PITTS, deux chercheurs de
l'Université de Chicago, proposent un modèle de neurone formel.
Cette recherche a engendré le développement d'une approche
particulière de l'intelligence artificielle à partir de 1960,
l'approche numérique6(*).
Les progrès dans le domaine des mathématiques
ont également contribué à la naissance de l'Intelligence
artificielle en tant que discipline. La logique d'ARISTOTE était
essentiellement d'ordre philosophique.
C'est George BOOLE7(*) (1815-1864) qui a formulé les règles et
les notations de la logique mathématique dans son livre : The
Mathematical Analysis of Logic: Being an Essay towards a Calculus of
Deductive Reasoning (1847).
Gottlob FREGE (1848-1925) est responsable à quelques
détails près du calcul de premier ordre (first-order
logic) utilisé en Intelligence artificielle.
Au niveau conceptuel, la cybernétique a joué un
rôle dans la genèse de ce domaine scientifique8(*). Pendant la Seconde Guerre
mondiale, on développe aux États-Unis des dispositifs
d'asservissement (radars, aéronautique, etc.) C'est en 1948 que Norbert
WIENER reprend le terme pour encadrer le processus de rétroaction
(feed-back) dans son livre intitulé Cybernetics: on Control and
Communication in the Animal and the Machine. Il pose alors le
problème de la personnalité de l'homme en termes
d'information9(*) : «
Quel est le coeur de l'individualité humaine, quelle
barrière sépare une personnalité d'une autre?
»10(*)
Ainsi, Norbert WIENER propose un modèle informationnel
de l'homme à partir d'un constat : les informations au niveau cellulaire
permettent le processus du renouveau permanent du corps. C'est le propre de
l'individualité biologique. Or ce même modèle permet la
comparaison avec les autres machines informationnelles.
Hubert DREYFUS, qui soutient la thèse selon laquelle
une machine ne peut pas accéder à l'intelligence, fait remonter
l'origine de l'IA au dialogue de PLATON, l'Euthyphron11(*) (399 av. J-C) où
Socrate demande à Euthyphron de lui définir la
piété :
« Ce que Socrate demande ici à Euthyphron,
c'est ce que nos modernes théoriciens de l'informatique appelleraient
une procédure opératoire, un ensemble de règles qui nous
disent avec précision, étape par étape, comment agir.
»12(*)
Au XXe siècle le terme robot remplace celui
d'automate. Si ce dernier est essentiellement un jouet, le premier
désigne une machine qui remplace l'homme dans les travaux
pénibles. Le terme robot qui veut dire servitude en tchèque
paraît pour la première fois en 1917 dans une nouvelle,
Opilec13(*),
écrite par le dramaturge tchèque Karel CAPEC (1880-1938). Il
figure ensuite dans le titre de la pièce R.U.R (Rossum's Universal
Robots), publiée en 1920, et représentée en 1921 au
Théâtre national de Prague. On découvre clairement dans
cette oeuvre qu'un cerveau artificiel peut échapper au contrôle de
l'inventeur.
Nous voici donc confronté au mythe de l'apprenti
sorcier qui, selon FLICHY14(*) s'oppose au mythe de Prométhée. Le jour
où l'homme inventera un être plus intelligent que lui, ce sera sa
dernière invention selon Kenneth WARWICK15(*), spécialiste en cybernétique et
robotique à l'Université de Norwich en Angleterre.
3.1.2. Naissance de l'intelligence
artificielle moderne : Dartmouth 1956
La philosophie, l'informatique, la médecine et les
mathématiques ont engendré la réflexion sur ce qui est
devenu en 1956 l'intelligence artificielle. Certains spécialistes en
mathématiques, théories de l'information, économie et
cybernétique se sont rencontrés au collège de
Dartmouth16(*) en 1956 et
ont inauguré la recherche en IA. C'est à l'occasion de cette
conférence que John McCARTHY invente le terme artificial
intelligence pour remplacer complex information processing et
heuristic programming.
Dans cette conférence de 1956, John McCARTHY
(professeur de mathématiques, Dartmouth College), Martin MINSKY
(mathématicien, Harvard), Claude SHANNON (théoricien de
l'information, Bell Labs), Allan NEWELL (Rand Corporation) et Herbert SIMON
(économiste, Carnegie Mellon University, Pittsburgh et prix Nobel en
1978) se donnent comme objectif d'étudier la faisabilité de
programmes informatiques intelligents.
Nous soulignons l'aspect multidisciplinaire de cette nouvelle
science.
On y a présenté les premiers programmes,
notamment le Logical Theorist, (NEWELL et SIMON), capable de
démontrer un des théorèmes du livre de RUSSELL et de
WHITEHEAD, Principa Mathematica, d'une manière originale.
Herbert SIMON affirme avoir inventé un programme
capable de penser d'une manière non numérique,
c'est-à-dire symbolique17(*). Durant la conférence, certaines idées
maîtresses de ce qui allait devenir l'intelligence artificielle ont
été énoncées.
«Postulat 1 : chaque aspect de l'apprentissage ou de
l'intelligence peut être décrit avec une telle précision
qu'une machine pourrait le simuler
Postulat 2 : l'esprit humain n'a pas accès direct
au monde extérieur, mais ne peut qu'agir grâce à une
représentation interne du monde, correspondant à une série
de structures symboliques (hypothèse des systèmes de symboles
physiques)
Postulat 3 : la pensée consisterait à
étendre les structures de symboles, à les briser, à les
détruire, à les réorganiser et à en créer de
nouvelles.
Postulat 4 : l'intelligence est la capacité de
manipuler des symboles. Divers supports matériels peuvent donner
naissance à de l'intelligence18(*). »
A la suite de la conférence, deux écoles
distinctes émergent, celle du numérique et celle du symbolique.
Le premier groupe (du MIT) se rassemble autour de Martin MINSKY,
préoccupé au départ par les processus d'apprentissage et
la simulation numérique, héritière de la
cybernétique. La seconde école (Carnegie-Mellon),
constituée autour de NEWELL et de SIMON, travaille sur le traitement
symbolique. Elle construit en 1957 le General Problem Solver.
Son objectif principal concerne la résolution des problèmes et la
nature du raisonnement19(*).
Les cybernéticiens du MIT (connexionnistes)
s'intéressent, au contraire, aux réseaux de neurones artificiels
utilisés dans la reconnaissance de formes « patterns
», c'est-à-dire des structures comme la voix,
l'écriture manuscrite, la vision artificielle, l'analyse et la
classification de données (data mining).
3.1.3. Difficultés
rencontrées par la discipline
Si, au cours de son histoire, l'intelligence artificielle a
connu certains succès, cette discipline a également subi des
échecs, comme celui de la traduction automatique. Les machines à
traduire, en effet, n'ont pas fait leurs preuves. Pour traduire un texte, il
faut que « la machine comprenne le sens des mots, qu'elle ait
accès à la signification interne du message.
»20(*) En 1966,
l'ALPAC (Automatic Language Processing Advisory Committee) publie un
rapport critiquant la recherche en traduction automatique, provoquant ainsi la
suppression des subventions. On s'est également rendu compte que les
ordinateurs, malgré la croissance de leur espace mémoire, avaient
de grandes difficultés à apprendre, « à tirer des
leçons de l'expérience, et à généraliser
à partir de cas particuliers. »21(*) La traduction
automatique et l'analyse sémantique constituent un défi pour
l'intelligence artificielle22(*). Comment éviter une nouvelle Tour de Babel
sans des outils appropriés ?
3.1.4. Intelligence artificielle et enjeux
pour l'État
L'intelligence artificielle représente un enjeu
essentiel pour des raisons militaires et sécuritaires, car il est
important dans un contexte de conflits et de concurrence planétaires
d'intercepter des messages provenant des groupes terroristes, d'espionner des
activités économiques et militaires d'autres pays et de
prévenir éventuellement une attaque23(*). L'État
fédéral américain a tout d'abord financé la
recherche en intelligence artificielle pendant la période de la guerre
froide. Il a mis également en place le système de surveillance et
de contrôle ECHELON pour observer, et se renseigner sur, les
activités économiques et commerciales des pays concurrents. La
technologie développée a été mise à la
disposition des entreprises américaines, qui ont pu ainsi concevoir
d'autres applications à moindre coût.
1.2. DEFINITION
Que signifie le terme « intelligence artificielle »
? Des définitions existent dans les ouvrages scientifiques et dans les
dictionnaires spécialisés ou non. En quoi un programme IA
diffère-t-il des autres ? Nous tenterons de répondre à ces
deux questions. Examinons d'abord les définitions fournies par les
dictionnaires. Le dictionnaire le Petit Robert en propose
une:
« I.A., partie de l'informatique qui a pour but la
simulation de facultés cognitives afin de suppléer l'être
humain pour assurer des fonctions dont on convient, dans un contexte
donné, qu'elles requièrent de l'intelligence. »24(*)
Ainsi, le système ne produit pas une action
intelligente mais se contente de la simuler. Si la machine peut exécuter
une opération qui requière de l'intelligence chez l'humain, on
peut la considérer comme intelligente.
Le dictionnaire encyclopédique de Bernard LAMIZET et
Amhed SILEM poursuit la comparaison en ajoutant la notion de concurrence entre
l'homme et la machine. Ces auteurs voient dans l'intelligence artificielle
l'avenir de l'informatique.
«Discipline dont le but est l'étude et la
conception de systèmes dont le comportement se rapproche de ce que nous
qualifions d'intelligence chez l'homme. De par l'ambition de ce domaine et le
nombre de domaines en lesquels elle s'est, au fil des années,
scindée, il s'agit d'une composante majeure de l'informatique. De plus,
il s'agit sans aucun doute de celle qui dispose des plus vastes perspectives
puisqu'elle se pose en concurrente de l'esprit humain dont nous sommes bien
loin d'avoir percé les insondables secrets. »25(*)
Raoul SMITH26(*) introduit la notion d'apprentissage à partir
de l'environnement et de l'expérience et présente le concept de
la représentation symbolique des connaissances.
Celle-ci permet de faire des inférences,
c'est-à-dire de raisonner à partir des connaissances
formalisées produites. De surcroît, il souligne l'épineux
problème de la compréhension du langage naturel ou humain, l'un
des enjeux de l'intelligence artificielle du futur. On peut facilement
constater que le terme couvre un vaste champ de recherche.
Les articles et ouvrages de vulgarisation présentent
aussi des définitions. Jean-François DORTIER introduit des
notions d'analyse, de résolution de problèmes, de prise de
décisions, d'apprentissage et de perception. L'intelligence artificielle
a développé ces techniques au cours des cinquante
dernières années.
« Domaine de l'informatique qui s'attache à
construire des programmes intelligents, c'est-à-dire capables d'analyser
un environnement, de résoudre des problèmes, de prendre des
décisions, d'apprendre, de percevoir. »27(*)
Alain BONNET souligne deux objectifs de l'IA : comprendre la
nature de l'intelligence (But partagé par les sciences cognitives) et
simuler l'intelligence :
« L'intelligence artificielle est une discipline
visant à comprendre la nature de l'intelligence en construisant des
programmes d'ordinateur imitant l'intelligence humaine. »28(*)
« L'intelligence artificielle s'intéresse aux
processus cognitifs mis en oeuvre par l'être humain lors de
l'accomplissement de tâches intelligentes. »29(*)
Cela ne signifie pas pour autant que l'ordinateur produit
réellement une conduite intelligente. C'est l'observation des
comportements humains exigeant un degré d'intelligence qui permet la
modélisation et l'exécution sur la machine.
Jacques FERBER, professeur d'informatique et
spécialiste en intelligence artificielle distribuée, souligne la
comparaison entre la performance de l'intelligence humaine et celle de la
machine. Il ne s'agit pas d'une forme d'intelligence générale
mais d'une forme multifactorielle.
« Le terme «intelligence artificielle» a
été utilisé pour désigner un projet de recherche
consistant à concevoir une machine intelligente, c'est-à-dire
capable de réussir aussi bien qu'un être humain dans des
tâches jugées complexes. »30(*)
La méthode de l'IA consiste à élucider
certaines activités du cerveau pour les reproduire sur ordinateur.
Comprendre, communiquer, résoudre un problème, élaborer
une stratégie et prendre une décision font partie de cet
ensemble. L'intelligence artificielle s'inspire de l'étude de ces
conduites chez l'homme et propose une modélisation informatique. Elle va
de pair avec le développement des sciences cognitives.
Quelle est la spécificité de l'intelligence
artificielle par rapport à la programmation classique? Son but est de
comprendre la nature de l'intelligence et de construire des programmes simulant
les conduites associées à cette qualité.
Au départ l'informaticien cherche à
résoudre un problème. Le programme doit donc se servir d'un
ensemble de mécanismes afin de trouver une méthode susceptible
d'apporter une solution. L'intelligence artificielle diffère alors
essentiellement de la programmation classique. Pour celle-ci, c'est l'humain
qui construit le raisonnement à appliquer et le programme
s'exécute jusqu'aux résultats prévisibles. Autrement dit,
la programmation est déterministe. Au contraire, dans une application en
IA, « c'est le programme qui choisit le chemin à
suivre. »31(*)
Celui-ci n'est pas déterminé au préalable.
Ainsi, la méthode de recherche en intelligence
artificielle consiste à partir d'une activité humaine
jugée intelligente (ou tâche intelligente), à
émettre des hypothèses sur les processus mis en oeuvre lors de
l'accomplissement de la tâche considérée, à les
incorporer dans un programme, à observer le comportement et les
résultats produits par celui-ci, à affiner la théorie du
départ et à modifier le programme.32(*)
Tout d'abord la caractéristique principale d'un
programme est l'emploi d'une représentation symbolique de l'aspect du
monde concerné. L'intelligence artificielle utilise des langages de
programmation de haut niveau ou langages déclaratifs, qui permettent de
manipuler des symboles structurant nos connaissances. Cette
représentation établit une relation entre le monde réel
dans lequel s'inscrit le problème à traiter et le système
symbolique que l'on utilise pour le résoudre, et qui n'est pas
forcément numérique.
L'intelligence artificielle sépare les connaissances
à traiter par le programme et les modes de raisonnement ou
d'inférence (déductive ou inductive) susceptibles de manipuler
ces connaissances et d'apporter une solution au problème posé.
En second lieu, l'utilisation d'heuristiques est une autre
caractéristique fondamentale.
On peut définir celles-ci comme « une
méthode informelle sans garantie de succès ». «
Une démarche heuristique consiste, face à un problème,
à essayer un chemin en gardant la possibilité d'en essayer
d'autres si celui qui paraissait prometteur n'a pas conduit rapidement à
une solution. »33(*)
Le programme est confronté à un certain nombre
de difficultés. Il doit être capable de fournir une solution au
problème posé malgré l'absence de l'ensemble de
données relatives au problème. Il doit également pouvoir
faire face à des entrées contradictoires ou conflictuelles. Il
doit être capable d'apprendre. Alain BONNET définit cet
apprentissage en informatique par « la capacité
d'améliorer ses performances en tenant comptes des erreurs
passées. »34(*) Ce processus implique la capacité de
généraliser, de découvrir des analogies, de choisir des
omissions, c'est-à-dire d'oublier des détails inutiles.
Les principales caractéristiques
présentées ci-dessus montrent la différence entre la
programmation classique, procédurale et déterministe, et les
méthodes utilisées en intelligence artificielle. Mais à
quoi sert l'IA ? Examinons les domaines d'application de la recherche en
intelligence artificielle.
1.3. DOMAINE DE L'IA
Le domaine de l'intelligence artificielle tente de comprendre
comment les hommes pensent et s'efforce de construire des entités
intelligentes.
La recherche en IA recouvre un nombre important de domaines.
On peut énumérer les domaines suivants35(*) :
- La représentation des connaissances : si l'on
veut qu'un logiciel soit capable de manipuler des connaissances, il faut savoir
les représenter symboliquement. C'est là un des secteurs les
plus importants de la recherche en intelligence artificielle.
- Le traitement du langage naturel : qu'il s'agisse de
traduire un texte dans une autre langue ou de le résumer, le
problème crucial à résoudre est celui de sa
compréhension. On pourra dire qu'un logiciel comprend un texte
lorsqu'il pourra le représenter sous une forme indépendante de la
langue dans laquelle il est écrit : c'est une tâche
très difficile mais des progrès significatifs ont
déjà été réalisés.
- La résolution de problème. Les jeux
fournissent une bonne illustration de ce domaine : le champion du monde de
backgammon est un programme depuis quelques années déjà et
cela sera vraisemblablement aussi le cas pour le jeu d'échecs dans peu
de temps. Le jeu de Go résiste beaucoup plus aux efforts des
programmeurs de jeux.
- La reconnaissance de la parole : les progrès
sont beaucoup plus lents qu'on le l'imaginait mais constants. On est encore
loin de pouvoir produire un logiciel capable de reconnaître les paroles
d'un locuteur quelconque et ce la essentiellement parce que la
compréhension d'un mot, d'une phrase requiert beaucoup d'informations
extra-langagières comme le contexte et la connaissance du monde dans
lequel nous vivons.
- La reconnaissance de l'écriture : même la
reconnaissance de l'écriture dactylographiée n'est pas un
problème facile bien que l'on trouve sur le marché des logiciels
très performants. L'écriture manuscrite pose des
problèmes plus difficiles à résoudre dans la mesure
où cette tâche peut nous poser à nous aussi des
problèmes insolubles.
- La reconnaissance des visages : longtemps
considéré comme un des problèmes les plus difficiles de
l'intelligence artificielle, les réseaux neuronaux permettent d'obtenir
des résultats intéressant.
- La robotique :
o Les robots de recherche : le robot COG de Rodney Brooks
du MIT en 1991 est capable de voir, d'entendre et de réfléchir
et notamment de se regarder dans un miroir en s'identifiant à son image
COG réagit en fonction de son visuels comme le ferait un enfant. C'est
le robot le plus évolué de sa génération.
o Les robots d'exhibition. En 2000 Honda présenta
Asimo (Advanced Step in Innovative Mobility), un robot d'exhibition
représentant l'aboutissement de 14 années de recherches. Il a
été conçu sous la direction de l'ingénieur Masato
Hirose. Ce petit androïde mesure 1.20 m et pèse 53 kg. Il se
déplace à 16km/h mais il est capable de courir à allure
modérée (12km/h), de sautiller de danser et de monter ou
descendre des escaliers. Lors d'une représentation publique, Asimo rate
une marche et alerte, présenter des signes d'intelligence et puis tomber
et être incapable de se rétablir, révélait toute
l'impuissance des hommes à lui insuffler la vie et les réflexes
fondamentaux. A la fois fascinant et pathétique, sa chute dans
l'escalier révélait combien le chemin était encore long
vers la création d'un androïde totalement autonome.
- L'apprentissage : On a compris très tôt
qu'un logiciel devrait avoir des capacités d'apprentissage autonome pour
pouvoir être véritablement qualifié d'intelligence.
- L'aide au diagnostic médical : Les logiciels
d'aide au diagnostic ont été conçus dans le but de fournir
aux praticiens du secteur médical des outils diagnostics innovants et
faciles d'utilisation. Ils prennent en compte avant tout les dossiers
médicaux des patients et sont édités par
spécialité médicale.
- Les systèmes experts : un système expert
est un logiciel capable de simuler le comportement d'un expert humain
effectuant une tache précise. Le succès de l'intelligence
artificielle dans ce domaine est indéniable, dû au
caractère cible de l'activité qu'on lui demande de
simuler36(*).
Les systèmes experts ont aussi joué un
rôle important dans l'évolution de l'intelligence artificielle. En
effet, cette branche a connu un certain succès à partir des
années quatre-vingts.
Ces systèmes ont pour but de modéliser
l'expertise humaine dans un domaine spécifique. Ils comportent deux
modules dont une base de connaissances et un moteur d'inférence. Ce
sont, selon FERBER, « des programmes informatiques capables de
remplacer l'être humain dans ses tâches réputées les
plus complexes et qui réclament de l'expérience, du savoir-faire
et une certaine forme de raisonnement. »37(*)
1.4. APPLICATION PRATIQUE DE L'IA
Les techniques et méthodes de l'intelligence
artificielle s'emploient dans une multitude de domaines. En voici quelques
applications pratiques: systèmes experts en médecine, dans le
secteur bancaire et financier ; systèmes de gestion et de contrôle
des réseaux informatiques ; systèmes de réservation de
billets ; systèmes utilisés dans la gestion du transport
aérien ; systèmes de datamining et de
datawarehousing ; agents logiciels, moteurs de recherche, logiciels
Internet (pour l'achat en-ligne). Les systèmes de défense,
également, ont très vite intégré la technologie IA.
Au demeurant, les budgets militaires en ont souvent financé la
recherche38(*).
Cette discipline a permis le développement de
méthodes et d'algorithmes capables de faciliter des opérations
nécessaires à la maintenance des réseaux et à la
recherche documentaire parmi beaucoup d'autres activités.
CHAP 2. LES INTERACTIONS
DANS UN SMA
Dans ce chapitre nous nous intéresserons principalement
au modèle d'interaction des systèmes multi-agents communiquants,
dont les agents interagissent par messages asynchrones, eux-mêmes
exprimés dans un langage de communication d'agent (par exemple FIPA).
Au sein de cette catégorie, les systèmes multi-agents
conversationnels sont ceux dont les agents interagissent sous forme de
conversation de messages.
2.1. LES AGENTS
INTELLIGENTS
La presse informatique s'est intéressée aux
agents intelligents en 1997. Le terme désignait alors des programmes
d'interface, de recherche documentaire et de profilage des internautes. On
distinguait les technologies PUSH et PULL. On y associait des notions de
coopération, de collaboration, de mobilité39(*). Ce point a pour ambition de
définir le concept en examinant les diverses définitions et d'en
décrire les applications.
2.1.1. Comment définir
un agent intelligent ?
Le terme « agent intelligent » désigne un
certain nombre d'applications fonctionnant à la fois dans un
environnement Internet et sur d'autres environnements comme les systèmes
d'exploitation. La définition du terme reste très
générale. Elle se réfère à une partie d'un
système informatique (programme, code, crawler, spider) ou au
système complexe lui-même (métamoteur en-ligne, comparateur
de prix, logiciel). Si on recherche des définitions aujourd'hui sur
Internet, on peut se servir de Google40(*).
Cependant le terme couvre un plus grand champ
d'applications.
Jeffrey M. BRADSHAW dresse l'historique du terme dans son
article, « An Introduction to Software agents41(*) ». L'idée de
construire un programme « orienté agent » vient de
John McCARTHY au milieu des années cinquante, mais ce serait Oliver G.
SELFRIDGE qui aurait créé le terme42(*).
La recherche s'est faite essentiellement aux Etats-Unis et en
Grande-Bretagne.
Don GILBERT, travaillant pour IBM, décrit l'agent
intelligent en fonction d'un espace à trois dimensions : agence,
intelligence, mobilité. La première couvre le degré
d'autonomie et d'autorité et se mesure par l'interaction entre l'agent
et les autres entités du système. La seconde définit le
degré de raisonnement et de comportement appris et acquis, la
capacité de l'agent à s'adapter à l'usager, et à
exécuter les tâches déléguées par ce dernier.
La troisième concerne la mobilité de l'agent à travers un
ordinateur ou un réseau43(*).
Stan FRANKLIN et Art GRAESSER44(*) proposent en 1996 une taxonomie d'agent. Les agents
autonomes comportent les agents biologiques, les robots et un troisième
groupe consistant en agents logiciels et en agents de la vie artificielle. Les
agents logiciels eux-mêmes se subdivisent en agents
spécialisés dans une tâche, en agents de divertissement et
en virus.
2.1.2. Définition
L'association française de normalisation (AFNOR)
définit un agent intelligent ainsi:
« Objet utilisant les techniques de l'intelligence
artificielle : il adapte son comportement à son environnement et en
mémorisant ses expériences, se comporte comme un
sous-système capable d'apprentissage : il enrichit le système qui
l'utilise en ajoutant, au cours du temps, des fonctions automatiques de
traitement, de contrôle, de mémorisation ou de transfert
d'informations. »45(*)
Selon cette définition, souvent citée dans la
littérature spécialisée, la dénomination «
agent intelligent » correspond à la présence de
l'intelligence artificielle dans un programme. Le terme désigne souvent
un logiciel46(*).
Cependant, certains agents prétendument intelligents font preuve de
très peu d'intelligence dans leurs programmes.
Le choix de l'adjectif « intelligent » comporte
souvent des considérations liées au marketing plutôt
qu'à une authentique capacité.
En réalité, le terme agent est une
métaphore. Ce mot vient du verbe latin agere qui signifie
conduire ou agir pour quelqu'un d'autre47(*) par délégation. Le programme, donc,
agit comme un humain à qui on a confié une tâche ou une
mission.
Nous nous trouvons confrontés à la
multiplicité de définitions révélant la
complexité du domaine. Par exemple,
Béatrice FOENIX-RIOU, consultante et auteur d'un
ouvrage destiné aux veilleurs professionnels, assimile les agents
à une fonction : « Les agents intelligents sont des logiciels
capables de collecter l'information et de la traiter en fonction de
critères de valeur ou de pertinence. »48(*)
Selon cet auteur, les outils disponibles sur Internet sont
très éloignés des logiciels promis par les partisans de
l'intelligence artificielle, bien que « certains intègrent des
technologies issues de l'intelligence artificielle
»49(*). Le mot
« agent intelligent » est souvent employé car le terme est
vendeur. Pour le moment, ce type de logiciel semble encore au stade de
projet.
Béatrice FOENIX-RIOU préfère le terme
d'agent « presque intelligent » qui lui semble plus proche
de la réalité. Examinons, toutefois, à travers les travaux
qui lui sont consacrés, les tentatives de définition.
Henry SAMIER, enseignant-chercheur à ISTIA
(Université d'Angers) et Victor
SANDOVAL, enseignant-chercheur à l'École
centrale de Paris, définissent un agent comme « une
entité autorisée à agir à la place d'une personne
et en son nom50(*).
Ils attribuent l'intelligence d'un agent « à
l'intégration des mécanismes d'apprentissage, de
raisonnement et de planification dans les algorithmes de
programmation. »51(*)
Il n'est donc pas facile de fournir une définition
simple comprenant toute la diversité d'objets décrits. Pour les
spécialistes de la veille, le terme désigne les logiciels agents
du type méta-moteur ayant la capacité d'analyser les documents et
d'organiser les résultats des requêtes. Si l'on étudie,
à un niveau plus abstrait, les caractéristiques des agents
à partir de la littérature spécialisée52(*), on peut s'approcher d'une
définition plus compréhensive.
2.1.3. Caractéristiques
d'un agent intelligent
Si on examine les termes qui caractérisent un agent
intelligent, on remarque notamment les suivants : autonomie, apprentissage,
coopération, délégation, proactivité, raisonnement,
réactivité, communication et mobilité53(*).
Le degré d'autonomie d'un agent intelligent varie en
fonction de sa capacité à agir sans l'intervention humaine une
fois qu'il a été paramétré. L'apprentissage
désigne le processus de mémorisation et d'adaptation à
partir de l'expérience. L'agent enregistre ses expériences et
modifie son comportement en fonction de celles-ci. Sa capacité à
coopérer lui permet de collaborer avec d'autres agents, notamment les
moteurs de recherches et d'autres bases de données. La
délégation implique qu'il est autorisé à agir et
peut prendre des décisions après une négociation. La
pro-activité s'inscrit dans un processus de prises d'initiatives :
l'agent peut anticiper des actions. Le raisonnement implique qu'il
possède un moteur d'inférence.
La réactivité lui permet de modifier ses
réactions en fonction de son environnement (intranet, réseau
local, Internet, extranet, ordinateur). La communication désigne sa
possibilité de dialoguer avec l'utilisateur et avec d'autres agents
(méta-moteurs, serveurs).
La mobilité signifie qu'il se déplace dans son
environnement.
Cette classification des caractéristiques d'un agent
met en évidence l'ambition du projet : construire des programmes
capables d'une action autonome et de remplacer les humains dans un certain
nombre de tâches.
2.1.3. Classification des
agents intelligents
Il existe plusieurs manières de classer les agents. On
peut les regrouper en fonction de l'environnement, de la dichotomie PUSH/PULL,
ou CLIENT/SERVEUR, ou par rapport à leurs tâches. Celles-ci sont
définies par leurs concepteurs.
L'environnement désigne la plate-forme sur laquelle les
agents sont installés. On énumère ainsi trois grandes
classes d'agents intelligents54(*): ceux du PC, d'Internet et les agents d'intranet. Les
agents du PC (desktop agents) s'imbriquent dans le système
d'exploitation de l'ordinateur (Windows, Mac OS, etc.). Ils sont connus sous le
nom d'assistants. Leur fonction est d'aider l'usager dans l'exécution
d'une tâche automatisée comme installer un nouveau logiciel ou un
nouveau périphérique en plug and play. Les agents
d'intranet (Intranet agents) permettent de récupérer des
ressources sur les serveurs de l'entreprise. Les agents d'Internet
(Internet agents) aident l'utilisateur à rechercher des
documents sur Internet. Les moteurs et méta-moteurs font partie de cette
catégorie.
Une seconde distinction se fait entre les agents du type PULL
et ceux du type PUSH. Le verbe anglais pull signifie tirer vers soi,
tandis que le mot push veut dire envoyer vers quelqu'un d'autre.
L'utilisateur initie la requête en paramétrant un agent à
partir de mots-clés ou d'expressions plus complexes. Il
délègue la tâche à un agent PULL comme un moteur ou
méta-moteur. Cependant, l'usager interagit avec le programme en
transformant la requête en fonction des résultats
retournés.
Au contraire, avec la technologie PUSH, l'utilisateur est
passif. Les logiciels de type PUSH permettent d'accéder à des
chaînes d'information thématiques ou d'actualité, comme les
chaînes de télévision ou de journaux. Les informations sont
envoyées régulièrement aux abonnés en fonction de
leur profil ou de leurs centres d'intérêts définis au
préalable ou appris grâce à la vigilance du programme
informatique. PointCast, Marimba et BlackWeb constituent des exemples de
logiciels de PUSH. Le moteur Google (news alerts) et certains
méta-moteurs comme Copernic ont intégré ce type
d'activité.
Les agents de diffusion sélective font partie de la
technologie PUSH. Leur but est de trouver pour l'utilisateur les informations
susceptibles de l'intéresser sans qu'il en ait fait la demande. Le
système fonctionne de la manière suivante. L'utilisateur souscrit
un contrat avec un fournisseur d'informations qui lui envoie un choix de
documents en fonction de ses goûts et intérêts. Un agent
intelligent choisit automatiquement les documents et établit une liaison
entre l'agent installé sur l'ordinateur de l'utilisateur et celui du
serveur du fournisseur. Les journaux américains comme The New York
Times offrent ce type de service.
Les agents d'alerte et de veille surveillent une source
d'information ou un thème pour prévenir l'utilisateur en fonction
d'une requête prédéfinie55(*).Ils envoient des messages par courrier
électronique lors d'un changement de contenu. Parmi ce type d'agent,
nous rencontrons Url-Minder et Net Mind High lighter.
Le dernier mode de classement décrit les usages
prévus par les éditeurs de logiciels : les tâches
accomplies par l'agent. Passons en revue ces divers types de programme en
précisant que cette liste n'est pas exhaustive.
Un agent de filtrage est conçu pour examiner des
courriers reçus et détruire les e-mails non désirés
sur la messagerie, éliminer les informations non pertinentes d'une
requête, chercher et préparer des informations à partir de
diverses sources. (Quelques exemples : News Hound, ZDNet personal View ou
NewsPage Direct.)
Un agent aspirateur (retrieval agent)
télécharge un site entier sur le disque dur, facilitant ainsi
l'analyse de son contenu hors-ligne. Les agents avertisseurs ou d'alerte
hors-ligne (notifiers) préviennent l'usager lorsqu'un site
change, lorsqu'une information importante arrive ou qu'un
événement important se produit.
Les agents de recherche (search agents) identifient
des informations pertinentes sur Internet en relation avec un ensemble de
moteurs et en fonction des préférences des usagers. Ils peuvent
intégrer un module d'apprentissage. Ce que l'on nomme ici agent fait
l'objet d'un ensemble de fonctionnalités introduites dans les progiciels
d'agents intelligents du type méta-moteur.
Nous rencontrons également des agents livreurs
d'informations hors-ligne (delivery agents) qui, comme leur nom
l'indique, envoient des informations personnalisées aux usagers sur leur
disque dur. La connexion n'est pas établie pendant la lecture ou la
consultation des documents reçus, ce qui permettait auparavant de
diminuer la consommation de bande passante.
La technologie PUSH apparaît comme une solution aux
problèmes posés par la croissance exponentielle de documents sur
le Web. Il est extrêmement difficile et coûteux (en temps) de
trouver des informations recherchées uniquement par le biais du PULL. Le
PUSH, par contre, permet à l'internaute de recevoir des documents
préparés pour être téléchargés :
« La solution a été imaginée par
PointCast. Il s'agit de rassembler l'information que les utilisateurs
recherchent, d'y mêler de la publicité et des annonces et de leur
envoyer pendant qu'ils dorment !...
Avec le push, c'est l'information qui trouve
l'utilisateur. »56(*)
Cependant, le PUSH connaît des inconvénients : la
quantité d'informations envoyées et enregistrées sur le
disque dur peut s'avérer considérable et devenir très
rapidement difficile à gérer, d'où la
nécessité de moteurs de recherche interne performants.
La dichotomie client/serveur permet également une
classification. Certains agents peuvent être
téléchargés et installés sur le disque dur de
l'usager. D'autres, au contraire, opèrent à partir du serveur du
propriétaire de l'agent, et fonctionnent en mode client-serveur.
L'internaute se connecte et utilise les services de la
technologie mise à sa disposition gratuitement. L'avantage des agents du
côté client réside dans leur paramétrage plus
poussé par rapport aux agents localisés sur un serveur à
distance.
Le dernier mode de classement décrit les usages
prévus par les éditeurs de logiciels : les tâches
accomplies par l'agent.
Les agents d'achat ou comparateurs de prix (shopping
agents) facilitent la recherche des meilleurs prix pour un produit
donné. Ils ne sont pas forcément appréciés par les
propriétaires des sites Web commerçants et leur entrée
dans un site peut être interdite. La concurrence pure et parfaite sur
Internet ne fait pas l'unanimité. Ce type de technologie intègre
progressivement les sites des moteurs de recherche57(*) ou des portails.
Les agents de bavardage (chatterbots)
s'avèrent capables de s'entretenir avec un usager.
Le premier de ce type, Eliza58(*), se comportait comme une psychanalyste qui posait des
questions à son patient pour le faire parler. Depuis, on conçoit
les chatterbots pour introduire une forme de dialogue et
d'interactivité sur certains sites Web commerciaux. Le bot peut
répondre à des questions posées par l'internaute sur un
produit ou un service ou envoyer des fiches techniques en fonction des
mots-clés repérés dans l'énoncé du
visiteur.
Les agents de petites annonces (classified agents)
examinent les offres de produit dans des bases de données en fonction du
sujet ou du domaine spécifié par l'internaute. Ils envoient les
résultats par e-mail.
L'agent pense-bête (announcement agent) a pour
mission de rappeler à l'usager les événements ou les
rendez-vous importants. Ce type d'agent peut s'installer en ligne ou sur le
disque dur d'un PC.
D'autres types existent, certains spécialisés
dans les livres (book agents) et qui cherchent les nouveautés
dans le monde de la publication en fonction des préférences des
usagers. Les agents de suivi du monde des affaires (business information
monitoring agents) filtrent l'actualité économique, les
publications et rapports mis sur Internet par les entreprises. Les agents de
services financiers personnalisés (financial service
agents)59(*)
apportent des informations financières en fonction du portefeuille
personnel de l'usager. Enfin, les agents de recrutement (job agents)
cherchent les profils d'éventuels candidats pour un emploi en fonction
des CV mis en-ligne60(*).
Un schéma d'usage émerge à partir de
toutes ces descriptions : l'usager délègue une tâche
spécifique et reçoit les résultats de l'opération
automatiquement sans être obligé d'en renouveler la demande.
On constate que la plupart de ces agents ont été
inventés en fonction d'une demande d'ordre économique. Ils
correspondent aux besoins des consommateurs ou des entreprises anticipés
par les développeurs et les éditeurs de logiciels. Certains sont
offerts, et le coût du développement est supporté par des
modes de financement tels que le partenariat avec des sites commerciaux, la
publicité, mais souvent par abonnement pour l'instant. Ces agents
peuvent facilement s'intégrer dans des systèmes globaux de
recherche d'information comme les portails. D'ailleurs les usagers
informaticiens ont la possibilité de construire leurs propres agents
grâce aux api61(*)
(application programming interface) offerts par ces derniers.
Comment donc définir simplement un agent intelligent ?
C'est un programme qui exécute une tâche à l'initiative de
l'usager. Il est autonome et il peut automatiser ses missions. Il agit par
délégation.
Le terme désigne le plus souvent un programme de
recherche d'information, si on examine les définitions sur le web. Voici
les quelques définitions données par Google (code definir :
agent intelligent) confirmant notre propos :
· En informatique, un agent est l'équivalent d'un
robot logiciel. C'est un programme qui accomplit des tâches à la
manière d'un automate et en fonction de ce que lui a demandé son
auteur.
http://www.
wikipedia.org/wiki/Agent_intelligent
· Elément logiciel (programme) capable
d'exécuter certaines tâches de façon permanente
(surveillance de réseaux, recherche documentaire...) qui ne se manifeste
qu'en cas de besoin (demande d'intervention, fin de recherche...). ...
http://www.
revuesim.free.fr/index.php
· Logiciel visant à faciliter la recherche et la
gestion de l'information sur l'Internet. Il possède des attributs
propres et agit dans le but de d'accomplir un certain nombre de tâches
pour un autre agent logiciel ou un humain. ... http://www.
aeris.11vm-serv.net/cours/util_outils/glos.html
· (n.) Objet d'un serveur qui exécute diverses
requêtes (HTTP, NNTP, SMTP et FTP) pour le compte de l'utilisateur. D'une
certaine manière, l'agent intelligent joue le rôle de client pour
le serveur, en effectuant des requêtes remplies par le
serveur. http://www.
docs.sun.com/app/docs/doc/819-4628/6n6p2pm93
· Programme autonome et personnalisable capable
d'apprendre par lui-même et de reproduire des tâches
particulières (exemple : les agents de recherche d'informations).
www.francedecision.com/v2/component/option,com_rd_glossary/task,showcat/catid,19/Itemid,109/
· c'est un objet informatique capable
d'interactivité avec des serveurs et d'autres objets informatiques. Il
comporte des membres et des méthodes. Les membres sont des sortes
d'attributs comme le nom du propriétaire, la durée d'un travail,
une valeur estimée ou une unité de mesure (etc). ...
http://www.
217.128.136.10/Glossaire/toutleglossaire.htm
Le rôle d'un agent, selon ces définitions,
consiste soit à chercher des informations pour un internaute soit
à enregistrer ses pratiques de navigation.
2.2. DES INTERACTIONS AUX
CONVERSATIONS
Demazeau définit le système multi-agents selon
cinq aspects62(*):
l'agent, l'environnement, l'interaction, l'organisation et l'utilisateur.
L'interaction est ainsi un des aspects clés des systèmes
multi-agents. Elle offre un moyen pour assurer la coopération et la
négociation entre agents. Sans interaction (ou communication), l'agent
n'est qu'un individu isolé, sourd et muet, renfermé sur sa boucle
perception-délibération-action63(*). Bien que l'interaction et la communication sont
souvent confondues dans la littérature, la communication
représente la transmission d'information entre agents, alors que
l'interaction comprend l'action sur le monde, ainsi que la communication entre
les agents du système64(*). En effet, deux modes de communication se distinguent
dans la littérature : la communication indirecte qui se fait par
transmission de signaux via l'environnement, et la communication directe, qui
correspond aux échanges de messages entre les agents.
Nous nous penchons sur les systèmes multi-agents dont
l'interaction est régie par les protocoles d'interaction. Un protocole
d'interaction est un enchaînement prédéfini de messages.
Les protocoles d'interaction sont introduits dans les
systèmes multi-agents dans le but de faciliter la spécification
et l'implémentation de l'interaction entre les agents. D'après la
définition de FIPA1 (Foundation of Intelligent Physical
Agents), un protocole d'interaction est un pattern commun de
communication. Ainsi la spécification et l'implémentation du
protocole doivent être indépendantes du domaine d'application et
de l'architecture interne de l'agent.
2.2.1 Systèmes
multi-agents Communiquants
2.2.1.1 Réification des messages
Dans les systèmes multi-agents communiquants, les
messages sont des objets ou entités manipulables et accessibles par les
agents. Ils sont adressés à un ou plusieurs agents en
particulier, par le biais d'une adresse ou un identifiant, et sont typés
par une sémantique d'acte de langage. Ils sont qualifiés
d'intentionnels du fait notamment qu'ils dénotent une intention
du locuteur sur l'interlocuteur.
Une bonne analogie pour se le représenter est celle des
e-mails. Les e-mails sont des messages standardisés par la RFC
822, qui contiennent un certain nombre d'informations explicites sur
l'interaction qu'ils représentent : la source du message, le ou les
destinataires, la date d'envoi, etc.
Les messages entre agents communiquant sont assez comparables.
Dans le cas d'objets distribués, les appels de méthodes distants
sont aussi encodés sous forme de messages, in fine. Cependant
les méta-informations, comme la source du message, ne sont pas
accessibles par le destinataire, ce qui fait une différence
importante.
La figure ci-après donne un exemple de message dans le
langage FIPA-ACL, encodé textuellement.
Dans FIPA, le message est lui-même placé dans une
enveloppe qui sépare les paramètres du message de ceux
liés à son transport effectif.
(propose
: sender (agent-identifier
: name cnet2@locallap
: addresses (sequence
Fipaos-rmi : // 192.168.0.2 : 3000/cnet2
)
)
: receiver (set
(agent-idenfier
: name cent-proxy@locallap
: addresses (sequence
Fipaos-rmi : // 192.168.0.2 :
3000/cent-proxy
)
)
)
: content (deal
: product bananas
: quantity 1
: price 15
)
: protocol fipa-iterated-contract-net
: conversation-ide cent-proxy@locallap-auction
#0.cnet2@locallap
)
Figure 1. Exemple d'un message
FIPA-ACL en format textuel (sans l'enveloppe)
Source : Denis Jouvin, Délégation de
Rôle et Architectures Dynamiques de systèmes Mullti-agents
conversationnels, Université Lyon I-Claude Bernard, Paris, Thèse
de Doctorat 2003.
2.2.1.2 Théorie des actes de langages
Le typage sémantique des messages prend son origine de
la théorie des actes de langage. Cette théorie de la philosophie
du langage est apparue dans les années 60 par les travaux de
Austin65(*) et ensuite de
Searle66(*). Elle part du
principe que la communication humaine est constituée d'actes de
langage, aussi appelé performatifs, que l'on peut classer
en cinq grandes catégories :
- Les assertions, qui informent l'interlocuteur d'une croyance
de la part du locuteur sur l'état du monde;
- Les directives, qui sont des requêtes, indiquant
l'intention du locuteur que l'interlocuteur agisse de façon à
satisfaire la requête ;
- Les actes expressifs, exprimant des sentiments ressentis par
le locuteur;
- Les déclarations, qui informent l'interlocuteur d'une
intention du locuteur ou un état de quelque chose qui dépend de
ce dernier ;
- Les engagements, qui sont des promesses, ou à
l'inverse des menaces.
Cette théorie a ensuite été
appliquée à la communication entre agents autonomes, par Cohen et
Levesque67(*), en partie
par anthropomorphisme, puisque les actes de langages sont à l'origine un
modèle philosophique de la communication humaine, et que le
modèle multi-agents est lui-même inspiré de systèmes
naturels ou sociaux.
2.2.1.3 Langages de communication entre agents
Les premiers langages de communication entre agents (ACL pour
Agent Communication Language) ont ensuite fait leur apparition. Les
deux plus répandus sont KQML, de Finin, Labrou et al.68(*) 69(*), est apparu un peu plus tard,
FIPA-ACL70(*) 71(*), standardisés par la
FIPA. Ces langages de communication ont été directement
inspirés de la théorie des actes de langage, avec une certaine
connotation « connaissance » héritée de l'intelligence
artificielle distribuée : les agents sont parfois perçus comme
des bases de connaissances indépendantes.
La standardisation de ces langages de communication entre
agents est principalement confinée au niveau communicationnel,
ce qui constitue une clef pour l'interopérabilité.
Leur sémantique concerne avant tout l'interaction. Pour
des raisons que nous qualifierons d'historiques, elle comporte une
interprétation de plus haut niveau, intentionnelle, mais celle-ci est
suffisamment générique pour être applicable à tout
système impliquant une communication par messages. Il est vrai que la
partie sémantique intentionnelle des actes de langages, de haut
niveau, a été peu à peu délaissée
récemment, au profit de considérations de plus bas niveau comme
la coordination.
Niveau communicationnel.
Ce niveau équivaut au niveau des actions
défini par Pitt et al. 72(*), ou au niveau conversationnel de Martin et
al.73(*), se limite
à considérer les échanges de messages, et ce qui contraint
et régit explicitement ces échanges, sans tenir compte de la
sémantique du contenu des messages, et ce qui attrait aux
niveaux d'abstraction plus élevés que la conversation
(ontologies, manipulation de connaissances ou croyances, états internes
ou mentaux des agents, organisation de haut niveau, etc.). Ces niveaux
d'abstraction participent pleinement à influencer et diriger les
interactions, mais ne sont pas perceptibles au niveau communicationnel.
De la même manière, le niveau communicationnel
exclue le niveau (plus bas) du transport des messages, qui, bien que
nécessaire à l'interopérabilité, est
dépendant de l'environnement d'exécution.
La figure ci-après reprend ce découpage en
trois couches de l'interaction :
- le niveau transport de messages,
- le niveau communicationnel,
- et le niveau spécifique au domaine, correspondant au
contenu des messages.
Figure 2. Niveau communicationnel
dans l'interaction
Source : Denis Jouvin, Délégation de
Rôle et Architectures Dynamiques de systèmes Mullti-agents
conversationnels, Université Lyon I-Claude Bernard, Paris, Thèse
de Doctorat 2003.
Les ACL sont notamment indépendants du langage
utilisé pour encoder les connaissances contenues dans les messages, ce
qui représenterait le niveau sémantique supérieur (voir
figure 2). Ils sont également indépendants du transport et de
l'encodage des messages, ce qui correspondrait au niveau inférieur.
Plutôt que de décrire chaque langage de
communication séparément, nous aborderons ici l'aspect acte de
langage parallèlement dans KQML aussi bien que FIPA-ACL. Nous
insisterons beaucoup plus sur le langage de communication FIPA-ACL, dans le
cadre des réunions virtuelles d'attributions de charges horaires au
Département d'Informatique de Gestion à l'ISP/Bukavu, l'objet de
ce présent travail.
Tableau 1. Classification des
principaux actes de langage de KQML et FIPA ACL
Source : Denis Jouvin, Délégation de
Rôle et Architectures Dynamiques de systèmes Multi-agents
conversationnels, Université Lyon I-Claude Bernard, Paris, Thèse
de Doctorat 2003.
Les actes de langage définis dans les ACL se rattachent
aux catégories décrites plus haut dans la classification initiale
de Searle, à l'exception bien-sur de la catégorie des actes
expressifs. Le tableau 1 donne une correspondance entres les principaux actes
de langage de KQML et FIPA- ACL, ainsi que leur catégorie.
En comparant ces deux langages de communication d'agents, nous
pouvons remarquer que FIPA- ACL est plus parcimonieux et économe de
performatifs que KQML, dont les performatifs tendent à être plus
spécifiques, et redondants, et dont certains ont une sémantique
dédié à des tâches particulières, non
liées à la simple communication, comme par exemple la
manipulation de base de connaissance, ou encore l'enregistrement auprès
d'un agent facilitateur. Malheureusement cette spécificité
entaille quelque peu le principe d'indépendance du niveau connaissances
évoqué plus haut. Ces mêmes actes sont exprimables dans
FIPA-ACL par des actes génériques comme Request,
couplés à un contenu utilisant une ontologie spécifique
standardisée.
2.2.1.5. Apports et limites des actes de langages
Cette partie tente de faire le point sur, d'une part, ce
qu'apporte l'utilisation des actes de langages dans notre problématique,
et d'autre part les limites de cette théorie.
Les actes de langages sont les briques de base de la
sémantique communicationnelle. Ils représentent des
modèles fragmentaires de motifs d'interaction, génériques
dans le sens où ils sont non spécifiques à un domaine, et
également dans le sens où ils sont théoriquement
combinables ou composables, selon une certaine sémantique.
Les actes de langage nous renseignent sur le comportement
attendu de l'agent qui les utilise. Le principal apport est donc relatif
à l'interopérabilité : l'utilisation de tel ou tel acte de
langage est une méta-information sur le comportement de l'agent en terme
de communication. La standardisation de cet aspect est un facteur de
convergence et d'interopérabilité entre deux agents effectuant
une tâche collective similaire, et conçus séparément
: grâce à cette sémantique, il y a de plus fortes chances
pour qu'ils utilisent les mêmes actes de langages.
Cette information n'est certes pas suffisante pour garantir
l'interopérabilité. Le contenu des messages, et les niveaux
sémantiques supérieurs plus spécifiques au domaine (par
exemple les ontologies), doivent aussi être standardisés tout en
maintenant la séparation avec le niveau communicationnel. De même,
le niveau inférieur, le transport des messages, doit être
également interopérable.
Contexte d'interaction. Le contexte de
l'interaction est indispensable pour interpréter sans
ambiguïté le déroulement d'une communication, même
à ce niveau. Cette nécessité était
déjà suggérée par les théoriciens du
langage, contemporains de Searle. Ces derniers reconnaissaient qu'il fallait
une unité d'analyse plus large que le simple acte de langage pour
décortiquer la structure du dialogue, et ont introduit par exemple la
notion de paire d'adjacence, liée à la structure des
conversations.
C'est aussi pourquoi un langage comme FIPA-ACL ne
définit pas seulement des messages et actes de langages, mais aussi des
conversations, régies par des protocoles d'interactions74(*).
Exemple 1. Un agent fournisseur d'un service donné
procède par enchère, par envois d'appels à proposition
successifs (CFP pour Call For Proposal), à des acheteurs
potentiels, puis acceptations ou refus de leurs propositions. Si nous
supprimons la notion de conversation, la réponse aux propositions, comme
aux CFP, devient ambiguë : un participant a besoin de savoir s'il
était le gagnant au tour d'enchère précédent, afin
de savoir s'il doit proposer ou non un meilleur prix ; un CFP pourrait tout
aussi bien signifier une nouvelle enchère, ou la continuité d'une
enchère parallèle. De même, le vendeur a besoin de
rattacher une proposition à une enchère donnée, dans le
cas de deux enchères en parallèle, ne serait-ce que pour savoir
à qui envoyer le nouveau CFP basé sur cette proposition. Il faut
donc identifier chaque enchère, et rattacher les propositions et CFP
à ce contexte.
2.1.1.5 Extensions et langages moins
répandus
Les langages de communication entre agents et leurs extensions
présentés dans cette section sont de toute évidence moins
répandus que KQML et FIPA-ACL, mais ils en reprennent et partagent les
fondements. Nous les présentons ici d'abord par souci de
complétude, mais aussi parce qu'ils soulignent le besoin de contexte
d'interaction et de conversation que nous avons identifié.
- KAoS de Bradshaw et al.75(*) 76(*), définit un langage de
communication somme toute assez similaire à KQML. Il contient moins
d'actes de langages, que les auteurs dénomment par « verbes »,
mais est très axé sur la notion de conversation.
Les messages de KAoS ont un paramètre permettant
d'identifier une conversation, et un autre spécifiant le protocole
d'interaction utilisé (conversation policies). Les
conversations peuvent être imbriquées, et modélisées
par une machine à états finis.
Les protocoles d'interaction sont organisés en suites,
qui sont des « familles» de protocoles d'interaction, dans lesquels
les rôles sont déclarés. Les rôles des
différents protocoles sont classés soit comme initiateurs
(client), soit fournisseurs du service (serveur). La suite permet de
réutiliser les verbes d'un protocole, dans le but de l'étendre en
une version plus spécifique ou élaborée. Un service est
associé à une ou plusieurs suites. Le facilitateur se comporte
comme un répertoire de services.
- COOL de Barbuceanu et Fox77(*), est quant à lui une
extension de KQML orientée vers les conversations et leur coordination,
et plus particulièrement la spécification opérationnelle
de protocoles d'interaction, appelés ici classes de conversations. COOL
ne redéfinit pas la sémantique et le format des messages de KQML,
mais ajoute un certain nombre d'actes de langages comme Propose,
Counter-propose, ou encore commit, de-commit.
COOL utilise un paramètre permettant d'identifier les
conversations dans les messages, de la même manière que KAoS. Son
originalité est qu'il définit un formalisme pour décrire
les règles, états et transitions d'une classe de conversation.
Dans ce formalisme les rôles sont explicites, et sont décrits au
moyen d'une machine à états finis. Il ajoute également des
règles de continuations, permettant de spécifier comment un agent
pourra enchaîner plusieurs conversations, et des préconditions
d'applicabilité de certains rôles à un message
donné, par le biais d'un nouveau paramètre de message, internet.
Il permet enfin de définir des interdépendances entre
conversations et leurs états, ce qui constitue une forme de composition
de conversations.
- AgenTalk de Kuwabara et al78(*), est plus axé sur la
définition de protocoles d'interaction, à la manière de
COOL, mais cette fois-ci sous la forme d'un langage de script. Le but est
clairement d'opérationnaliser les définitions de protocoles en
interprétant directement ces scripts, et non une description formelle.
Un interpréteur est fourni par l'auteur, et appliqué à un
projet de télé-organisation.
Une originalité de AgenTalk est la possibilité
pour un script d'hériter d'un autre script, ce qui permet de concevoir
un protocole d'interaction comme une extension d'un protocole existant. La
encore nous retrouvons l'idée de composition de protocoles, sous une
forme d'héritage particulière.
La présentation de ces trois ACL est
intéressante car elle montre d'une part certaines réponses aux
critiques faites à KQML dans ses débuts, et, d'autres part, la
nécessité unanime de disposer d'une unité de
modélisation de la communication plus large que le simple acte de
langage : la conversation.
L'apparition de cette notion, notamment dans FIPA- ACL, marque
je pense un virage important dans la communauté des SMA communiquants.
De fait, l'idée d'agents fortement cognitifs, capables d'inférer
par eux-mêmes la séquence du discours à suivre par simple
raisonnement sur la sémantique des actes de langages, est peu à
peu abandonnée, car peu réaliste dans l'état actuel des
choses. Les concepteurs misent plus volontiers sur des séquences
pré-établies, conçues pour une tâche donnée,
mais réutilisables, que deviendront les protocoles
d'interaction. Un tel protocole est donc une manière de
spécifier une collaboration, en termes de communications.
Pour permettre aux agents de suivre ces protocoles
prédéfinis, il est nécessaire de réifier (que
j'utilise ici au sens de « rendre explicite ») un minimum les
instances de conversations. D'où l'apparition et l'utilisation de
paramètres identifiant la conversation (Conversation en KaoS ou COOL, ou
Conversation-ID en FIPA ACL), et également d'un
paramètre identifiant le protocole d'interaction qui la régit
(protocol en FIPA-ACL). Le fait est que KQML n'inclut pas ces paramètres
- même si une version modifiée, KQML-Lite, inclut protocol.
Dans cet ordre d'idée, un langage de communication
entre agents devient plus un outil de coordination au sens large, c'est
à dire de standardisation des conversations qui doivent être
coordonnées correctement, qu'un langage définissant la
sémantique des intentions de l'agent par rapport aux connaissances
communiquées.
2.2.2 Systèmes
multi-agents conversationnels
Conversation est un concept important dans ce
travail de recherche, car c'est autour de lui et autres que s'articulent les
différentes solutions proposées au Département
d'Informatique de Gestion pour la gestion des réunions d'attribution des
charges horaires. Il est donc essentiel de les définir et de les situer
convenablement par rapport aux définitions que l'on trouve dans la
littérature, afin d'éliminer d'éventuelles confusions.
2.2.2.1 Du contexte d'interaction à la
conversation
Cette section définit précisément ce que
j'entends par contexte d'interaction, mais développe aussi l'idée
que ce contexte d'interaction est nécessaire à la
spécification du comportement des agents.
Le contexte d'interaction est un contexte dans lequel tout
agent se place lorsqu'il effectue plusieurs échanges de messages, ou
interactions diverses, liées les unes aux autres par des relations de
dépendance sémantique, par exemple de causes à effet, et
par un objectif collectif temporaire. Ce contexte comprend aussi bien les
interactions passées, déjà effectuées dans le cadre
de cette tâche, que les interactions potentielles futures attendues de
l'agent et des autres participants, c'est à dire les différents
engagements et responsabilités pris implicitement ou explicitement par
eux à ce sujet. Une bonne coordination dépend de ces engagements,
et de leur connaissance partagée.
Les responsabilités associées aux interactions
futures peuvent être modélisées de façon plus ou
moins détaillée. Elles sont directement liées à la
description du comportement de l'agent dans ce contexte, puisqu'il est
censé se conformer à la description publique de ce comportement.
Dans le cadre d'une conversation, nous exprimerons que ces
responsabilités sont régies par un rôle dans un
protocole d'interaction.
Protocoles multi-parties et rôles multiples. Les
protocoles d'interactions ne sont pas nécessairement des dialogues
impliquant uniquement deux interlocuteurs, comme c'est le cas dans le
modèle client-serveur sous-jacent à l'appel de méthode
distant. Une conversation peut impliquer un grand nombre d'agents, chacun
devant suivre un comportement cohérent et coordonné par rapport
aux autres.
Figure 3. Conversation
multi-parties
Source : Denis Jouvin, Délégation de
Rôle et Architectures Dynamiques de systèmes Mullti-agents
conversationnels, Université Lyon I-Claude Bernard, Paris, Thèse
de Doctorat 2003.
Dans la définition d'un protocole d'interaction, les
responsabilités sont regroupées en différents
rôles, qui sont attribués à chaque participant et
qui correspondent aux responsabilités et au comportement attendu de cet
agent en particulier dans la conversation.
Multi-parties signifie que le protocole comporte plus
de deux rôles.
Par extension, un rôle peut être associé
à un groupe de participants ayant des comportements
supposés identiques. Nous parlerons alors de rôle
multiple. Le contexte d'interaction que représente la conversation
comprend également les identités de tous les participants
à la tâche collective, ainsi que les rôles qui leurs sont
affectées.
La figure 4 montre, en notation intuitive par messages
numérotés, un exemple abstrait des conversations
multi-parties.
Définition d'une conversation.
Une conversation est un contexte d'interaction,
effectuée dans le cadre d'une tâche collective, faisant
état des messages déjà échangés, des
interlocuteurs ou participants connus de la conversation, et des
responsabilités et rôles qui leurs sont affectés, en termes
d'échanges de messages potentiels.
Nous pouvons ajouter que la prise en compte des conversations
multi-parties et à rôles multiples, est une différence
majeure entre les systèmes multi-agents conversationnels et les
systèmes à objets distribués ou orientés
composants. Même lorsque des protocoles sont associés aux
interfaces des composants, leur modélisation se limite au modèle
client-serveur, c'est à dire à un dialogue initié par un
seul composant client, avec le composant serveur.
2.2.2.2 Structure de message et réification
de conversation
Pour pouvoir permettre aux agents de participer à
plusieurs tâches collectives simultanément, la conversation
elle-même doit être identifiée explicitement dans les
messages, de façon à éliminer les ambiguïtés,
en rattachant les messages aux contextes qui les concernent. Ce besoin a
été reconnu par plusieurs Chercheurs [79(*)][80(*)][81(*)].
En pratique, dans un système donné, une partie
des méta-informations de la communication sera implicite, une autre
partie sera explicite, encodée dans les messages échangés.
Cette partie explicite est plus importante dans les systèmes
multi-agents que dans d'autres systèmes distribués, ce qui offre
de multiples possibilités :
- Enrichir et désambiguïser la sémantique
de chaque message, d'une façon générale ;
- Étendre le modèle d'interactions à des
tâches collectives et conversations de plus de deux interlocuteurs ;
- Permettre aux agents de valider plus facilement que les
autres participants respectent les rôles qui leurs sont attribués
;
- Permettre aux agents d'implémenter des protocoles
plus compliqués ou optimisés, grâce à
l'élimination d'ambiguïtés ;
- Enfin permettre aux agents d'effectuer plusieurs
conversations simultanément.
Ces apports, que nous détaillerons plus avant en
section 2, dépendent du degré de réification des
conversations (simple identifiant, protocole, rôle, composition,
etc.).
Figure 4. Exemple d'un message
FIPA-ACL
Source : Denis Jouvin, Délégation de
Rôle et Architectures Dynamiques de systèmes Mullti-agents
conversationnels, Université Lyon I-Claude Bernard, Paris, Thèse
de Doctorat 2003.
Le concept de conversation est présent dans le
modèle des messages de plusieurs ACL, notamment FIPA-ACL. La figure 4
donne une représentation synthétique de la structure des messages
de FIPA-ACL. Cette structure de message comprend une liste de paramètres
nommés, dont la valeur peut éventuellement être une
liste.
Les paramètres prédéfinis sont
donnés dans le tableau2, où nous traitons KQML et FIPA ACL
ensembles, par soucis de clarté.
Tableau 2. Paramètre des
messages KQML et FIPA ACL
Source : Denis Jouvin, Délégation de
Rôle et Architectures Dynamiques de systèmes Mullti-agents
conversationnels, Université Lyon I-Claude Bernard, Paris, Thèse
de Doctorat 2003.
Au vu de ce tableau (en considérant surtout FIPA-ACL),
nous observons que, sans compter le performatif, cinq paramètres sont
liés à la gestion de la conversation : protocol,
conversation-id, reply with, in-reply-to, et reply-by. En pratique,
reply-with et in-reply-to sont peu utilisés, au profit
de conversation-id qui identifie globalement la conversation. Le
paramètre reply-to est essentiellement utilisé dans le
cas de courtage de type recrutement (protocole recruiting).
Remarque. Le protocole d'interaction est
référencé dans les messages, ainsi qu'un identifiant de la
conversation. Par contre, les rôles ne sont pas réifiés :
ils sont implicites, déduits du performatif du premier message
reçu par les participants, durant l'initialisation de la conversation.
La plupart des protocoles d'interactions de FIPA sont des dialogues. Le
rôle complémentaire est alors implicite, et sa réification
inutile, ce qui explique probablement pourquoi les standards actuels ne
réifient pas les rôles.
Pour modéliser correctement des SMA conversationnels
dans le cas général, nous ne pouvons imposer au
modélisateur de limiter les conversations à des dialogues ; les
conversations doivent pouvoir être multi-parties. Certaines tâches
collectives nécessitent en effet par essence plus de deux rôles. A
titre d'exemple, citons les protocoles de cryptographie et
d'établissement de clef et les enchères sécurisées.
Ces protocoles mettent souvent en jeu trois rôles ou plus, dont une
tierce partie de confiance, qui doit explicitement être distincte des
autres participants.
CHAP. 3. LES PROTOCOLES
D'INTERACTION FIPA-ACL
3.2. ANALYSES
Le tableau 3 donne les principaux protocoles d'interactions
spécifiés dans FIPA-ACL, ainsi que les performatifs initiant des
conversations équivalentes en KQML (qui ne définit pas à
proprement parler de protocoles d'interaction, mais associe à certains
performatifs un protocole implicite dont ils sont les premiers messages).
Tableau 3. Protocoles d'interaction standards de FIPA-
ACL
Source : Jouvin, Délégation de
Rôle et Architectures Dynamiques de systèmes Mullti-agents
conversationnels, Université Lyon I-Claude Bernard, Paris, Thèse
de Doctorat 2003.
Dans les sous-sections suivantes nous analyserons en
détail les principaux protocoles de cette liste.
a. Request et dérivés (Query et
Propose)
La figure 6 représente les protocoles FIPA-Request et
FIPA-propose en Agent UML. Ces différents protocoles suivent
tous un schéma d'exécution proche : ils sont composés
d'une requête initiale, suivie d'une réponse qui peut-être
soit un refus, soit une acceptation. L'acceptation est implicite dans le cas de
query, où le résultat est alors directement
renvoyé. Pour request, l'acceptation est suivie de la
notification du succès ou de l'échec dans la tâche
demandée. Pour propose, la tâche est seulement
négociée mais n'est pas effectuée dans le cadre de la
conversation.
Figure 5. FIPA-Request et
FIPA-Propose en Agent UML (tiré des spécifications de FIPA)
Redondance. Le diagramme de FIPA-Request illustre la remarque
de la section 3.1 a sur la redondance des rôles dans la
spécification globale du protocole. L'auteur semble avoir choisi de
représenter ici les alternatives du côté du participant. Ce
rôle stipule par exemple qu'un inform ne peut être
envoyé qu'après avoir envoyé un agree. La
définition du rôle d'initiateur, quant à elle, semble
accepter les messages dans n'importe quel ordre, sans aucune contrainte, ce qui
est inexact en réalité.
Le fait est que la notation condensée combinant
plusieurs réceptions de message sur une même ligne de vie ne
permet pas de relier les segments d'activation à d'autres segments
d'activation passés. En notation non condensée, il aurait
été possible de prolonger le segment suivant la réception
de agree, jusqu'à une alternative se séparation en trois
branches pour réceptionner les trois autres messages, ce qui aurait
permis d'exprimer que l'initiateur ne peut recevoir ces derniers
qu'après réception de agree.
En outre, du côté participant, l'auteur utilise
une condition de garde (agreed) pour exprimer cette même
contrainte. Il aurait été plus intuitif de la représenter
graphiquement, en utilisant des lignes de vie séparées, dont une
contiendrait le segment de l'envoi du agree qui se prolongerait alors
jusqu'à l'envoi de message complexe.
Exceptions. La spécification de ces protocoles inclut
explicitement l'envoi de notunderstood, qui correspond à une exception
du protocole. À l'inverse, d'autres protocoles plus complexes ne les
incluent pas. Il serait plus clair de choisir une ligne de conduite : soit
d'exclure systématiquement le traitement des exceptions de la
définition du protocole ; soit de l'inclure, mais d'utiliser une
notation plus synthétique, comme le propose Koning82(*).
b. Contract-Net et Iterated-Contract-Net
Figure 6. FIPA-Contract-Net et
FIPA-Iterated-Contract-Net en Agent UML
Le protocole Contract-Net, introduit par
Smith83(*), a
suscité beaucoup d'enthousiasme dans plusieurs domaines, dont les
systèmes multi-agents, car il reflétait une nouvelle vision
décentralisée de certains problèmes d'optimisation. En
soi, ce protocole est particulièrement simple, ce qui est aussi une
raison de son succès.
Dans FIPA-Contract-Net, L'initiateur divulgue à un
ensemble de participants un appel à proposition, CFP ; puis collecte les
propositions émises par les participants. Il choisi un gagnant, selon un
critère donné, et rejette les propositions des autres.
La figure 7 présente les diagrammes Agent UML de
Contract-Net, et de sa version itérative, Iterated-Contract-Net. Le
premier diagramme comporte une erreur sur les réceptions de failure,
inform et inform-ref, qui ne sont bien-sur pas successives : la ligne
d'activation devrait ici être divisée en 3 segments.
Boucle. Comme le montre la figure 7, Iterated-Contract-Net
boucle sur une sous-conversation de type Contract-Net, tant que l'initiateur
envoi des CFP. Dès lors qu'une des propositions est acceptée, ou
que toutes sont refusées, il se termine.
Parallélisme. Dans Iterated-Contract-Net, les messages
envoyés en parallèle après le branchement conditionnel
possèdent une clause d'ordonnancement dans le temps. Il me semble que
cela appelle la question suivante : pourquoi spécifier l'envoi
parallèle de messages, s'ils doivent être ordonnés dans le
temps ? Peut-être l'auteur du schéma a-t-il eu recours à ce
stratagème parce que la notation n'autorise pas la création d'une
nouvelle ligne d'activation après un envoi de message complexe.
c. English-Auction et Dutch-Auction
Figure 7. FIPA-English-Auction et
FIPA-Dutch-Auction en Agent UML
(tirés des spécifications FIPA)
Ces deux protocoles d'enchère de FIPA-ACL sont
intéressants car ils sont simples à appréhender
intuitivement, mais comportent plusieurs difficultés de
représentation et d'implémentation. La figure 8 en donne les
diagrammes Agent UML.
Le fonctionnement d'une enchère est proche de celui de
Iterated-Contract-Net, avec quelques nuances. Il s'agit de boucle
d'itérations comportant un appel à propositions (cfp), suivi de
propositions de la part des participants. Dans le cas de l'enchère
à l'anglaise, le prix va croissant, et la boucle continue tant que des
participants répondent en émettant au moins une proposition au
cfp. Pour l'enchère à la hollandaise, le prix est fixé
plus haut que le prix du marché, puis ce dernier va décroissant
à chaque itération. Au début aucun participant ne
répond, et l'enchère se termine dès qu'un ou plusieurs
participants proposent à une itération. L'enchère
hollandaise est à première vue plus avantageuse pour le vendeur,
car il a toutes les chances d'obtenir le meilleur prix des acheteurs.
Égalité : L'initiateur
départage les participants ayant proposés simultanément
à la dernière itération par l'envoi d'un accept
au vainqueur, et de reject pour les autres Time-out. Ces deux
protocoles sont basés sur un time-out à chaque
itération. Les participants ne sont pas obligés de signifier
qu'ils refusent un cfp, leur silence est un refus implicite. Ce time-out
introduit un état mixte, qui rend le protocole difficile à
implémenter.
Il est curieux de constater que ce time-out n'est pas
représenté sur les diagrammes dans les spécifications de
FIPA, alors qu'il est essentiel au protocole.
Nous pouvons noter que, tout comme contract-net, les deux
messages du dernier branchement parallèle sont agrémentés
d'une clause d'ordonnancement.
Cardinalités : Le message
request présente une cardinalité de 1, alors que celle
de inform est de n. L'interprétation intuitive est
qu'un inform est envoyé à tous les participants, le
vainqueur compris, indiquant la fin de l'enchère, puis un
request est envoyé uniquement au vainqueur.
- Soit nous considérons que toute cardinalité de
n (ou supérieures à 1) implique une réception
synchronisée de n messages ;
- Soit nous considérons séparément le
comportement induit par chaque participant, auquel cas une réception
multiple est par défaut non synchronisée, et les divergences de
comportement des participants sont représentées par des
alternatives. Il sera alors possible d'exprimer, dans l'enchère, que le
request ne sera envoyé qu'au vainqueur, à qui
l'initiateur a déjà envoyé accept.
d. Brokering et Recruiting
Les protocoles FIPA-Brokering et FIPA-Recruiting sont tous
deux directement inspirés de leurs équivalents dans KQML. Ils
constituent tous deux des actes de courtage, dont le principe
général est qu'un agent courtier, comparable à un
facilitateur, joue le rôle d'intermédiaire entre un agent
initiateur et les participants avec lesquels ce dernier souhaite interagir, le
courtier ayant pour tâche de trouver des participants adéquats.
L'utilité de ces protocoles dans les systèmes multi-agents a
été soulignée notamment par Finin et al. 84(*)
La figure 9 donne le diagramme de FIPA-Recruiting en
Agent UML. FIPABrokering est similaire, à ceci près que la
réponse du sous-protocole est d'abord reçu par le courtier
(broker) qui la retransmet à l'initiateur.
En FIPA-ACL l'initiateur va d'abord envoyer un message de type
proxy, dans lequel est imbriqué le premier message de la conversation
cible, et le profile des participants qu'il recherche. Puis le courtier va
rechercher des participants adéquats, mettre à jour les
destinataires du message imbriqué, et le transmettre aux participants.
Ensuite, la sous-conversation imbriquée va se dérouler (nous n'en
savons pas plus), puis les participants vont renvoyer soit au courtier, dans le
cas de Brokering, soit directement à l'initiateur, dans le cas de
Recruiting, une « réponse finale ».
Figure 8. FIPA-Recruiting en Agent
UML (Tiré des spécifications de FIPA)
Réponse et délégation. La
sémantique naïve de réponse ne s'applique à toute
sous conversation, en particulier si elle est multi-partie. Il se peut que le
protocole de cette conversation implique une participation beaucoup plus active
que l'attente d'une réponse de la part de l'initiateur. Dans le cas de
Recruiting, nous pouvons imaginer que la conversation va se poursuivre
entre l'initiateur (ou le destinator) et les participants, sans que le
courtier n'intervienne, ce qui règle le problème. Mais dans le
cas de Brokering, devons-nous considérer que le courtier va jouer le
rôle de l'initiateur dans la conversation imbriquée ? Ou bien
devons-nous considérer qu'il va rediriger chaque message à
l'initiateur, puis que l'initiateur lui renverra les réponses
intermédiaires, elles-mêmes imbriquées dans des messages de
type proxy, à renvoyer aux participants? La spécification ne
répond malheureusement pas à ces questions. Celle du performatif
proxy ne nous aide pas davantage.
3.3. ANALYSE ET INTEGRATION DU PROTOCOLE CONTRACT-NET
DANS LES REUNIONS D'ATTRIBUTIONS DES CHARGES HORAIRES AU DEPARTEMENT
D'INFORMATIQUE DE GESTION
3.3.1. Analyse du Protocol Contract-net
Le protocole Contract Net est le protocole d'interaction le
plus utilisé dans les systèmes multi-agents. Il repose sur un
mécanisme d'allocation de tâches régi par le protocole
d'appel d'offres qui est utilisé dans les organisations humaines. Ce
protocole est basé sur le rôle d'initiateur (appelé
Manager) et le rôle participant (voir figure 4.1) que nous
détaillons dans la suite de cette section.
a) Le rôle initiateur du Contract
Net
La figure 4.2 est un automate qui modélise
l'activité du rôle initiateur. L'initiateur commence par envoyer
un appel à proposition (cfp) qui contient la description de
l'action à exécuter et une expression de pré-condition
contenant un paramètre de proposition. Dans une extension de ce
protocole, on ajoute un Timeout pour éviter des attentes
infinies de l'initiateur. Le Timeout est indiqué dans
l'attribut reply-by du message Cfp.
Voici un exemple de message cfp issue de85(*). Dans ce message l'agent i
demande à l'agent j de lui faire une proposition pour la
vente de 50 prunes.
(cfp
: sender (agent-identifier : name i)
: receiver (set(agent-identifier :name j))
: content
"((action (agent-identifier :name j)
( sell plum 50))
( any ?x (and (= (price plum) ?x) (< ?x 10))))"
: ontology fruit-market
: langage fipa-sl)
Figure 9. Message cfp
Nous considérons que les actions de communication
(actions d'envoi ou de réception de messages) sont
génériques, elles sont supportées par l'agent qui joue le
rôle. La gestion de communication est une compétence de base de
l'agent, supportée par la majorité des plates formes
multi-agents. Les données nécessaires à la
préparation du message Cfp sont :
(i) la description de l'action à exécuter,
(ii) la pré-condition et
(iii) le(s) paramètre(s) de proposition.
Figure 10. Le rôle
initiateur du protocole FIPA Contract Net
Source : Tarek Jarraya, Réutilisation des
protocoles d'interaction et Démarche orientée modèles pour
le développement multi-agents, Université de Reims
Champagne-Ardenne, 8 décembre 2006.
Après la réception de toutes les propositions,
l'initiateur doit les évaluer pour en choisir une.
En cas d'utilisation de Timeout, l'évaluation
a lieu juste après son expiration, même si l'initiateur n'a pas
encore reçu toutes les réponses, qui sont au nombre des
participants moins les réponses Refuse reçues. Toute
proposition reçue, après l'expiration du Timeout, sera
automatiquement rejetée en envoyant un message Reject-proposal.
Dans certains cas, cette évaluation peut aboutir à un rejet total
de toutes les propositions. L'évaluation des propositions est une action
décisionnelle propre à chaque agent. De ce fait, elle doit
être considérée comme un paramètre du rôle.
Cette action décisionnelle est considérée comme une
boîte noire qui prend comme paramètre une liste de propositions et
qui peut retourner la proposition sélectionnée.
Dans le cas où une proposition est
sélectionnée, l'initiateur envoie un message Accept-proposal
au participant dont la proposition est acceptée et un message
Reject-proposal aux autres participants. A la fin de
l'interaction, l'initiateur reçoit de la part du participant un
Inform-done pour confirmer l'exécution de
l'action. Il peut recevoir à la place du Inform-done un
Inform-result qui contient le résultat retourné suite
à l'exécution de l'action.
L'activité du rôle peut se terminer par :
- un échec dans les cas suivants : (i)
l'initiateur ne reçoit aucune proposition, (ii) aucune proposition n'est
acceptée, ou (iii) l'initiateur reçoit un message
Failure,
- un succès, après la réception
du message Inform-done ou Inform-result.
D'après cette analyse nous pouvons dire que toutes les
actions et les décisions de ce rôle peuvent être
décrites de façon générique. Cependant, nous ne
constatons que l'exécution de ce rôle nécessite : (i) la
description de l'action à réaliser, (ii) la liste des agents
participants et
(iii) le processus d'évaluation des propositions
evaluate-Proposals.
b) Le rôle participant du
contract-net
La figure 4.3 est un automate qui modélise
l'activité du rôle participant. A la réception du
Cfp, le participant évalue son intérêt pour
l'action en fonction de ses ressources et de ses compétences. Si
l'action est intéressante, le participant formule une proposition en se
basant sur la description de l'action et l'expression de pré-condition,
qui est donnée dans le message Cfp. Le participant donne une
valeur au paramètre de proposition.
Voici un exemple de message propose issue de86(*). Dans ce message agent j
propose à agent i de lui vendre 50 prunes à 5$.
(cfp
: sender (agent-identifier : name j)
: receiver (agent-identifier :name i)
: content(
"((action j (sell plum 50))
(=(any ?x (and (= (price plum) ?x) (< ?x 10))) 5))"
)
: ontology fruit-market
: in-reply-to proposal2
: langage fipa-sl)
Figure 11. Message propose
Le participant peut aussi refuser de faire une proposition.
Pour ce faire, il envoie un message Refuse à l'initiateur.
L'action décisionnelle de faire une proposition Decide_to_Propose, est
considérée comme interne à l'agent. Elle prend comme
paramètres la description de l'action à exécuter ainsi que
l'expression de la pré-condition et peut retourner comme résultat
une proposition.
A la réception d'un Accept-proposal, le
participant s'engagera à exécuter l'action décrite dans le
Cfp sous les conditions définies dans l'expression de
pré-conditions et avec la proposition qu'il vient de soumettre.
L'exécution de l'action dépend des compétences et des
ressources de l'agent, elle ne fait pas partie de la description du rôle
d'interaction. Si le participant parvient à exécuter l'action,
alors il envoie un message Inform-done ou Inform-result
contenant le résultat de l'exécution de l'action. Si le
participant échoue dans l'exécution de l'action, alors il envoie
un message Failure contenant la raison de l'échec. Dans le cas
où le participant reçoit un message Reject-proposal, il
quitte l'interaction.
L'activité du rôle peut se terminer par un :
Figure 12. Le rôle
participant du protocole FIPA Contract Net
Source : Tarek Jarraya, Réutilisation des
protocoles d'interaction et Démarche orientée modèles pour
le développement multi-agents, Université de Reims
Champagne-Ardenne, 8 décembre 2006.
- échec, à la réception d'un
message Reject-proposal, ou l'envoie d'un message Failure.
- succès, après l'envoie du message
Inform-done ou Inform-result.
En résumé, l'activité de ce rôle
peut être décrite de façon générique.
Cependant, son exécution nécessite la spécification du
processus de construction de la proposition.
3.3.2. Intégration du Protocol Fipa contract- net
dans les réunions virtuelles d'attributions des charges horaires au
Département d'Informatique de Gestion.
3.3.2.1. Le rôle initiateur
Dans le cas de réunions d'attribution des charges
horaires au Département d'Informatique de Gestion. L'initiateur de la
réunion est le chef de Département.
a) Son rôle
Il commence par envoyer un appel à proposition (cfp)
à tous les membres du Département. Le détail de la
planification de la réunion contient les informations
suivantes :
- La définition du sujet ;
- La date de début ;
- La de fin ;
- L'ordre du jour.
La durée prévue et la date de début
interviennent dans ce Protocol dans le cadre d'extension. Ils sont
gérés par un TimeOut pour éviter des attentes
infinies de l'initiateur (le chef de Département).
( cfp
: sender(agent-identifier
: name Munguakonkwa cnet2@locallap
: adresse (sequence
Fipaos-rmi : //192.168.0.2 : 3000/cnet2
)
)
: receiver (Set
( agent-identifier
: name jm-proxy@locallap
: adresses (sequence
Fipa-rmi : // 192.168.0.3 : 3000 /cnet-proxy
)
)
)
: content (deal
: sujet attribution charge horaire
: date début 22 Octobre 2010
: date fin 25 Octobre 2010
: Agenda lecture pv, présentation désiderata,
adoption
)
: protocol fipa-contract-net
)
Voici l'exemple d'un message cfp87(*) dans lequel le chef de
Département (Agent i) demande à l'agent j (enseignant membre du
Département) de lui faire des propositions des désidératas
de leurs charges horaires.
Figure 13. Message cfp
envoyé par le chef de Département
Les données nécessaires à la
préparation du message Cfp sont :
- La description de l'action à
exécuter ;
- La pré-condition ;
- Les paramètres de proposition88(*)
RefusedProposal
RejectAllProposal
Un enseignant n'a pas envoyé ou a envoyé en
retard
Propose(Enseignant propose désidérata) dans le
délais
1
2
3
[ExpiredTimeOut] EvaluateProposals
Evaluation selon la date début et de fin
[AcceptProposal]
5
4
6
InformDone(l'enseignant envoie désidérata)
[Faillure]
Refuse (n'avoir pas réagi au cfp
[IsInitialised] sendForProposal
Le chef de Dpt envoie un cfp à tous les membres
+
+
Figure 14. Initiateur du Protocole
fipa contract-net
Dans cette intégration nous pouvons dire que toutes les
actions et les décisions de ce rôle peuvent être
décrites de façon générique. Cependant nous
constatons que l'exécution de ce rôle nécessite.
- La description de l'action à réaliser
- La liste des agents participants et
- Le processus d'évaluation des propositions
evalueteProposals
Nous remarquons aussi que le protocol fipa
contract-net s'arrête juste au niveau de l'acceptation du cfp
après le message inform-done ou inform-result du
participant.
Par ailleurs, pour les réunions d'attributions des
charges horaires, l'initiateur doit encore réaliser les rôles
suivants :
- Collecter toutes les désidératas des
enseignants confirmés par l'envoie d'un inform-done.
- Etablir la charge horaire de chaque enseignant ;
- Produire un état de sortie.
A notre niveau, nous pensons qu'il faut songer à
réifier les 3 autres rôles de l'initiateur pour pouvoir mener
à bout la modélisation de cette réunion virtuelle.
3.3.2.2. Le rôle de participant
Ici les participants sont les différents enseignants
membres du Département d'Informatique de Gestion. Leurs rôles
sont :
- Consulter les détails d'organisation de la
réunion (contenu dans le cfp de l'initiateur) ;
- La présentation des désidératas (en
réaction au cfp) à partir d'un inform-done ou
inform-result.
Voici un exemple de message propose dans lequel l'agent
(participant) présente un désidérata à l'agent j
(chef de Département).
(cfp
: sender (agent-identifier : participant)
: receiver (agent-identifier : chef de
Département)
: content (deal
: Nom de l'enseignant : Mungua
: Titre académique : Chef des Travaux
: Intitulé du cours : Programmation avec java
: Charge théorique : 30H
: Charge pratique : 30H
)
: in-reply-to proposal2
: protocol fipa-contract net
)
Figure 15. Message propose
envoyé par les membres du Département
Nous considérons que le participant (l'enseignant) ne
peut pas refuser de faire une proposition. Par contre l'initiateur peut
constater que le participant n'a pas réagi au cfp.
L'action décisionnelle de faire une proposition
Décide-to-Propose est considérée comme interne
à l'agent. Elle prend comme paramètre de la description de
l'action à exécuter ainsi que l'expression de la
pré-condition et peut retourner comme résultat une proposition du
désidérata de la charge horaire.
A la réception d'un Accept-proposal, le
participant s'engagera à exécuter l'action décrite dans
le cfp sous les conditions définies dans l'expression de
pré-condition et avec la proposition qu'il vient de soumettre.
L'activité du rôle peut se terminer par
un :
- Echec à la réception d'Echec à la
réception d'un Reject-proposal ou l'envoie d'un message
Faillure
- Succès, après l'envoie du message
infor-done ou inform-resultat.
En résumé, l'activité de ce rôle
peut être décrite de façon générique.
Cependant, son exécution nécessite la spécification du
processus de construction de la proposition.
1
2
3
[AcceptToPropose] SendPropose
L'enseignant envoie son désidérata
[RejectProposal]
Envoie en retard
6
4
[Faillure]
Refuse ToPropose
[CallForProposol] Decide-to-Propose
L'enseignant décide d'envoyer son désiderata
5
[Successl]/ SendInformDone
AcceptProposal/
PerformContract
Le chef de Dpt accepte le désidérata
Figure 16. Participant du
Pritocole fipa contract-net
fii
Initiateur
Participant
Le chef de Dpt envoie un cfp qui comprend le sujet, date
début et fin...
Refuse le cfp (l'enseignant ne réagi pas au cfp
du chef de Dpt)
Propose (l'enseignant accepte de proposer son
désidérata
Reject-proposal (l'initiateur refuse la proposition pour
avoir été envoyé en retard
Accept-proposal (l'initiateur accepte le
désidérata de l'enseignant
Faillure
Inform-done
Inform-result
Protocol Fipa Contract-net
Figure 17. Diagramme du
protocole Fipa de Modélisation des réunions virtuelles
d'attribution des charges horaires
CHAP.4. MISE EN PLACE D'UN
SERVEUR DES REUNIONS VIRTUELLES
4.1. MODELISATION DES
REUNIONS VIRTUELLES AVEC UML
4.1.1. Elaboration d'un cahier
de charge
Cahier de charge
· Il s'agit de réaliser la partie serveur d'une
application client-serveur permettant de faire des réunions virtuelles
multimédia sur Internet. L'objectif de cette application est de
permettre d'imiter le plus possible le déroulement de réunions
d'attribution des charges horaires au Département d'Informatique de
Gestion. Cependant, dans ce travail, les interventions des participants se
feront en mode mono-média seulement (i.e. échanges en forme
textuelle).
· Le serveur devra permettre de planifier et de
gérer le déroulement des réunions.
· Après s'être connecté au serveur
(à l'aide d'un nom de login et d'un mot de passe mémorisé
par le système), une personne a la possibilité de planifier des
réunions virtuelles (choix d'un nom, définition du sujet, date de
début et durée prévue, ordre du jour), de consulter les
détails d'organisation d'une réunion, de présenter des
désidérata relative à la charge horaire , de
collectionner toutes les désidératas des membres du
Département, d'établir une charge horaire pour chaque enseignant,
d'ouvrir et de clôturer une réunion (seulement l'animateur), En
cours de réunion, un participant peut demander à prendre la
parole. Quand elle lui est accordée, il peut entrer le texte d'une
intervention qui sera transmise en « temps-réel »
par le serveur à tous les participants de la réunion.
4.1.2. Démarche de
Modélisation
UML présente 9 diagrammes principaux. Ces diagrammes
sont utilisés dans les différents processus de
développement du système de la manière suivante :
Dans la découverte du besoin du
système :
- Le diagramme de cas d'utilisation
- Le diagramme de séquence
Dans l'analyse :
- Diagramme de classe
- Diagramme d'objets
- Diagramme d'états-transition
- Diagramme de collaboration
- Diagramme d'activités
Dans la conception
- Diagramme de séquence
- Diagramme de déploiement89(*)
Dans ce travail nous utiliserons seulement les diagrammes
suivants pour la modélisation de notre projet :
ü Construction du diagramme de cas d'utilisation
ü Construction du diagramme de séquence et de
collaboration
ü Construction du diagramme de classe
ü Généralisation à l'aide du
diagramme d'états-transitions
4.1.3. Construction du diagramme de cas
d'utilisation
Bien souvent, la maîtrise d'ouvrage et les utilisateurs
ne sont pas des informaticiens. Il leur faut donc un moyen simple d'exprimer
leurs besoins. C'est précisément le rôle des diagrammes de
cas d'utilisation qui permettent de recueillir, d'analyser et d'organiser les
besoins, et de recenser les grandes fonctionnalités d'un système.
Il s'agit donc de la première étape UML d'analyse d'un
système.
Un diagramme de cas d'utilisation capture le comportement d'un
système, d'un sous-système, d'une classe ou d'un composant tel
qu'un utilisateur extérieur le voit. Il scinde la fonctionnalité
du système en unités cohérentes, les cas d'utilisation,
ayant un sens pour les acteurs. Les cas d'utilisation permettent d'exprimer le
besoin des utilisateurs d'un système, ils sont donc une vision
orientée utilisateur de ce besoin au contraire d'une vision
informatique.
Présentation désidérata
Consultation
Planification
Animation
EntréeSortie
Tous les cas d'utilisation utilisent la
connexion
Collection désidérata
Connexion
Etablir charges horaires
<<Extend>>
<<Include >>
<<Include >>
<<Include >>
<<Include >>
<<Include >>
<<Include >>
ServeurRéunion
Organisateur
Participant
Figure 18. Diagramme de cas
d'utilisations
Exemple de cas d'utilisation : Planification
La planification d'une réunion virtuelle est
effectuée par une personne jouant le rôle d'organisateur pour
cette réunion. Ceci consiste à faire le choix d'un nom, la
définition du sujet, de la date de début et la durée
prévue, ainsi que l'ordre du jour.
4.1.4. La construction du diagramme de classe
Le diagramme de classes est considéré comme le
plus important de la modélisation orientée objet, il est le seul
obligatoire lors d'une telle modélisation.
Le diagramme de classes modélise les concepts du
domaine d'application ainsi que les concepts internes créés de
toutes pièces dans le cadre de l'implémentation d'une
application. Chaque langage de Programmation Orienté Objets donne un
moyen spécifique d'implémenter le paradigme objet (pointeurs ou
pas, héritage multiple ou pas, etc.), mais le diagramme de classes
permet de modéliser les classes du système et leurs relations
indépendamment d'un langage de programmation particulier90(*).
a) Représentation graphique d'une
classe
Figure 19
Représentation UML d'une classe
Une classe est un classeur. Elle est
représentée par un rectangle divisé en trois compartiments
(figure 19). Le premier indique le nom de la classe, le deuxième ses
attributs et le troisième ses opérations.
b) Processus de construction du diagramme de
classe
· Identifier les classes d'objets
o Garder les bonnes classes
o constitution du dictionnaire de données
· Identifier les associations.
o Garder les bonnes associations
· Identifier les attributs.
o Garder les bons attributs
· Raffiner au moyen de l'héritage
o Généralisations et raffinages
· Itérer la modélisation
· Grouper les classes en modules91(*)
Réunion
Nom : String
Sujet : String
DateDébut : Date
Datefin : Int
Agenda : String
Participe
* 1
1 *
*
Enseignant
Nom
Postnom
FonctionAc
TitreAc
Cours
Intitulé
HeureThéorique
HeurePratique
AnnéeEtude
Promotion
Organise
1
Dispense
Figure 20. Diagramme de classe
Commentaires :
Enseignant : plusieurs
Enseignants participe à une réunion.
Un enseignant dispense plusieurs cours.
Un enseignant organise plusieurs réunions.
4.1.5. Diagramme des séquences
Le diagramme de séquence modélise les
interactions entre objets suite à un événement externe.
L'aspect temporel y est pris en compte et permet de distinguer les messages
asynchrones des messages synchrones.
Les principales informations contenues dans un diagramme de
séquence sont les messages échangés entre les lignes de
vie, présentés dans un ordre chronologique. Ainsi, contrairement
au diagramme de communication, le temps y est représenté
explicitement par une dimension (la dimension verticale) et s'écoule de
haut en bas.
Représentation des messages
Un message
définit une communication particulière entre des lignes de vie.
Plusieurs types de messages existent, les plus communs sont :
· l'envoi d'un signal ;
· l'invocation d'une opération ;
· la création ou la destruction d'une instance.
Message
asynchrone
Figure 21. Représentation d'un message
asynchrone
Messages synchrones
Figure 22.
Représentation d'un message synchrone
a) Cas d'utilisation
« connexion »
Connexion Erroné
Connexion Nominale
ServeurRéunionVirtuelle
Connecte (« jm »)
Erreur (déjà connecté)
Jm : Enseignant
Connecte
Erreur (déjà connecté)
Jm : Enseignant
ServeurRéunionVirtuelle
Connecte (« jm »)
Connecté
Connecte
Ok
Utilisateur Utilisateur
Connexion Nouvelle
Jm : Enseignant
ServeurRéunionVirtuelle
Connecte (« jm »)
Connecté
Connecte
Ok
Utilisateur
Figure 23. Diagramme de
séquence du cas d'utilisation connexion
b) Cas d'utilisation Planification
Planifier réunion
ServeurRéunionVirtuelle
Planifie (« R1 »
« avancement »
« 09/09/10-10 :22 », 1,
« divers »)
Ok
Make (r1)
SetAsOrganisateur (r1)
Jm : Enseignant
r1 : réunion
Jm : organisateur
Figure 24. Diagramme de
séquence du cas d'utilisation planification
c) Cas d'utilisation Animation
ServeurRéunionVirtuelle
Ouvre (« Réunion »)
ok
r1 : réunion
Ferme (« Réunion »)
Ok
Ouvre (jm)
ferme (jm)
Jm : Personne
Jm : Animateur
Figure 25. Diagramme de
séquence du cas d'utilisation Animation
d) Cas d'utilisation EntréeSortie
EntréeSortieNominal
ServeurRéunionVirtuelle
Entre (« Réunion »)
r1 : réunion
ok
Jm : Personne
Ok
Entre(Munga)
sort(Munga)
Sort(« Réunion»)
Mungua : Participant
Figure 26. Cas d'utilisation
entrée-sortie
Mungua : Utilisateur
e) Cas d'utilisation Présentation
désidérata
Jm : Enseignant
ServeurRéunionVirtuelle
Présente
Présentation désidérata (int. Cours, total
heures...)
Ok
Présenté
Figure 27. Cas d'utilisation
présentation désidérata
4.1.6. Diagramme d'états-transition
Les diagrammes d'états-transitions d'UML
décrivent le comportement interne d'un objet à l'aide d'un
automate à états finis. Ils présentent les
séquences possibles d'états et d'actions qu'une instance de
classe peut traiter au cours de son cycle de vie en réaction à
des événements discrets (de type signaux, invocations de
méthode).
Ils spécifient habituellement le comportement d'une
instance de classeur (classe ou composant), mais parfois aussi le comportement
interne d'autres éléments tels que les cas d'utilisation, les
sous-systèmes, les méthodes. Le comportement est
modélisé par un graphe dans lequel les noeuds représentent
les états possibles des objets et les arcs représentent les
transitions d'état à été.
Une transition, c'est l'exécution d'une action. C'est
la réaction de l'objet sous l'effet d'une occurrence
d'événement qui le f ait passé d'un état à
un autre.
a) Diagramme d'états-transition :
Réunion
Planifiée
Ouverture
Fermée
Planifier(p)[p=o
ganisateur]
Ouvrir(p)[p=animateur]
sortir(p)[participe(p)]
clôturer(p)[p=animateur]]
Planifier(p)
Entrer(p)[autorisé(p)]
Figure 28. Diagramme
d'états-transition réunion
b) diagramme d'états-transition :
Enseignant
En Réunion
Entrer(r)
Déconnecte
Déconnecte
Connecté
Connecte (passwd)
Déconnecté
Connecte (passwd)
Passif
Parlant
DemandeParole
Attente
Relâche
Termine
Accorde Parole
Détruire
Figure 29. Diagramme
d'états-transitions : enseignant
4.2. LE MODELE ORIENTE
CLIENT-SERVEUR
4.2.1. Concepts de base sur
le client-serveur
ú Un client est un processus (programme) qui demande
des services au serveur en lui envoyant des requêtes.
ú Un serveur est un processus qui rend des services aux
processus clients en exécutant leurs requêtes.
4.2.2. Paquetages
nécessaires
ú java.net : paquetage nécessaire pour les
fonctionnalités réseaux : il nous fournira les classes Socket qui
permet à un client de se connecter à un serveur et
ServerSocket qui permet au serveur de se lancer
ú java.io : paquetage important pour la création
des flux E/S
ú Il nous fournira les classes BufferedReader
pour créer un flux d'entrée et PrintWriter pour
créer un flux de sortie.
ú java.sql: paquetage important pour la création
la connexion aux BD et leur manipulation à l'aide des requêtes
sql. Il nous fournit les classes
ú java.awt ou java.swing: paquetages importants pour la
création des interfaces graphiques utilisateurs
ú java.awt.event: paquetage important pour les
événements avec les GUI
4.2.3. Structure d'un
client
ú Un client commence par se connecter au serveur. Il
doit donc préciser l'adresse IP ou le nom de la machine ainsi que le
numéro du port dans lequel officie le serveur:
new Socket(« IP du serveur »,
port);
ú Création des flux d'entrée :
New BufferedReader(new
InputStreamReader(Socket.getInputStream()));
ú Création des flux de sortie :
new PrintWriter(Socket.getOutputStream(),
true);
ú Formulation de la requete
String requete = « .... »;
ú Envoi de la requête au serveur par un flux de
sortie
PrintWriter.println(requete);
ú Formulation de la requête
String requete = « .... »;
ú Envoi de la requête au serveur par un flux de
sortie
PrintWriter.println(requete);
4.2.4. Structure d'un serveur
ú Le serveur commence par se lancer sur un port
précis;
new ServerSocket(port);
ú Se met à l'attente (écoute) des
connexions clientes
Socket = Serveur.accept();
ú Confie la connexion cliente reçue à un
service
new Service(socket du client).start();
4.2.5. Structure d'un
service
ú Le service reçoit la connexion cliente lui
confiée par le serveur
ú Crée les flux de communication avec le
client
ú Lit la requête à travers un flux
d'entrée
ú Traite la requête du client
ú Envoie le résultat à travers un flux de
sortie au client.
4.2.5. JDBC
ú Java DataBase Connectivity
ú Création de l'interface JDBC-ODBC :
Class.forName(« sun.jdbc.odbc.JdbcOdbcDriver»);
ú Connexion à une source de donnée
Connection=
DriverManager.getConnection(« jdbc:odbc:source de
donnée »,
« user », « password »);
ú Création d'un objet de la classe Statement
pour l'exécution des requêtes sql
Statement= Connection.createStatement();
ú Exécution d'une requête
d'écriture
int nbEnreg =
Statement.executeUpdate(« requête sql »);
ú Exécution d'une requête
d'interrogation
ResultSet =
Statement.executeQuery(« requête sql »);
4.2.6. Architecture d'une
application JDBC92(*)
JDBC permet de développer des programmes Java clients
(applications autonomes, applets, composants dans applications N-tiers) qui
accèdent à des SGBD
Figure 30. Architecture d'une
application Jdbc
4.2.7. Architecture
client-serveur93(*)
Client-serveur : un programme client s'adresse à un
programme sur une machine distante (le serveur) pour échanger des
informations et des services.
Figure 31. Architecture
client-serveur
Programme client ne communique pas directement avec SGBD
· Sur le poste client : interface client du SGBD qui
gère le protocole de communication spécifique au SGBD
· Sur le poste serveur : interface serveur du SGBD
qui gère les connexions avec les différents clients.
4.2.1. Création d'une
source des données
ú Ouvrir le panneau de configuration
ú Double-cliquer Outils d'administration
ú Dans Outils d'administration, double-cliquer Source
de données (ODBC)
ú Dans la fenêtre Sources de données
(ODBC), cliquez sur le bouton Ajouter
ú Choisissez le pilote ODBC utilisé pour la BD
Cliquer sur Sélectionner...
ú Sélectionnez la BD et cliquez sur OK
4.4. PRESENTATION DE
NOTRE APPLICATION EN RESEAU LOCAL
a) Matériel utilisé
Pour que notre application tourne en réseau
nécessite les matériels suivants :
- Les ordinateurs : Il nous faux des
ordinateurs capables des biens tourner le système d'exploitation Windows
2000, XP capable de communiquer dans réseau à partir d'un
serveur central.
- Les câbles : Il nous faut des
câbles coaxiaux à paire torsadée avec un connecteur de
type Rj45.
- Switch et/ou un Hub : Les
câbles droits seront reliés à un concentrateur (HUB) ou
à un répartiteur (SWITCH).
- Protocole TCP/IP : un protocole
standard pour tous les réseaux et plates-formes. Les données
sont envoyées en paquet et réassemblées à leur
réception, avec capacité de résister aux attaques
nucléaires.
L'adresse IP est un ensemble de 4 octets
séparés par des points (dans sa version e). Chaque octet peut
voir sa valeur aller de 0 à 255. Une adresse IP sera donc de la forme
XXX.XXX.XXX.XXX. Exemple :
192.168.0.1.
Il existe des adresses IP dites routables, et d'autres dites
non routables. Une adresse IP routable non routable cantonnera l'usage de
votre ordinateur au réseau local. 192.168.0.1 est un adresse IP non
routable, il n'existe donc aucun ordinateur utilisant l'adresse IP 192.168.0.1
directement relié à internet, il passera toujours par un
fournisseur d'accès lui fournissant une adresse IP routable94(*).
Pour affecter une adresse IP à chaque ordinateur il
faut procéder comme suit :
- Cliquer sur Panneau de configuration /Centre réseau
et partage
- Cliquer Gérer les connexions réseau
- Cliquer sur connexion au réseau local, puis sur
propriété
- Cliquer sur protocole internet version 4 (TCP/IPV4).
ü Ordinateur n°1
Adresse IP : 192.168.0.1
Masque de sous réseau : 255.255.255.0
ü Ordinateur n°2
Adresse IP : 192.168.0.2
Masque de sous réseau : 255.255.255.0
ü Ordinateur n°3
Adresse IP : 192.168.0.3
Masque de sous réseau : 255.255.255.0
ü ....
4.3. QUELQUES LIGNES DE
NOTRE CODE SOURCE ECRIT EN JAVA
4.3.1. Le fichier serveur
import java.net.*; // fonctionnalités réseau
public class Serveur{
public static void main(String[] args){
// 1. Lancement du serveur
for (; ; ){
ServerSocket sckEcoute = null;
try{
sckEcoute = new ServerSocket(1500);
} catch (Exception e){
System.out.println("Echec lancement serveur :\n" +e);
System.exit(0);
}
// 2. écoute de la connection du premier client
Socket conCliente = null;
boolean boucle = true;
while(boucle){
try{
conCliente = sckEcoute.accept();
new Service(conCliente).start();
} catch (Exception e){
boucle = false;
System.out.println("Echec connection cliente :\n" +e);
}
}
}
} //fin main
}
4.3.2. Le fichier service
import java.net.*;
import java.sql.*;
import java.io.*;
public class Service extends Thread{
Socket sck = null;
Connection con = null; // connexion à la BD
Statement stat = null; // exécution des cd sql
ResultSet rs = null; // pour recueillir les rsultats de la
consultation
ResultSetMetaData rsmd=null; // info sur resultset
String requete;
String requete1;
ResultSet rs1 = null;
Statement stat1 = null;
BufferedReader bfrd = null;
PrintWriter prtw = null;
public Service(Socket s){
sck = s;
}
/*
La méthode run est obligatoire dans une classe Thread.
c'est elle qui est exécutée
lors de l'invocation d'un thread par la laméthode
start()
*/
public void run(){
try{
bfrd = new BufferedReader(new
InputStreamReader(sck.getInputStream()));
prtw = new PrintWriter(sck.getOutputStream(),true);
} catch (Exception e) {
System.out.println("erreur creation flux \n" +e);
System.exit(0);
}
// 2. lire la reque du client
try{
requete = bfrd.readLine();
} catch (Exception e){
System.out.println("erreur lecture requete \n" +e);
System.exit(1);
}
// 3. analyser la requete cliente
String lettre1 = "";
lettre1 = requete.substring(0,1);
// 4. Appel de la méthode d'écriture pour une
requete d'écriture
if(lettre1.equals("i")) insertion();
else{
// 5. Appel de la méthode de consultation pour une
requete de consultation
consultation();
//chargecommun();
//suppression();
}
}
// Mthode d'écriture
public void insertion(){
connexion();
try{
int nbEnreg = stat.executeUpdate(requete);
} catch (Exception e){
System.out.println(e);
System.exit(1);
}
}
// méthode de suppression
public void suppression(){
connexion();
try{
int nbEnreg = stat.executeUpdate(requete);
} catch (Exception e){
System.out.println(e);
System.exit(1);
}
}
// Méthode de consultation
public void consultation(){
// connexion à la base
connexion();
try{
// exécuter la requete
rs = stat.executeQuery(requete);
//rs = stat.executeQuery(requete1);
// exploitation du rs
ResultSetMetaData rsmd = rs.getMetaData();
int nbCol = rsmd.getColumnCount();
while(rs.next()){
for(int i=1; i<=nbCol; i++){
prtw.println(rs.getString(i));
}
}
}catch(Exception e){
System.out.println(e);
System.exit(2);
}
}
// Consultation charge commun
}
4.3.3. Le fichier
Planification
import java.awt.*; // interface graphique
import java.applet.*; // Fonctionnalités applet
import javax.swing.*; // interface
import java.awt.event.*; // événements
import java.net.*; // aspect réseau
import java.sql.*;
import java.io.*; // envoi des requêtes et
réception
public class Planification extends Applet implements
WindowListener {
// attributs de la planifcation de la réunion
private String nom, sujet, agenda, datedebut;
private String datefin;
// objets graphiques globaux
TextField txnom=new TextField ();
TextField txsujet=new TextField ();
TextField txagenda=new TextField ();
TextField txdebut=new TextField ();
TextField txduree=new TextField ();
public Insets getInsets() {
Insets normal = super.getInsets();
return new Insets(normal.top + 60, normal.left + 40,
normal.bottom +40, normal.right + 40);
}
public void init(){
setSize(400, 300); // taille de l'applet
GridLayout gr=new GridLayout (5,2);
setLayout(gr); //disposition de l'applet
// Titre de l'applet
Label lbTitre = new Label("Planification réunion");
Font f = new Font("arial", Font.BOLD, 30);
lbTitre.setFont(f);
lbTitre.setBounds(5, 20, 350, 50); add(lbTitre);
Panel centre=new Panel(); add("Center",centre);
//GridLayout gr=new GridLayout (5,2);
centre.setLayout (gr);
centre.add(new Label ("Nom"));
centre.add(txnom);
centre.add(new Label ("Sujet"));
centre.add(txsujet);
centre.add(new Label ("Agenda"));
centre.add(txagenda);
centre.add(new Label ("DateDebut"));
centre.add(txdebut);
centre.add(new Label ("DateFin"));
centre.add(txduree);
Font f1=new Font("arial",Font.BOLD,14);
centre.setFont(f1);
centre.getInsets();
Panel sud=new Panel(); add("south",sud);
Button bt1=new Button("Envoyer");
Button bt2=new Button("Annuler");
Button bt3=new Button("VoirDésidérata");
sud.add(bt1);
sud.add(bt2);
sud.add(bt3);
sud.getInsets();
//
bt1.addActionListener( //gestion du bouton envoyer
new ActionListener(){
public void actionPerformed(ActionEvent e){
appelServeur(e);
}
}
);
bt2.addActionListener(// gestion du bouton annuler
new ActionListener(){
public void actionPerformed(ActionEvent e){
txnom.setText(null);
txsujet.setText(null);
txagenda.setText(null);
txdebut.setText(null);
txduree.setText(null);
}
}
);
bt3.addActionListener(
new ActionListener(){
public void actionPerformed(ActionEvent e){
Dimension dim=getSize();
String[]
message={""+dim.width,""+dim.height,"mess1","mess2","mess3"};
ChargeHoraire.main(message);
}
});
}//fin de la methode init
public static void main(java.lang.String[] args) {//ces methodes
en dessous m'on permis de tourner
Planification applet = new Planification();//une applet dans
une application
Frame frame = new Frame("Planification de la
réunion");
frame.addWindowListener(applet);
frame.add("Center", applet);
frame.setSize(500, 700);
frame.show();
applet.init();
applet.start();
}
public void windowActivated(WindowEvent e) { } //
public void windowClosed(WindowEvent e) { }
public void windowClosing(WindowEvent e) {
System.exit(0);
}
public void windowDeactivated(WindowEvent e) { }
public void windowDeiconified(WindowEvent e) { }
public void windowIconified(WindowEvent e) { }
public void windowOpened(WindowEvent e) { }
public void appelServeur(ActionEvent evt){
// 1. récupérer les données de
l'interface
nom = txnom.getText(); sujet = txsujet.getText();
agenda = txagenda.getText(); datedebut = txdebut.getText();
datefin = txduree.getText();
// 2. construire la requete sql d'enregistrement
String requete = "insert into reunion ( nom, sujet, agenda,
datedebut,datefin) values ('"+nom+"', '"+sujet+"', '"+agenda+"',
'"+datedebut+"', '"+datefin+"')";
// 3. se connecter au serveur
Socket sck = null; // pour la connection cliente au
réseau (serveur)
try{
sck = new Socket("127.0.0.1", 1500);
} catch (Exception e){
JOptionPane.showMessageDialog(
null,
"erreur : " + e, "connexion au serveur",
JOptionPane.ERROR_MESSAGE
);
}
// 4. créer le flux d'envoi de la requete
PrintWriter prtw = null; // flux d'envoi de données
try{
prtw = new PrintWriter(sck.getOutputStream(), true);
} catch (Exception e){
JOptionPane.showMessageDialog(
null,
"erreur : " + e, "création flux sortie",
JOptionPane.ERROR_MESSAGE
);
}
// 5. envoyer la requete au serveur
prtw.println(requete);
} // fin appelServeur
}
Le fichier charge horaire
import java.awt.*; // interface graphique
import java.applet.*; // Fonctionnalités applet
import javax.swing.*; // interface
import java.awt.event.*; // événements
import java.net.*; // aspect réseau
import java.sql.*;
import java.io.*; // envoi des requetes et reception
public class ChargeHoraire extends Applet implements
WindowListener{
// attributs de présentation des
désidérata de la charge horaire
private String enseignant, titreac,intitule,
chargetheorique,chargepratique,intitulesel;// ils sont String
// car je ne pas su comment obtenir int dans dans textField
//
// objets graphiques globaux
Choice txenseignant=new Choice ();
Choice txtitreac=new Choice ();
TextArea txintitule=new TextArea();
//TextArea txintitulesel=new TextArea();
TextArea txDesCom=new TextArea();
/*//TextField txchargetheorique=new TextField();
//TextField txchargepratique=new TextField();
//création des espaces entre composants et le bord de la
fenêtre
public Insets getInsets() {
Insets normal = super.getInsets();
return new Insets(normal.top + 60, normal.left + 40,
normal.bottom +40, normal.right + 40);
}
public void init(){
BorderLayout br=new BorderLayout();
setLayout(br);
Panel haut=new Panel(); add("North",haut);
Panel centre=new Panel(); add("Center",centre);
Panel bas=new Panel(); add("South",bas);
Panel ouest=new Panel(); add("West",ouest);
Panel est=new Panel(); add("East",est);
GridLayout gr=new GridLayout(3,2,5,10);
GridLayout gr2=new GridLayout(4,2,0,0);
FlowLayout gr3=new FlowLayout(FlowLayout.RIGHT,150,5);
haut.setLayout(gr);
haut.add(new Label("Enseignant"));
haut.add(txenseignant);
txenseignant.addItem("KYENDA SULIKDA D.");
txenseignant.addItem("KASELE Léandre");
txenseignant.addItem("TASHO KASONGO");
txenseignant.addItem("BULABULA DEMA");
txenseignant.addItem("LUNANGA MANIX");
txenseignant.addItem("MERDA NZIBO");
txenseignant.addItem("BANYAKWAChristophe");
txenseignant.addItem("KAMPEMEP Damien");
txenseignant.addItem("WAIL ILUNDU");
txenseignant.addItem("KUTANGILA David");
txenseignant.addItem("...");
haut.add(new Label("TitreAc"));
haut.add(txtitreac);
txtitreac.addItem("Professeur Ordinaire");
txtitreac.addItem("Professeur ");
txtitreac.addItem("Professeur Associé");
txtitreac.addItem("Chef des travaux");
txtitreac.addItem("Assistants");
txtitreac.addItem("CPP");
txtitreac.addItem("...");
/*haut.add(new Label("Charge Théorique"));
haut.add(txchargetheorique);
haut.add(new Label("Charge Pratique"));
haut.add(txchargepratique);
//haut.add(cb1);
//haut.add(cb2);
//haut.add(cb3);*/
haut.getInsets();
ouest.setLayout(gr2);
ouest.add("West", new Label("
Désidérata/Enseigant "));
ouest.add("West",txintitule);
centre.setLayout(gr2);
centre.add("Center", new Label("
Désidérata/Commun "));
centre.add("Center",txDesCom);
//est.setLayout(gr2);
//est.add("Center", new Label(" Charge Horaire "));
//est.add("Center",txintitulesel);
//est.setLayout(br);
Button commun=new Button ("DesCommun");
Button Ajout=new Button ("Ajouter");
Button Delete=new Button ("Delete");
Button EtatSortie=new Button ("EtatSortie");
bas.setLayout(gr3);
bas.add(commun);
bas.add(Ajout);
bas.add(Delete);
//bas.add(EtatSortie);
Ajout.addActionListener(
new ActionListener(){
public void actionPerformed(ActionEvent e){
Dimension dim=getSize();
String[]
message={""+dim.width,""+dim.height,"mess1","mess2","mess3"};
Horaire.main(message);
}
});
commun.addActionListener(
new ActionListener(){
public void actionPerformed(ActionEvent e){
chargecommun(e);
}
}
);
txenseignant.addItemListener(
new ItemListener (){
public void itemStateChanged(ItemEvent e) {
Object obj = e.getItem();
String selection = (String)obj;
System.out.println(1);
//showStatus("choix : "+selection);
if (selection== "KYENDA SULIKDA D."){
// chargecommun(e);
consultation(e);
}
if (selection== "KASELE Léandre") consultation(e);
if (selection== "TASHO KASONGO") consultation(e);
if (selection== "BULABULA DEMA") consultation(e);
if (selection== "LUNANGA MANIX") consultation(e);
if (selection== "MERDA NZIBO") consultation(e);
if (selection== "BANYAKWAChristophe") consultation(e);
if (selection== "KAMPEMPE Damien") consultation(e);
if (selection== "KUTANGILA David") consultation(e);
System.out.println(" choix : "+selection);
}
}
);
Delete.addActionListener(
new ActionListener(){
public void actionPerformed(ActionEvent e){
Dimension dim=getSize();
String[]
message={""+dim.width,""+dim.height,"mess1","mess2","mess3"};
Delete_Info.main(message);
}
});
}// fin de la méthode init
public void consultation(ItemEvent itm){
// 2. construire la requete sql d'enregistrement
System.out.println(1);
String requete = "select * from chargehoraire order by
enseignant";
// 3. se connecter au serveur
Socket sck = null; // pour la connection cliente au
réseau (serveur)
try{
sck = new Socket("127.0.0.1", 1500);
} catch (Exception e){
JOptionPane.showMessageDialog(
null,
"erreur : " + e, "connexion au serveur",
JOptionPane.ERROR_MESSAGE
);
}
// 4. créer le flux d'envoi de la requete
PrintWriter prtw = null; // flux d'envoi de données
BufferedReader bfrd = null;
try{
prtw = new PrintWriter(sck.getOutputStream(), true);
bfrd = new BufferedReader(new
InputStreamReader(sck.getInputStream()));
} catch (Exception e){
JOptionPane.showMessageDialog(
null,
"erreur : " + e, "création flux sortie",
JOptionPane.ERROR_MESSAGE
);
}
// 5. envoyer la requete au serveur
prtw.println(requete);
boolean boucle = true;
for (int j=0;j<=15;j++){
try{
for(int i=1; i<=6; i++){
txintitule.append(bfrd.readLine()+ "\t");// reception de la
reponse du serveur et les affiche d
// dans une zone de texte
}
txintitule.append("\n");
}catch(Exception e){
//boucle = false;
}
}
} // fin consultation
public void chargecommun(ActionEvent itm){
// 2. construire la requete sql d'enregistrement
String requete = " select enseignant,intitule,promotion from
chargehoraire where 'intitule'='intitule' AND 'promotion'='promotion' order by
intitule «;
// 3. se connecter au serveur
Socket sck = null; // pour la connection cliente au
réseau (serveur)
try{
sck = new Socket("127.0.0.1", 1500);
} catch (Exception e){
JOptionPane.showMessageDialog(
null,
"erreur : " + e, "connexion au serveur",
JOptionPane.ERROR_MESSAGE
);
}
// 4. créer le flux d'envoi de la requete
PrintWriter prtw = null; // flux d'envoi de données
BufferedReader bfrd = null;
DataInputStream dis=null;
try{
prtw = new PrintWriter(sck.getOutputStream(), true);
bfrd = new BufferedReader(new
InputStreamReader(sck.getInputStream()));
//dis=new DataInputStream(bfrd);
} catch (Exception e){
JOptionPane.showMessageDialog(
null,
"erreur : " + e, "création flux sortie",
JOptionPane.ERROR_MESSAGE
);
}
// 5. envoyer la requete au serveur
//prtw.println(requete);
prtw.println(requete);
boolean boucle = true;
for (int j=0;j<=6;j++){
try{
for(int i=1; i<=6; i++){
txDesCom.append(bfrd.readLine()+ "\t");// reception de la
reponse du serveur et les affiche d
// dans une zone de texte
}
txDesCom.append("\n");
}catch(Exception e){
//boucle = false;
}
}
System.out.println(1111111);
}
public static void main(java.lang.String[] args) {//ces methodes
en dessous m'on permis de tourner
ChargeHoraire applet = new ChargeHoraire();//une applet dans
une application
Frame frame = new Frame("Collection
désidérata");
frame.addWindowListener(applet);
frame.add("Center", applet);
frame.setSize(1000, 600);
frame.show();
applet.init();
applet.start();
}
public void windowActivated(WindowEvent e) { } //
public void windowClosed(WindowEvent e) { }
public void windowClosing(WindowEvent e) {
System.exit(0);
}
public void windowDeactivated(WindowEvent e) { }
public void windowDeiconified(WindowEvent e) { }
public void windowIconified(WindowEvent e) { }
public void windowOpened(WindowEvent e) { }
}
4.3. Guide d'utilisateur
Pour démarrer notre application, l'utilisateur doit
s'assurer que tout est en marche (ordinateurs capables de se communiquer),
matériels et autres outils de communication disponible (hub,
câble...). Cette application fonctionne également en boucle
locale en laissant par défaut l'adresse IP : 127.0.0.1 pour
l'adresse IP du serveur.
Cette application comprend deux parties : une partie
serveur et une autre destinée au client.
Pour la partie Serveur l'utilisateur doit de prime abord
lancé le serveur. Pour y arriver il doit soit compiler et
exécuter le fichier serveur.java dans un éditeur comme Jcreator
ou tous simple compiler à partir de la console dos de la manière
suivante :
Pour compiler :
Tapez la commande suivante : cd mémoire_jm/javac
serveur.java, puis validez.
Pour exécuter : cd mémoire_jm/java serveur,
puis validez.
L'utilisateur peut en plus utilisez l'icône du
programme au Bureau, en y double-cliquant, on obtient la fenêtre
suivante :
Cliquez sur le bouton DEMARRER LE PROGRAMME,
et poursuivre pour s'authentifier.
Si l'utilisateur se connecte comme
« Animateur » il peut alors Planifier la
réunion dans le formulaire suivant.
Après avoir planifier l'Animateur (le Chef de
Département) envoie ces détails à tous les membres, qui
reçoivent et propose leur désidérata dans les formulaires
suivants :
Cliquez sur le bouton Affichage pour
visualiser les détails de la réunion. Pour proposer son
désidérata cliquer sur le Bouton
Désidérata.
Dans ce formulaire l'enseignant peut formuler son
désidérata en choisissant son nom, son titre académique et
la promotion puis choisir un cours et cliquer chaque fois le bouton
Ajouter.
Après la définition des
désidératas par les membres (enseignant) du Département,
le Président peut collecter tous ces désidératas dans le
formulaire suivant :
Dans ce formulaire le Chef du Département visualise les
désidératas envoyés par tous les enseignants en
sélectionnant un enseignant quelconque. En plus il visualise les
différents cours proposés par un ou plusieurs enseignants dans la
même promotion en cliquant sur le bouton DesCommun.
Il reste au chef de Département de prendre une
décision sur l'ensemble.
Il a la possibilité soit d'Ajouter un
ou plusieurs cours dans la charge d'un enseignant en cliquant sur le Bouton
Ajouter, soit Supprimer quelques cours pour un enseignant en
cliquant sur le bouton Delete. Pour supprimer il suffit de
fournir au programme le nom de l'enseignant, l'intitulé du cours et la
promotion dans la fenêtre suivante :
CONCLUSION
Nous nous sommes intéressé dans ce travail aux
systèmes multi-agents, et plus particulièrement à la
Modélisation d'un système multi-agents : application
à la réunion virtuelle d'attribution des charges horaires au
Département d'Informatique de Gestion.
L'analyse des protocoles d'interaction de FIPA nous a permis
de réifier les principaux concepts de l'interaction entre agents.
Pour définir les interactions entre agents,
différents protocoles d'interaction ont été
proposés. Nous avons mis l'accent sur le protocole
contract-net. Ce protocole d'interaction est le plus utilisé
dans les systèmes multi-agents. Il repose sur un mécanisme
d'allocation de tâches régi par le protocole d'appel d'offres qui
est utilisé dans les organisations humaines. Il est basé sur le
rôle d'initiateur (appelé Manager) joué par le chef de
Département dans le cas de notre projet et le rôle participant
joué par les enseignants membres du Département.
Nous avons posé comme hypothèse directrice, la
proposition d'un langage et d'un protocole de communication qui pourrait
assurer l'interopérabilité entre agents participant à
la réunion d'attribution des charges horaires. L'implémentation
d'une application client-serveur pour la gestion des réunions
virtuelles d'attributions des charges horaires.
Ce travail est subdivisé en quatre chapitres :
Le premier chapitre porte sur l'histoire de l'intelligence
artificielle. Dans ce chapitre nous avons présenté une
brève historique de l'intelligence artificielle départ
différents auteurs. Nous avons ensuite tenté de définir
l'intelligence artificielle. Enfin nous avons parlé des
différents domaines de l'intelligence artificielle et leurs
applications pratiques.
Dans le deuxième chapitre portant sur les interactions
dans un système multi-agents nous avons parlé des
systèmes multi-agents communiquants et les systèmes multi-agents
conversationnels. Nous avons ensuite parlé de la théorie des
actes de langage sur laquelle repose un langage de communication.
Dans le troisième chapitre portant sur les protocoles
d'interaction FIPA-ACL. Nous avons analysé minutieusement les
différents protocoles de FIPA-ACL, notamment : le protocol
Request et dérivés (Query et Propose), le
protocol Contract-Net et Iterated-Contract-Net, le
protocole English-Auction et Dutch-Auction et le protocole
Brokering et Recruiting.
Nous avons insisté sur le protocole fipa contract
net au moyen duquel nous avons modélisé la réunion
d'attribution des charges horaires.
Le dernier chapitre a porté sur la Mise en place d'un
serveur des réunions virtuelles d'attributions des charges horaires au
Département d'Informatique de Gestion. Dans ce chapitre il a
été question de modéliser au moyen des différents
diagrammes UML les réunions virtuelles d'attributions des charges
horaires. Nous nous sommes servis du diagramme de cas d'utilisation, du
diagramme de séquence, du diagramme de classe et du diagramme
d'états-transition.
C'est cette modélisation qui nous a
préparé à implémenter une application
orienté client-serveur pour la gestion des réunions virtuelles.
Grâce à cette application le chef de Département
d'Informatique de Gestion a la possibilité de planifier la
réunion et d'envoyer les détails de la réunion en
broadcast à tous les membres du Département. Chaque membre du
Département (participant) a la possibilité d'envoyer son
désidérata dans le délai prévu. Enfin, il
appartient au Chef de Département de collecter et d'établir une
charge horaire pour chaque enseignant.
Notre hypothèse a été validée
à partir l'intégration du protocole FIPA Contract net dans les
réunions virtuelles d'attributions des charges horaires, de par le
rôle du Manager et du participant. Mais aussi à
l'implémentation de l'application ci-haut cité.
Pour y arriver nous avons fait recours au langage UML et
à la méthode comparative.
Deux langages ont marqué notre étude :
- Le langage de communication FIPA contract net ;
- Le langage UML (Unified Modeling Language).
Ce travail présente beaucoup d'approches pour
être développé. C'est pourquoi, nous avons appliqué
le concept des réunions virtuelles qui bas son plein aujourd'hui dans le
domaine informatique à la gestion d'une réunion d'attribution
des charges horaires au Département d'Informatique de Gestion.
D'autres approches qui n'ont pas été développé
constitueront l'objet d'une autre recherche.
Le présent travail, étant réalisé
par un humain, il n'est pas exempté d'imperfection. Ainsi, les
remarques et suggestions pour son amélioration sont donc les
bienvenues.
BIBLIOGRAPHIE
Ouvrages et Revues
1. AFNOR,
Vocabulaire de la documentation, 2e édition, 1987.2. Alain
BONNET, L'Intelligence artificielle, Promesses et
Réalités,
InterEditions, Paris, 1984, p. 17.3. Alain BONNET,
L'Intelligence artificielle, Promesses et Réalités,
InterEditions, Paris, 1984, p. 20.4. Alper CAGLAYAN,
Collin HARRISON, Agent Sourcebook, A Complete Guide to
Desktop,Internet, and Intranet agents, Wiley Computer Publishing, New
York, 1997. 5. ARISTOTE, Organon III, J.
Vrin, Paris, 2001.6. Art 7. de VADE MECUM du gestionnaire d'une institution
d'enseignement Supérieure et Universitaire, De la charge horaire
7. Béatrice FOENIX-RIOUX,
Recherche et veille sur le Web visible et invisible,
Éditions TEC & DOC, Paris, 2001, p. 136. 8. C.
BONNET, J.F. MACARY, Technologies PUSH, Eyrolles, Paris, 1998, p.36 9.
Daniel CREVIER, A la recherche de l'intelligence artificielle,
Flammarion,
coll. « Champs », 1997, p. 67-69.10. Denis
Jouvin, Délégation de Rôle et Architectures Dynamiques
de
Systèmes Multi-Agents Conversationnels,
thèse de Doctorat,
Université
Lyon I - Claude Bernard, 200311. Don Gilbert
et al. IBM intelligent agent strategy, IBM, 1995.12. Francisco Martin,
Enric Plaza, Juan Rodriguez-Aguilar: Conversation
Protocols: Modeling and Implementing Conversations
in Agent-Based
Systems. Dans les actes de International Workshop
on Specifying and
Implementing Conversation Policies (SICP),
Seattle, WA, USA, Mai
1999.13. George BOOLE, The Mathematical
Analysis of Logic : Being an Essay
towards a Calculus of Deductive Reasoning,
Macmillan, London,
184714. Hervé CHAUDET, Liliane
PELLEGRIN, Intelligence artificielle et
psychologie cognitive, Dunod, 1998, p715.
Hubert L. DREYFUS, Intelligence artificielle, mythes et limites,
Flammarion, Paris, 1984, p. 3. 16. Hyacinth NWANA,
«Software Agents : An Overview», Knowledge
Engineering Review, Vol.11, N° 3, p.
1-40, Sept. 1996.17. J. Ferber. Les systèmes multi-agents, vers une
intelligence collective.
InterEditions, Paris, 1995.18. J.-P. Briot and Y.
Demazeau, editors. Principes et architecture des
systèmes multiagents. Collection I.
Hermes-lavoisier, 2001. in-french.19. Jacques FERBER, Les systèmes
multi-agent, vers une intelligence
collective, InterEditions, Paris,
1995.p.620. Jacques FERBER, Les systèmes multi-agents,vers une
intelligence
collective, InterEditions, Paris, 1995, p.
5.21. Jacques PITTRAT, « La naissance de l'intelligence
artificielle », La
Recherche, No. 170, Octobre, 1985, p.
1132.22. Jean Michel DOUDOUX, Développons en Java, ndl.23.
Jean-François DORTIER, « espoirs et réalité de
l'intelligence artificielle,
Le cerveau et la pensée,
Sciences Humaines », Paris, 1999, p. 362.24.
Jean-François DORTIER, « espoirs et réalité de
l'intelligence artificielle,
Le cerveau et la pensée, Sciences
Humaines », Paris, 1999, p. 73.25. Jean-Luc Koning,
Marc-Philippe Huget, Jun Wei, Xu Wang: Extended
Modeling Languages for Interaction Protocol Design.
Dans les actes de
International Workshop on Agent Oriented Software
Engineering
(AOSE),Montréal, Canada, Mai 2001.
MichaelWooldridge, Gerhard Weiß,
Paolo Ciancarini (éd.), LNCS vol. 2222.
26. Jeffrey M. BRADSHAW, An
Introduction to Software agents, http://agents.umbc.edu /introduction/01-
Bradshaw.pdf, livre consulté le 17 décembre 2003.
27. Jeremy Pitt, Abe Mamdani: Communication Protocols
in Multi-Agent Systems. Dans les actes de International Workshop on
Specifying and Implementing Conversation Policies (SICP),
Seattle, WA, USA, Mai 1999. ACM28. John Austin: How to Do Things with
Words. Oxford Press, 196229. John Richard WISDOM, les agents
intelligents sur internet : enjeux économiques et
sociétaux, Thèse de l'École Nationale
Supérieure des Télécommunications, Paris, 200530.
John Searle: Speech Acts: an Essay in the Philosophy of Language,
Cambridge Press, 1969.31. Kazuhiro Kuwabara, Toru Ishida, Nobuyasu Osato:
AgenTalk: Coordination Protocol Description for Multiagent Systems. Dans les
actes de International
32. Conference on Multi-Agent Systems (ICMAS), San
Francisco, CA, USA, Juin 1995. V. Lesser, L. Gasser (éd.), AAAI
Press.33. Le Nouveau Petit Robert, 2000. d'après Bernard LAMIZET, et
Ahmed
SILEM, Dictionnaire encyclopédique des
sciences de l'information et de la communication, Ellipses, Paris,
1997, p.305.34. Marian Nodine, Amy Unruh: Constructing Robust Conversation
Policies
inDynamic Agent Communities. Dans les actes de
International Workshop on Specifying and Implementing Conversation
Policies (SICP), Seattle, WA,USA, Mai 1999.35. Mihai Barbuceanu, Mark Fox:
COOL: A Language for Describing Coordination in Multi Agent Systems. Dans les
actes de International
36. Conference on Multi-Agent Systems (ICMAS), San
Francisco, CA, USA, Juin 1995.
37. V. Lesser, L. Gasser (éd.), AAAI Press38. Norbert
Wiener, Cybernetics: on Control and Communication in the
animal and the Machine, Wiley, 1948.39.
Patrice FLICHY, L'Imaginaire d'Internet, Editions La
Découverte, Paris,
200140. Philip Cohen, Hector Levesque: Intention Is
Choice With Commitment.
Dans Journal of Artificial Intelligence
(AI), 41(3), Mars 1990. Elsevier41. Philippe BRETON, Une Histoire de
L'Informatique, Seuil, 1990, p. 162.42. Philippe GENOUD UJF, Java
DataBase Connectivity, 13/03/200743. PLATON, « Euthypron »,
Premiers dialogues, Flammarion, Paris, 1967,
pp. 185-211.44. Pr. Jean Marc Jéséquel,
Analayse par objet avec UML, IRISA
UNIV .Rennes Source :
http://www.irisa.fr/prive/jezequel45. Raoul SMITH, Dictionary of ARTIFICIAL
INTELLIGENCE, Collins, London,
1990, p. 22.46. René DESCARTES, Les
méditations métaphysiques, Bordas, Paris, 1987,
pp. 17-28.47. REVELLI, Carlo, Intelligence
Stratégique sur Internet, Paris, Dunod, 1998, p. 212. 48. SAMIER,
Henri ; SANDOVAL, Victor, La recherche intelligente sur Internet, outils et
méthodes, Paris, Hermès, 1998, p. 151. 49. Stan FRANKLIN et
Art GRAESSER, «Is it an Agent, or just a Program?: A Taxonomy for
Autonomous Agents» , Proceedings of the third international workshop
on agent theories, architectures, and languages, New York,
Springer-Verlag,1996,
Source:web:http://www.google.fr/search?q=cache:6oi7wQy9OOcJ:stanford.edu/jmc/history/
dartmouth/dartmouth.html, document consulté le 13 12 2004.50. Stuart
RUSSEL, Peter J., NORVIG, Artificial Intelligence, A Modern
Approach, Prentice-Hall International, Inc,
New Jersey, 1995. p. 8.51. Tim Finin, Rich Fritzson, Don McKay, Robin McEntire:
KQML as an Agent Communication Language. Dans Conference on
Information and
Knowledge Management (CIKM), Décembre
1994
52.
www.cse.unsw.edu.au/~wobcke/COMP4416/readins/Franklin.Graesser.
97.ps+%22IBM+ intelligent+agent+strategy%22&hl=fr53. Y. Demazeau.
From interactions to collective behaviour in agent-based
systems. 1995s.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
WEBOGRAPHIE
1.
http://ia-tpe2010.e-monsite.com/rubrique,les-domaines-d-applications,1181161.html,
valide le 21 août 2010
2. (
http://www.cs.umbc.edu/~jklabrou/publications/),
valide le 21 août 2010
3. (
http://www.fipa.org/specs/fipa/),
valide le 21 août 2010
4.
http://wwwformal.stanford.edu/jmc/history/dartmouth/dartmouth.html
5. http://www.google.fr/search?q=cache:6oi7wQy9OOcJ:
6. http://www.cse.unsw.edu.au/~wobcke/COMP4416/readins
7.
http://www.cs.umbc.edu/~jklabrou/publications/.
8. http://www.google.fr/search?q=cache:6oi7wQy9OOcJ:
9.
http://www.cse.unsw.edu.au/~wobcke/COMP4416/readins/Franklin.Graesser.97.ps+%22IBM+intelligent+agent+strategy%22&hl=fr
10.
http://agents.umbc.edu/introduction/01- Bradshaw.pdf, livre
consulté le 17 décembre 2003.
11.
http://agents.umbc.edu/introduction/01- Bradshaw.pdf, livre
consulté le 17 décembre 2003.
12. http://www.
wikipedia.org/wiki/Agent_intelligent
, consulté le 16 Août 2010
13. http://www.
revuesim.free.fr/index.php
, consulté le 16 Août 2010
14. http://www.
aeris.11vm-serv.net/cours/util_outils/glos.html,
consulté le 16 Août 2010
15. http://www.
docs.sun.com/app/docs/doc/819-4628/6n6p2pm93
, consulté le 16 Août 2010
16.
www.francedecision.com/v2/component/option,com_rd_glossary/task,showcat/catid,19/Itemid,109/,
consulté le 16 Août 2010
17. http://www.
217.128.136.10/Glossaire/toutleglossaire.htm,
consulté le 16 Août 2010
TABLE DES MATIERES
EPIGRAPHE
I
DEDICACE
II
REMERCIEMENT
III
LISTE DES ACRONYMES
IV
RESUME
V
INTRODUCTION
- 1 -
I.1. PROBLEMATIQUE
- 1 -
I.2. HYPOTHESES
- 3 -
I.3. ETAT DE LA QUESTION
- 4 -
I.4. METHODOLOGIE DU TRAVAIL
- 4 -
I.5. JUSTIFICATION DE CHOIX DU SUJET
- 5 -
I.6. DELIMITATION DU SUJET
- 5 -
CHAP. 1. HISTOIRE DE L'INTELLIGENCE
ARTIFICIELLE
- 6 -
1.1. HISTOIRE
- 6 -
3.1.1. Origines scientifiques de l'IA
- 6 -
3.1.2. Naissance de l'intelligence
artificielle moderne : Dartmouth 1956
- 9 -
3.1.3. Difficultés rencontrées
par la discipline
- 10 -
3.1.4. Intelligence artificielle et enjeux
pour l'État
- 11 -
1.2. DEFINITION
- 11 -
1.3. DOMAINE DE L'IA
- 15 -
1.4. APPLICATION PRATIQUE DE L'IA
- 17 -
CHAP 2. LES INTERACTIONS DANS UN SMA
- 18 -
2.1. LES AGENTS INTELLIGENTS
- 18 -
3.1.5. 2.1.1. Comment définir un
agent intelligent ?
- 18 -
3.1.6. 2.1.2. Définition
- 19 -
3.1.7. 2.1.3. Caractéristiques d'un
agent intelligent
- 21 -
3.1.8. 2.1.3. Classification des agents
intelligents
- 21 -
2.2. DES INTERACTIONS AUX CONVERSATIONS
- 27 -
3.1.9. 2.2.1 Systèmes multi-agents
Communiquants
- 28 -
3.1.10. 2.2.2 Systèmes multi-agents
conversationnels
- 38 -
CHAP. 3. LES PROTOCOLES D'INTERACTION
FIPA-ACL
- 44 -
3.2. ANALYSES
- 44 -
3.3. ANALYSE ET INTEGRATION DU PROTOCOLE
CONTRACT-NET DANS LES REUNIONS D'ATTRIBUTIONS DES CHARGES HORAIRES AU
DEPARTEMENT D'INFORMATIQUE DE GESTION
- 54 -
3.3.1. Analyse du Protocol Contract-net
- 54 -
3.3.2. Intégration du Protocol Fipa
contract- net dans les réunions virtuelles d'attributions des charges
horaires au Département d'Informatique de Gestion.
- 58 -
CHAP.4. MISE EN PLACE D'UN SERVEUR DES REUNIONS
VIRTUELLES
- 64 -
4.1. MODELISATION DES REUNIONS VIRTUELLES AVEC
UML
- 64 -
4.1.1. Elaboration d'un cahier de charge
- 64 -
4.1.2. Démarche de Modélisation
- 65 -
4.2. LE MODELE ORIENTE CLIENT-SERVEUR
- 73 -
4.2.1. Concepts de base sur le client-serveur
- 73 -
4.2.2. Paquetages nécessaires
- 74 -
4.2.3. Structure d'un client
- 74 -
4.2.4. Structure d'un serveur
- 74 -
4.2.5. Structure d'un service
- 75 -
4.2.5. JDBC
- 75 -
4.2.6. Architecture d'une application JDBC
- 75 -
4.2.7. Architecture client-serveur
- 76 -
4.2.1. Création d'une source des
données
- 77 -
4.4. PRESENTATION DE NOTRE APPLICATION EN RESEAU
LOCAL
- 79 -
4.3. QUELQUES LIGNES DE NOTRE CODE SOURCE ECRIT
EN JAVA
- 80 -
4.3.1. Le fichier serveur
- 80 -
4.3.2. Le fichier service
- 81 -
4.3.3. Le fichier Planification
- 83 -
4.3. Guide d'utilisateur
- 93 -
CONCLUSION
- 98 -
BIBLIOGRAPHIE
- 100 -
WEBOGRAPHIE
- 103 -
TABLE DES FIGURES
- 106 -
LISTE DES TABLEAUX
- 107 -
TABLE DES FIGURES
Figure 1. Exemple d'un message FIPA-ACL en format
textuel (sans l'enveloppe)
- 29 -
Figure 2. Niveau communicationnel dans
l'interaction
- 32 -
Figure 3. Conversation multi-parties
- 39 -
Figure 4. Exemple d'un message FIPA-ACL
- 41 -
Figure 5. FIPA-Request et FIPA-Propose en Agent UML
(tiré des spécifications de FIPA)
- 46 -
Figure 6. FIPA-Contract-Net et
FIPA-Iterated-Contract-Net en Agent UML
- 48 -
Figure 7. FIPA-English-Auction et
FIPA-Dutch-Auction en Agent UML
- 50 -
Figure 8. FIPA-Recruiting en Agent UML
(Tiré des spécifications de FIPA)
- 53 -
Figure 9. Message cfp
- 54 -
Figure 10. Le rôle initiateur du protocole
FIPA Contract Net
- 55 -
Figure 11. Message propose
- 57 -
Figure 12. Le rôle participant du protocole
FIPA Contract Net
- 58 -
Figure 13. Message cfp envoyé par le chef
de Département
- 59 -
Figure 14. Initiateur du Protocole fipa
contract-net
- 60 -
Figure 15. Message propose envoyé par les
membres du Département
- 61 -
Figure 16. Participant du Pritocole fipa
contract-net
- 62 -
Figure 17. Diagramme du protocole Fipa de
Modélisation des réunions virtuelles d'attribution des charges
horaires
- 63 -
Figure 18. Diagramme de cas d'utilisations
- 66 -
Figure 19 Représentation UML d'une
classe
- 67 -
Figure 20. Diagramme de classe
- 68 -
Figure 21. Diagramme de séquence du cas
d'utilisation connexion
- 70 -
Figure 22. Diagramme de séquence du cas
d'utilisation planification
- 70 -
Figure 23. Diagramme de séquence du cas
d'utilisation Animation
- 71 -
Figure 24. Cas d'utilisation
entrée-sortie
- 71 -
Figure 25. Cas d'utilisation présentation
désidérata
- 72 -
Figure 26. Diagramme d'états-transition
réunion
- 73 -
Figure 27. Diagramme d'états-transitions :
enseignant
- 73 -
Figure 28. Architecture d'une application Jdbc
- 76 -
Figure 29. Architecture client-serveur
- 76 -
LISTE DES TABLEAUX
Tableau 1. Classification des principaux actes de
langage de KQML et FIPA ACL
- 33 -
Tableau 2. Paramètre des messages KQML et
FIPA ACL
- 42 -
* 1 Denis Jouvin,
Délégation de Rôle et Architectures Dynamiques de
Systèmes Multi-Agents Conversationnels, thèse de Doctorat,
Université Lyon I - Claude Bernard, 2003
* 2 Art 7. De la
charge horaire de VADE MECUM du gestionnaire d'une institution
d'enseignement Supérieure et Universitaire.
* 3 Stuart RUSSEL, Peter J.,
NORVIG, Artificial Intelligence, A Modern Approach, Prentice-Hall
International,Inc, New Jersey, 1995. p. 8.
* 4 ARISTOTE, Organon
III, J. Vrin, Paris, 2001.
* 5 René DESCARTES,
Les méditations métaphysiques, Bordas, Paris, 1987, pp.
17-28.
* 6 John Richard WISDOM, les
agents intelligents sur internet : enjeux économiques et
sociétaux, Thèse de l'École Nationale Supérieure
des Télécommunications, Paris, 2005
* 7 George BOOLE, The
Mathematical Analysis of Logic : Being an Essay towards a Calculus of
Deductive
Reasoning, Macmillan, London, 1847
* 8 Le mot
cybernétique provient du mot grec kybernetes qui signifie le
barreur d'un navire. Ampère utilise le mot dans son livre La
Cybernétique (1848) dans un sens politique.
* 9 Norbert Wiener,
Cybernetics: on Control and Communication in the animal and the Machine, Wiley,
1948.
* 10 Philippe BRETON,
Une Histoire de L'Informatique, Seuil, 1990, p. 162.
* 11 PLATON, «
Euthypron », Premiers dialogues, Flammarion, Paris, 1967, pp.
185-211.
* 12 Hubert L. DREYFUS,
Intelligence artificielle, mythes et limites, Flammarion, Paris, 1984,
p. 3.
* 13 Ivre en langue
tchèque
* 14 Patrice FLICHY,
L'Imaginaire d'Internet, Editions La Découverte, Paris, 2001
* 15 Jacques PITTRAT, «
La naissance de l'intelligence artificielle », La Recherche, No.
170, Octobre, 1985, p.1132.
* 16 La conférence
est connue sous le nom de Dartmouth Summer Research project on Artificial
Intelligence. Une présentation du texte d'appel à
contribution est donnée à cette adresse: http://wwwformal.
stanford.edu/jmc/history/dartmouth/dartmouth.html, document
consulté le 13 12 2004.
* 17 Daniel CREVIER, A
la recherche de l'intelligence artificielle, Flammarion, coll. «
Champs », 1997, p. 67-69.
* 18 Idem, p.68
* 19 Hervé CHAUDET,
Liliane PELLEGRIN, Intelligence artificielle et psychologie cognitive,
Dunod, 1998, p7
* 20 Jean-François
DORTIER, « espoirs et réalité de l'intelligence
artificielle, Le cerveau et la pensée, Sciences Humaines,
Paris, 1999, p. 73.
* 21 Idem, p.73
* 22 Des usages se
développent autour des fonctions de traduction des moteurs depuis 2004.
On peut penser qu'il y a eu quelques progrès.
* 23 L'échec des
services de renseignement américains à empêcher les
attentats du 11 septembre 2001 est notoire.
* 24 Le Nouveau Petit
Robert, 2000.
* 25 D'après Bernard
LAMIZET, et Ahmed SILEM, Dictionnaire encyclopédique des sciences de
l'information et
de la communication, Ellipses, Paris, 1997, p.305.
* 26 Raoul SMITH,
Dictionary of ARTIFICIAL INTELLIGENCE, Collins, London, 1990, p.
22.
* 27 Jean-François
DORTIER, « espoirs et réalité de l'intelligence
artificielle, Le cerveau et la pensée, Sciences Humaines,
Paris, 1999, p. 362.
* 28 Alain BONNET,
L'Intelligence artificielle, Promesses et Réalités,
InterEditions, Paris, 1984, p. 17.
* 29 Alain BONNET,
L'Intelligence artificielle, Promesses et Réalités,
InterEditions, Paris, 1984, p. 17.
* 30 Jacques FERBER, Les
systèmes multi-agents,vers une intelligence collective, InterEditions,
Paris, 1995, p. 5.
* 31 Alain BONNET,
L'Intelligence artificielle, Promesses et Réalités,
InterEditions, Paris, 1984, p. 17.
* 32 Alain BONNET, op. cit.,
p.18
* 33 Alain BONNET,
L'Intelligence artificielle, Promesses et Réalités,
InterEditions, Paris, 1984, p. 20.
* 34 Alain BONNET,
L'Intelligence artificielle, Promesses et Réalités,
InterEditions, Paris, 1984, p. 24.
* 35
http://ia-tpe2010.e-monsite.com/rubrique,les-domaines-d-applications,1181161.html,
valide le 21 août 2010
* 36
http://ia-tpe2010.e-monsite.com/rubrique,les-domaines-d-applications,1181161.html
, valide le 21 août 2010
* 37 Jacques FERBER, Les
systèmes multi-agent ,vers une intelligence collective,
InterEditions, Paris, 1995.p.6
* 38 John Richard WISDOM, les
agents intelligents sur internet : enjeux économiques et
sociétaux, Thèse de l'École Nationale Supérieure
des Télécommunications, Paris, 2005
* 39 John Richard WISDOM, les
agents intelligents sur internet : enjeux économiques et
sociétaux, Thèse de l'École Nationale Supérieure
des Télécommunications, Paris, 2005.
* 40 Le code « define :
intelligent agent » retourne une liste de définitions à
partir de dictionnaires spécialisés enligne.
* 41 Jeffrey M. BRADSHAW,
An Introduction to Software agents,
http://agents.umbc.edu/introduction/01-
Bradshaw.pdf, livre consulté le 17 décembre 2003.
* 42 Idem, p.4
* 43 Don Gilbert et al. IBM
intelligent agent strategy, IBM, 1995.
* 44 Stan FRANKLIN et Art
GRAESSER, «Is it an Agent, or just a Program?: A Taxonomy for
Autonomous
Agents» , Proceedings of the third international
workshop on agent theories, architectures, and languages, New York,
Springer-Verlag, 1996, source
web:http://www.google.fr/search?q=cache:6oi7wQy9OOcJ:www.cse.unsw.edu.au/~wobcke/COMP4416/readins/Franklin.Graesser.97.ps+%22IBM+intelligent+agent+strategy%22&hl=fr
* 45 AFNOR, Vocabulaire de
la documentation, 2e édition, 1987.
* 46 Notamment les
méta-moteurs en-ligne ou hors ligne sont présentés comme
agents intelligents
* 47 Jeffrey M. BRADSHAW,
op. cit. p.6. cité par John Richard WISDOM, les agents
intelligents sur internet : enjeux économiques et sociétaux,
Thèse de l'École Nationale Supérieure des
Télécommunications, Paris, 2005
* 48 Béatrice
FOENIX-RIOUX, Recherche et veille sur le Web visible et invisible,
Éditions TEC & DOC, Paris,
2001, p. 136. Cité par John Richard WISDOM.
* 49 Idem, p.136.
* 50 SAMIER, Henri ; SANDOVAL,
Victor, La recherche intelligente sur Internet, outils et
méthodes, Paris, Hermès, 1998, p. 151. Cité par Jhon
Richard WISDOM
* 51 Idem, p. 58
* 52 Hyacinth NWANA,
«Software Agents : An Overview», Knowledge Engineering
Review, Vol.11, N° 3, p. 1-
40, Sept. 1996. Cité par Jhon Richard WISDOM
* 53 Alper CAGLAYAN, Collin
HARRISON, Agent Sourcebook, A Complete Guide to Desktop, Internet,
and
Intranet agents, Wiley Computer Publishing, New York,
1997. Cité Jhon Richard WISDOM, op. cit
* 54 Idem, p.9-14
* 55 REVELLI, Carlo,
Intelligence Stratégique sur Internet, Paris, Dunod, 1998, p.
212. Cité par Jhon Richard WISDOM, op. cit
* 56 C. BONNET, J.F. MACARY,
Technologies PUSH, Eyrolles, Paris, 1998, p.36 cité par Jhon
Richard WISDOM, op. cit
* 57 Froogle du moteur Google
ou Kelkoo acheté par Yahoo. Cité par Jhon Richard WISDOM, op.
cit
* 58 Programme conçu par
Joseph WEISENBAUM, Eliza est le nom du personnage de Pygmalion de
George
Bernard Shaw. En effet, ce personnage devait, dans cette
pièce de théâtre, apprendre à améliorer son
langage. En fonction du domaine de la conversation, un module peut être
développé, séparé du module qui
génère la conversation. WEISENBAUM appelait les modules
scripts. L'un de ces scripts simulait une
psychothérapie.. Source : Daniel Crevier, op. cit. p.162.
Site : http://www-ai.ijs.si/eliza/eliza.html
* 59 Ce type d'agent fait
partie de l'offre de Yahoo et s'intègre facilement dans la barre
d'outils de ce portail
* 60 Source : Alper CAGLAYAN,
Collin HARRISON, op. cit., p. 57-83. Cité par Jhon Richard
WISDOM, op. cit
* 61 Application Programming
Interface
* 62 Y. Demazeau. From
interactions to collective behaviour in agent-based systems. 1995.
* 63 J. Ferber. Les
systèmes multi-agents, vers une intelligence collective. InterEditions,
Paris, 1995.
* 64 J.-P. Briot and Y.
Demazeau, editors. Principes et architecture des systèmes multiagents.
Collection I. Hermes-lavoisier, 2001. in-french.
* 65 John Austin: How to Do
Things with Words. Oxford Press, 1962, Londres, Angleterre cité
par Denis Jouvin, Délégation de Rôle et Architectures
Dynamiques de systèmes Mullti-agents conversationnels, Université
Lyon I-Claude Bernard, Paris, Thèse de Doctorat 2003.
* 66 John Searle: Speech Acts:
an Essay in the Philosophy of Language. Cambridge Press, 1969, cité par
Denis Jouvin, Op.cit
* 67 Philip Cohen, Hector
Levesque: Intention Is Choice With Commitment. Dans Journal of Artificial
Intelligence (AI), 41(3), Mars 1990. Elsevier, cité par Denis
Jouvin Op. cit
* 68 Yannis Labrou, Tim
Finin: A Proposal for a New KQML Specification.Université de Maryland
Baltimore County (
http://www.cs.umbc.edu/~jklabrou/publications/),
cité par Denis Jouvin Op. cit
* 69 Tim Finin, Rich
Fritzson, Don McKay, Robin McEntire: KQML as an Agent Communication Language.
Dans Conference on Information and Knowledge Management (CIKM),
Décembre 1994, cité par Denis Jouvin Op. cit
* 70 Foundation for
Intelligent Physical Agents: FIPA Communicative Act Library Specification. (
http://www.fipa.org/specs/fipa/)
* 71 Idem
* 72 Jeremy Pitt, Abe
Mamdani: Communication Protocols in Multi-Agent Systems. Dans les actes de
International Workshop on Specifying and Implementing Conversation
Policies (SICP), Seattle, WA, USA, Mai 1999. ACM, cité par Denis
Jouvin Op. cit
* 73 Francisco Martin, Enric
Plaza, Juan Rodriguez-Aguilar: Conversation Protocols: Modeling and
Implementing Conversations in Agent-Based Systems. Dans les actes de
International Workshop on Specifying and Implementing Conversation Policies
(SICP), Seattle, WA, USA, Mai 1999., cite par Denis Jouvin Op. cit
* 74 Denis Jouvin,
Délégation de Rôle et Architectures Dynamiques de
Systèmes Multi-Agents Conversationnels, thèse de Doctorat,
Université Lyon I - Claude Bernard, 2003
* 75 Jeffrey Bradshaw,
Stewart Dutfield, Bob Carpenter, Renia Jeffers, Tom Robinson: KAoS: A Generic
Agent Architecture for Aerospace Applications. Dans les actes de Conference
on Information and Knowledge Management (CIKM), Baltimore, MD, USA,
Décembre 1995. cité par Jouvin Dennis, Op.Cit
* 76 Jeffrey Bradshaw: KAoS:
An Open Agent Architecture Supporting Reuse, Interoperability, and
Extensibility. Dans les actes de Knowledge Acquisition Workshop
(KAW).Novembre 1996., cité par Jouvin Dennis, Op.Cit
* 77 Mihai Barbuceanu, Mark
Fox: COOL: A Language for Describing Coordination in Multi Agent Systems. Dans
les actes de International Conference on Multi-Agent Systems
(ICMAS), San Francisco, CA, USA, Juin 1995. V. Lesser, L. Gasser
(éd.), AAAI Press
* 78 Kazuhiro Kuwabara, Toru
Ishida, Nobuyasu Osato: AgenTalk: Coordination Protocol Description for
Multiagent Systems. Dans les actes de International Conference on
Multi-Agent Systems (ICMAS), San Francisco, CA, USA, Juin 1995. V. Lesser,
L. Gasser (éd.), AAAI Press.
* 79 Marian Nodine, Amy
Unruh: Constructing Robust Conversation Policies inDynamic Agent Communities.
Dans les actes de International Workshop onSpecifying and Implementing
Conversation Policies (SICP), Seattle, WA,USA, Mai 1999.
* 80 Mihai Barbuceanu, Mark
Fox: COOL: A Language for DescribingCoordination in Multi Agent Systems.Dans
les actes de InternationalConference on Multi-Agent Systems (ICMAS),
San Francisco, CA, USA,Juin 1995. V. Lesser, L. Gasser (éd.), AAAI
Press
* 81 Kazuhiro Kuwabara, Toru
Ishida, Nobuyasu Osato: AgenTalk: CoordinationProtocol Description
forMultiagent Systems. Dans les actes de InternationalConference on
Multi-Agent Systems (ICMAS), SanFrancisco, CA, USA,Juin 1995. V. Lesser,
L. Gasser (éd.), AAAI Press
* 82 Jean-Luc Koning,
Marc-Philippe Huget, Jun Wei, Xu Wang: Extended Modeling Languages for
Interaction Protocol Design. Dans les actes de International Workshop on
Agent Oriented Software Engineering (AOSE), Montréal, Canada, Mai
2001. Michael Wooldridge, Gerhard Weiß, Paolo Ciancarini (éd.),
LNCS vol. 2222.
* 83 Reid Smith: The Contract
Net: A Formalism for the Control of Distributed Problem Solving. Dans les actes
de International Joint Conference on Artificial Intelligence
(IJCAI), Cambridge, MD, USA, Août 1977. R. Reddy (éd.), W.
Kaufmann
* 84 Tim Finin, Rich Fritzson,
Don McKay, Robin McEntire: KQML as an Agent Communication Language. Dans
Conference on Information and Knowledge Management (CIKM), (),
Décembre 1994.
* 85 FIPA. Fipa acl message
structure specification. Technical report, 2002.
* 86 FIPA. Fipa-acl message
structure specification. Technical report, 2002.
* 87 Call for Proposal
* 88 Tarek Jarraya,
Réutilisation des protocoles d'interaction et Démarche
orientée modèles pour le développement multi-agents,
Université de Reims Champagne-Ardenne, 8 décembre 2006.
* 89 KUTANGILA MAYOYA, cours
d'UML, L2/IG ISP Bukavu, inédit, 2010
* 90
http://laurent-audibert.developpez.com/Cours-UML/html/Cours-UML,
consulté le 4 février 2010
* 91 Pr. Jean Marc
Jéséquel, Analayse par objet avec UML, IRISA UNIV .Rennes
.
Source : http://www.irisa.fr/prive/jezequel
* 92 Philippe GENOUD UJF, Java
DataBase Connectivity, 13/03/2007
* 93 Philippe GENOUD UJF, Java
DataBase Connectivity, 13/03/2007
* 94
|