|
L'adoption d'une approche organisationnelle pour la conception et la réalisation d'un système multi- agents d'acquisition coopérative d'information( Télécharger le fichier original )par Fadwa et Nesrine Ben Hawala et Said Université de la Manouba Tunis - Maitrise d'informatique appliquée à la gestion 2008 |
Tableau 1 : Les Types d'interaction [Ferber 1995]. Ces différentes situations d'interaction ont été définies par [Ferber 1995] comme suit :
Parmi les différentes formes d'interaction qui existent, on va s'intéresser dans ce qui suit aux notions de coopération qui est la forme générale d'interaction la plus étudiée dans les systèmes multi-agents, notamment à la coordination d'actions. I.5.2. CoopérationDeux agents sont en situation de coopération aux deux conditions minimales suivantes [Hoc 1996] « -Ils poursuivent chacun des buts qui peuvent entrer en interférence, soit au niveau des résultats, soit au niveau des procédures - oeuvrant de manière concurrente sur des sous-ensembles disjoints de données, la solution étant obtenue sous la forme d'un ensemble de solutions locales. ils font en sorte de traiter ces interférences pour que les activités de chacun soient réalisées de façon à faciliter la réalisation de celles de l'autre ou la réalisation de la tâche commune (si elle existe). » Il existe Trois formes de coopération qui peuvent être distinguées (Figure 4) : - La coopération confrontative, selon laquelle une tâche est exécutée par plusieurs agents de spécialités différentes oeuvrant de manière concurrente sur le même ensemble de données, le résultat étant obtenu par "fusion". - La coopération augmentative, selon laquelle une tâche est répartie sur une collection d'agents similaires, - La coopération intégrative, selon laquelle une tâche est décomposée en sous- tâches accomplies par des agents de spécialités différentes et oeuvrant de manière coordonnée, la solution étant obtenue au terme de leur exécution.
Figure 4 : Les formes de coopération [Hoc 1996]. I.5.3. Coordination d'actionsC'est la manière dont les actions des différents agents doivent être organisées dans le temps et l'espace. La coordination d'actions a ainsi été décrite par Thomas W. Malone [Malone 1988] comme l'ensemble des activités supplémentaires qu'il est nécessaire d'accomplir dans un environnement multi-agents et qu'un seul agent poursuivant les même buts n'accomplirait pas. Selon Ferber [Ferber 1995] la coordination d'actions est nécessaire pour quatre raisons principales: « 1. Les agents ont besoin d'informations et de résultats que seuls d'autres agents peuvent fournir. 2 .Les ressources sont limitées : la coordination est d'autant plus importante que les ressources sont faibles Il faut donc partager ces ressources de manière à optimiser les actions à effectuer (éliminer les actions inutiles, améliorer le temps de réponse, diminuer les coûts, etc.) tout en essayant d' 'eviter les conflits éventuels (conflits d'accès, collisions, actions contradictoires, etc.).
L'interaction est à la base de la constitution d'organisations, simultanément les interactions supposent la définition d'un espace et généralement d'une organisation préétablie dans lesquels ces interactions peuvent se produire. I.6. OrganisationI.6.1. DéfinitionsL'organisation est définie comme un cadre d'activité et d'interaction, mis en place par la définition de groupes, rôles et de leurs relations, et considérée comme l'ensemble des relations structurelles dans un ensemble d'agents. De sa part Fox [Fox 1981] défini l'organisation comme étant une structure décrivant les interactions et autres relations qui existent (dans le but d'assouvir un objectif commun) entre les membres de la dite organisation. De l'autre part Ferber [Ferber 1995] va dans ce sens en affirmant que les organisations constituent à la fois le support et la manière dont se passent les inter-relations entre les agents, c'est-à-dire dont sont réparties les tâches, les informations, les ressources et la coordination d'actions. Il précise que ce qui rend l'organisation si difficile à cerner est qu'elle est à la fois le processus d'élaboration d'une structure et le résultat de ce processus. I.6.2. Les Aspects organisationnelsDans [Hübner et al., 2002] l'organisation est décrite via une spécification structurelle, une spécification fonctionnelle et une spécification déontique. Spécification structurelle : définit les relations entre les agents à travers les notions de groupes, rôles et liens qui sont utilisés pour structurer un SMA selon trois niveaux: individuel (comportements qu'un agent doit mettre en oeuvre lorsqu'il joue un rôle), social (relations entre rôles), et collectif (agrégation de rôles dans des structures). Spécification fonctionnelle : explicite comment un SMA atteint généralement son but global (décomposition du but en plans, puis distribution de missions aux agents). Spécification déontique : décrit les permissions et les obligations des rôles pour les missions. I.6.3. Les niveaux organisationnelsOn peut distinguer deux niveaux d'organisation dans les systèmes multi-agents: niveau abstrait et niveau concret : Niveau abstrait : il désigne la structure organisationnelle : c'est ce qui caractérise, sur un plan abstrait, une classe d'organisation [Ferber 1995]. Elle est Caractérisée par des rôles affectés aux agents et des relations abstraites existant entre ces rôles. Niveau concret : c'est une instanciation d'une structure organisationnelle, une réalisation comprenant l'ensemble des entités qui participent effectivement à l'organisation ainsi que l'ensemble des liens qui associent ces agents à un moment donné. I.6.4. Les concepts organisationnelsAvec l'émergence de l'approche organisationnelle, on a vu apparaître de nouveaux concepts liés à l'organisation des SMA, tel que rôle, groupe, protocole, responsabilité, permission... qu'on va essayer de les définir. Rôle : c'est une représentation abstraite d'une fonction, d'un service ou d'une identification d'un agent au sein d'un groupe. Un rôle peut être attribué à plusieurs agents et un agent peut avoir plusieurs rôles. Un rôle représente ce que l'on attend comme comportement de l'agent dans l'organisation : travailler en coopération avec d'autres agents, et trouver son positionnement par rapport à l'organisation elle-même. Cela peut être une simple tâche à remplir vis à vis de l'application globale, mais également une relation à un statut ou une fonction dans l'organisation. Groupe : il est définit comme la notion primitive de regroupement d'agents. Chaque agent peut être membre d'un ou plusieurs groupes. Un groupe est avant tout un terme générique pour qualifier une communauté d'agents en relation (par interaction, par partage d'un environnement, par un but). Permission : Elles représentent les ressources auxquelles le rôle a accès et consistent essentiellement en la liste des valeurs que le rôle a le droit de lire ou de modifier. Responsabilité : Représentant ce que l'agent doit être capable d'assurer dans le système. L'organisation des agents, leurs interactions et leurs coordinations donnent naissance à des comportements sociaux qui nécessitent un moyen de communication permettant aux agents d'échanger des informations ou de transmettre des requêtes. I.7. CommunicationI.7.1. DéfinitionLa communication peut être définie comme une forme d'interaction qui peut être exprimée par un transfert des signaux, des requêtes ou des connaissances via un médiateur. « C'est parce que les agents communiquent qu'ils peuvent coopérer, coordonner leurs actions, réaliser des tâches en commun et devenir ainsi de véritables êtres sociaux» [Ferber 1995] I.7.2. Protocoles de communicationAu sein d'un SMA, les agents ont besoin d'interagir pour échanger de l'information, pour se coordonner et pour coopérer. Les protocoles de communication permettent de représenter ces interactions, il existe en fait plusieurs formalismes pour ces protocoles :
Échanger de l'information nécessite d'utiliser un langage commun. Il existe plusieurs langages de communication inter-agents qui proposent une forme structurée de messages échangés afin d'assurer une standardisation de contenu de ces messages. Il existe aujourd'hui deux grands standards de language de communication inter- agent (ACL : Agent Communication Language) - KQML (Knowledge Query and Manipulation Language) - FIPA ACL, mis au point par la FIPA (Foundation for Intelligent Physical Agents). Langage KQML : Le langage KQML [Finin 1994] a été proposé pour supporter la communication inter-agents. Ce langage définit un ensemble de types de messages (appelés abusivement «performatifs») et des règles qui définissent les comportements suggérés pour les agents qui reçoivent ces messages. Les types de messages de ce langage sont de natures diverses: simples requêtes et assertions («ask», «tell»), instructions de routage de l'information («forward» et «broadcast»), commandes persistantes («subscribe», «monitor»), commandes qui permettent aux agents consommateurs de demander à des agents intermédiaires de trouver les agents fournisseurs pertinents («advertise», «recommend», «recruit» and «broker»). Langage FIPA ACL : Les messages dans ce langage sont sous forme des actions ou des actes communicatifs, car ils sont prévus pour effectuer une certaine action en vertu de l'envoi. Les spécifications de FIPA-ACL se composent d'un ensemble de types de message et de la description de leur pragmatique que sont, des effets sur les attitudes mentales des agents (expéditeur et récepteur). Les spécifications décrivent chaque acte communicatif avec une forme narrative et une sémantique formelle est superficiellement semblable à KQML. Sa syntaxe est identique à celle de KQML excepté différents noms pour quelques primitifs réservés[URL 1]. I.8. ConclusionOn a présenté dans ce chapitre une brève description des concepts de base des systèmes multi-agents qui présentent un domaine très ouvert pour la recherche. Il existe en fait différentes problématiques de recherche qui portent sur les différent caractéristiques d'un SMA à savoir l'organisation social des SMA, la coopération, et la communication inter-agent. Parmi les autres axes de recherches on peut citer notamment les travaux qui se sont focalisés sur les méthodes de conception multi-agent. Dans le chapitre suivant on va étudier plus en détails quelques unes. CHAPITRE II : METHODES DE CONCEPTION DES SMAChapitre IIMéthodes de conception des SMA
L'approche centrée-agent se focalise sur l'étude des différents formalismes de représentations des connaissances internes des agents (croyance, Désire, Intention, ...). L'accent est alors mise sur le niveau micro du système et non pas sur une vue globale de l'ensemble. Le comportement du système est issu de l'ensemble des comportements individuels et des interactions, dans ce cadre du raisonnement orienté vers la prise en compte des états mentaux, les chercheurs ont développé l'architecture BDI (Belief, Desire, Intention). II.2.1. Modèle BDIL'idée de base de l'approche BDI [Müller 1996] est de décrire l'état interne d'un agent en termes d'attitudes mentales et de définir une architecture de contrôle grâce à laquelle l'agent peut sélectionner le cours d'action de ses attitudes mentales. Trois attitudes mentales de base sont définis : les croyances (beliefs) les désirs (desires) et les intentions (intentions) :
II.2.2. Approche Voyelle
II.3. Approche organisationnelleL'approche organisationnelle se base sur les concepts de plus haut niveau d'abstraction tel que les groupes, les rôles, les protocoles d'interactions, les responsabilités, les permissions.... Elle peut être vue comme une technique qui sert à contraindre les comportements individuels des agents vers les objectifs globaux à satisfaire. On part alors d'une organisation conçue par les développeurs du SMA pour arriver aux comportements individuels de chaque agent. On va présenter dans la partie qui suit quelques modèles qui s'inscrivent dans ce cadre organisationnel. II.3.1. Le modèle AGRa. Présentation du modèleLe modèle AGR (Agent, Groupe, Rôle) [Gutknecht et al., 2004], est l'évolution du modèle AALAADIN (Figure 6) qui trouve son origine dans une réflexion sur les différents écueils des modèles centrés agents. Aalaadin [Ferber 1998] est sans doute la plus connue des approches organisationnelles comportementalistes des SMA. Menée par O. Gutknecht et J.Ferber, cette démarche s'articule selon quatre axes :
4. Un axe étudiant des pistes pour une méthodologie de conception des SMA organisationnels. L'organisation dans ce modèle s'articule autour de trois notions : agent, groupe et rôle.
Figure 6 : Modèle Aalaadin.
Un rôle est la représentation abstraite de la fonction d'un agent dans un groupe. Un rôle est local à un groupe et n'a plus aucun sens en dehors de ce contexte. Pour jouer un rôle dans le groupe, l'agent doit postuler pour ce rôle, et l'affectation se fait en fonction de ses compétences. Ces rôles peuvent être portés par un nombre d'agents arbitraire, dépendant de la situation et des normes de l'organisation. b. Aspects méthodologiquesPour [Gutknecht 2001], l'enjeu à long terme d'une méthodologie organisationnelle des SMA est de dégager des patterns de conceptions organisationnels, c'est à dire des descriptions éprouvées d'organisations classiques (réseaux contractuels, organisations hiérarchiques, structure de représentant, ...) pour en faciliter la réutilisation. [Gutknecht 2001] propose une méthodologie en cinq phases :
II.3.2. MOISE+Dans [Hübner et al., 2002] les auteurs expliquent qu'il existe deux familles de modèles organisationnels pour les SMA. D'un côté, on trouve les modèles qui s'appuient sur des plans globaux, qui s'intéressent au fonctionnement de l'organisation. De l'autre côté, il y a les modèles qui se concentrent plutôt sur la structure du système, sur les rôles et les relations entre eux. Le modèle Moise+ est une tentative d'unification de ces deux familles, on y retrouve donc une spécification structurelle (structure du SMA) et une spécification fonctionnelle (buts à atteindre). Afin d'expliciter la manière dont les agents collaborent pour concourir aux buts communs, ces deux spécifications sont reliées par une spécification déontique. a. La spécification structurelleDans MOISE+, il existe trois concepts principaux, rôles, relations entre rôles, et groupes (Figure 7) qui sont utilisés pour structurer un SMA selon trois niveaux : individuel (comportements qu'un agent doit mettre en oeuvre lorsqu'il joue un rôle), social (relations entre rôles), et collectif (agrégation de rôles dans des structures). MOISE+ enrichit le modèle original avec des propriétés structurelles (héritage, l'inclusion de groupes) et comportementales (compatibilité, cardinalité).
c. La spécification déontique
II.3.3. GAIA
II.4. Approche Organisationnelle VS approche centrée AgentEn adoptant une approche centrée agent, la conception des SMA s'avère inappropriée dans plusieurs cas et possède plusieurs inconvénients : - Le nombre d'interactions inter-agents est imprévisible du moment où il n'y a pas de restrictions sur les interactions. - Prévoir le comportement global du système en se basant sur les comportements individuels des agents est une tâche très difficile voir même impossible vue les comportements inattendus des agents et leur caractère autonome. - Applications non sécurisées : la possibilité que tous les agents communiquent entre eux sans contrôle global peut créer des problèmes de sécurité puisqu'une intrusion d'un agent externe au système est facile à envisager. - Absence de modularité : dans les systèmes orientés objet, les entités qui opèrent ensemble sont regroupées dans des modules ou packages. L'interaction entre ces modules (essentiellement un échange de paramètre dans l'approche orientée objet) est sujette à une restriction d'accès à tous les membres. On distingue des attributs publics et d'autres privés (inaccessible depuis l'extérieur). Dans l'approche centrée agent, le principe de modularité est totalement absent puisque chaque agent est accessible depuis n'importe quel autre agent. L'approche organisationnelle vise à remédier toutes ces limites toute en : - Diminuant le nombre d'interactions entre les agents puisque la structure sociale des SMA impose des contraintes d'interactions. - Diminuant la complexité de la tâche de conception en ajoutant des concepts d'abstraction de haut niveau tel que les organisations et les groupes. - La phase de conception est indépendante des issues d'implémentation puisqu'on ne va pas penser dès la conception à construire un agent spécifique pour jouer un rôle déterminé. - Possibilité de concevoir des systèmes ouverts formés de composants hétérogènes où les architectures internes des agents ne sont pas spécifiées. - Possibilité de concevoir des systèmes sécurisés puisque l'organisation d'un groupe n'est visible que pour les agents qui appartiennent à ce groupe. - Chaque agent dispose des capacités nécessaires pour accomplir son objectif d'où l'interdépendance entre les composants du système diminue. II.5. ConclusionL'approche organisationnelle est apparue pour diminuer à la fois la complexité du système en diminuant le nombre d'interaction et l'interdépendance entre les composants, et la complexité de la conception des systèmes en introduisant des concepts d'abstraction de haut niveau tel que la structure organisationnelle. Cependant, il existe une grande confusion au niveau des concepts qui doivent être évoqués dans les modèles organisationnels proposés ainsi que les niveaux et les aspects organisationnels qui doivent être traités. En effet, selon plusieurs auteurs la conception des SMA selon une approche organisationnelle est encore mal appréhendée. Peut-on s'attendre donc à la création d'une approche standard ou à une normalisation des modèles comme ce fut le cas en orienté objets avec le langage UML? CHAPITRE III : PLATES-FORMES MUL TI-A GENTSChapitre III
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Devoirs : Actions abstraites Interventions Règles de coordination Droits : Ressources Autorisations |
Tableau 2 : Structure d'un rôle.
b. Règles
Elles sont définies comme étant les lois ou les protocoles servant à organiser les échanges inter-agents, la dynamique du système dans un environnement ouvert, l'autoorganisation, et l'attribution des rôles aux agents selon un ensemble de contraintes.
c. Groupes
Le fait de rassembler les agents en groupes permet de mieux appréhender la structure et la modularité du système. Les agents peuvent être regroupés selon certains critères : ceux qui participent par exemple à l'accomplissement du même sous-but ou ceux qui ont le même rôle.
aims
goal
link
decomposed
rules
type
have
execute
1..*
1..*
interaction protocol
attribution constraint
I/O Protocole
Role
Group
1..*
1..*
1.*
1
1..*
1..*
Task
contraintes inter-rôles
contraintes intra-rôles
assign
use
Enter/Leave
Plan
1..*
sub-goal
constituted
1..*
permissions
0..*
resou rces
1..*
1..*
agent
0..*
0..*
conversation
Organisation
have
|
1..* |
organised
1..*
capacities
obey
communicate
Figure 11 : Le modèle organisationnel [Bouslimi 2007].
Les concepts de rôle, d'organisation, de groupe, de but, de sous but, de tâche, de plan d'action, de règles et de permissions forment le niveau abstrait dans ce modèle.
Les ressources, les agents et les conversations forment le niveau concret de ce
modèle.
Il existe trois aspects principaux traités dans plusieurs travaux concernant l'organisation des SMA :
a. L'aspect structurel
C'est la description de l'aspect statique de l'organisation. Elle définit les relations entre les agents à travers les notions de groupes, rôles et liens mutuels qui sont utilisés pour structurer le SMA.
b. L'aspect fonctionnel
C'est la description de l'aspect dynamique de l'organisation à travers la spécification de but global de l'organisation, sa décomposition en sous buts et l'identification de l'ensemble de rôles qui vont exécuter ces sous buts.
c. L'aspect déontique
C'est la description des permissions, des obligations et des restrictions relatives aux rôles, à l'attribution des rôles aux agents, aux contraintes intra et inter rôles...
Cet aspect peut être définis par :
-Les protocoles d'interaction : décrient la manière avec laquelle un rôle peut communiquer avec les autres rôles ainsi que le mode de communication (synchrone, asynchrone).
-Les permissions : décrivent les ressources accessibles par un rôle et le mode d'accès à ces ressources.
-Les contraintes inter-rôles : concernent la cardinalité des agents qui peuvent jouer le même rôle en même temps.
-Les contraintes intra-rôles : dans une organisation d'un SMA, un agent peut jouer un ou plusieurs rôles en même temps. Ce type de contraintes interdit le fait q'un agent peut jouer deux rôles conflictuels en même temps, tel est l'exemple d'acheteur et de vendeur.
-Les capacités : décrivent les caractéristiques d'un agent (autonome, réactif, proactif, social ...)
-Les protocoles d'entrée /sortie : définissent les conditions qu'un agent doit satisfaire pour s'introduire ou quitter une organisation.
Ce problème nécessite la coopération de plusieurs sources d'informations relatif aux différents thématiques : de transport, d'horaire, d'hébergement, ...ce qui nécessite sa décomposition en deux grands sous problèmes : celui de transport et l'autre de
l'hébergement pouvant eux même être décomposés en d'autres sous problèmes plus simples en vue d'obtenir des simples tâches de recherche d'informations. Le schéma suivant (Figure 12) donne une vue global sur ce problème.
I
Hebergement
|
Transport |
I |
I I
A
A
A I
|
A A |
|
A I
Voyage
Transport
par Avion
Transport
par Train
I I
I
Coût_train Gares Coût_avion
Num_vol Aéroports
A
Date_début Date_fin
I
A I I
A
A
G_départ G_arrivée
Prix_train Tarifs_train
TarifsAjeune TarifsA_famille
Tarifsjeune Tarifs_famille
RA(=)
A _départ A_arrivée
Prix_Avion Tarifs_Avion
Horaire
A A A A
A A
|
Heure_départ |
Date_départ Heure_arrivée |
Date_arrivée |
A
Type Adresse Prix DatesHébergement
I
A A A
Légende :
I : Inclusion
A :
Agrégation
RA(-) : relation de compatibilité entre
attributs
Figure 12 : Le problème de voyage
Dans notre exemple, un voyageur demande au système de lui organiser un voyage selon les préférences qu'il souhaite. Le système décompose cette tâche en deux sous tâches : organisation de transport et organisation d'hébergement. Le premier sous problème concernant le transport est à la base de fournir la liste des voyages disponibles conformément aux spécifications et aux préférences de l'utilisateur à propos de la destination, du départ, de la date et du moyen de transport. Une fois que ce sous problème est résolu, le souci sera l'hébergement à la ville de destination qui doit respecter la contrainte que la date d'arrivée devant correspondre à la date du début de l'hébergement. Ce problème nécessite la coopération entre plusieurs rôles pour être résolu puisqu'il nécessite la décomposition en plusieurs sous problèmes reliés entre eux et impliquant des traitements en parallèle et des interactions entre les différents rôles. Ceci justifie notre adoption d'une approche multi-agents pour la résolution de ce problème.
Il s`agit de concevoir un SMA qui a pour but de rechercher et d'extraire des informations à partir des différentes sources d'informations afin de répondre à des requêtes externes dans le but de l'organisation d'un voyage selon les préférences du voyageur.
L'objectif global de notre application est de récupérer des informations afin de répondre à des requêtes externes, cet objectif peut être décomposé en plusieurs sous buts :
-Réception des spécifications de l'utilisateur
-Décomposition du problème en sous problèmes plus simples -Recherche de source d'information convenable
-Extraction des informations utiles.
-composition du résultat final.
Ceci nous mène à distinguer les rôles suivants (Figure 13) : - Rôle Médiateur
Ce rôle assure les tâches suivantes : recevoir les requêtes externes au système et les reformuler en un langage compris par les agents.
Par la suite décomposer ces requêtes, les transformer en sous requêtes plus simples et les distribuer aux coordinateurs. Et enfin réunir les réponses de ces sous requêtes pour former la réponse à la requête d'origine.
- Rôle Coordinateur
Il est chargé d'exécuter des sous requêtes provenant du médiateur. Il est en communication avec le Matchmaker en vue d'avoir des informations sur les adresses des traducteurs capables de répondre à ses sous requêtes.
- Rôle Matchmaker :
Il Fournit aux coordinateurs les adresses des traducteurs capables de répondre aux services demandés.
- Rôle Traducteur :
Il est associé à une source d'information, traduit la question posée par le coordinateur dans le langage de requête de cette source et convertit les informations extraites de sa source dans un langage compréhensible par le coordinateur.
Spécification de l'utilisateur
Médiateur
Utilisateur
Coordinateur
Coordinateur
Traducteur
Matchmaker
Traducteur
Source
d'information
Source
d'information
Figure 13 : Structure du système. b. Spécification des rôles
Dans cette partie on va détailler les différents rôles conformément à la structure déjà définie par le modèle organisationnel.
Pour présenter l'ordre des enchaînements des tâches ainsi que le nombre d'occurrence, on a utilisé le formalisme de notation suivant :
T1 + T2 : la tâche T1 suivie de T2.
T1 || T2 : les deux tâches peuvent s'exécuter en parallèle. T* : la tâche T se répète plusieurs fois.
Après la saisie des données par l'utilisateur et le lancement de la recherche, il y aura création d'un agent qui va jouer le rôle Médiateur dont le but principal est de collecter les spécifications de l'utilisateur, de les reformuler, de décomposer le problème, stocker les résultats qui proviennent et enfin les réunir pour composer le résultat final (Figure 14).
Médiateur
Devoirs
Actions abstraites :
· T1 : Reformulation de la requête de l'utilisateur
· T2 : Décomposition de la requête en sous requêtes
· T3 : Stocker les résultats reçus
· T4 : Composition du résultat final
Interventions :
· T5 : Réception des spécifications de l'utilisateur
· T6 : Envoie des sous requêtes aux coordinateurs
· T7 : Réception des résultats des coordinateurs
· T8 : Envoie de la réponse finale à l'utilisateur Règle de coordination : T5+T1+T2+ (T6+ T7+T3)* +T4+T8 Droits
Ressources : Ø
Autorisations : Ø
Figure 14 : Rôle Médiateur.
Une fois que l'agent jouant le rôle Médiateur a envoyé ses sous requêtes, il y aura création de deux agents qui vont jouer le rôle Coordinateur (Figure 15), chacun d'entre eux va envoyer une demande de recrutement d'un Traducteur auprès du Matchmaker, lors de la réception du l'adresse du Traducteur, il envoie la sous requête au Traducteur correspondant, et il communique le résultat reçu au Médiateur.
Coordinateur
Devoirs
Actions abstraites :
· T1 : demande de recrutement d'un traducteur au Matchmaker Interventions :
· T2 : Réception de sous requêtes provenant du médiateur
· T3: Réception de l'adresse du traducteur
· T4 : Envoie de sous requête au traducteur concerné
· T5 : Réception du résultat du traducteur
· T6 : Envoie du résultat au médiateur
· T7 : Envoie d'informations supplémentaires
Règle de coordination : T2+T1+T3+T4+T5+ (T6||T7)
Droits
Ressources : Ø
Autorisations : Ø
Autorisations : Lecture
Figure 15 : Rôle Coordinateur.
L'agent jouant le rôle Matchmaker (Figure 16) a pour principal but de fournir à l'agent jouant le rôle Coordinateur la liste des Traducteurs capables de répondre à ces besoins.
Matchmaker
Devoirs
Actions abstraites :
· T1 : sélection de traducteur convenable
Interventions :
· T2 : réception de requête de coordinateur
· T3 : réception de publication de capacités de traducteur
· T4 : envoie de l'adresse de traducteur au coordinateur Règle de coordination : (T3*) || (T2+T1+T4)
Droits
Ressources : Ø
Autorisations : Ø
Figure 16 : Rôle Matchmaker.
Chacun des deux agents Coordinateur va communiquer la sous requête qui lui provient du Médiateur à un agent Traducteur (Figure 17) affecté à une source d'information. Après avoir publié ses capacités chez le Matchmaker et recevoir les sous requêtes, l'agent jouant le rôle Traducteur convertit ces sous requêtes reçues en langage de requête de la source d'information qui lui est affectée. Par la suite, il extrait les informations utiles de cette source, traduit les résultats obtenus en langage de communication des agents et enfin il les envoie à l'agent jouant le rôle Coordinateur.
Traducteur
Devoirs
Actions abstraites :
· T1 : traduction de la requête reçue en langage de requête de son système
d'information
· T2 : extraction des informations
· T3 : traduction de résultat en langage compréhensible par l'agent Interventions :
· T5 : publication des capacités
· T6 : Réception de sous requête de coordinateur
· T7 : envoie de sous requête à la source d'information
· T8 : réception du résultat
· T9 : envoie du résultat à l'agent coordinateur
Règle de coordination : (T5 *)| | (T6+T1 +T7+T2+T8+T3+T9)
Droits
Ressources : base de données
Autorisations : lecture
Figure 17 : Rôle Traducteur. c. Contraintes d'attribution des rôles
- Contraintes intra-rôles
Le système qu'on souhaite développer se base sur un ensemble d'agents travaillant en coopération afin d'accomplir un objectif globale. Chaque agent, amené d'accomplir un tel sous objectif, est chargé d'exécuter un ou plusieurs rôles à condition que ceux-ci ne soit pas conflictuels. Dans notre système chaque agent est chargé d'exécuter un rôle unique.
L'agent jouant le rôle Médiateur par exemple ne peut exécuter que ce rôle au sein de l'organisation (présenté par la notation conflit dans le Tableau 3).
- Contraintes inter-rôles
Ce type de contrainte définie la cardinalité des agents qui peuvent jouer le même rôle en même temps au sein d'une même organisation. Concrètement, notre système inclut d'une part des rôles attribués chacun à un seul agent, le cas de l'agent jouant le rôle Matchmaker, de l'autre part, il inclut des rôles attribués chacun à plusieurs agents, le cas des agents jouant le rôle Traducteur, de même les agents jouant le rôle coordinateur (Tableau 3).
|
Médiateur |
Coordinateur |
Matchmaker |
Traducteur |
|
|
Contrainte intra-rôle |
Conflit |
Conflit |
Conflit |
Conflit |
|
Contrainte inter-rôle |
1..1 |
1..2 |
1..1 |
1..2 |
Tableau 3 : Les Contraintes d'attribution des rôles.
Après la spécification fonctionnelle des rôles, le diagramme de séquences présenté par la Figure 18 suivante donne une vue globale sur les interactions entre ces différents rôles.
Figure 18 : Diagramme de séquence des rôles
47
Dans cette figure, un utilisateur saisie ses préférences concernant son voyage. Le Médiateur décompose le problème en deux sous problèmes et les sous-traite à deux Coordinateurs. Chaque Coordinateur envoie au Matchmaker une demande pour lui fournir l'adresse d'un traducteur pouvant répondre aux sous requête qu'il prend en charge. Le Matchmaker répond à chaque Coordinateur en fournissant l'adresse du Traducteur sélectionné. Chaque Coordinateur peut ensuite sous-traiter auprès du Traducteur correspondant la sous requête qu'il prend en charge. Chaque traducteur accède à la source de donnée qui lui est affectée pour extraire les données nécessaires. Lorsque tous les Coordinateurs fournissent la réponse au Médiateur, celui-ci peut composer ses réponses et fournir le résultat à l'utilisateur.
Dans ce chapitre, on a adopté une approche organisationnelle pour la conception de notre système. Ceci a pour avantages de diminuer la complexité de la tâche de conception en ajoutant des concepts d'abstraction de haut niveau tel que les organisations, les groupes, les rôles...Et d'assurer l'indépendance entre la phase de conception et celle d'implémentation puisqu'on ne va pas penser dès le début à construire un agent spécifique pour jouer un rôle déterminé. Dans le chapitre qui suit on va passer au développement de notre système.
V.1. Introduction
Après avoir identifié les différentes fonctionnalités de notre système à travers la décomposition fonctionnelle de l'objectif global de l'organisation et la détermination des différents rôles qui composent notre application, nous allons passer à la dernière phase de notre projet : l'implémentation du SMA. Nous allons alors mettre en oeuvre la démarche conceptuelle adoptée dans le chapitre précédent afin d'aboutir à une organisation concrète d'un SMA d'ACI.
Le présent chapitre est structuré comme suit : la section 2 est consacrée à la description des outils logiciels utilisés lors du développement de notre application à savoir la plate-forme MADKIT et les deux SGBD MySQL et Access. La section 3 est dédiée à une présentation des schémas conceptuels des bases de données utilisées, de l'architecture d'implémentation du système et de quelques interfaces. Enfin, nous exposerons les conclusions de cette phase et dégagerons quelques perspectives.
V.2. Outils de développement de l'application V.2.1. Plate-forme MADKIT
Comme nous l'avons déjà mentionné, notre système est développé sur la base de la plate-forme Madkit qui est une plate-forme destinée au développement et à l'exécution des SMA fondés sur des critères organisationnels (groupes et rôles).
En fait, la plate-forme Madkit est basée sur un MO (le modèle AGR) qui permet en particulier de caractériser les agents en utilisant la notion de groupe et de rôle.
Dans cette partie on va s'intéresser avec plus de détails aux aspects techniques de la structure et des fonctions des agents dans cette plate-forme qui propose une librairie de classe JAVA pour la réalisation de ces agents.
Structure et fonctions d'un agent
La classe de base d'un agent MadKit (AbstractAgent)[URL 3], définit quelques fonctionnalités de base qui sont associées à chaque agent et qui sont :
· Cycle de vie
Le cycle de vie d'un agent est composé d'une séquence de quatre états : création, activation, exécution, et destruction.
Les agents héritant de la classe Agent doivent implémenter les méthodes suivantes:
public void activate() : qui est lancée lors de l'initialisation de l'agent
public void live() : qui définit le comportement permanent de l'agent.
On peut également employer la méthode end(), qui est appelée par le noyau si on lui demande d'arrêter l'agent.
· Communication
La communication est implémentée sous forme de passage de message asynchrone, soit d'un agent à un autre identifié par son AgentAddress ou son groupe et rôle, soit sous la forme d'une diffusion à tous les teneurs d'un rôle dans un groupe donné.
· Organisation
Tout agent dispose de primitives permettant d'observer son organisation locale (connaître les groupes et rôles courants) et d'y agir (prise de rôle, entrée et retrait d'un groupe).
· Outils
La classe de base des agents permet également de manipuler une éventuelle interface graphique associée à l'agent, les flots d'entrée/sortie ...
· MessagesLes messages sont définis par héritage à partir d'une classe de base Message qui ne définit que la notion d'émetteur et de destinataire. Une bibliothèque de messages de base (Figure 19) est néanmoins fournie et permet l'envoi de chaînes, d'objets sérialisés, de documents XML, ou bien de messages conformes aux spécifications KQML et FIPA-ACL.
AbstractMessage
Message
|
|
|
||||||||
|
||||||||||
|
|
|||
Figure 19 : Hiérarchie des messages standards dans Madkit.
Une base de données permet de mettre des données à la disposition des utilisateurs pour une consultation, une saisie ou bien une mise à jour, tout en respectant leurs droits. La gestion de la base de données se fait grâce à un système appelé système de gestion de bases de données (SGBD)
Un SGBD est un ensemble de services (applications logicielles) permettant de gérer les bases de données : permet d'accéder aux données d'une façon simple, d'autoriser un accès aux informations à de multiples utilisateurs et de manipuler les données présentes dans la base de données...
Dans notre application, nous avons opté aux choix de deux SGBD Access et MySQL pour la consultation et l'extraction des informations indispensables de répondre aux requêtes externes provenant de l'utilisateur.
· SGBD Access
Microsoft Access est un Système de Gestion de Base de Données Relationnel (SGBD-R) présentant une approche bureautique et n'est pas conçu pour supporter de très grandes bases de données opérationnelles sur de vastes réseaux. En Java, Microsoft Access peut être utilisé de façon transparente à l'aide de la passerelle JDBC-ODBC [URL 4].
· SGBD MySQL
MySQL est dérivé de SQL (Structured Query Language), en français, langage de requête structurée. C'est un système de gestion de base de données relationnel. Concrètement, SQL permet de dialoguer avec une base de données en langage presque courant. SQL s'utilise surtout via une fenêtre de commande, MySQL s'utilisant via un langage de programmation, PHP étant le langage de prédilection de MySQL. Le meilleur moyen de se mettre à MySQL et de progresser est d'installer EasyPHP. EasyPHP est un logiciel freeware qui crée un environnement serveur complet à la fois pour PHP et MySQL[URL 4].
Il est à noter que les deux SGBD présentés ci-dessus, sont utilisés afin de concevoir et réaliser deux Base de Données différentes et qui vont constituer par la suite nos deux sources d'informations depuis lesquelles nous allons extraire les données nécessaires afin de répondre à la requête de l'utilisateur.
V.3. Présentation de l'application V.3.1. Architecture du système
Le but essentiel de notre travail est la réalisation d'un SMA d'acquisition coopérative d'informations pour l'organisation d'un voyage en gérant les préférences de l'utilisateur. On va préciser dans cette partie comment se déroule le traitement d'un tel problème : L'utilisateur soumet son problème à l'interface et reçoit par la suite une réponse à sa requête .Cette réponse est assurée via un ensemble d'agents qui vont être en communication continuelle afin de répondre d'une manière coopérative à la requête posée par l'utilisateur. Les agents formant notre système sont :
- Un agent jouant le rôle Médiateur qui va se charger de la décomposition de problème en deux grands sous problèmes le premier concernant le voyage, et le deuxième concernant l'hébergement.
- Deux agents jouant le rôle Coordinateur : Coordinateur 1 et Coordinateur2.
Le Coordinateur 1 va se charger du premier problème concernant le voyage et le
Coordinateur2 va prendre la charge du deuxième problème concernant l'hébergement.
- Un agent jouant le rôle d'un Matchmaker qui va localiser les agents capables de
répondre à une requête donnée.
- Deux agents jouant le rôle Traducteur : Traducteur 1 et Traducteur2.
Le premier agent sera affecté à une source de données Access disposant des données sur les voyages, et le deuxième sera affecté à une source de données MySQL.
La figure référencée Figure 20 présente une vue globale sur l'architecture de notre
SMA.
Figure 20 : Architecture du système.
Comme nous l'avons déjà mentionné, la réalisation de notre système nécessite la coopération de plusieurs sources d'informations différentes. En fait pour pouvoir organiser un voyage, il faut disposer de plusieurs informations relatives à ce type de problème : des informations sur les voyages disponibles, les dates de départ et d'arrivées des voyages, les horaires, les prix...notamment des informations sur l'hébergement : les hôtels disponibles, les adresses des hôtels, les disponibilités des chambres ...
Les informations concernant le voyage sont stockées dans une base de données Acces s dont le modèle conceptuel présenté par la Figure 21.
Figure 21 : Table Voyage.
Les informations concernant l'hébergement sont stockés dans une base de données MySQL, Le modèle conceptuel de cette base est présenté ci-dessous (Figure 22).
date
de but
date
fin
HOTEL
NumHotel no m_hote l ville
rue
Chambre
NumChamb re
Correspond
0, n
1,1
Reservation
1,1
1,n
Appartient
NumReservati on
_
_
Figure 22 : Modèle Conceptuel de la base Hébergement.
Le modèle logique de cette base de données est le suivant :
Hôtel (Num_Hotel, NomHoltel, Rue, CodePostal) ;
Chambre (Num_Chambre, #Num_Hotel) ;
Réservation (Num_Réservation , #Num_Chambre, Date_Debut , Date_Fin) ;
V.3.3. Captures d'écran a. Interface de l'application :
Figure 23 : Interface de l'application
La figure ci-dessus (Figure 23) représente l'interface principale de l'application.
Cette interface est en fait un agent MadKit disposant de certaines capacités et qui est dans notre cas l'agent Médiateur qui se charge de la réception du problème provenant de l'utilisateur, et par la suite le décomposer et l'envoyer aux coordinateurs.
L'interface permet aux utilisateurs d'effectuer leurs requêtes et permet aussi de gérer leurs préférences.
Pour cela l'interface est composée de :
- six listes de choix, la première pour le choix de moyen de transport, la deuxième pour le choix de la ville de départ, la troisième pour le choix de la ville de destination, et trois listes pour le choix de la date désiré : jour, mois et année.
- quatre boutons d'option : Les deux premier pour le choix de type de tarif : soit tarif jeune soit tarif famille. Si le tarif choisi est jeune, le voyageur va bénéficier d'une réduction de 20% sur le prix de son voyage.
Les deux autres boutons d'option sont pour le choix de la date désirée pour le voyage : soit la date de départ, soit la date d'arrivée.
- deux boutons : bouton Rechercher pour lancer la recherche des voyages et des hôtels disponibles, bouton Quitter pour quitter l'application
b. Les interfaces des agents
Comme nous l'avons signalé, notre SMA est composé d'un ensemble d'agent communicant tout le long de leur cycle de vie de façon continue afin de répondre d'une manière coopérative à la requête posée par l'utilisateur. Cette communication est assurée via un échange de messages String entre les différents agents du système. En effet, dès le lancement de la recherche, le Médiateur se charge de lancer tous les autres agents du système qui vont par la suite résoudre le problème reçu d'une manière coopérative jusqu'à l'obtention du résultat final.
Lors du fonctionnement de chaque agent, il indique qu'il est entré dans la communauté associée au projet à lequel il appartient, aussi dans le groupe qui lui correspond avec le rôle qui lui est attribué. Par exemple dans la Figure 24 l'agent Médiateur indique qu'il appartient à la communauté travel, et joue le rôle médiateur dans le groupe nommé Gmed.
Dans cette interface on peut également visualiser les différents messages reçus par
l'agent.
Dans ce qui suit on va présenter les interfaces affectées à chaque agent tout le long de son cycle de vie.
Figure 24 : Interface Médiateur.
Figure 25 : Interface Coordinateur 1.
Figure 26 : Interface Coordinateur2.
Figure 27 : Interface Matchmaker
Figure 28 : Interface Traducteur 1.
Figure 29 : Interface Traducteur2.
Il est possible de voir le fonctionnement des agents en utilisant le GroupObserver (Figure 30) qui est un agent Madkit qui permet d'observer la structure organisationnelle du système, c'est-à-dire l'ensemble des groupes et des rôles et la participation des agents aux groupes et aux rôles.
Figure 30 : Agent GroupObserver.
Le GroupObserver permet aussi de tracer les messages qui ont lieu entre les agents et notamment tous les messages à l'intérieur d'une communauté ou d'un groupe. La Figure 31 représente un exemple d'échange de messages entre les agents du système lors de la réception d'une requête.
Figure 31 : Exemple des messages échangés par les agents.
c. L'interface résultat
L'interface résultat représente le résultat final affiché par l'agent médiateur après avoir reçu les résultats provenant des agents coordinateurs.
La figure 32 est une capture d'écran d'un résultat proposé à un utilisateur, suite à une demande d'organisation de voyage.
L'interface est composée de deux tableaux :
- Le premier affiche les informations concernant les différents voyages disponibles correspondant aux préférences saisies par l'utilisateur : le numéro de voyage, les dates de départ et d'arrivée, l'heure de départ et d'arrivée de voyage.
- Le deuxième affiche les informations concernant les hôtels se trouvant dans la ville de destination choisie, et qui doivent être disponibles à la date d'arrivée du voyageur et disposer des chambres non réservés.
Figure 32 : Interface Résultat.
Pour un accès rapide à notre système, on a le choix d'accéder soit par double click sur l'icône de bureau portant le nom `Organisation de Voyage' soit par le menu démarrer du desktop MadKit :MadKit>SMA>Organisation de Voyage comme le présente Figure 33 :
Figure 33 : Menu principal.
Dans ce chapitre, nous avons présenté le volet technique de notre application. Il s'agit d'un système composé d'un ensemble d'agents qui se communiquent d'une manière continue et qui se chargent de la recherche et de l'extraction des informations dans le but de répondre d'une manière coopérative à une requête externe.
On a définit les aspects techniques utilisés lors de l'implémentation de notre SMA tels que la plate-forme Madkit et les SGBD-R Access et MySQL, et on a présenté les différents composants de notre système : les différents agents présentés via les captures d'écran.
On a respecté aussi les divers rôles et fonctionnalités fixés dans la phase de conception lors de développement de notre application et lors de la création des différents agents composant notre système.
Toutefois, des améliorations sont toujours envisageables :
- La structuration des messages échangés en utilisant des langages plus évolués tel que KQML et FIPA-ACL
- Déployer l'application dans le cadre du Web, ainsi les sources d'informations seront des sites hétérogènes et l'accès sera assuré via des API tel que Google ou Yahoo.
On s'est intéressé dans ce travail à l'un des nouveaux paradigmes en informatique, présent actuellement comme un champ de recherche très actif, celui des Systèmes MultiAgents (SMA). Ce paradigme est apparu pour répondre aux exigences des applications complexes dont la réalisation nécessite la coopération entre plusieurs entités (agents). Le concept de base de ce domaine est la notion d'agent, qui représente une entité autonome capable de percevoir, de représenter et d'agir sur son environnement.
Les premiers SMA implémentés se sont focalisés sur la rubrique la plus fine qui est celle de l'agent. D'où l'émergence des travaux qui ont porté sur le modèle de raisonnement des agents tel que l'approche BDI. Par la suite, et vu la constatation du caractère social des agents qui existent souvent dans le cadre d'un SMA, l'accent est mise sur une nouvelle approche de conception : l'approche organisationnelle. Cette approche se base sur des concepts de plus haut niveau d'abstraction tel que les groupes, les rôles, les protocoles d'interactions, les normes et les permissions. Elle peut être vue comme une technique qui sert à contraindre les comportements individuels des agents vers les objectifs globaux à satisfaire. On part alors d'une organisation conçue par les développeurs du SMA pour arriver aux comportements individuels de chaque agent. C'est dans ce contexte que se situe notre travail qui consiste en l'adoption d'une approche organisationnelle pour la conception est l'implémentation d'un SMA dévoué au domaine de l'Acquisition Coopérative d'Informations (ACI).
Ce travail nous a permis d'aborder des domaines originaux par rapport aux études effectuées lors de notre cursus universitaire :
- Le domaine des SMA et plus précisément leur aspect conceptuel ;
- Le domaine d'ACI appliqué au problème d'organisation de voyage ;
- L'aspect technique relatif au développement des SMA via la plateforme
MadKit.
Le système développé a pour principal objectif de rechercher et d'extraire des informations à partir de sources d'informations différentes et hétérogènes afin de répondre à des requêtes externes. Notre contexte applicatif était l'organisation de voyage et le souci
de notre SMA était de fournir la bonne réponse devant être conforme aux besoins de l'utilisateur. Ceci est assuré moyennant la plate forme Madkit.
Toutefois, des améliorations sont envisageables :
- Tenir compte de l'interaction avec l'utilisateur lors de l'exécution. En effet, l'utilisateur peut interagir avec le système pour mentionner ses préférences ou reformuler sa requête initiale. Cet aspect est relativement difficile à réaliser et représente une lacune de plusieurs systèmes d'ACI présents dans la littérature ;
- Utiliser des API tel que Google ou Yahoo comme sources d'informations au lieu d'un simple SGBD ;
- Evaluer expérimentalement l'apport de l'adoption d'une approche organisationnelle par rapport à une approche centrée-agent.
1. Scripts de création de la base de données Hébergement
Dans cette partie on va s'intéresser à présenter les scripts de création des bases de données, générés par le logiciel AMC designer, dédié essentiellement au développement des applications à base de méthode de conception MERISE. Ces scripts sont générés suite au modèle conceptuel de donnée (MCD) qu'on a élaboré et qui est présenté dans le chapitre d'implémentation.
On va commencer par les scriptes de création de la base de données Hébergement et de scripts de leurs tables : HOTEL, CHAMBRE et RESERVATION .
-- Nom de la base : HEBERGEMENT -- Nom de SGBD : MySQL
-- Date de création : 30/04/2008 04:03
|
Create database HEBERGEMENT ; |
|||
|
-- Table: HOTEL |
|||
create table HOTEL
( NUMHOTEL varchar(20) not null,
NOM _HOTEL varchar(30) null ,
VILLE varchar(10) null ,
CODEPOSTAL varchar(10) null ,
RUE varchar(30) null ,
constraint PK_HOTEL primary key
(NUMHOTEL)
);
|
-- Table: CHAMBRE |
|||
|
create table CHAMBRE; |
( NUMCHAMBRE varchar(20) not null,
NUMHOTEL varchar(20) not null,
constraint PK_CHAMBRE primary key (NUMCHAMBRE)
|
); |
|||
|
-- Index: LIER_FK |
create index LIER _FK on CHAMBRE (NUMHOTEL asc); /
-- Table: RESERVATION
create table RESERVATION
(
NUMRESERVATION varchar(20) not null,
NUMCHAMBRE varchar(20) not null,
DATE_DEBUT date null ,
DATE_FIN date null ,
constraint PK_RESERVATION primary key (NUMRESERVATION)
);
====================================================
-- Index : ASSOC_6_FK
====================================================
create index ASSOC_6_FK on RESERVATION (NUMCHAMBRE asc)
/
alter table CHAMBRE
add constraint FK _CHAMBRE _LIER _HOTEL foreign key (NUMHOTEL)
references HOTEL (NUMHOTEL)
/
alter table RESERVATION
add constraint FK _RESERVAT _ASSOC_6 _CHAMBRE foreign key (NUMCHAMBRE) references CHAMBRE (NUMCHAMBRE)
/
Celui-ci correspond au script de création de la base de données VOYAGE exécutée par le SGBD Access, elle ne contient que la table voyage contenant l'ensemble des voyages.
2. Scripts de création de la base de
données Voyage
-- Nom de la base : VOYAGE
create database VOYAGE
|
/ |
||||
|
-- Table : VOYAGE |
||||
create table VOYAGE (
NUM_VOYAGE TEXT not null,
DATE_DEPART DATE not null,
DATE_ARRIVEE DATE not null,
HEURE _DEPART DATE null ,
HEURE _ARRIVEE DATE null ,
VILLE _DEPART TEXT null ,
VILLE _ARRIVEE TEXT null ,
PRIX FLOAT(10) null );
RÉFÉRENCES BIBLIOGRAPHIQUES
Références Bibliographiques
[Bouslimi 2007] Bouslimi I, Barika F. (2007). A multi-agent organizational design of a distributed intrusion detection system
[CAS 1996] Castelfranchi C., Commitments : From Individual Intentions to Groups and Organizations.
[CAS 1998] Castelfranchi C., Modeling Social Action for AI Agents.
[Demazeau 1997] Demazeau, Y. (1997). Steps towards multi-agent oriented programming. In First international workshop on multi-agent systems.
[Erceau 1991] J.Erceau. J.Feber . 1991. L`Intelligence Artificielle Distribuée. [Ferber 1995] J. Ferber. Les systèmes multi-agents, vers une intelligence collective. [Ferber 1998] J.Feber, design of organizations in multi-agent systems.
[Finin 1994] T. Finin and R. Fritzson. KQML: a language and protocol for knowledge and information exchange.
[Fox 1981] Fox, M. (1981). An organizational view of distributed systems. In IEEE Transactions onSystems, Man, and Cybernetics.
[HAN 2000] Hannoun M., Boissier O., Sichman J, Sayettat C.,MOISE : An Organizational Model for Multi-A gent Systems
[Gutknecht, 2001] Gutknecht, O., Michel, F., et Ferber, J. (2001). Integrating tools and infrastructures for generic multi-agent systems. In Proceedings of Autonomous Agents 2001 conference.
[Gutknecht et al ., 2004] Gutknecht, O., Ferber, J., et Michel, F. (2004). From agents to organizations : an organizational view of multi-agent systems.
[Hoc 1 996]Hoc, J.M (1996) supervision et contrôle de processus la cognition en situation dynamique
[Hübner et al. . 2002] Hübner, J. F., Sichman, J. S., and Boissier, O. (2002). A model for the structural, functional, and deontic specification of organizations in multiagent systems.
[Malone 1988] Malone T. W. (1988) What is coordination theory.
[Müller 1996] J. P. Müller. The Design of Intelligent Agents - A layered Approach. [Ricordel 2001] P.-M. Ricordel. Programmation Orientee Multi-Agents : Developpement et Déploiement de Systèmes Multi-Agents Voyelles.
[Russell et Norvig 1995] : Russell, S. and Norvig, P. (1995). Artificial Intelligence : a Modern Approach.
[Wooldridge 1998] : Wooldridge, Jennings, Sycara, A Roadmap of Agent Research and Development
[Wooldridge et al. 2000] M. Wooldridge, N. R. Jennings, and D. Kinny. The Gaia
Methodology For Agent-Oriented Analysis and Design
.
Liste des URLs
[URL 1]: www.turing.cs.pub.ro/auf2/html/chapters/chapter1/chapter_1_2_4.html [URL 2]: www.limsi.fr/~jps/enseignement/examsma/2005/1.plate-formes_3 [URL 3]: http://www.madkit.org
[URL 4] : http://www.Wikipédia.org
