WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Modélisation d'un système multi-agents : application à  la réunion d'attribution des charges horaires au département d'informatique de gestion

( Télécharger le fichier original )
par Jean-Marie MUNGUAKONKOKWA
ISP Bukavu - Licence en pédagogie appliquée option informatique de gestion 2009
  

Disponible en mode multipage

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

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






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Il existe une chose plus puissante que toutes les armées du monde, c'est une idée dont l'heure est venue"   Victor Hugo