Conception et réalisation d'un système multi- agents pour les enchères en ligne

2009-2010

Conception et réalisation d'un système

multi-agents pour les enchères en ligne

Chouchane Med Redha Sahraoui Yacine

Ministère de l'enseignement supérieur et de la recherche scientifique
Université Larbi Ben M'hidi d'OEB

Département d'informatique

Mémoire de fin d'études

Pour l'obtention du diplôme
d'Ingénieur d'Etat en informatique

Option : Systèmes parallèles distribués

Thème

Conception et réalisation d'un système

multi-agents pour les enchères en ligne

Réalisé par : Encadré par :

-Mr SAHRAOUI Yacine -Mr Berkane Mohamed

-Mr CHOUCHENE M^ed Redha

IRgrng~cigrngnts



throub temetcionb Ale tout puibbant de noub avoit donne la fotce et le couta~e pout taalibet ce ttavail.

2l ebt toujoutb delicat de temetciet l'enbemdle deb petbonneb ?ui ont conttibud a l'ahoutibbement de ce ttavail de tliabe. Que ceux ?ui ne bont pab mentionnab ne noub en tiennent pab ti~ueut..

throub temetcionb donc vivement notte enbei~nant _cfietkane diolamed, de noub avoit ptopobe ce bujet et de noub avoit encadté conjointement pendant celle-ci. et pout beb nombteux conbeilb .

throub le temetcionb encote pout ba dibponibilité, et ba toactivité a la lectute et a la cottection de nob documentb, et de bon boutien.

throb temetciementb itont natutellement vetb toub ceux ?ui ont accept~ avec bienveillance de patticipet aujut# de thebe.

_cfnfin un ~tand metci a toub nob amib ~ui noub ont encoutage de ptab ou de loin pendant la fin de ce thebe.

Vdicacs

Se dadie ce ttavail :

cc me, &cab elLetb patella, ri font tosyoutb a 'nab aotab a
tout moment. Qua _cpieu voub =cattle une longue et houteube
vie ;
cc mon. cleat Imp ;
e 'nab datab bcautb ;
cc moo cleat ftete dtgick ri n.'on.tjamaib came de me boutenit ;
0⁴¹ tore met andb, r11~ mexeubent de ne lab avoit pub eitab ;
cc notte quiee national de football ri hanote l'ofetia.

lacine.

DED1CACE

A votes pareits
A votes sceurs

VOWS VOWS rtes olepews6s pour ma saws compter.
ew recowwai.ssawce de tour Les snort-Roes cowsewti.s par tour et
cknout pour vote perw.ettre ot'attei,144tre cette 6tape de ma vile.
Avec toute ovta tewolresse.

atte olittt VOWS prote e et Vous b6wisse

A vt,ta raioe voi.re , votes otn.cLes, taintes, cottstins et coustints.
vows avez de pr.s ott de Law cowtri,lott6 A wta forovtattow.

Affectueuse recoWN411.ssawoe

A tout Les novas A A1,14, B,ei,ola et ailLeurs

A outs camarades orattolitares et tour pew( de La facuLt6 des scitinzes exacter de
L'RtAlversi,t6 Luria 13etn, Mlitoli,.

Je Mate ce travail.

Sommaire

Résumé 1

Problématique et objectifs 2

CHAPITRE I: Le système client/serveur.

1. Introduction 4

2. Le paradigme client/serveur 5

3. Présentation du modèle client/serveur 5

3.1. Caractéristiques du serveur 6

3.2. Caractéristiques du client 7

3.3. Point commun entre le client et le serveur 7

3.4. Caractéristiques du modèle client/ serveur 7

4. Le modèle pair à pair 9

4.1. Présentation du modèle pair- à-pair 9

4.2. Caractéristiques du modèle pair- à-pair 9

4.3. Typologies du modèle pair-à- pair 10

4.3.1. Le modèle centralisé 10

4.3.2. Le modèle hybride 11

4.3.3. Le modèle pur 12

4.3.4. Synthèse des typologies du modèle pair- à-pair 12

4.4. Avantages et inconvénients du pair- à-pair 13

5. Types de conceptions client/ serveur 14

5.1. Conception à 2 niveaux 14

5.2. Conception à 3 niveaux 14

5.3. Comparaison des deux types de conceptions 15

6. Synthèse 15

7. Conclusion 17

CHAPITRE II: La vente aux enchères en ligne.

1. Introduction 19

2. Définition de l'e-commerce et ces types 19

2.1. Définition 19

2.2.Les formes du commerce électronique 20

3. Fonctionnement de la vente aux enchères en ligne 21

3.1. La théorie des enchères 22

4. Avantages de la vente aux enchères en ligne 22

5. Les paramètres des enchères 23

6. Protocoles d'enchère 23

6.1. Enchère anglaise (premier-prix offre-publique) 23

6.2. Enchère premier-prix offre-cachée 24

6.3. Enchère hollandaise (descendante) 24

6.4. Enchère Vickery (deuxième-prix offre-cachée) 24

6.5. Enchères tous-payent 24

7. Problèmes avec les protocoles d'enchère 26

8. Exemples de sites Web de vente aux enchères 26

9. Le centre commercial virtuel 26

10. Traitement du paiement 28

11. Conseils concernant la protection des transactions en ligne 30

12. Conclusion 30

Chapitre III : Les agents & Les systèmes multi-agents

1. Introduction 32

2. L'agent :définitions 32

2.1. Définition de Woodbridge 32

2.2. Définition de Ferbert 32

2.3. Définition de Maes 33

3. Propriétés d'un agent 33

4. Classement des agents 33

4.1.relatives à leur réactivité 33

4.2.par rapport à leur mobilité 34

5. Le rôle 35

6. Le comportement 36

7. L'agent comme entité d'un système 36

7.1. Définition d'un système multi-agent(SMA) 36

7.2. Caractéristiques d'un SMA 37

8. Architecture du SMA 37

8.1. Organisation centralisée 37

8.2. Organisation libre (non centralisée) 38

9. L'environnement 38

10. Communication entre les agents 39

10.1. Communication asynchrone 39

10.2. Communication synchrone 39

10.3. Communication directe (monocast) 40

10.4. Communication en groupe de diffusion (multicast) 40

10.5. Transport des messages 40

11. Format d'échange des données 41

11.1. Format XML (description de la forme) 41

11.2. Format ACL / KIF / KQML (description du fond) 42

12. Coopération 43

13. La coordination 44

13.1.Définition 44

14. Négociation 44

14.1.Définition 44

15. Champs d'application des SMAs 44

15.1. Simulation 44

15.2. Résolution de problème 45

15.3. L'Intégration 45

16. Exemple de systèmes multi agents (commerce électronique) 46

16.1. Les agents dans le commerce électronique 46

16.2. Agents existent déjà dans le commerce électronique 47

17. Inconvénients des SMAs 48

18. Conclusion 49

Chapitre IV : Analyse et Conception

1. Introduction 51

1.1. Description fonctionnelle du système (Besoins fonctionnelles) 51

1.1.1. Front-office 51

1.1.2. Back-office 51

1.2. Choix de la méthode 51

2. Analyse 53

2.1. Identification des Agents 53

2.1.1 Les agents de la plateforme Client 53

2.1.2 Les agents de la plateforme serveur 53

2.1.3. Schéma général du système 54

2.2. Identification des Interactions 55

2.3. Environnement du système 56

2.4. Organisation 57

2.5. Utilisateurs 57

3. Conception 58

3.1 Scénario du processus de déroulement 58

3.2 Diagrammes de cas d'utilisations 60

3.3. Diagrammes de séquences 62

3.4. Diagrammes de classes 71

3.4.1. Conception de la base de données 71

3.4.2. Classes internes du système 73

3.4.3. Diagramme de classe d'agents 76

4. Conclusion 78

Chapitre V : Réalisation.

1. Introduction 80

2. Environnement de développement 80

2.1. Choix de la plateforme multi-agents 80

2.2. Choix du langage de la programmation 81

2.3. Choix du SGBD 81

2.4. Environnement de programmation 82

2. Architecture du prototype 82

3.1. Architecture logicielle 82

3.2. Caractéristiques du système 82

3. Réalisation du système 83

4.1. Les agents de notre système 83

4.2. Les interfaces du système 84

4.2.1. Interface de l'authentification 84

4.2.2. Interface d'inscription 84

4.2.3. Interface d'interaction client 85

4.2.4. Interface pour poser des offres 85

4.2.5. Interface pour configurer l'agent négociateur 86

4.2.6. Interface de payement 86

4.2.7. Interface pour l'administrateur 86

4. Conclusion 90

Conclusion et perspectives 91

Perspectives 92

Conclusion 92

Glossaire.
Bibliographie.
Annexes :
Annexe A : La plateforme jade.
Annexe B : AUML.

Liste des Figures :

Fig.1 : Une architecture client serveur 6

Fig.2 : Topologie d'un modèle centralisé 11

Fig.3 : Topologie d'un modèle Hybride 11

Fig.4 : Topologie d'un modèle Pur 12

Fig.5 : Conception à deux niveaux 14

Fig.6 : Conception à trois niveaux 15

Fig.7 : transaction via un grand (banque) 29

Fig.8 : Simulation de la vente aux enchères sur Internet 37

Fig.9 : Architecture libre (non centralisée) du SMA 38

Fig.10 : Shema represente la notion de boucle 39

Fig.11 : Représentation symbolique d'un système multi-agents 52

Fig.12 : Architecture générale du SMA(1) 54

Fig.13 : Architecture générale du SMA(2) 55

Fig.14 : Organisation du système multi-agents 57

Fig.15 : Diagramme de cas d'utilisation <SMA d'enchères> (Vue globale) 60

Fig.16 : Diagramme de cas d'utilisation <rechercher produit 61

Fig.17 : Diagramme de cas d'utilisation <Négocier produit> 62

Fig.18 : Diagramme de cas d'utilisation <Achat produit > 63

Fig.19 : Diagramme de cas d'utilisation < Gérer le catalogue de produits > 64

Fig.20 : Diagramme de séquences < Authentification > 65

Fig.21 : Diagramme de séquences < Inscription > 66

Fig.22 : Diagramme de séquences < Chercher produit > 67

Fig.23 : Diagramme de séquences < Gestion du catalogue produit > 68

Fig.24 : Diagramme de séquences < Négocier produit > 69

Fig.25 : Diagramme de séquences < Valider achat > 70

Fig.26 : Diagramme de Classe UML < Entités de la BDD> 72

Fig.27 : Architecture logicielle du système 82

Fig.28 : AP et AE dans la plateforme jade 83

Fig.29 : AGUI, AC, AN dans la plateforme jade 84

Fig.30 : Interface de l'authentification 84

Fig.31 : Interface d'inscription 85

Fig.32 : Interface d'interaction client 85

Fig.33 : Interface pour proposer des offers 86

Fig.34 : Interface pour configurer l'agent négociateur 86

Fig.35 : Interface de payement 86

Fig.36 : Interface pour l'administrateur 87

Fig.37 : Interface pour ajouter un produit 88

Fig.38 : Interface pour supprimer un produit 88

Fig.39 : Interface pour la modification d'un produit 89

Fig.40 : Interface pour supprimer un produit 89

Fig.41 : Interface pour visionner les categories 90

Liste des tables :

Tab.1 : Comparaison entre les différentes implémentations du client/serveur 9

Tab.2 : Comparaison entre les typologies du modèle pair-à- pair 13

Tab.3 : Synthèse des avantages et inconvénients du modèle client/serveur 17

Tab.4 : Comparaison entre agents cognitifs et agents réactifs 34

Tab.5 : Description des classes 72

Tab.6 : Description des associations 72

Introduction generale :

Notre thèse a pour but de développer un s_ystème multi-a_gents pour les enchères en li_gne qui permet d'automatiser les opérations commerciales aux acheteurs, en offrant un catalo_gue qui contient les produits mis en enchère afin de satisfaire les besoins du client.

Le but essentiel c'est d'avoir un certain de_gré d'autonomie a l'aide de ces entités lo_gicielles intelli_gentes ou tout simplement a_gents qui sont des pro_grammes auxquels on peut délé_guer une tache. Le s_ystème diffère du lo_giciel traditionnel _grace a ces entités autonomes qui né_gocient entre elles . Cette particularité les rend utiles pour l'environnement du commerce électronique notamment les enchères.

Dans ce contexte, on créer un s_ystème multi-a_gents oil les a_gents sont pro_grammé en JAVA sous la plateforme JADE et se communiquent avec le lan_ga_ge commun FIPA-ACL.

Notre travail consiste a comprendre le fonctionnement de deux architectures a savoir le paradi_gme client-serveur et celui des s_ystèmes multi-a_gent ainsi que le concept du e-commerce en particulier la vente aux enchères, pour cela nous avons entrepris notre étude selon les 5 chapitres suivants :

Chapitre / : il est consacré a une étude sur le modèle client-serveur (Présentation du modèle client-serveur, modèle pair -a- pair, t_ypes de conceptions...).

Chapitre 2 : ce chapitre est consacré a une étude _globale sur le concept de la vente aux enchères en li_gne.

Chapitre 3 : vu que nous somme en train de développer un s_ystème multi-a_gent , un chapitre sur la notion des a_gents et les s_ystèmes multi-a_gents s'avers indispensable pour notre étude. Chapitre 4 : il est consacré a la conception du s_ystème a mettre en ceuvre en suivant la démarche défini par la méthodolo_gie vo_yelle.

Chapitre 5 : nous arrivons dans ce chapitre a l'implémentation de notre s_ystème.

Est enfin nous terminerons par une conclusion _générale ,qui résume l'apport essentiel de notre travail , qui tente de s'ouvrir sur des nouveaux éléments de réflexions et propose quelques perspectives de recherche ,Deux annexes sont ajoutées a la fin pour éclaircir les notions non approfondis

Mot cles : S_ystèmes Multi a_gents, la vente aux enchères, commerce électronique.

Problématique et Objectifs

Problématique :

Les sites de vente en li_gne se manquent d'automatisation et d'autonomie, notamment les sites de vente en encheres au niveau de la médiation entre vendeurs et acheteurs et de la né_gociation automatique des offres et des prix.

Ainsi la non satisfaction des vendeurs et acheteurs tels que le but du vendeur est d'obtenir le plus haut prix pour son produit, et celui des acheteurs est d'obtenir ce produit au plus bas prix.

Objectifs :

Dans ce projet on va construire un s_ystème de vente aux encheres ou les né_gociations se déroule selon un protocole an_glais en se basons sur des a_gents de la plateforme Jade , ces derniers permettent de chercher un produit que le client le désir et de né_gocier (faire des propositions de prix avec différentes straté_gies) de maniere automatique.et de si_gnaler au _ga_gnant lorsque l'enchere est achevée.

Chapitre I.

LES SYSTEMES CLIENT/SERVEUR

~ Iln'~ a pas de grandeurpour qui veut grandir. Il n'~
a pas de modèle pour qui cherche ce qu'il n'a jamais
vu » -- Paul Eluard.

Résumé : Nous presentons dans ce chapitre le paradigme client/serveur puis nous decrirons cette technologie du point de vue modele en citant ses caracteristiques , puis on met l'accent sur l'architecture peer to peer, nous presenterons aussi les differents types de conceptions utilisees pour ce modele .

Et enfin, pour conclure nous en deduirons les faiblesses de ce paradigme.

1. Introduction

Dans l'informatique moderne, de nombreuses applications fonctionnent dans

un environnement client/serveur ; cette denomination signifie que des machines clientes (faisant partie du reseau) contactent un serveur - une machine generalement tres puissante

en terme de capacite d'entre/sortie de memoire et de processeur -- qui leurs fournit des services^(/).

Jusqu'a ce jour, la technologie client/serveur s'est developpee en suivant la genese ciapres:

- la premiere vague : celle de l'apparition du partage des ressour ces ; differents dispositifs sont alors mis en commun tels que des imprimantes et des lecteurs. C'est donc principalement le debut des serveurs de fichiers ; le client demande des enregistrements de fichiers au serveur.

- la deuxieme vague : celle des applications centralisées de bases de données. Le client forme des messages de requetes ⁽²⁾ pour que le serveur selectionne dans sa base l'information demandee et la lui renvoie via le reseau. Le client recoit donc juste ce qui

l'interesse et non un fichier complet.

- la troisième vague : celle des objets distribués. qui regroupent toutes les possibilites de techniques anterieures en leur ajoutant la capacite de repartir au mieux les fonctions

entre clients et serveurs .

De nos jours, il existe quatre modèles de client/serveur a savoir le contexte du travail

qui sont : le client serveur « traditionnel » -utilisant la methode RPC-, le Client/serveur a objet -RMI, CORBA et DCOM-, le client serveur de données - Requetes SQL- et

le modèle client/serveur web-CGI, Servlet, asp, jsp, php...

[RDJ, 99]

⁽¹⁾.Programmes ournissant des acces a des ressources : utilisation CPU (ressources physiques), d'interrogation. ⁽²⁾.d'une base de donnies (ressource logicielle), l'heure, des ichiers, une connexion, etc.

2. Le paradigme client/serveur

Le client/serveur qui est une evolution du mainframe (Systemes centralises) permet, par l'utilisation de nouvelles methodes et techniques, de passer outre les limites que l'on connaissait avec de tels systemes, ou :

· La logique de traitement : se situe sur la machine hOte, l'utilisateur interagissant avec celui-ci a travers un terminal PC en mode caractere ;

· Les donnees : le systeme centralise est base sur une architecture de fichiers partages qui sont traites dans leur totalite ;

· Les applications : sont developpees sans decomposer leurs trois champs d'activite (la presentation, le noyau applicatif et l'acces aux ressources)

[BRN, 95]

Par contre, l'idee du client/serveur est la suivante :

· Le s_ysteme de fi chier : est remplace par une base de donnees que l'utilisateur interroge a travers des requetes.

· Les communications : entre clients et serveur se font soit par RPC⁽³⁾ (Remote Procedure Call : Appel de procedure distantes) soit par requetes SQL.

De plus, l'idee du client/serveur est plus large ; un reseau n'est pas toujours necessaire.

1l est possible de le realiser sur une machine en degageant deux processus l'un -le client- qui envoie des requetes a l'autre -le serveur- ce dernier traitant les requetes et renvoyant des reponses.

[ROU,02]

3. Presentation du modele client/serveur

Le modele client/serveur est une des modalites des architectures informatiques distribuees.

Au sein de cette architecture, les processus sont classes entre offreurs de services (serveurs) et consommateurs de services (clients).

Le terme serveur s'applique a tout programme qui offre un service que l'on peut atteindre a travers un reseau.

Le serveur accepte des demandes issues du reseau, les traite et renvoie le

resultat au demandeur. Quant au terme client, il s'applique a tout programme qui emet une demande a une serveur et qui attend une reponse⁽⁴⁾.

[DCO, 95]

^(39.+echnique permettant d'appeler une procedure distante comme une procedure locale, en rendant transparents les messages ichanges.

^(49.-essage transmis par un serveur a un client suite a l'exécution d'une operation .



Fig.1 : Une architecture client /serveur.

· Le client émet une requete vers le serveur grace a son adresse IP et le port, qui désigne un service particulier du serveur.

· Le serveur recoit la demande et répond a l'aide de l'adresse de la machine cliente et son port.

3.1. Caracteristiques du serveur

Le rOle du serveur est l'hébergement des services. Il est peut etre spécialisé

en serveur d'applications, de fichiers ou de terminaux ou de messagerie électronique⁽⁵⁾.

· Il est Passif (esclave), en attente d'une requete ;

· Il est a l'écoute, pret a répondre aux requetes envoyées par les clients ;

· Des qu'une requete lui parvient, il la traite et envoie une réponse ;

· Il est capable de traiter les requetes et répondre a plusieurs clients simultanément (multi-threading) ;

· Il est contrOleur d'acces et garant de l'intégrité globale.

· Les serveurs peuvent etre mis a niveau sans effet sur les clients tant que l'interface des messages reste la meme.

⁽⁵⁾.11 s'agit de courrier dectronique.

3.2. Caractéristiques du client

· Actif (maitre) ;

· Envoie des requetes au serveur ;

· Attend et recoit les reponses du serveur.

Les systèmes client/serveur peuvent etre : soit plats dans le cas ou tous les clients communiquent seulement avec un seul serveur soit hierarchiques dans le cas ou les clients n'ont de contact qu'avec les serveurs de plus haut niveau qu'eux (les serveur DNS).

3.3. Point commun entre le client et le serveur

Le client et le serveur doivent, bien sur utiliser le meme protocole de communication.

3.4. Caracteristiques du modele client/ serveur [ERA, 04]

Les systèmes client/serveur partagent les caracteristiques suivantes constituant une base pour la conception d'application en reseau :

· Le partage de ressources : plusieurs clients peuvent etre o servis » simultanement et leurs accès aux ressources est controle.

· La transparence : la localisation des clients et des serveurs est transparente aux deux.

· L'echelonnage : Supporte mieux une augmentation du nombre de clients.

· L'interoperabilite : les plates formes clients peuvent etre heterogènes (le lien est fait grace au protocole).

· La delocalisation : il y a peu ou pas de contraintes de proximite entre les clients et le serveur.

· S_ystème ouvert : s'appuie sur des standards (ISO, ANSI, IEEE...) pour permettre la portabilite, le remplacement d'un composant d'un constructeur par celui d'un autre conforme aux standard.

· L'integrite : le code et les donnees du serveur sont geres de facon centralisee, ce qui garantit un moindre cout de maintenance et une meilleure integrite des donnees partagees.

· Echange de messages : les clients et les serveurs interagissent par l'intermediaire de messages, le message est le mecanisme d'emission des demandes de services et des reponses a celles-ci.

L'union entre le concept d'objet et de repartition a donne naissance a un nombre impressionnant de langages , de systèmes,de bibliothèques d'objets repartis ,et de produit commerciaux, parmi lesquels :CORBA ,DCOM, java (java RMI) ou encore .NET, qui sont consideres très branches comme technologies ,le tableau ci-dessous synthetise la difference entre ces systèmes :







Tab.1 :Comparaison entre les differentes implementations du client/serveur (in cluent .net et les web services ).

4. Le modèle pair a pair [CAB, 07]

Dans ce qui suit, nous presenterons les notions de base du paradigme pair-a-pair et ses differentes caracteristiques, ensuite, ses differentes topologies et en citer ses avantages et inconvenients pour enfin, le comparer avec le modele client/serveur.

4.1. Presentation du modèle pair- a-pair

Le modele pair-a-pair (peer to peer) est un modele de reseau informatique ou tous

les nceuds jouent a la fois le role de client et de serveur. Depuis les annees 90, ce modele est en pleine expansion ; les scientifiques se sont apercus de son enorme potentiel alors que jusqu'ici, c'est le modele client/serveur pur qui a ete adopte vu la simplicite de sa mise en ceuvre et la maitrise acquise au fils des annees. Le modele pair -a- pair profitant de l'expansion des acces a Internet et de la disponibilite de millions de machines, repousse considerablement les limites imposees par le modele client/serveur et a demontre ses avantages par rapport a ce modele par le partage de fichiers multimedias. Ainsi, des applications qui etaient developpees sur le modele client/serveur sont revues et repensees pour les faire tourner sous le modele

pair -a- pair (calcul distribue, espaces collaboratifs...etc.).

4.2. Caractéristiques du modèle pair -a- pair [CAB, 07]


· La decentralisation : c'est la principale caracteristique du modèle pair -a- pair, elle s'applique aux differentes topologies. Dans le cas du modèle centralise, seules les ressources sont decentralisees, mais les mecanismes de recherche et de localisation restent centralises. Alors que dans le cas du modèle pur, tout est decentralise : les

ressources, les mecanismes de recherche, la localisation, la securite, le routage.

· Passage a l'echelle : On denombre un tres grand nombre de participants aux differents reseaux de pair -a- pair sans pour autant poser de problemes au bon fonctionnement des applications. Ces caracteristiques sont limitees par des facteurs comme la quantite de messages echanges entre differents pairs.

· L'anonymat : est une fonction qui permet de ne pas etre identifiable sur un reseau. On peut distinguer six formes d'anonymat : l'auteur, l'editeur, le serveur, le document et la requete.

· L'auto-organisation : Necessaire en raison du passage a l'echelle et de l'absence d'un element central vu qu'il est difficile de prevoir le nombre des utilisateurs et la charge sollicitee comme, plus le passage a l'echelle augmente, plus la probabilite de fautes augmente d'oU la necessite d'une auto-maintenance

et d'une auto-reparation du systeme.

· Connectivite Ad Hoc⁽⁶⁾: Du fait de la volatilite des pairs, des mecanismes de duplication et de synchronisation sont mis en place a travers differents terminaux mobiles formant un reseau ad Hoc.

4.3. Typologies du modele pair-a- pair

Le modele pair-a-pair peut etre soit centralise soit h_ybride ou bien pur :

4.3.1. Le modele centralise :

1l est tres proche du modele client/serveur, repose sur un serveur central detenant l'ensemble des connaissances, les clients envoient et recoivent les informations a travers le serveur mais les ressources sont hebergees par les clients. Une fois qu'un client a recu du serveur la liste des ressources et des clients les hebergeant, il peut interagir directement avec les autres. C'est la principale difference avec le modele client/serveur.

Plusieurs systemes s'appuyant sur ce modele existent : Serveurs de base de donnees, serveurs web, etc.

⁽⁶⁾. Réseaux sansfils capables de s'organiser sans infrastructure définie préalablement oir chaque naud communique directement avec son voisin contrairement aux réseaux d'échange en mode infrastructure oh il est nécessaire de faire passerpar un point d'accès.



Fi_g.2 : Topologie d'un modèle centralisé

4.3.2. Le modèle hybride :

Avec ce modèle, le contrOle des informations s'échange a travers le serveur

alors que les flux de données sont échangés de pair a pair, le serveur de commande agit en tant qu'agent de surveillance pour tous les autres pairs et assure la concordance

de l'information.

Les serveurs de tel modèle sont utilisés pour assurer des fonctions relatives au routage, a la comptabilité ou a l'organisation fonctionnelle des pairs.



Fi_g.3:Topolo_gie d'un modèle H_ybride

4.3.3. Le modèle pur :

Dans ce type de modele, il n'y a aucun serveur. Le fait qu'un pair quitte le reseau n'affecte pas le systeme. Les pairs sont consideres comme strictement equivalents.

Differentes applications sont construites sur ce type de topologie : Gnutella, toutes les infrastructures a base de table distribuee tel que Chord, Pastry, Tapstry, CAN...



Fig.4:Topologie d'un modèle Pur

4.3.4. Synthèse des typologies du modèle pair -a- pair

Résumons dans le tableau en page suivante, les principales differences qui existent entre les différentes typologies du modèle pair -a- pair :



Tab.2 : Comparaison entre les t_ypologies du modèle pair -a- pair

4.4. Avantages et inconvenients du pair - a- pair

Le pair -a- pair est une technologie émergeante. Son utilité dans de différentes applications devient de plus en plus évidente a cause de :

· son coUt réduit (les coUts engendrés par un tel réseau sont le matériel, les cables et la maintenance).

· sa simplicité a toute épreuve!

Mais :

· Ce système n'est pas du tout centralisé, ce qui le rend très difficile a administrer

· Sa sécurité est très peu présente

· Aucun maillon de ce système n'est fiable

Ainsi, les reseaux d'egal a egal ne sont valables que pour un petit nombre d'ordinateurs (generalement une dizaine), et pour des applications ne necessitant pas une grande securite (il est donc deconseille pour un reseau professionnel avec des donnees sensibles).

5. Types de conceptions client/ serveur .

5.1. Conception à 2 niveaux

La conception a deux niveaux (aussi appelee architecture 2-tiers, « tier » signifiant etage en anglais)caracterise les systèmes clients/serveurs dans lesquels le client demande une ress ource et le serveur la lui fournit directement. Cela signifie que le serveur ne fait pas appel a une autre application afin de fournir le service.



Fig.5: Conception a deux niveaux

5.2. Conception a 3 niveaux

Dans la conception a 3 niveaux (appelees architecture 3-tiers), il existe un niveau intermediaire, c'est-à-dire que l'on a generalement une architecture partagee entre :

· Le client : le demandeur de ressources.

· Le serveur d'application (appele aussi middleware) : C'est le serveur charge de fournir la ressource mais faisant appel a un autre serveur.

· Le serveur secondaire (generalement un serveur de base de donnees), fournissant un service au premier serveur.



Fig.6: Conception a trois niveaux

5.3. Comparaison des deux types de conceptions

Le choix entre les deux conceptions 2-tiers et 3-tiers dépend de la facon dont l'application client/serveur est partagée en unités fonctionnelles⁽⁷⁾.

Le besoin de l'architecture 3-tiers s'est révélé lorsque le client/serveur s'est agrandi (cas d'applications critiques ayant prises des proportions intergalactiques).

6. Synthèse

Quelle que soit l'implémentation utilisée (CORBA, DCOM, Java RMI, .Net ou encore la technologie des Web service) et quelle que soit l'organisation

adaptée (les différentes typologies du pair -a- pair), le modèle client/serveur présente des avantages et des inconvénients que nous avons résumés dans le tableau ci-dessous :

.

⁽⁷⁾*Inter ace utilisateur, logique de traitement et les données partagees





Tab.3: S_ynthèse des avantages et in convénients du modèle client/serveur

7. Conclusion

Nous avons étudié dans ce chapitre le fameux modèle client/serveur, nous nous sommes

un peu étalées sur l'architecture peer to peer, ce que nous pouvons conclure est que ce type d'architecture fonctionne très bien dans les systèmes locaux et fermés (les intranets a titre d'exemple) dans lesquels les roles de client et de serveur sont établis a l'avance mais elle est une vision centralisée, rigide et passive, est controlée par le programmeur, ne supporte ni la taille, ni la complexité ni l'évolutivité croissante des nouvelles applications .En effet, le modèle client/serveur ne peut pas répondre a certaines contraintes (temps de réponses, disponibilité des services) qu'impose le volume d'information énorme sur le réseau Internet induit par le
nombre croissant des utilisateurs Web.

On est ainsi conduit a chercher a donner plus d'autonomie et d'initiatives aux différents modules logiciels.

Plusieurs approches ont été proposées pour pallier aux problèmes du modèle
client/serveur parmi lesquelles la mobilité des codes qui sera l'objet d'un autre chapitre .

Chapitre II~

LA VENTE AUX ENCHERES EN

LIGNE

« Rien n'est plus dangereux qu'une idee, quand on n'a qu'une idee. » - Alain(Ernile Chartier, dit)

Résumé : Ce chapitre presente les notions de commerce electronique et la vente aux encheres, ainsi que les deferents types d'e-commerce et les protocoles de la vente aux encheres, on donnant quelques exemples sur les sites les plus connus d'enchere.

1. Introduction

La nouvelle ere de l'information va revolutionner les processus de gestion dans de nombreux domaines surtout le commerce electronique (e-commerce, en anglais). Aujourd'hui, l'informatique est devenue le moteur de l'economie, donc le terme du e-commerce a ete etabli, et les applications de la vente et l'achat en ligne ont ete rapidement diffusees autour du monde. Ou on a tres souvent recours a la vente aux encheres sur Internet pour se debarrasser d'o bjets superflus. La vente aux encheres permet aux petits entrepreneurs de liquider des marchandises excedentaires ou defraichies, de maniere rentable, et meme d'evaluer le potentiel de vente d'un produit particulier sur Internet.

En fait, la vente aux encheres sur Internet a en partie modifie le fonctionnement des microentreprises. Pour la premiere fois, les vendeurs peuvent, a domicile, se brancher rapidement au marche mondial, et a un prix aborda ble.

De nos jours, le chef de file de la vente aux encheres, eBay, a plus de 65 millions d'usagers actifs.

Dans le monde actuellement, plusieurs milliers de commercants soucieux d'economie, gagnant leur vie a domicile en vendant des produits sur eBay.

2. Definition de l&e-commerce et ces types

Avant d'entamer a la vente aux encheres, tout d'abord, il faut savoir la notion d'e-commerce.

2.1. Definition

Le commerce electronique (e-commerce, en anglais) designe l'echange de biens et de services entre deux entites sur les reseaux informatiques, notamment Internet.

Le client effectuant des achats sur Internet est appele cyberconsommateur. Le e-Commerce ne se limite pas a la seule vente en ligne, mais englobe egalement :

· La realisation de devis en ligne

· Le conseil aux utilisateurs

· La mise a disposition d'un catalogue electronique

· Un plan d'acces aux points de vente

· La gestion en temps reel de la disponibilite des produits (stocks)

· Le paiement en ligne

· Le suivi de la livraison

· Le service apres-vente

Attention! : Il ne faut pas confondre e- business et e-commerce, e- business est plus large :

e- business designe tous les processus economiques transformes par le Web : l'integration des systemes d'information avec les clients et les fournisseurs (via des sites web a acces reserve : les extranets), le travail dans l'entreprise (via un site web reserve aux employes : l'intranet), le recrutement, la finance, le marketing (publicite p.ex.), etc.



2.2. Les formes du commerce electronique Il existe plusieurs formes de l'e-commerce a savoir :

- Business-to-Consumer (B2C) : Le B2C (prononcez " bi-tou-ci") designe le commerce en ligne de biens ou de services entre une entreprise et des particuliers. C'est notamment le cas pour les sites de vente en ligne.

- Business-to-Business (B2B) : les achats et les ventes des biens ou des services entre les societes sur le Web. C'est le modele d'e- business qui concerne les relations interentreprises. Il concerne la majeure partie des activites de l'e- business; la plupart des analystes considere que le Business to Business offre beaucoup plus de perspectives que le Business to Consumer.

- Consumer-to-Consumer (C) : Les affaires qui se deroulent entre les particuliers ou bien les clients. Expression designant les sites constituant des points de rencontre entre les Internautes ("chat club", forums, sites de vente aux encheres).

- Business-to-Employee (B2E) : Ce sont les relations commerciales entre les entreprises et les employes. De plus, il designe les applications et les services informatiques mis par les entreprises a disposition de leur personnel, generalement sur un Intranet. Y figurent en bonne place les portails d'entreprises accessibles sur les Intranet.

- Business to gouvernement (B2G) : Echange electronique entre les entreprises privees et le gouvernement en faisant et investissant des projets en ligne.

Noter bien qu'un site peut tres bien etre a la fois B2C et B2B.

Donc, l'apparition d'e-commerce implique l'apparition d'enchere sur Internet.

3. Fonctionnement de la vente aux encheres en ligne

La vente aux encheres electronique s'appelle souvent la place du marche en ligne. Elle reunit acheteurs et vendeurs sur Internet dans le but d'echanger biens et services.

La plupart du temps, le processus de vente aux encheres electronique se deroule selon le modele des encheres traditionnelles.

En general, un acheteur rencherit sur d'autres acheteurs pour o btenir un produit ou un service en particulier, et le plus offrant peut se procurer l'article au terme du processus.

Si vous voulez acheter un produit, vous pouvez explorer un site de vente aux encheres en ligne en examinant differentes categories de produits, ou utiliser des mots cles qui decrivent ce que vous cherchez. Au moment oil vous participez au processus d'achat du produit, la plupart des sites de vente aux encheres electronique peuvent rencherir a votre place (en reponse a d'autres mises), jusqu'à concurrence du montant limite que vous avez determine d'avance.

Par consequent, vous n'avez pas besoin de verifier sans cesse sur le site pour savoir si vous avez fait la meilleure offre, ou pour rencherir.

Les vendeurs, pour leur part, peuvent etablir un prix minimal (le plus bas prix acceptable). Il peut egalement y avoir une limite temporelle aux encheres, au terme de laquelle le produit ou service ira a la personne qui aura fait la meilleure offre.

Les sites de vente aux encheres electronique peuvent accepter des modes de paiement varies tels que le paiement par carte de credit, les services de reglement en ligne tels que PayPal ou Escrow, le paiement par carte bancaire, les cheques personnels, les cheques de banque ou les mandats.

En general, les modes de paiement acceptes sont affiches sur le site Web.

3.1. La theorie des encheres = les protocoles et les strategies des agents dans les encheres.

· L'initiateur veut vendre un objet au plus grand prix et les participants veulent l'acheter au plus petit prix possible.

· Un protocole centralise, inclut un initiateur et plusieurs participants.

· L'initiateur annonce un objet pour la vente. Dans certains cas, l'o bjet peut etre une combinaison d'autres objets, ou un objet avec plusieurs attributs.

· Les participants font des soumissions (offres). Cela peut etre fait plusieurs fois, en fonction du type d'enchere.

· L'initiateur choisi le gagnant.

4. Avantages de la vente aux encheres en ligne

Vendre aux encheres sur Internet presente des avantages tangibles compare aux autres types de vente en ligne, voici quelques avantages clefs de la vente aux encheres en ligne :

· La vente aux encheres est ouverte au monde 24 heures sur 24. Cela rend la vente aux encheres fortes commodes pour les vendeurs et les acheteurs vivant dans des fuseaux horaires differents.

· La vente aux encheres gen~re une certaine fe brilite, propice aux ventes et aux achats, la vente aux encheres cree des clients assidus, amateurs d'emotions fortes.

· Les sites de vente aux encheres presentent donc une mise en marche rentable de vos produits, la vente aux encheres attire un grand nombre d'usagers. Il s'agit donc d'un systeme fort rentable de commercialisation de vos produits, un systeme oa le coat d'exploitation et le capital investi sont faciles a recuperer.

· Echanges et commentaires creant une certaine convivialite, vendeurs et acheteurs ajoutent de commentaires susceptibles de renforcer ou de miner les reputations a l'interieur du reseau. En creant un sentiment d'appartenance, reliant des usagers disperses de par le monde.



5. Les parametres des encheres

> Encheres avec valeur privee: la valeur d'un agent pour un objet depend seulement de ses preferences privees.

> Encheres avec valeur commune: la valeur de l'o bjet depend completement de l'evaluation des autres.

> Encheres avec valeur correlee: la valeur de l'objet depend des evaluations internes et externes.

6. Protocoles d'enchère

6.1. Enchere anglaise (premier-prix offre-publique) -- chaque participant annonce publiquement son offre. Le participant avec la plus grande soumission gagne l'o bjet au prix de son offre.

Strategie:



Dans les encheres a valeurs privees la strategie dominante est de



toujours faire une offre avec un peu plus grande que la plus grande offre actuelle et s'arreter quand la valeur privee est atteinte.

Dans les encheres a valeurs correlees, le participant augmente le prix a une rate constante ou a une rate qu'il considere appropriee.

6.2. Enchere premier-prix offre-cachée -- chaque participant soumet une

offre sans savoir les offres des autres. Celui qui fait la plus grande soumission gagne l'o bjet et paye le montant de son offre.

Strategie:



Pas de strategie dominante.

Offrir moins que sa vraie evaluation, mais cela depend des autres soumissions qui sont pas connues.

6.3. Enchere hollandaise (descendante) -- l'initiateur diminue tout le temps le prix jusqu'a ce qu'un des participants achete l'objet au prix actuel. Strategie:



Equivalente du point de vue strategique avec l'enchere premier-prix offre-cachee.

Efficiente en temps reel.

6.4. Enchere Vickery (deuxieme-prix offre-cachee) -- chaque participant

soumet une offre sans savoir les offres des autres. Celui avec la plus grande offre gagne, mais au prix de la deuxieme plus grande offre.

Strategie:



La strategie dominante du participant est d'offrir sa vrai evaluation.

6.5. Encheres tous-payent -- chaque participant doit payer le montant de son offre (ou un autre montant) a l'initiateur.

Les diagrammes ci-dessous présentent les principales differences entre les enchères anglaises et les enchères hollondaises

· Vente aux enchères anglaises



· Vente aux enchères hollondaises



7. Problèmes avec les protocoles d'enchère

n Des blocages peuvent apparaitre.

n Initiateur menteur :

o Probleme dans l'enchere Vickery.

o Probleme dans l'enchere anglaise -- l'initiateur utilise des faux participants dans
l'enchere pour augmenter l'evaluation de l'o bjet par les autres participants.

o L'initiateur offre le deuxieme plus grand prix pour o btenir son prix reserve -- il est possible qu'il arrive a garder l'o bjet.

o Les encheres avec des valeurs communes peuvent etre soumises a la malediction du gagnant ("winner's curse").

o Des encheres inter-liees -- le participant peut mentir sur la valeur d'un objet pour obtenir une com binaison d'o bjets a leur prix d'evaluation.

8. Exemples de sites Web de vente aux enchères(8)

· www.uBid.com (site de vente aux encheres non specialise).

· www.eBay.com (site de vente aux encheres non specialise).

· www.alibaba.com (site de vente aux encheres non specialise).

· www.bidville.com (site de vente aux encheres non specialise).

· www.liquidation.com (stocks commerciaux et biens gouvernementaux excedentaires -- large eventail de categories de produits).

· www.dovebid.com (fournisseur international de services de vente aux encheres, d'evaluation, d'echange et de gestion des actifs immobilises).

· www.elance.com (axe sur les services. Vous pouvez chercher un fournisseur en fonction de la categorie ou afficher votre projet et recevoir des propositions de fournisseurs de services).

9. Le centre commercial virtuel

9.1. En quoi consiste un centre commercial virtuel?

Un centre commercial virtuel (ou cybercentre commercial ou centre commercial en ligne) consiste en un site Internet qui fonctionne sur le mode du centre commercial. On peut acceder a un vaste ensemble de vendeurs et de produits a partir d'un seul site Web. Dans certains cas, les centres commerciaux electroniques disposent d'un panier d'achat virtuel et

⁽⁸⁾Sources : Index de web.com www.indexoftheweb.com/Shopping/ Auctions.htm www.emarketservices.com, http:// www.e-bc.ca /pages/ressources/internet-auctions.php

d'un systeme de paiement communs a l'ensemble des vendeurs. Dans d'autres sites, les vendeurs ont davantage de controle sur les fonctions de commerce electronique, de paiement et de livraison.

9.2. Son fonctionnement

En general, l'exploitant ou l'hote d'un centre commercial virtuel exige le paiement de droits pour etablir et maintenir le kiosque ou la boutique du marchand et pour inclure ses produits dans le catalogue. De plus, l'hote peut exiger que le vendeur lui paie une redevance sur chaque vente ou chaque fois que quelqu'un clique sur un de ses produits.

Les frais de listage peuvent varier de 25 cents a 2 $ ou plus par produit. Les frais de parachevement de la vente se situent entre 1,25 et 5 %, habituellement en fonction du prix de l'article.

Les centres commerciaux virtuels ne sont pas tous exploites de la meme facon. Dans le cas de certains sites pleinement integres, l'hote assume le traitement du paiement et le catalogue du site tandis que dans d'autres cas, il incombe au marchand de veiller '

l'apparence de la boutique et au traitement du paiement, et de s'occuper de la livraison et des remboursements.

En ce qui concerne les sites plus integres de centres commerciaux virtuels, l'hote peut egalement elaborer des profils d'utilisateur ayant trait aux clients qui accedent a l'un ou l'autre des magasins en ligne. Cette methode permet de developper des centres commerciaux hautement specialises (c.-à-d. axes sur des creneaux de marche particuliers).

www.etsy.com: c'est un exemple de centre commercial virtuel le plus frequente.

9.3. Comment les centres commerciaux virtuels peuvent-ils aider les

petites entreprises?

Avez-vous deja voulu vendre vos produits et services en ligne, sur votre propre site Web, tout en ayant le sentiment de ne pas etre pret? Les centres commerciaux virtuels peuvent vous procurer l'acces a un marche plus grand, a peu de frais. Il s'agit egalement d'un bon moyen d'annoncer vos produits et services sur le Web.

Dans l'optique de l'acheteur, les centres commerciaux virtuels permettent de comparer les produits sans devoir multiplier les demarches.

Gardez a l'esprit que les centres commerciaux virtuels se fondent sur le modele des magasins de detail, et ils constituent a court terme l'une des facons les plus simples d'etablir votre site de commerce electronique.

Grace aux centres commerciaux virtuels, vous n'avez pas a vous soucier de mettre sur pied un site de cybercommerce.

Les centres commerciaux virtuels peuvent attirer des clients qui, autrement, ne trouveraient peut-etre pas votre site Web. Il s'agit d'une solution peu risquee et peu couteuse pour eprouver en ligne le marche de vos produits.

Si vous parvenez a asseoir la reputation de votre entreprise en ligne, vous pourriez alors envisager d'autres solutions telles que votre propre magasin electronique.

9.4. Y a-t-il des risques?

Les centres commerciaux virtuels pourraient ne pas constituer la solution ideale si vous souhaitez que votre entreprise se demarque. Meme si on a lance un bon nombre de centres commerciaux sur le Web au cours des dernieres annees, beaucoup echouent dans les deux ans qui suivent leur creation. Les entrepreneurs doivent evaluer avec soin si le recours a un cybercentre commercial d'un type particulier leur convient.

10. Traitement du paiement

Beaucoup d'encre a coule a propos des moyens de paiement en ligne. Il en existe de nombreuses categories, mis a disposition par de nombreux prestataires. Bien sur, tous les moyens de paiement classiques sont disponibles (cheques, mandats...), et ne necessitent peu ou pas de developpements. A l'inverse, le "paiement securise par carte bancaire" necessite une interface avec les reseaux cartes bancaires (RCB), il implique donc l'intervention d'un intermediaire specialise.

> Paiements off-line

C'est de tres loin le plus simple a mettre en oeuvre ; les clients paient avec les moyens habituels: cheque, mandat, ou n° CB par courrier/fax/telephone.

Les deux premiers vont de soi, mais le paiement par CB off-line necessite l'utilisation par le marchand d'une interface bancaire de saisie des transactions CB (minitel, Internet, ...). Dans ce dernier cas, la banque prendra sa commission de 1 a 3% sur chaque transaction.

> Sites de banques :

Ce sont les solutions les plus simples a mettre en oeuvre ; en gros, quand le client desire payer, il est redirige vers une page hebergee par une banque avec comme parametres son identifiant et le montant a payer. La page de la banque, securisee, permet a l'internaute de saisir ses informations bancaires. Lorsque la transaction est terminee, l'internaute est a nouveau redirige vers le site marchand avec comme parametre son identifiant le resultat de la transaction que le marchand enregistre. L'inconvenient de ce systeme est le va-et-vient du client qui risque d'abandonner en cours.

> Batch CB

Cette solution ressemble a la precedente, si ce n'est que la page securisee est geree par le marchand et non plus par la banque. L'avantage est l'ergonomie, la souplesse fonctionnelle et la continuite de la navigation du client.

L'inconvenient majeur est que le marchand est responsable de la securite des informations ainsi rescues, et qu'il doit veiller a ce qu'elles demeurent inaccessibles a toute personne mal intentionnee (en interne comme en externe). En outre, il doit les detruire des qu'il n'en a plus

L'usage (c'est la loi), et veiller a la recense de tous les certificats et logiciels de securite necessaires a la securite.

> Argent electronique (eCash) :

Analogue electronique de l'argent liquide. L'argent electronique a emis par une banque, et chacun des billets (ou chacune des pieces) electronique comporte un numero de serie unique et represente une somme d'argent precise. L'argent electronique peut etre stockee sur un support materiel tel le porte monnaie electronique ou sur le serveur d'une banque tel le porte monnaie virtuel.

D'autres institutions financiere permettent au client de deposer une somme d'argent et

d'o btenir des " jetons "(argent electronique) pouvant etre utilises chez les vendeurs acceptant ce type de paiement. Le chargement du porte monnaie se fait par un autre moyen de paiement (CB, mandat, ...).



Grand

ig.7 :transaction via un grand (banque).

> Autres moyens de paiement : la liste des modes de paiement que nous avons donnee n'est pas exhaustive, voici quelques autres modes de paiement :

- Cartes bancaires jetables : numeros de CB emis par une banque a usage unique,

- Telephone surtaxe : pour payer, l'internaute doit telephoner ou envoyer un certain SMS. "Au moment d'utiliser le service de paiement en ligne offert par une societe specialisee. " Selon Wikipedia ( www.wikipedia.org), PayPal ( www.paypal.com) est l'entreprise specialisee dans le traitement des paiements en ligne qui connait la plus grande popularite.

Selon www.canadaone.com les petites entreprises ont recours aux systemes d'organisations telles que PayPal ( www.paypal.com), CCNow, ( www.ccnow.com) PsiGate ( www.Psigate.com), Beanstream ( www. beanstream.com) et InternetSecure ( www.internetsecure.com) ", en ce qui a trait a des transactions liees a une vente aux encheres ou effectuees dans des centres commerciaux virtuels, tant les acheteurs que les vendeurs doivent habituellement creer des comptes qui leur permettent de faire un paiement ou de le recevoir. La plupart des societes de paiement en ligne imputeront des frais au vendeur en echange de leurs services (recevoir des fonds d'un compte et les transferer dans un autre). Les acheteurs et les vendeurs doivent tenir compte de plusieurs elements au moment de determiner le mode de paiement qui leur conviendra".

11. Conseils concernant la protection des transactions en

(9)

ligne

n Verifiez s'il est possible de renverser les paiements.

n Examinez les conditions du paiement en ligne ou du service d'entiercement.

n Examiner la politique de confidentialite des services en ce qui a trait au mode de paiement, et les mesures de securite.

n Verifiez la legitimite des cheques ou mandats.

n Les vendeurs doivent imputer le montant de la vente a la carte de credit seulement apres avoir procede a l'expedition du produit.

n Verifiez la legitimite du service d'entiercement ou de paiement en ligne, surtout si vous ne le connaissez pas.

12. Conclusion

Aujourd'hui, Internet nous offre la possibilite d'ouvrir des boutiques accessibles a tout le monde partout dans le monde. Malheureusement, ce nouveau mode d'achat presente des inconvenients a savoir la mefiance vis-a-vis des sites de vente.

Internet est aussi un moyen tres efficace pour rester en contact avec le client pour comprendre ces besoins et les satisfaire. Ainsi, on augmente les chances qu'il reste fidele a l'entreprise.

⁽⁹⁾ Source : http://www.ftc.gov/bcp/conline/pubs/online/auctions.shtm et Internet Auctions - What You Should Know Before You Buy or Sell. Australian Competition & Consumer Information.

Chapitre III.

LES AGENTS &

LES SYSTEMES MULTI-AGENTS

ol'esprit est une societe d'agents plus simples qui cooperent
ou se font concurrence»
(La société de Pesprit. InterEditions19 88)

Résumé : Ce chapitre presente les notions d'agents et de systemes multi-agents. Ces systemes possedent des proprieties remarquables qu'il est utile de presenter des a present. Nous presenterons notamment leur typologie , leur comportement et leur caractere adaptatif lors de situations d'interaction et de cooperation.

1. Introduction

Le domaine des systemes multi-agents (SMAs) n'est pas recent, il est actuellement un champ de recherche tres actif. Cette discipline est a la connexion de plusieurs domaines en particulier de l'intelligence artificielle , des systemes informatiques distribues et du genie logiciel. C'est une discipline qui s'interesse aux comportements collectifs produits par les interactions de plusieurs entites autonomes et flexibles appelees agents, que ces interactions tournent autour de la cooperation, de la concurrence ou de la coexistence entre ces agents.

2. L' AGENT: definitions

2.1. Definition de Wooldridge:

Agent intelligent [Woold, 2001] est une entite situee dans un environnement, capable de realiser des actions flexibles et autonomes dans cet environnement dans le but d'atteindre ses objectifs .

2.2.Definition de Ferber :

Jacques Ferber, propose cette definition [Ferber, 1995] et dans [Ferber, 1999]. « On appelle agent une entitephysique ou virtuelle :

· qui est capable d'agir dans un environnement,

· qui peut communiquer directement avec d'autres agents,

· qui est mue par un ensemble de tendances (sous la forme d'objectifs individuels ou

d'une fonction de satisfaction, voire de survie , qu'elle cherche a optimiser),

· qui possede des ressources propres ,

· qui est capable de percevoir (mais de maniere limitee) son environnement ,

· qui ne dispose que d'une representation partielle de cet environnement (et eventuellement aucune) ,

· qui possede des competences et offre des services,

· qui peut eventuellement se reproduire , mourir et changer d'etat

· dont le comportement tend a satisfaire ses objectifs , en tenant compte des

ressources et des competences dont elle dispose, et en fonction de sa perception, de

ses representations et des communications qu'elle recoit ».

2.3. Définition de Maes :

Pattie Maes [Maes, 1995] du groupe de recherche SMA au MIT propose une bonne definition generique du terme agent: "An agent is a computational system that inhabits a complex_' dynamic environment. The agent can sense_' and act on_' its en vironment_' and has a set ofgoals or motivations that it tries to achieve through these actions."

De ces definitions on va deduire les notions fontamentales qui caractirisent un agent: Capable de percevoir, decider et agir.

3. Propriétés d'un Agent

Ø Autonome:

La prise de decision sur son comportement est uniquement en fonction de ses perceptions, connaissances , et representation du monde (un agent peut etre dependant et autonome).

Ø Proactif :

Gen~re ses buts, prise d'initiative pour satisfaire ses buts, pas dirige seulement par les evenements.

Ø Flexible:

Reaction aux changements dans l'environnement; adaptation aux ressources disponibles.

Ø Social:

Capacite d'interagir pour atteindre ses buts, pour aider d'autres agents dans leurs activites.

Ø Situé:

Capacite de percevoir l'environnement et a y agir de façon limitee.

4. Classement des agents

4.1. Relative a leur réactivité

Les agents peuvent etre classes en deux categories principales selon leur comportement et leur granularite. Cette notion de granularite est bien sur tres subjective, elle exprime la complexite de « raisonnement » d'un agent afin de separer les agents dits "intelligents" et des agents moins "intelligents". On parle d'agents cognitifs et d'agents reactifs.

· Cognitifs:

Ils peuvent anticiper, prevoir le futur, memoriser des choses ... ils reflechissent.

· Réactifs:

Ils reagissent directement a l'environnement percu, par pulsion (ex : les fourmis).

Systèmes d'agent cognitifs		Systèmes d'agent réactifs	Présentation explicite del'environnement
Pas de représentation		Peut tenir compte de son passé
Pas de mémoire de son historique		Agents complexes
Fonctionnement stimulus/action		Petit nombre d'agents
Grand nombre d'agent		Tab.4 : Comparaison entre agents cognitifs et agents réactifs.

· Hybride: Combinaison des deux, il est conçu pour allier des capacités réactives à des capacités

cognitives, ce qui lui permet d'adapter leur comportement en temps réel à l'évolution de leur univers. Un agent hybride est composé de plusieurs couches arrangées selon une hiérarchie.



4.2. Par rapport a leur mobilité

· Agents fixes

C'est le systeme le plus immediat (facile) a implementer. Un SMA avec des agents non mobile presente tous les interets d'un SMA classique :



Execution des divers agents en parallele (en general sous forme de threads) et donc independance d'execution des differents agents,

Communication grace a un protocole et un systeme de communication (en reseau si c'est le cas) ,



Libre arbitre des agents : ils decident de repondre ou non aux sollicitations (messages) exterieures ,

Les agents peuvent etres de n'importe quel type : reactif, cognitif, etc.

· Agents mobiles

Lors de l'utilisation d'agents mobiles toutes les caracteristiques des agents fixes sont conservees. L'utilisation des agents mobiles presente en outre ,

plusieurs avantages :



De la charge de calcul : un agent mobile peut en effet se deplacer sur un ordinateur plus puissant pour effectuer un calcul complexe. De meme il peut quitter une machine qui est sature pour aller sur une autre.

reduction du trafic reseau : un agent qui a besoin de traiter une grande quantite de donnees situees sur un autre ordinateur (base de donnees par exemple) peut se deplacer sur l'ordinateur possedant les donnees et revenir avec le resultat. Cela permet d'eviter de faire transiter les donnees sur le reseau.

Les agents mobiles presentent des interets evidents , mais sont cependant plus complexes a gerer. Par exemple :

- Il faut faire suivre les messages lorsque l'agent se deplace.

- Pour qu'un agent puisse se deplacer, il faut bien entendu que des sites d'accueil existent.

- L'utilisation de plusieurs langages de programmation peut poser des problemes pour la mobilite des agents.

5. Le role

Le role est une representation abstraite d'une fonction ou d'un service propose par un agent. Un role peut etre attribue dynamiquement a un agent. Il peut par exemple jouer un role de client ou de fournisseur ou meme les deux simultanement. D'autres roles peuvent etre definis comme le role de mediateur qui se charge de la mise en relation des clients et des fournisseurs.

Chaque methodologie peut apprehender le role de differentes façons. Certaines proposent d'associer potentiellement plusieurs roles a un agent. D'autres specifient qu'un role est au contraire tenu par plusieurs agents.

Dans Aalaadin [Ferber & Gutknecht, 1997] , chaque agent peut prendre en charge plusieurs roles et un role identique peut etre tenu par plusieurs agents mais le role sera toujours local a l'agent.

Dans [Drogoul, 199 8] , un agent est vu comme un ensemble de roles, parmi lesquels on peut distinguer trois niveaux :

· Les roles individuels qui sont les differents comportements que les agents sont capables de tenir sans se soucier de la strategie choisie pour les tenir.

· Les roles relationnels qui concernent comment ils choisissent d'interagir avec un autre

(en activant ou en desactivant les roles individuels) avec le respect des dependances mutuelles de leurs roles individuels.

· Les roles organisationnels ou comment les agents peuvent gerer leurs interactions pour devenir ou rester organises (en activant ou en desactivant des roles relationnels).

6. Le comportement

Un comportement est une reponse a un evenement ou une situation. Dans ce contexte , un evenement est une chose qui se produit et qui change l'environnement ou l'etat de l'agent. Un agent defini son comportement en fonction des evenements qui lui arrivent. Un evenement peut etre par exemple l'arrivee d'un courier electronique.

Lorsqu'un evenement se produit, l'agent doit l'analyser et l'evaluer pour produire une reponse adaptee.

La decision d'un agent va donner lieu a une action, cette derniere n'est pas seulement envisagee comme le resultat de ce que font les agents mais comme le resultat des reactions du monde aux influences des agents.

Le comportement d'un agent peut etre considere d'un point de vue externe ou interne a l'agent. Le comportement externe d'un agent correspond a l'observation d'une suite d'actions entreprises par celui-ci , alors que son comportement interne correspond a l'expression de ses capacites de perception, de decision, et d'action.

Pour nous, le comportement interne d'un agent exprime quand et comment un agent va utiliser ses connaissances , ses savoir-faire et ses facultes de perception de l'environnement, ou de communication pour decider de ses actions. Pour un concepteur, la definition du comportement est alors : "comment assembler les di**~rentes parties d'un agent de mani.re qu'il accomplisse les actions que l'on attend de lui ? ".

7. L'agent comme entite d'un systeme

7.1. Definition d'un systeme multi-agent (SMA).

· Agents intelligents interagissant [Weiss, 1999] Agent +autonomie

Intelligent +but, tiches

Interagissant +prise en compte des autres.

· Systeme distribue compose d'un ensemble d'agents.

· Un ensemble organise d'agents [Briot, 2001].

Un SMA peut-etre ouvert (cas d'un magasin ou des clients entrent et sortent

librement) ou ferme (l'ensemble d'agents reste le meme comme dans un match de football). Un SMA peut etre homogene, c'est-à-dire que tous les agents sont construits sur le

meme modele (ex: une reunion de travail, une colonie de fourmis) ou heterogene, c'est-àdire que les agents sont construits de modeles differents et/ou de granularite differentes (ex: un eco-systeme).

7.2. Caracteristiques d'un SMA

ü Chaque agent a des informations ou des capacites de resolution de problemes limitees , ainsi chaque agent a un point de vue partiel.

ü Il n'y a aucun controle global du systeme multi-agent.

ü Les donnes sont decentralisees.

ü Le calcul est asynchrone.

. Architecture du SMA

8.1. Organisation centralisee

Dans une conception centralisee , un agent connait tous les autres agents.

Ainsi lorsque l'on a besoin d'une competence particuliere ou d'un agent particulier on s'en refere a cet agent pour connaitre le/les agents concernes.

On peut noter que ces deux fonctionnalites font partie de CORBA. Ainsi , si tous les agents sont des objets CORBA , il n'y a plus grand chose a faire.

> Désavantages des Systèmes centralises:

L'avantage de la methode est sa simplicite de mise en oeuvre. Cependant , un seul objet gerant toutes les adresses , il peut devenir un goulet d'etranglement et grever de façon significative les performances du systeme. De meme, si l'objet gerant le systeme d'adressage plante , le systeme plante avec.

Ex : vente aux enchéres

100 agents, chacun 10 comportements ce qui implique 10¹⁰⁰comportements possibles. Comment gerer tout cela de maniere centralisee lors de la conception ?



Fig. 8:Simulation de la vente aux encheres sur Internet.

8.2. Organisation libre (non centralisee)

Aucun agent ne connait tous les agents. Localement, un agent peut connaitre les agents avec il est susceptible de traiter, mais personne n'a, a priori, de vision globale.

Personne ne connait personne a priori et c'est en dialoguant que l'on trouve les autres.

On peut par exemple s'inscrire sur un groupe de diffusion qui nous interesse pour entrer en contact avec d'autres agents.



Envoi de

messages

Agent

Fig.9 : Archetecture libre (non centralisee) du SMA Avantages des Systemes non centralises:

Cette methode presente l'avantage d'être plus "distribue" que la method centralisee. En cas de defaillance d'une partie du systeme, le reste peut continuer a fonctionner.

Cependant la recherche d'un agent donn~e ou d'une categorie d'agent ayant des competences particulieres est moins directe.

De meme l'attribution d'adresses unique a chaque agent est moins directe que dans la methode centralisee.

9. L'environnement

Un agent ne peut exister sans environnement et sans systeme multi-agents ,

Donc l'environnement est une structure dans laquelle l'agent evolue. Un agent va agir sur son environnement et l'environnement va agir sur l'agent.

On retrouve cette notion de boucle de retro-action dans la « commande » de Francisco Varela [Varela, 19 89].



Fig.10 :Shema represente la notion de boucle.

Cette structure peut etre centralisee et on la represente comme un bloc monolithique. Elle peut aussi etre formee de cellules reunies en reseau et on la represente sous forme d'un automate cellulaire. On parle dans ce dernier cas d'environnement distribue. Chaque cellule se comporte comme un environnement centralise en miniature.

Ce qui distingue un environnement distribue d'un environnement centralise tient en quatre points :

ü L'etat de la cellule depend des autres cellules qui l'environnent et donc aussi des influences produites par les agents dans les cellules voisines.

ü La perception des agents s'etend generalement au-dela d'une cellule , ce qui fait qu'il n'est pas possible d'envoyer a l'agent uniquement les informations de l'etat de la cellule sur laquelle il se trouve.

ü Les agents se deplacent de cellule en cellule , ce qui fait qu'il faut gerer les liens que les agents entretiennent avec une cellule particuliere.

ü Des signaux peuvent se propager de cellule en cellule. Cette propagation prend un certain temps et il faut alors synchroniser le deplacement des signaux avec les mouvements des agents.

10. Communication entre les agents

10.1. Communication asynchrone :

Reponse non donnee immediatement. On demande et on n'attend pas la reponse, on fait autre chose en attendant.

10.2. Communication synchrone :

La communication synchrone est celle que l'on a le plus l'habitude de manipuler : c'est, par exemple , un appel de methode. Un objet demande quelque chose a un autre objet et attend la reponse avant de poursuivre son execution.

10.3. Communication directe (monocast) :

On discute directement d'un agent avec un autre agent : les deux agents sont en communication directe. En fonction des implementations, les deux objets se "connaissent" directement via leurs references, connaissent un proxy de l'objet ou ne connaissent que le nom de l'objet et utilisent les services d'un facteur pour delivrer le message. Les diverses implementations dependant du niveau d'independance que l'on veut donner aux agents.

10.4. Communication en groupe de diffusion (multicast) :

Inscription a une liste de diffusion et reception de tous les messages qui y sont associes (utilisation des sockets multicast).

La difference entre la communication directe et les listes de diffusion, est exactement la meme que celle qui existe entre le mail et les mailing-list. (On peut noter que les listes de diffusion s'apparentent a la technologie push.)

Dans le cas ou plusieurs listes existent, il est possible de les structurer sous forme d'une liste ou d'une arborescence. Cette derniere possibilite est beaucoup plus souple. De meme un objet partage peut gerer la liste des sujets et en ajouter a la demande d'un utilisateur.

Un cas particulier de la communication multicast est la communication broadcast. La communication broadcast consiste a envoyer un message a tous les agents du SMA. Ceci permet, par exemple , a un agent d'indiquer sa presence aux autres agents. Ce type de communication s'implemente tres facilement si l'on dispose d'une couche de communication multicast.

Note : Les sockets multicast sont basees sur le protocole UDP. Ce protocol se situe un niveau en dessous les sockets TCP/IP et ne garantie pas la reception des donnees envoyees. Il se peut donc que certains messages envoyes via les multicast sockets n'arrivent jamais.

10.5. Transport des messages :

Le transport des messages est un point important dans les SMAs : les agents "dialoguent" uniquement par echange de message, donc les performances du transport de messages influencent directement les performances du SMA.

Le transport des messages peut se faire de diverses manieres :

- a l'aide d'objets CORBA ou des sockets pour la couche de transport des donnees.

- D'autres systemes proprietaires permettent aussi de transporter des messages : PRC en C/C++ , RMI en Java, COM/DCOM sous Windows...,

- Par appel de methode directe sur l'agent ou appel de methodes sur un objet proxy de l'agent (celui-ci permettant aux autres objets/agents de ne jamais connaitre directement l'agent) ,

- Par utilisation d'un MOM (Message Oriented Middleware) qui agit comme un facteur et distribue les messages aux agents interesses.

Nous venons d'evoquer les methodes de transport susceptibles d'etres utilisees pour la communication directe entre deux agents, pour la communication multicast, on peut rajouter d'autres points :

- la gestion des differents sujets des listes de diffusion,

- la diffusion des messages d'un point de vue materiel : on peut utiliser la couche de transport de messages directs ou utiliser des protocols multicast, comme les multicast socket. Il faut aussi noter que dans le cas d'une implementation reseau , il faut definir un "reseau virtuel" logiciel au-dessus de la couche reseau materielle. En effet il faut pouvoir donner une adresse (equivalent a de l'adresse IP pour les machines) a tous les agents presents dans le systeme. Il faut aussi pouvoir router les messages afin que n'importe quel agent puisse dialoguer avec n'importe quel(s) autre(s) agent(s). Plusieurs solutions sont envisageables pour resoudre ce probleme :

- Un objet distribue unique qui attribue les adresses (objet CORBA par exemple) et qui gere le routage des messages,

- Une architecture du type reseau Ethernet (il me semble) , c'est a dire avec des routeurs (gateway) a differents niveaux. Par exemple un routeur par SMA puis un routeur pour un groupe de SMA. Cette architecture peut etre auto-configurable (en se basant en partie sur les adresses IP des machines par exemple) ou etre configuree par des fichiers d'initialisations par exemple.

11. Format d'échange des données

11.1. Format XML (description de la forme)



XML : permet de decrire des structures de donnees aussi bien que de representer des donnees. Ceci permet donc au langage XML d'être un bon candidat pour l'echange de donnees entre les differents agents du systeme.

Plusieurs solutions se presentent tout de meme pour l'echange de donnees avec XML : Les donnees que l'on echange n'ont pas une structure fixe (a priori), il faut donc :

- Soit decrire la structure des donnees dans le document XML puis construire un objet qui puisse accueillir ces informations ;

- Soit definir une bibliotheque d'objet qui sont susceptibles d'etres echanges ,

et se referer a cette bibliotheque lorsque l'on echange des informations.

Les deux solutions semblent envisageable et presentent chacune leurs

avantages et leurs inconvenients.

Il faut noter que l'utilisation de langages differents entraine d'autres problemes, notamment sur les types de base : un entier n'a pas la meme plage de valeur

dans tous les langages , etc.

11.2. Format ACL / KIF / KQML (description du fond)



KQML (Knowledge Query Modeling Langage) :

Est un langage qui permet de definir un moyen de communication uniforme entre les divers acteurs du systeme multi-agents. Ce langage , contrairement a XML decrit la forme dont les donnees sont echangees (du pseudo-lisp) mais aussi le fond, c'est a dire les informations a mettre dans le message. Meme si l'on utilise XML pour la forme, pour le contenu du message il peut etre interessant de regarder ce qui a ete fait avec KQML , Le nom de l'expediteur , du destinataire , le sujet du message, l'intention du message et/ou le type du message, la priorite du message, la date d'emission , la duree de validite (dans le cas d'une application oil la notion de temps est importante) le type de contenu de message, le contenu du message, etc.



FIPA-ACL :

Ces dernieres annees , KQML semble perdre du terrain au profit d'un autre langage qui est FIPA-ACL qui est plus riche semantiquement et dote d'une liste plus reduite de performatifs et d'une semantique plus precise que celle de KQML.

Theorique , FIPA-ACL s'inspire de la theorie des actes de langage; d'un point de vue plus technique, le message est egalement une chaine de caracteres possedant une syntaxe -à la LISP -(paires de parentheses) commencant par un nom de performatif et suivi par une liste de couples attribut-valeur.

FIPA-ACL s'appuie sur la definition de deux ensembles :

- Un ensemble d'actes de communication primitifs , auquel s'ajoutent les autres actes de communication pouvant etre obtenus par la composition des ces actes de base.

- Un ensemble de messages predefinis que tous les agents peuvent comprendre.

FIPA-ACL possede 21 actes communicatifs.

Ces actes communicatifs peuvent etre groupes selon leurs fonctionnalites de la facon suivante :

· Passage d'information: inform*, inform-if (macro act) , inform-ref (macro act) , confirm*, disconfirm*;

· Requisition d'information : query-if, query-ref, subscribe ;

· Negociation : accept-proposal, cfp , propose, reject-proposal ;

· Distribution de tiches (ou execution d'une action) : request*, request-when , request-whenever, agree, cancel, refuse ;

· Manipulation des erreurs : failure, not-understood.



KIF (Knowledge Interchange Format ):

Les agents ont besoin de comprendre le contenu des messages qu'ils recoivent. Ceci est possible par l'intermediaire de KIF.

KIF est un langage logique pour la description dans le cadre de systemes experts, bases de donnees ,... il a ete concu comme langage intermediaire , lisible par un programme et par un humain.

KIF est une version prefixee du calcul des predicats du premier ordre. La description du langage inclut une specification pour la syntaxe et une pour la semantique.

Exemple: (> (*(width chip1) (length chip1)) (*(width chip2) (length chip2))).

12. Cooperation

Il existe plusieurs points de vue sur la cooperation, selon que l'on considere que la cooperation est une attitude des agents qui decident de travailler en commun ou que l'on se pose comme un observateur qui interprete a posteriori les comportements.

- La cooperation comme attitude intentionnelle :

La cooperation est caracteristique d'une attitude (posture) des agents. On dit que des agents cooperent s'ils s'engagent dans une action commune apres avoir identifie et adopte un but commun.

Pour quelques chercheurs , il y a cooperation si les agents s'engagent dans une action et identifient un but commun , c'est-a-dire reconnaissent que les autres agents sont engages dans le meme but.

- La cooperation du point de vue de l'observateur :

On considere la cooperation comme une qualification de l'activite d'un ensemble d'agents par un observateur exterieur qui n'aurait pas acces aux etats mentaux des agents.

En tant observateur , on observe un certain nombre de phenomenes que l'on utilise comme des indices d'une activite de cooperation.

Voici quelques d'indices proposes par T. Bouron pour qualifier les activites de cooperations:

-Le degre de parallelisation , qui est fonction de la repartition des tiches et de leur resolution concurrente.

- La robustesse , qui concerne l'aptitude du systeme a suppleer la defaillance d'un agent. - La non redondance des actions, qui caracterise le faible taux d'activites redondantes. - La non persistance des conflits , qui temoigne du faible nombre de situations bloquantes.

Il existe deux indices qui semblent necessaires et suffisants pour caracteriser s'il y a ou non activite de cooperation :

1. L'ajout d'un nouvel agent permet d'accroitre differentiellement les performances du groupe.

2. L'action des agents sert a eviter ou a resoudre des conflits potentiels ou actuels.

13. La coordination

13.1. Definition :

La coordination d'actions est l'ensemble des activites supplementaires qu'il est necessaire d'accomplir dans un environnement multi-agents et qu'un agent poursuivant les memes buts n'accomplirait pas.

Exemple : les processus informatiques doivent synchroniser leurs actions lorsqu'ils accedent a des ressources communes de maniere a ce que le systeme reste dans un etat coherent.

La coordination d'actions est necessaire pour quatre raisons principales:

1. Les agents ont besoin d'informations et de resultats que seuls d'autres agents peuvent fournir,

2. Les ressources sont limitees , il est alors necessaire de coordonner les attitudes des agents pour eviter les eventuelles collisions d'acces ,

3. On cherche a optimiser les couts en eliminant les actions inutiles et en evitant les redondances d'action ,

4. On veut permettre a des agents ayant des objectifs distincts mais dependant les un des autres de satisfaire ces objectifs et d'accomplir leur travail en tirant eventuellement partie de cette dependance.

14. Négociation

14.1. Definition :

La negociation est une activite qui consiste a echanger des informations entre agents afin d'aboutir a un compromis mutuellement acceptable.

Les chercheurs en IAD utilisent la negociation comme un mecanisme pour coordonner un groupe d'agents. Differentes approches ont ete developpees en s'appuyant sur la riche diversite des negociations humaines dans divers contextes.

Un des protocoles les plus utilises pour negociation s'appuie sur une metaphore organisationnelle: le protocole du reseau contractuel (contract-net) a ete une des approches les plus utilises dans les SMAs.

15. Champs d'application des SMAs.

15.1. Simulation

Etudes de phenomenes complexes du monde reel : ethologie , scoiologie , economie environnement.

Representer et simuler des systemes sociaux ou naturels faisant intervenir un grand nombre d'individus

- Ecosysteme avec pecheurs, bancs de poisons et polluants ,

- Societe d'insectes : construction fourragement chez les fourmis , araignees , termites abeilles ...

- Formation d'un embouteillage , dynamique d'opinion ...

· Comprehension des interactions entre humains : simulations comportementales-explication de l'impact de comportement individuel sur le niveau global

- Etude de clienteles

- Integration de malades mentaux

· Modéliser des environnements virtuels : Jeux video (massivement //) multiJoueur, cinema (Massive), formation sur des environnements pour activités collectives.

15.2.Resolution de probleme

· Controle de processus distribue sans centralisation.

· Supervision d'un atelier de production: plusieurs machines, plusieurs pieces, plusieurs usinages , ...organisation ? Reorganisation en cas de panne ?.

· Supervision de reseaux de telecommunications : agents de suivi , agents de diagnostic de panne, agent operateur de maintenance.

· reseaux de transport (d'energie , ...) ...

15.3.o Integration >>faire inter-operer des logiciels avec des etres humains et des systemes mecaniques :

· Recherche et filtrage d'informations sur le Web: agregation de services
(ex : organisation voyage : billet train, chambre d'hotel , billet musee , ...)

· informatique diffuse ou intelligence ambiante, cpervasive computingo : monde informatique ouvert, capteurs ,

-Militaire , surveillance ,

-Social, surveillance des personnes agees a domicile ...

16. Exemple de systèmes multi agents (commerce electronique)

16.1. Les agents dans le commerce electronique

· Les agents d'analyse de la demande des consommateurs :

Ce sont les agents les plus importants , sont ceux qui s'adressent aux consommateurs , ceux qui analysent la demande globale pour adapter leur offre aux besoins du marche.

Voici les differentes fonctions qu'ils rempliront pour satisfaire au mieux les besoins du client :

1°) enregistrement du profil et des preferences de l'acheteur :

Informations generales (gouts, type de produits consommes, statut, professions...) ceci permettra :

ü Un accueil personnalise et guidage

ü Des propositions commerciales personnalisees.

2°) enregistrement des demandes successives d'un consommateur :

Il est necessaire d'enregistrer les demandes d'un consommateur pour l'analyser pour suivre en temps reel l'evolution du profil des consommateurs et de mieux donner :

ü Une synthese des demandes successives des consommateurs

ü Une analyse de la demande dans le temps tests ponctuel (ex : etude de l'impact micro-promotions ne durant que quelques minutes pour connaitre la reactivite des clients ou de leurs agents).

3°) Recommandation sur l'evolution de l'offre commerciale :

Les agents d'analyse de la demande auront acces a des statistiques sur la demande globale des consommateurs et seront a meme d'analyser les raisons des leurs succes ou de leurs echecs pour proposer des recommandations quant aux orientations future de la politique commerciales de leur societe.

v Benefice pour le consommateur : offre mieux adaptee a ses besoins.

v Benefice pour le marchand : meilleure connaissance de ses clients, reactivite plus grande.

· Les agents dédiés a l'analyse de l'offre :

L'agent intelligent peut prendre en charge a la place de l'utilisateur la recherche et la negociation des prix de produit pendant que celui-ci se consacre a d'autres travaux. Ces agents pourront donc renseigner sur :

ü La disponibilite d'un produit en menant une recherche par marque, recherche par categorie (produit+accessoires).

ü L'identification des distributeurs : localisation d'un distributeur precis Liste integrale ou selective de distributeurs (en fonction des services qu'ils offrent : garantie , facilite de paiement...)

ü En traitant les informations collectees :

Tableaux comparatifs des offres selon differents criteres :

ü Prix

ü Services

ü Avis des autres consommateurs (sur un livre , disque, une automobile,...). En etablissant une preselection automatique d'articles en fonction des preferences du consommateur (priorite au rapport qualite/prix , au service, aux avis des autres consommateurs...)

ü En realisant la transaction :

ü De façon automatique (achat repetitif d'un panier de produits/alimentation , achat des qu'un modele est en solde).

ü Ou semi-automatique : recommandation/suggestions , accords et transaction automatique (ordre d'achat, paiement, reception de la facture et gestion simplifiee de la comptabilite).

v Benefice pour le consommateur :

Minimiser le temps, analyser d'une offre commerciale plus etendue , transparence des marches. Soutien d'un agent qui connait de mieux en mieux ses goats.

v Benefice pour le distributeur :

Localisation plus facile des boutiques, augmentation des ventes pour celles qui parviennent ~ analyser la demande.

· Agents specialise dans la recherche de produits et services :

Ce sont des agents intelligents dedies a la recherche de produits et services. Il suffit de leurs indiquer les outils de recherche auquel ils doivent s'adresser, de taper les mots-cles pertinents et ils se chargeront de se connecter a Altavista, Yahoo ! , Magellan etc.... et rapatrieront automatiquement les documents correspondants aux criteres de recherche sur le disque dur de l'utilisateur.

Ils peuvent egalement verifier a intervalle regulier le contenu d'un site pour un client de tout changement du sur le site (baisse des prix, disponibilites d'un produit).

16.2. Agents existent déJà dans le commerce electronique:

ü Agents du courtage de produits :

Firefly [BIB 01]: aide ces utilisateurs a trouver des produits en utilisant la methode de la bouche a l'oreille en s'aidant des actions d'autres utilisateurs sans s'occuper des caracteristiques de produit. Il est actuellement utilise pour recommander des livres et CDs.

PersonaLogic [BIB 02] : comme Firefly l'agent aide l'utilisateur a trouver le produit qui correspond le plus aux caracteristiques definies , PersonaLogic utilise la recommandation par contrainte et applique le CSP pour atteindre son but.

> Agents du courtage de marchands

Bargain Finder [BIB 02] : developpe par Andersen Consulting, il est parmi les premiers agents qui comparent les prix en ligne , pour cela il interroge les sites offrant ces produits et compare leurs prix.

Jango [BIB 02]: plus avance que Bargain Finder, il utilise le « browser » du client pour lancer la recherche qui s'affichera d'une facon claire.

Kasbah [BIB 03] : concu dans les laboratoires du MIT, il utilise un systeme multi-agents pour la recherche des vendeurs , pour cela un agent est cree et lui assigne des contraintes qu'il doit utiliser pour trouver un acheteur ou un vendeur potentiel. Il est aussi un agent de negociation.

> Agents de négociation :

Tete-a-tete [BIB 04]: les agents de Tete-a-Tete utilisent la negociation cooperative, les agents vendeurs comme acheteurs sont aussi des agents de courtage qui utilisent le CSP pour trouver un produit donne.

AuctionBot [BIB 05]: developpe par l'universite du Michigan, l'utilisateur cree un agent pour vendre un produit en choisissant un type d'enchere donnee. La difference entre un site d'enchere et AuctionBot c'est que ce dernier, met en place une API qui permet la creation de son propre agent.

17. Inconvénients des SMAs

Les systemes multi-agents et malgre leur interet, ils soulevent plusieurs problemes.

-Un probleme important porte sur la definition d'un modele qui assure au modelisateur que l'outil informatique implemente bien le modele que le modelisateur a decrit , et que les consequences observes lors de la simulation sont bien directement des consequences du modele et non le produit d'un comportement non desire du systeme informatique.

-Un autre grand probleme tient dans l'explosion du nombre de communication entre agents pour l'organisation du SMA donc l'augmentation non negligeable des communications. Il arrive frequemment qu'une application SMA soit moins rapide ~ l'execution qu'une application non repartie.

1 8. Conclusion

Les interactions entre les agents et la resolution distribuee qu'elles mettent en place induisent alors une contradiction avec le principe d'autonomie de decision propre au concept d'agent. Les agents peuvent avoir conscience de cette resolution collective (agents cognitifs) ou non (agents reactifs) , mais de toute façon , ils utiliseront ou subiront a un moment ou a un autre des contraintes issues de leurs interactions avec les autres agents du systeme.

Toute la difficulte de concevoir des systemes multi-agents consiste alors a gerer cette contradiction entre le principe d'autonomie des agents et la resolution collective par le systeme qu'ils composent. Tous les agents doivent s'integrer au même systeme pour former un tout coherent resolvant le probleme a traiter, même si les formalismes qui modelisent les differents agents du systeme sont heterogenes. Cette necessite d'integration et d'interaction avec les autres fait intervenir des mecanismes et des notions permettant la coordination de la resolution distribuee du probleme pour obtenir un comportement global coherent et efficace du systeme. Les notions d'interactions et d'organisation permettent d'apprehender cette necessite.

Chapitre IV.

Anal~se et Conception

«Il semble que la perfection soit atteinte, non quand il nji a plus rien a
a~outer, mais quand il ny a plus rien a retrancher »
- Antoine de Saint Exupery.

Résumé : dans ce chapitre, nous presentons la conception de notre prototype. Nous entamons d'abord par une description fonctionnelle du système suivie d'une identification des cinq dimensions proposees par la methode voyelle: agent, interaction, environnement, organisation et utilisateur. Et nous terminerons par la modelisation de notre système avec le langage AUML.

1. Introduction

Notre projet qui s'inscrit dans le domaine de vente aux enchères en ligne par système multi-agent, vise a aider l'utilisateur du système durant tout le processus de son activite (achat \ vente). A fin d'atteindre ce but, nous procederons en mettant en application les notions presentees precedemment a travers :

- La description fonctionnelle du systeme, - La conception du Systeme Multi-Agents .

1.1. Description fonctionnelle du système (Besoins fonctionnelles)

Notre Travail consiste a concevoir et réaliser un système de vente aux enchères a

base de la technologie Agent, ayant comme but essentiel d'assurer cette activité en présentant les fonctionnalités suivantes :

1.1.1. Front-office : qui est le programme qui va interagir avec le client, Cette partie se decompose en plusieurs modules qui permettent aux clients et prospects de :

· Rechercher un produit a negocier,

· Entrer en negociations,

· Valider l'achat d'un produit.

1.1.2. Back-office : qui est une la partie invisible du système a laquelle le client n'a pas accès et qui permet :

· Négocier selon un protocole anglais le prix d'un produit,

· Mise a jour de l'information de vente d'une enchère spécifique,

· /nformer le client gagnant de l'enchère,

· supprimer une enchère vendu du système.

1.2. Choix de la méthode

Parmi les méthodes qui couvrent le mieux le cycle de développement d'un systèmes multiagents,nous avons choisi la méthodologie Voyelles pour modéliser notre système. Ce choix se justifie comme suit :

· Cette méthode repose sur la decomposition du système en cinq dimensions : Agent,

Environnement, /nteraction, Organisation, Utilisateur (cette dernière est créée récemment). Cette décomposition permet de modularisé le système, simplifier sa construction et offrir une meilleure réutilisation du code.

· Voyelles n'est couplée a aucune notation ni plateforme, ce qui offre la possibilité d'utiliser le langage AUML (Agent Unified Modeling Language : cf. Annexe B), qui est une extension du langage UML, dans la phase de conception du système et la plateforme Jade pour réaliser le système.

· Voyelles repose sur des principes purement multi-agents.
> Principes sur la methode « Voyelles »

Le processus de développement avec la méthode Voyelles (ou AE/O) comporte trois étapes essentielles :

· ? Analyse : consiste a identifier les cinq composantes : Agent (A), Environnement (E), /nteractions (/), Organisation (O), Utilisateurs (U).

· Conception : il s'agit de choisir les modèles opérationnels des composantes.

· Implementation : consiste en l'instanciation des modèles en utilisant des plateformes et des langages choisis.



Fig.11 : Representation symbolique d'un systè me multi-agents

2. Analyse

2.1. Identification des Agents

Vu que notre systeme s'inspire du modele client / serveur, en peut arranger ces agents en deux grandes classes :

2.1.1. Les agents de la plateforme Client : ce sont les agents qui se trouve sur la machine cliente chaque utilisateur connecte au systeme possede une instance de agents suivant :

> Agent GUI (AGUI) :

o Recoit des commandes de l'utilisateur et agit egalement, il n'a pas le comportement proactif,

o /l fait toutes les actions disponibles dans l'interface utilisateurs,

o Met a jour l'information de l'enchere lorsqu'il recoit des messages de la part d'autres agents.

> Agent negociateur (AN) :

o Négocie d'une manière automatique en faveur de l'utilisateur,

> Agent chercheur (AC) :

o Responsable de rechercher des articles au nom de l'utilisateur.,

o /nforme l'utilisateur si le produit désiré est disponible.

2.1.2. Les agents de la plateforme serveur : ces derniers se trouve sur la machine serveuse, on trouve egalement :

> Agent Principal (AP):

o Responsable de la creation des comptes, de l'authentification,

o Cree de nouvelles encheres, etablie la liste des encheres existantes,

o Cree un agent d'enchere lorsque une nouvelle enchere est ajouter au systeme

o Répond aux questions pour des articles ou des enchères.. > Agent d'enchere (AE) :

o Responsable de la commande d'une enchere particuliere,

o Les utilisateurs s'enregistrent a l'enchere et puis envoient des offres a l'agent d'encheres, L'agent d'enchere informe les utilisateurs enregistrés des changements du prix de l'article.

o A l'extrémité de l'enchère, cet agent informe le gagnant et le vendeur et passe la main a l'agent principal.

o Quand l'enchère est terminée, cet agent est supprimé.

2.1.3. Sche rna general du systerne



Fig.12 : Architecture générale du SMA (1)


· Une autre vue du systerne :



Fig.13: Architecture generale du SMA (2)

Le système, comme illustre dans les figures précédentes, est compose principalement d'un système multi-agents qui accede a la base (BDD clients et Catalogue d'encheres) et qui communique avec d'autres agents (clientl ,client 2) et leur donne possibilité de rechercher éventuellement des produits ,négocier le prix de vente.

2.2. Identification des Interactions

Dans ce qui suis nous utiliserons les abréviations suivantes : Agent GUI = AGUI, Agent chercheur = AC, Agent Négociateur = AN, Agent principal = AP, Agent d'enchere = AE

Comme illustre la schematisation precedente, voici les interactions qui existent entre les differents agents du systeme :

1. Interactions Agent GUI /Agent chercheur :

- L'AGU/ passe une demande de recherche d'un produit a l'AC,

- L'AC informe l'AGU/ sur le resultat de recherche d'un article desire, AC est dote d'un Comportement proactif

- L'AGU/ est responsable de la creation de l'AC.

2. Interactions Agent GUI /Agent Negociateur :

- L'AGU/ passe a l'AN les informations necessaires (Article desire ,Prix max ...)

- L'AN met à jour l'AGUI du prix atteint par l'article désiré.

- L'AGU/ est responsable de la creation et la destruction de l'agent negociateur.

3. Interactions Agent GUI/Agent principal :

- L'AGU/ s'enregistre / se connecte d'aupres l'AP en envoyant les informations Necessaires.

4. Interactions Agent GUI/Agent d'enchere :

- L'AE informe l'AGU/ du gagnant

5. Interactions Agent chercheur/Agent principal : - L'AC passe une requete de recherche a l'AP - L'AP reponde a la requete de l'AC

6. Interactions Agent Negociateur/Agent d'enchere : - L'AN negocie le prix (Augmentation raisonnable du prix) avec sa reciproque l'AE

- Apres la MAJ du prix par AE, ce dernier informe tout ces reciproques (AN) de cette MAJ

7. Interactions Agent principal/Agent d'enchere :

- Lorsque une nouvelle vente est ajoute au systeme , l'AP cree un AE responsable.

2.3. Environne ment du systeme

C'est l'environnement physique support des actions des agents et disposant des ressources.

L'environnement de notre SMA est constitue de :


·:* Les bases de donnees du site d'encheres (BDD clients+Catalogue des produits a vendre).

Re marque: L'environnement de chaque agent est constitue de l'environnement du SMA interne et les autres agents du SMA externe (clients+serveur).

2.4. Organisation

< L'organisation est une structure decrivant comment les membres de l'organisation sont en Relation et interagissent afin d'atteindre un but commun >.

L'organisation structurelle est donnee par la figure suivante.

Les /HMs du systeme represente ses points d'interaction avec les utilisateurs du systeme (Client / Admin) . La page d'accueil du client lui permet de se connecter ou de s'inscrire, une fois que le client s'est connecte l'Agent GU/ lui cree un agent de recherche et un Agent Negociateur .

Dans le serveur on trouve un Agent Principal et les Agents d'Enchères, L'administrateur a son tour possède une interface lui permettons de manipuler le catalogue des produits ainsi que la BDD des clients, de changer les informations du Serveur de données et de lancer ou arreter le service.



Fig.14: Organisation du systeme multi-agents.

2.5. Utilisateurs

Nous avons identifie deux types d'utilisateurs du systeme :


·:* Client : C'est l'utilisateur le plus important car il s'agit d'un systeme oriente client. /l

communique avec le systeme par l'intermediaire de son Agent GU/ . Parmi ses taches :

- /nscription et connexion au systeme via l'Agent principal (plateforme serveur),

- Recherche de produits,

- participer a une enchere et entrer en negociation.

- Valider l'achat d'un produit.


·:* L'utilisateur interne (Admin): c'est l'utilisateur qui interagit avec le Back-office du systeme, il est charge de la :

- Gestion du catalogue des produits.

3. Conception

Apres avoir detaille chaque composant du systeme, nous allons decrire dans cette section le scenario du comportement du systeme sous la forme d'un pseudo algorithme :

3.1. Scenario du processus de déroulement

Debut

- L'utilisateur se connecte au systeme via son application ;

-Si L'utilisateur existe déjà alors - chargement de l'interface ;

- L'utilisateur specifie ses criteres de recherche et lance l'operation;

- Creation de l'AC ;

- L'AC envoie une requete de recherche d'un produit a L'AP du serveur ;

- Si (le produit existe) alors

- L'AC informe L'utilisateur ;

// Prix_max : designe la plus grande somme que l'utilisateur peu pays pour l'article(attribut prive du client)

- Creation de L'AN // AN : representant du client
- L'AN d'une maniere automatique prend les information nécessaire (produit a

négocier, prix_max) et entre en négociation avec L'AE spécifique ;

- Tant que Non(Contraintes de terminaison d'enchère) faire

- Si (Prix_max > Prix_actuel) alors

- AN envoie une proposition de prix meilleur a AE

- AE met a jour le prix Actuel et le diffuse pour tout les ANs Concerné ; - AN met a jour L'AGU/ du prix atteint

Sinon

- en informe le client que l'enchère est terminée négativement

Fin TQ

- L' AE déclare le vainqueur et lui envoie un message d'information ;

- L'AE informe tout les ANs de la fin du processus et passe la main a L'AP;

- AN informe le client par l'intermédiaire de son AGU/ (ce dernier l'informe Visuellement le client) .

- Le Client se charge du processus de paiement (Transaction bancaire) . - L'AE ainsi que l'enchère sont supprimés par l'AP

Sinon

// /l s'agit d'un nouvel utilisateur

- Lors de la déconnexion du client l'AC et AN sont supprimés

Fin

> Pourquoi AUML ?

Les agents ont des activités autonomes et des buts ,c'est ce qui diffère un agents d'un objet ,par conséquent UML est insuffisant pour modéliser les agents et les systèmes multi-agents et c'est pour cette raison que nous avons utilisé AUML (Annexe B) pour modéliser notre système .

3.2 Diagrammes de cas d'utilisations

Ce prototype est réalisé avec l'environnement de développement Enterprise architect 6.5 version prof supportant les normes UML 2.0.

a. Cas d'utilisation « Vue globale du systeme»

Ce diagramme de cas d'utilisation présente 3 types d'acteurs : client, banque et administrateur. L'utilisateur peut s'abonner pour devenir un client. Le client est un visiteur déjà inscrit sur le site de vente aux encheres. /l peut chercher et enchérir produit, une fois identifié sur le site. L'administrateur peut gérer les encheres ainsi que les clients, apres s'etre identifié sur le site.



uc SMA_Enchéres

Client

Banque

Acheter produit

Gérer
Catalogue
produits

Chercher produit

Enchérir
produit

Admin

Fig.15: Diagra mme de cas d'utilisation <SMA d'encheres> (Vue globale). pres avoir raffiné chaque cas a part on obtient les cas suivant :

b. Cas d'utilisation « Recherche produit »

Une fois inscrit dans le système, le client introduit dans un formulaire ses besoins (intitulé, catégorie , prix_min ,prix_max , Date_debut , Date_fin) et lance une opération de recherche du produit demandé en se basant sur ses criteres introduits. Une fois celui-ci trouvée,

le résultat est affiché au client. Le diagramme ci-apres illustre cela :



Libelle Type Date debut

_ Date fin

_ Prix min

_ Prix _--max

Verifier disponibilite

Prenom

email

Activite

«include»

Nom

Specifier
criteres

Engager un AC

Remplire formulaire

Env oyer requete

Date_naiss

«include»

«extend» «include»

S'authenfifier

Mot passe

«include» «include»

«extend»

Client

Pseudo

Inscription

Chercher produit

uc Chercher produit

Fig.16 : Diagra mme de cas d'utilisation <rechercher produit>

c. Cas d'utilisation « Négocier produit (Enchérir) »

Lorsque le produit désiré est disponible l'utilisateur peut en gager un AN qui s'occupe de la négociation du prix ce dernier doit d'abord prendre les critères nécessaires (libellé, prix_max ,prix (prix actuel) ) après il s'enregistre a l'enchère et entre se met a l'action en envoyant des proposition



uc Négocier produit

Client

Négocier produit

Engager un AN Env oyer une

Prendre les
critéres

«include»

«include»

Libellé Prix_max Prix

«include»

S'enrégistrer a
l'enchére

«include»

proposition

Fig.17 : Diagra mme de cas d'utilisation <Négocier produit>

d. Cas d'utilisation « Achat produit »

Ce cas aura lieu lorsque le client est le gagnant de l'enchère, alors il est obligé a payer le produit en remplissant ses informations bancaires (Num_cb, Code secret du compte) et demander la transaction, l'AP du serveur vérifie la validité de la transaction et a son tour envoie un accusé de réception au client.



uc Achat produit

Client

Envoie Acusé

de réception «include» par AP «include»

Valider Achat

Introduire informations bancaires

«include»

Num_cb

Code_secret

«include»

Valider transaction

«include»

Transaction

Prix

Supprimer enchére

Banque

Fig.18: Diagra mme de cas d'utilisation <Achat produit >

e. Cas d'utilisation «Gérer le catalogue de produits»

La gestion de stock est une tache obligatoire est permanente que l'Administrateur doit effectuer, Ce dernier peut ajouter, modifier ou supprimer des produit du catalogue,

Ou chacun de ces opérations est effectué par l'AP.



uc Gérer catalogue produits

Gerer
catalogue

«include»

Se connecter

Admin

code_produit

Ajouter
enchére

Modifier
enchére

Supprimer
enchére

Libellé

«include»«include»«include»

Type

MAJ BDD par
AP

Prix_init

«extend» «extend»

Durée

Ajouter AE

extension points: Ajouter une enchére

Supprimer AE

extension points: Supprimer une enchére

Fig.19 : Diagra mme de cas d'utilisation < Gerer le catalogue de produits >

3.3. Diagrammes de sequences

Dans ce qui suit nous allons representer les differentes interactions dans le systeme en mettent en oeuvre les diagrammes de sequences.

a. Diagra mme de sequences « Authentification »



sd Authentification

AGUI

AP

BDD

Saisie (id,mot_passe)

Envoie (infos)

Informer (Exist)

alt Disponibilité client

[Existe=true]

Chargement d'interface

[else]

Message d'erreur

Vérification et validation (infos)

Réponse

:Client

Requete d'authentification

Demande des infos

Fig.20: Diagra mme de sequences < Authentification >

b. Diagra mme de sequences « Inscription »



sd Inscription

AGUI

AP

BDD

Demande d'inscription

Saisie des infos

Chargement d'interface

Chargement d'interface

Requéte d'inscription

Demande des infos

Envois (infos)

Confirmation

Ajouter client (infos)

:Client

Fig.21 : Diagramme de séquences < Inscription >

c. Diagra mme de sequences « Chercher produit »



sd Chercher produit

AGUI

AP

BDD

Lancer une recherche

Chargement d'interface

Introduire les infos

Créer()

AC

Prendre infos produit()

Informer (resultat)

Requete de recherche (infos)

Informer (resultat)

Envoie_acusé_réception

Chercher (infos)

Réponse (resultat)

:Client

Fig.22: Diagra mme de sequences < Chercher produit >

d. Diagra mme de sequences « Gestion du catalogue »



sd Gestion du catalogue

:Admin

Choix de l'operation et saisie d'infos

alt Manipulation BDD

[ops=ajout]

[ops=modif]

[ops=suppr]

Gui_Admin

Requete de modification (infos)

Requete de suppression (infos)

Requete d'ajout (infos)

Informer (resultat)

Informer (resultat)

Informer (resultat)

AP

Creer AE(prod)

Détruire AE (prod)

Supprimer produit (infos)

Modifier produit (infos)

Ajouter produit (infos)

BDD

Fig.23 : Diagra mme de sequences < Gestion du catalogue produit >

e. Diagra mme de sequences « Négocier produit»



sd Négocier produit

:Client

Lancer opération Négocier

AGUI

Prendre_criteres()

Créer()

Informer (echec)

Detruire()

[Enchére_terminé=faux]

loop Conditions de l'enchére

alt Condition d'une propsition

[Prix<Prixm_max]

[else]

AN

Demande d'inscription (infos)

Informer_MAJ_enchere(prix)

Réponse_proposition_recu

Envoie_proposition

Reponse

AE

Modifier prix enchére()

*

BDD

Fig.24 : Diagra mme de sequences < Négocier produit >

f. Diagra mme de sequences «Valider achat »

A la fin d'une vente, l'administrateur (qui joue le role du vendeur) peut accepter ou refuser la vente. Si celle-ci est acceptée, elle pourra etre considérée comme un contrat qui lie l'acheteur et le vendeur.

Pour payer un objet que l'acheteur a acheté, il faut entrer en contact avec le vendeur, lui demander le montant total (frais de port inclus) s'il n'est pas déjà précisé et lui envoyer

directement l'argent via un des moyens de paiement qu'il accepte. Pour contacter le vendeur, il faut utiliser l'e-mail du vendeur présenté en fin d'enchères. Le vendeur n'enverra l'objet qu'une fois le paiement recu. Une fois l'objet recu l'acheteur peut laisser une évaluation au vendeur qui en fera de même pour l'acheteur.

Note :

Litige : Un litige correspond a un non respect du contrat entre l'acheteur et le vendeur : produit non envoyé, produit envoyé défectueux, produit ne correspondant pas a celui acheté, non paiement, refus de l'achat.



sd Valider achat

AGUI

AE

AP

BDD

Informer (Gagant)

Informer_terminaison_(infos)

Detruire()

Demende payement

Chargement d'interface

Saisie_infos_banc

créer()

Transaction
bancaire

Verifier transaction ()

Supprimer produit (infos)

Demande transaction (infos)

MAJ_etat_enchére (etat=vendu)

:Client

Fig.25 : Diagra mme de sequences < Valider achat >

3.4. Diagrammes de classes

3.4.1. Conception de la base de donnees

a. Identification des classes

Apres avoir enumerer les entites que la realisation du systeme exige nous avons trouve ce qui suit :

· Entite <Client> : cette classe contient les informations sur les clients, une instance de celle ci permet de creer un nouveau client, modifier ou supprimer un ancien.

· Entite <Produit> : elle contient les informations sur les produits existant dans le catalogue de l'entreprise, Une instance de cette classe permet de creer un nouveau produit, En modifier ou en supprimer un.

· Entité <Type> : contient l'ensemble des types de produits.

b. Details des classes

Classe	Attribut | méthode	Description
Client	pseudo mp nom prenom date_nais adresse activité email état Ajouter() Modifier() Supprimer()	Pseudonyme Mot de passe Nom du client Prénom client Date de naissance Adresse du client Activité du client Un Email valide du client Connecté | deconnecté Ajouter un client Modifier un client Supprimer un client
Produit	code_prod libellé_prod prix_init prix date_d date_f etat_prod Ajouter() Modifier() Supprimer() Chercher()	code du produit Libelle du produit Prix initial du produit Prix actuel Date de mise en vente Date de fin de la vente vendu | non vendu Ajouter un produit Modifier un produit Supprimer un produit Effectuer une recherche d'un produit
Type	code_type	code du produit

Chapitre IV Analyse et conception

nom_type

nom du type

Tab.5 : Description des classes

c. Associations entre classes

Association	Classes incluses		Cardinalités	Acheter
Client	0..1
	1		Inclure
Type	1..n
	1

Tab.6 : Description des associations

d. Model UML

Le diagramme UML, illustre par la figure suivante, donne un apercu sur les classes citees precedemment, il presente 3 classes et 2 associations.

class BDD



Client

+ pseudo: String

+ mp: String

+ nom: String

+ prenom: String

+ date_nais: Date

+ activité: String

+ adresse: String

+ email: String

+ etat: boolean

+ Ajouter() : boolean {query}

+ Modifier() : boolean {query}

+ Supprimer() : boolean {query}

Porduit

+ code_prod: long

+ libélle_prod: String

+ prix_init: float

+ prix: float

+ date_d: Date

+ date_f: Date

+ etat_prod: boolean

+ Ajouter() : boolean {query}

+ Modifier() : boolean {query}

+ Supprimer() : boolean {query}

+ Chercher() : boolean {query}

1..*

Acheter
1 0..1

Inclure

1

Type

+ code_type: int

+ nom_type: String

Fig.26 : Diagra mme de Classe UML < Entités de la BDD>

e. Passage au model relationnel

- Client (pseudo , mp , id_Gprod* , nom , prenom , date_nais , adresse , activité , email , état ) - Produit (codeprod , pseudo*, mp* , codetype*, libellé_prod , prix_init , prix , date_d , date_f , etat_prod )

- Type (code_type , nom_type)

3.4.2. Classes internes du systeme

Pour ce qui suit la symbolisation des messages entres agents est donnée comme suit :



Message envoyé Message recu

a. Classe AGUI (Agent d'interface)



Cet agent recoit cinq messages et envoie deux messages.

Key* signifie que la clé est étrangere

b. Classe AC (Agent Chercheur)



Cet agent recoit un message qui contient le résultat et envoie deux messages.

c. Classe AN (Agent Négociateur)



Cet agent envoie et recoit trois messages.

d. Classe AP (Agent Principal)



L'agent principal comme son nom la plus part du travail se deroule autour de cet agent, il envoie et recoit cinq messages.

e. Classe AE (Agent d'enchère) :



L'agent d'enchere recoit deux messages et envoie cinq messages.

3.4.3. Diagra mme de classe d'agents

AE / Vendre un
produit

class Diagramme d'agent

«create»

«extends»

AP / gerer le catalogue
, responsable de
ventes

«implements»

«interface»

Protoco/Se/veur

«extends»

AC / Recherche
des produits

extends

implements

«Abstract»
Behaviour Jade

«create»

implements

«interface»
Protoco/Cfient

Agent Jade

extends

AGUI / Agent de ('interface client

extends

1 «create»

1

AN / negocier le
prix



4. Conclusion

Dans ce chapitre nous avons modélisé notre système, le but le plus important était d'introduire la notion des systèmes multi-agent dans la pratique des ventes au enchères afin d'automatisé quelque taches, Nous présenterons dans l'étape suivante a l'aspect technique de cette étude.

Chapitre V.

REALISATION

~Le privilege des grands, c'est de voir les catastrophes d'une terrasse » --Jean Giraudoux.

Résumé : Ce lo_giciel de la vente aux encheres via Internet traite les offres des clients et apres un certain temps et sous le protocole d'enchere an_glais choisit le _ga_gnant. Cette opération d'enchere s'appuie sur notre plateforme SIVLA.

1. Introduction

Préalablement a la réalisation du projet, nous sommes passés par une phase d'anal_yse et conception pour laquelle nous avons défini les besoin. Nous avons utilisé AUIVLL.

Remarque : dans ce qui passé nous avons proposé une architecture qui peut etre complete pour un s_ysteme de vente aux encheres en li_gne comprenant le paiement en li_gne, mais nous avons réalisé juste la partie la plus importante dans notre sujet, qui est le processus d'enchere selon le modele an_glais a base d'a_gents.

2. Environnement de développement 2.1. Choix de la plateforme multi-agents

JADE (cf. Annexe A) est une plateforme de développement d'a_gents _gratuits et Open Source développée par CSELT⁽⁰¹⁾ et qui résulte principalement d'une activité de recherche. JADE comprend deux composantes de base : une plate-forme a_gents compatible FIPA et un paquet lo_giciel pour le développement des a_gents Java, les 3 roles principaux définissant une plate-forme multi-a_gents sous la norme FIPA sont :

AMS (Agent Management System) : il fournit le service de nomma_ge, assure que chaque a_gent possède un nom unique et représente la fabrication des a_gents. En effet il peut créer et tuer un a_gent dans un conteneur de la plate-forme.

DF (Director Facilitator) : il fournit le service dit de «pa_ge jaune». Il a pour but d'aider a la recherche d'un a_gent _grace a son nom ou encore a ses compétences par exemple.

ACC (Agent Communication Channel) : il fournit la route (routa_ge des messa_ges) pour les interactions de base entre les a_gents dans et hors de la plate-forme.

¹⁰⁾ Centro Studi E Laboratori Telecomunicaioni, traduit par Centre d'Etude et Laboratoire de Tilicommunication : btt p://jade.cselt.it

-Pourquoi jade ?

Nous avons utilise jade a cause de sa richesse et la puissance de son API ,

les a_gents developpes sous la plate-forme Jade, sont entièrement ecrits en Java,

Jade assure une communication transparente par echan_ge de messa_ges dans le lan_ga_ge normalise FIPA-ACL,

Elle _g~re le c_ycle de vie des a_gents de leurs naissances jusqu'a leurs morts (creation, mort,reprise,
·).

2.2.Choix du langage de la programmation Ce lo_giciel, ecrit en JAVA, et la justification c'est que :

n Les A_gent developpes sous jade sont entierement ecrits en JAVA. Ce lan_ga_ge s'est donc impose comme etant une consequence du choix precedent,

n JAVA est un lan_ga_ge multiplateformes qui permet aux concepteurs, selon le principe: « write once, run every where », d'ecrire un code capable de fonctionner dans tous les environnements (quelque soit le s_ysteme d'exploitation),

n JAVA est un lan_ga_ge oriente objets, simple qui reduit le risque d'erreurs et d'incoherence,

n JAVA est dote d'une riche bibliotheque de classe comprenant la _gestion des interfaces _graphiques (fenetre, boite de dialo_gue),

n Un acces simplifie aux bases de donnees, soit a travers la passerelle JDBC-ODBC ou a travers un pilote JDBC specifique au SGBD,

Après le choix du lan_ga_ge, nous avons deux possibilites pour developper les interfaces

du SMA, soit des applications qui s'executent dans un browser (Applets), soit des applications autonomes qui s'executent au mo_yen d'une machine virtuelle.

L'applet a pour avanta_ge de ne necessiter aucune installation sur le poste de l'utilisateur ; en revanche, une Applet a un champ d'action beaucoup plus reduit pour les raisons de securite. Par ailleurs, le temps de char_gement d'une applet peut etre lon_g, les classes Java etant char_gees depuis un serveur Internet. Pour ces raisons nous avons choisi de concevoir une application Java plutOt qu'une Applet.



2.3. Choix du SGBD

Nous avons choisi le SGBD , il est base sur une architecture client/serveur.

Les points forts de M_ySQL sont :

- implementation libre et populaire ;

- facile a mettre en oeuvre ;



Chapitre V. Realisation

- rapide à apprendre ;

- support multi-plateforme ; - fiable et rapide.

2.4. Environnement de programmation

En ce qui concerne l'environnement de développement Java, nous avons choisi NetBeans 6.5.M1 qui est un environnement de développement inte_gre (EDI).

3. Architecture du prototype

3.1. Architecture logicielle

Fig.27 : Architecture logicielle du systeme.

3.2. Caracteristiques du Systeme

ü Portabilité : notre s_ystème est multi plateformes, c'est- à-dire qu'il peut etre execute sur plusieurs s_ystèmes d'exploitation.

ü La veille automatique : l'agent d'enchère informe l'agent négociateur dès qu'il y ait un changement de prix actuel. Ceci permet à l'agent d'interface utilisateur d'informer le client de ce changement.

82

4. Réalisation du système

4.1. Les agents de notre système

La creation d'un a_gent se fait par la pro_grammation d'une classe qui herite de la classe jade.core.A_gent. Cette classe doit posseder la methode setup() qui est appelee a l'initialisation de l'a_gent. A la creation de l'a_gent, il va lui etre attribue un identificateur a l'aide de la classe jade.core.AID.

Cet objet identificateur est de la forme : < nickname > @ < platform -- name >. On peut acceder a cet identificateur _grace a la methode _getAID.

Afin d'importer des comportements(behavior) on utilise o import

jade.core.behaviours.Behaviour » qui sont classes en trois cate_gories : OneShotBehaviours, C_yclicBehaviour et SimpleBehaviours().(cf. Annexe A).

ü Agent principal et d'enchère dans la plateforme JADE (Serveur)



Fig.28 :AP et AE dans la plateforme jade.

ü Agent GUI , Agent de recherche , Agent de négociation (Client)



Fig.29 :AGUI,AC,AN dans la plateforrne jade

4.2. Les interfaces du systerne

4.2.1. Interface de l'authentification

C'est l'interface où l'utilisateur peut accéder a son compte en remplissant le login et le mot de passe.



Fig.30 : Interface de l'authentification

4.2.2. Interface d'inscription

Cette interface a pour but d'abonnement du client s'il ne fi_gure déjà pas dans la BDD.



Fig.31 : Interface d'inscription. 4.2.3. Interface d'interaction client

Offre a l'utilisateur differentes possibilites pour visionner le catalo_gue des produits, et d'enter en ne_gociations.



Fig.32 : Interface d'interaction client.

4.2.4. Interface pour proposer des offres

Dans cette interface le client introduit son meilleur prix pour le produit choisie ainsi que la strate_gie utilise pour les ne_gociations (infos prises en compte par l'AN) , l'a_gent ne_gociateur

entre a l'enchere de maniere automatique , et si le prix actuel d'enchere dépasse le prix max , le client est informé~



Fig.33 : Interface pour proposer des offres. 4.2.5. Interface pour configurer l'agent negociateur



Fig.34 : Interface pour configurer l'agent negociateur. 4.2.6. Interface de payement



Fig.35 : Interface de payement. 4.2.7. Interface pour l'administrateur :

Cette interface permet :

- Démarrer/Arreter la plateforme Jade

- de manipuler les données aux BDD, il s'a_git de trois operations : ajouter, modifier et la suppression

- la confi_guration du Serveur BDD.

- de visionner les clients du s_ystèmes



Fig.36 : Interface pour l'administrateur.

Ajout d'un produit



Fig.37 : Interface pour ajouter un produit.

ü Suppression d'un produit



Fig.38 : Interface pour supprimer un produit.

ü Modification d'un produit



Fig.39 : Interface pour la modification d'un produit.

ü Suppression d'un Client



Fig.40 : Interface pour supprimer un produit.

ü Visionner les categories



Fig. 41 : Interface pour visionner les categories.

5. Conclusion

Nous avons présenté dans ce chapitre le logiciel que nous avons développé en se basant sur la solution des agents intelligents afin de favoriser la coopération entre ces derniers d'une part et d'introduire indépendance dans la prise de décision de notre système d'autre part. Cette implémentation a prouvé que l'utilisation du paradigme d'agent dans le e-commerce ainsi que la théorie des enchères peut offrir une nouvelle vision. Ce qui nous a fait comprendre le fonctionnement de cette technologie et son utilisation pour aboutir aux objectifs que nous nous sommes fixés.

Conclusion

&

Perspectives

~Les batailles qui mettent en concurrence des
paradigmes ne sontpas de celles qu'on peut arbitrer a
l'aide de preuves » -- .S. Kuhn

Perspectives

Notre travail , d'un point de vue personnel, nous a permis d'acquérir une certaine rigueur méthodologique et nous a permis aussi d'approfondir nos connaissances sur les SMA, la modélisation logicielle et les technologies réseau.

Dans ce travail, nous avons présenté le domaine des agents et systèmes multi agents, défini les applications e -commerce et l'utilisation des agents dans ce domaine en particulier dans les enchères.

Afin de montrer l'apport de ce modèle dans le domaine de vente aux enchères, nous avons développé un prototype de système multi-agents pour les enchères en ligne, ou l'apparition d'interaction et la coopération d'un ensemble d'agents. Ce système est destiné a combler les points suivants :

ü Permet a l'administrateur de déposer des produits a enchérir ;

ü Permet au client de trouver le produit désiré et participer aux enchères.

ü Permet de diminuer le temps de recherche grace a l'utilisation de plusieurs agents donc diminuer le temps de connexion (répartition des taches) ;

ü Automatiser l'enchère aux niveaux de négociations (Agents dédies spécialement a l'enchère et la négociation).

ü Utilisation des stratégies de négociations [Une seul proposition (one shot bid) , 1ere position (Always first ) , Enchérir périodiquement (Periodic Bid) ].

Conclusion

Sans nous projeter davantage dans le futur, les SMA trouvent déjà des applications
dans les télécommunications, le travail collaboratif assisté par ordinateur, la robotique, la

simulation de systèmes complexes, les bases de données réparties (Recherche concurrente ), les systèmes multi -capteurs,

le commerce électronique, la bioinformatique, la planification et la supervision, l'optimisation des problèmes spatiaux etc.

Toutes ces applications montrent a quel point les SMA peuvent trouver une place dans l'industrie logicielle de demain. Ce nouveau concept de modélisation et de programmation devrait s'imposer progressivement mais des efforts sur des méthodologies de conception restent a faire afin de guider le développeur dans l'élaboration de ses futures applications distribuées.

Malgré l'intéret grandissant de la communauté scientifique et commerciale envers les SMA, il est raisonnable de prendre en compte également les problèmes engendrés par la distribution de l'informatique. Ce que l'on gagne par un traitement des taches en parallèle assuré par des

agents intelligents, on le perd par la somme considérable des informations échangées entre agents. En outre le traitement massivement parallèle induit par les SMA montre la faiblesse des architectures matérielles actuelles. Le nombre de processus sur une machine est naturellement limité. Cependant de nouvelles puces électroniques verront probablement le

jour pour palier cette complexité de traitement. A chaque problème sa solution mais le temps a toujours son mot a dire ...

Glossaire

ACL

Agent Communication Langage : Langage de communication qui combine habilement KQML et KIF. KQML est pris pour la partie administrative et KIF pour la représentation des données et /ou expressions a évaluer.

API

Application Programming Interface : Bibliothèques d'objets (dans le cas de langages objets) qui permettent au programmeur d'utiliser directement des objets. L'API réseau du Java permet d'ouvrir des sockets, mais aussi de gérer les adresses IP ainsi que les URL.

CORBA

Common 0bject Request Brocker Architecture : Une architecture définie par l'0MG qui permet l'implémentation d'objets distribués. Ces objets sont accessibles par l'intermédiaire de nombreux langages grace a la définition d'IDL.

Framework

Ensemble d'outils (de conception, d'exécution, de dégage) qui permettent de faire quelque chose, par exemple de mettre en oeuvre d'autres programmes. Ces outils peuvent êtres des programmes, des méthodes de travail, des librairie, etc.

IDL

Interface Definition Language : Un langage qui permet de définir les objets C0RBA. Une Interface IDL déclare les opération, exceptions et attributs. IDL ne permet pas d'implémenter les objets, comme son nom l'indique, il ne fait que définir les interfaces des objets.

Java / JDK

Java, langage créé en 1995 par Sun, ce langage est orienté

objet et présente le gros avantage d'être portable. JDK (Java

Développement Kit) est le kit de développement Java fournis

par Sun pour le développement de programmes Java.

KIF

Knowledge Interchange Format : Langage qui permet de coder des expressions, algorithmes ou données dans le plus pur style Lisp : 3+5 deviens (+ 3 5)

KQML

Knowledge Query Modeling Langage, ce langage est le standard de fait pour l'échange d'information entre les agents. (Pour s'en persuader, il suffit de regarder la liste des produits déjà existants).

MOM

Message 0riented Middleware : Middleware orienté message, c'est un middleware qui contrairement a C0RBA ou RMI ne permet pas l'appel de méthodes a distances, mais seulement l'échange de messages. Un M0M peut aussi contenir des services.

ORB

0bject Request Broquer : Les librairies, processus et autres infrastructures qui permettent, dans un environnement distribué C0RBA, aux objets de communiquer entre eux. L'0RB permet aux objets qui demandent des services d'entrer en contact avec les objets qui fournissent ces services.

OSI

0pen System Interconnection : Le modèle 0SI est composée de 7 niveaux. Ces niveaux sont organisés de maniere hiérarchiques. Les niveaux sont définis de telle sorte qu'une modification dans un niveau ne nécessite pas de modification dans les autres niveaux.

Proxy

0bjet et /ou programme qui permet d'accéder a des ressources qui ne sont pas accessibles directement, c'est donc un intermédiaire. L'utilisation d'un proxy est en général de protéger la ressource a laquelle on veut accéder. RMI

Remote Method Invocation est une technique qui permet a des objets Java de se servir d'objets Java distants comme s'il s'agissait d'objet local. L'équivalent en C /C++ est RPC (Remote Procedure Call). C0RBA fournis les memes fonctionnalité, mais présente l'avantage de ne pas etre réduit a un seul langage.

Socket

0bjet qui permet de communiquer sur un réseau de type TCP/IP. La création d'une socket nécessite un serveur sur lequel on se connecte et un client qui

se connecte a ce serveur. Les deux peuvent ensuite communiquer, c'est " dire, envoyer et recevoir des suites d'octets. La définition d'un protocole de

communication est donc indispensable.

Thread

Programme qui s'exécute a l'intérieur d'un autre programme : ceci permet " un programme de faire plusieurs choses en même temps. Un thread est parfois appelé tache.

UDP

User Datagram Protocol : Protocole en dessous de TCP/IP sur le modèle 0SI. Ce protocole ne garantie pas l'arrivée des données (datagrams), ni leur ordre d'arrivée.

FIPA

est une organisation a but non lucratif produisant des normes pour l'inter opérabilité des agents hétérogenes de logiciel.

www.fipa.org

Bibliographie

[RDJ, 99] Robert ORFALI, Dan HARKEY, Jerri EDWARDS

Titre: CLIENT/SERVEUR GUIDE DE SURVIE

Date : Novembre 1999

[BRN, 95] Bernard Fabrot

Titre : Réinstaller Windows

Date : 1995

[ROU,02] Siegfried Rouvrais, Université de Rennes

Titre : « Utilisation d'agents mobiles pour la construction de

services distribués »

Date : Juillet 2002

[DCO,95] Douglas Comer, tcp/ip

Titre : architecture, protocoles, applications

Date : 2005

[ Fig ,1] Image : Architecture client-serveur

Lien : http://www.mpandco.com/images/client_serveur.jpg

[FRA, 04] Laurent Franck

Titre : architecture client/serveur,

département de génie électrique en informatique, INSA de Toulouse Date : 2004

[CAB, 07] Cabani Adnane

Titre : these pour obtenir le titre de docteur en informatique

Réseaux pair a pair et simulation distribuées Application a la simulation Multi-agent

Date :16/7/2008

[ferb,95] Les Systèmes Multi-Agents-Ferber, J --Inter Editions, 1997.

[woold,2001] An Introduction to MultiAgent Systems--Wooldridge, M. --Wiley 2002.

[Brio t,2001] Principes et Architectures des SMA--Briot, J.-P.,

Demazeau, Y., -I Hermes, 2001.

in agent-based systems, Proceedings of the first European Conference on Cognitive Science'95:117-132, 1995

[Ferber, 1995] Ferber J., Les systèmes multi-agents : vers une intelligence

collective, InterEditions, ISBN : 2-72-96-0572-X, 1995.

[Ferber, 1999] Ferber J., Multi-Agent Systems - An introduction to distributed
artificial intelligence, Addison-Wesley, ISBN 0-201-36048-9, 1999.

[Maes, 1995] Maes P., Intelligent Software, Scientific American, volume 273,
numéro 3, septembre 1995, pp.84-86.

[Drogoul, 1998] A. Drogoul, J.-D. Zucker, LIP6 1998/041: Rapport de Recherche LIP6 - 30 pages -Octobre/October 1998

[Varela, 1989] Varela F., Connaitre les sciences cognitives : tendances et perspectives.

Paris : Seuil, ISBN : 2-02-010474-1, 126 p, 1989.

[BIB 01] Il y a beaucoup des articles qui expliquent PersonaLogic, Bargain Finder

et Jango (et qui les comparent avec leurs alternatives), il suffit de faire une recherche sur google.

[BIB 02] Chavez Anthony, Pattie Maes, "Kasbah: An Agent MarketPlace

for Buying and Selling Goods", in proceedings of The First International Conference on The Practical Application of Intelligent Agents and

Multi-Agent Technology (PAAM"96), pp. 75-90, 1996. Asc/ [e-mail]

[BIB 03] R. Guttman and P. Maes, "Agent-mediated Integrative Negotiation

Retail Electronic Commerce." in the proceedings of

the Workshop on Agent Mediated Electronic Trading (AMET"98), Minneapolis, Minnesota, April 1998.

[BIB 04] P. Wurman, M. Wellman, and W. Walsh, "The Michigan

Internet AuctionBot: A Configurable Auction Server

for Human and Software Agents." in proceedings of the Second

International Conference on Autonomous Agents (Agents"98), May 1998.

"Representing agent interaction protocols in UML".

[BEL 00] Bellifemine F., Giovani C., Tiziana T. Rimassa G., "Jade Programmer's

Guide" Jade version 2.6 ( http://www.fipa.org/specs/fipa00001/), 2000.

[BEL 99] Bellifemine F., Poggi A., Rimassa G., "JADE -- A FIPA-compliant
agent framework", CSELT internal technical report. Part of this report has been also published in Proceedings of PAAM'99, London, pp.97-108, April 1999.

Annexe A.

~ Le progres technologique n'abolitpas les obstacles; il en change simplement la nature o - Huxley, Aldous

La plate~~orme Jade

Java A_gent DEvelopment Framework

1. Introduction

Pour construire un s_ystème multi-a_gent (SMA) on utilise une plate-forme multi-a_gent. Une plate-forme multi-a_gent est un ensemble d'outils nécessaire a la construction et a la mise en service d'a_gents au sein d'un environnement spéci fique. Ces outils peuvent servir é_galement ' l'anal_yse et au test du SMA ainsi créé. Ces outils peuvent etre sous la forme d'environnement de pro_grammation (API) et d'applications permettant d'aider le développeur. Nous allons étudier dans cette partie la plate-forme JADE(Java A_gent DEvelopment framework).

2. Bref description de JADE

JADE (Java A_gent DEvelopement framework) est une plate-forme multi-a_gent créé par le laboratoire TILAB et décrite par Belli femine et al. Dans [BEL 99], [BEL 00]. Elle permet le développement de s_ystèmes multi-a_gents et d'applications con formes aux normes FIPA. Elle est implémentée en JAVA et fourni des classes qui implémentent o JESS » pour la dé finition du comportement des a_gents. JADE possède trois modules principaux (nécessaire aux normes FIPA).

· DF « Director Facilitor » ;

· ACC «Agent Communication Channel »;

· AMS « Agent Management System ».

Ces trois modules sont activés à chaque démarrage de la plate-forme.

3. Architecture logiciel de la plate-forme JADE

Chaque instance de l'environnement d'exécution de JADE s'appelle un conteneur (container) car il peut contenir plusieurs a_gents. L'ensemble des conteneurs acti fs s'appelle une plate forme. Dans une plate forme, un conteneur spécial appelé conteneur principal (Main-container) doit toujours etre en activité, les autres conteneurs s'enre_gistrent auprès de celui-ci des qu'ils démarrent. Le conteneur principal héber_ge les a_gents techniques de Jade (DF, AMS, RMA, Dumm_yA_gent, ...).

La fi_gure suivante représente des modules sous forme des services de base qui sont le Director_y Facilitator (DF) et l'A_gent Mana_gement S_ystem (AMS), mais le service (MTS) sera char_gé a la demande, L'AMS est un autre composant important car ce service e ffectue la correspondance entre l'a_gent et leur identi ficateur (AID), Il n'_y a qu'un AMS par plate-forme.



Fig.1 : Architecture logiciel de La plate-forme JADE.

4. Architecture de la bibliotheque des classes

JADE est compose des packa_ges suivantes :

- JADE.CORE : implante le no_yau du s_ysteme et possede les classes 'Agent' et'behaviours' - Le package JADE.LANG : contient un sous packa_ge' JADE.LANG.ACL' pour chaque lan_ga_ge de communication utilise jade.

- JADE.CONTENT : contient l'ensemble du classes qui definissent les ontolo_gie.

- JADE.DOMAIN : contient toutes les classes java qui representent les entites a_gent mana_gement definies par FIPA particulierement AMS, DF.

- JADE.GUI : contient les classes utiles pour creer des GUIs,l'edition des messa_ges et la description des a_gents.

- JADE.MTP : contient une interface java que chaque MIP (MESSAGE TRANSPORT PROTOCOL) doit implementer.

- JADE.PROTO : contient les classes qui modelisent les protocoles standards d'interaction, et permettre aux pro_grammeurs d'ajouter d'autres protocoles.

5. Outils de debogage de JADE

Pour supporter la tâche difficile du débogage des applications multi-agents, des outils ont été développés dans la plate-forme JADE. Chaque outil est empaqueté comme un agent, obéissant aux mêmes règles, aux mêmes possibilités de communication et aux mêmes cycles de vie d'un agent générique (agentification de service).

5.1. Agent RMA (Remote Management Agent) :

Le RMA permet de contrôler le c_ycle de vie de la plate-forme et tous les a_gents la composant. L'architecture répartie de JADE permet le contrôle a distance d'une autre plate-forme. Plusieurs RMA peuvent etre lances sur la meme plate-forme du moment qu'ils ont des noms distincts.



Figure 2 : L'interface de l'agent RMA

5.2. Agent Dammy

Cette interface permet la composition et l'envoi de messa_ges ACL et maintient une liste de messa_ges ACL envo_yés et re_cus. Cette liste peut etre examinée par l'utilisateur et chaque messa_ge peut etre vu en détail ou meme édité.ou bien le sauve_gardé sur le disque et renvo_yé plus tard.



Figure 3 : L'interface de l'agent Dammy.

5.3. Agent Direcory Facilitator

L'inter face du DF peut etre lancée a partir du menu du RMA .Cette action est en fait implantée par l'envoi d'un messa_ge ACL au DF lui demandant de char_ger son interface _graphique. L'inter face peut etre juste vue sur l'hOte oil la plate-forme est exécutée. En utilisant cette interface, l'utilisateur peut intera_gir avec le DF.



Figure 4 : L'interface de l'agent DF.

5.4 Agent Sniffer

Quand un utilisateur décide d'épier un agent ou un groupe d'agents, il utilise un agent sniffer. Chaque message partant ou allant vers ce groupe est capté et affiché sur l'interface du sniffer.



Figure 5 : L'interface de l'agent Sniffer

5.5 Agent Inspector

Cet agent permet de gérer et de contrôler le cycle de vie d'un agent s'exécutant et la file de ses messages envoyés et reçus.



Figure 6 : L'interface de l'agent Inspector.

6. Cycle de vie d'un agent



Figure7 : Le cycle de vie d'un agent.

Voici la description des di fférents états d'un a_gent en accord avec la spéci fication de la FIPA :

-Initiated : l'objet a_gent est créé mais n'est pas encore enre_gistré aupres du service de nomma_ge (AMS).

- Active : l'objet a_gent est enre_gistré aupres du service de nomma_ge (AMS), il possède désormais une adresse unique et peut donc communiquer avec les autres a_gents.

- Suspended : l'exécution de l'a_gent est suspendu.

- Waiting : l'a_gent est bloqué et doit attendre un événement comme un messa_ge par exemple. -Transit : l'a_gent rentre dans cet état lorsqu'il mi_gre dans un autre conteneur.

-Deleted : l'a_gent est détruit et supprimé du service de nomma_ge (AMS).

7. Les Behaviours (Comportements)

Un comportement dé finie les taches qu'e ffectue un a_gent. Quelque soit le t_ype du Behaviour, il doit implémenter la méthode action() qui dé finit la sé_quence des instructions a exécuter et lorsque la méthode done() retourne true elle s'arrete.

La méthode block() d'un comportement permet de bloquer ce dernier. Suite a l'arrivée d'un

nouveau messa_ge.

Pour ajouter un comportement a la file des comportements de l'a_gent, on utilise la méthode addBehaviour(new BehaviourClass(Parametres)) de la classe 'a_gent'.

On distingue plusieurs types de comportement, les plus utilisés sont:

- Classe o Behaviour o : c'est la classe de base a partir de laquelle sont dérivés les autres classes de Behaviours.

Exemple :



public class MonBehaviour extends Behaviour{

// Ici vous pouvez declarer des variables

// Un Behaviour possède un constructeur

public MonBehaviour(/*paraml, param2,...*/){

// Initialisation du Behaviour.

}

public void action(){

// Traitement

// cette méthode est exécutée jusqu'a ce que la méthode done() retourne true.

}

public boolean done() {

return valeurBooleenne_;

}
}

- Classe OneShotBehaviour : c'est une spécialisation de la précédente, la méthode action() est exécutée une seule fois (par dé faut, la méthode done() retourne true). Donc vous n'avez pas a redé finir la méthode done().

- Classe CyclicBehaviour : la méthode action() est exécutée en répétition, la méthode done() retourne false. N'oublier pas de bloquer le Behaviour a la fin de la méthode action(), car il fait une boucle infinie (_gaspilla_ge de CPU). Le Behaviour sera débloqué quand un nouveau messa_ge est inséré dans la file de l'a_gent.

- Classe WakerBehaviour: la méthode action() est exécutée apres un temps donne en parametre (exprime en millisecondes) et une seule fois.

- Classe TickerBehaviour : la méthode action() est exécutée chaque t milliseconde (t est donne en parametre a la creation du Behaviour).

8. Communication entre agents

La communication entre agents se fait par un langage qui est FIPA-ACL(Agent Communication language). La classe ACLMessage représente les messages qui peuvent être échangés par les agents. La communication de messages se fait en mode asynchrone. Lorsqu'un agent souhaite envoyer un message, il doit créer un nouvel objet ACLMessage, compléter ces champs avec des valeurs appropriées et enfin appeler la méthode send(). Lorsqu'un agent souhaite recevoir un message, il doit employer la méthode receive() ou la méthode blockingReceive().

Un message ACL dispose obligatoirement des champs suivants :

Performative :	type de l'acte de communication
Sender :	expéditeur du message
Receiver :	destinataire du message
reply-to :	participant de la communication
content :	contenu du message
language :	description du contenu
encoding :	description du contenu
ontology :	description du contenu
protocol :	contrôle de la communication
conversation-id :	contrôle de la communication
reply-with :	contrôle de la communication
in-reply-to :	contrôle de la communication
reply-by :	contrôle de la communication

Tab.1 :Les champs d'un message ACL.

Tous les attributs de la classe ACLMessa_ge peuvent etre obtenus et modi fies par les methodes set/_get(). Le contenu des messa_ges peut etre aussi bien du texte que des objets car la serialisation Java est supportee.

8.1. Envoi d'un message

Exemple : Le code suivant correspond a l'envoi d'un messa_ge a l'a_gent « Yacine » dans le but de l'in former que (Le match de football est termine)

ACLMessa_ge ms_g = new ACLMessa_ge (ACLMessa_ge.INFORM)_; ms_g.addReceiver (new AID ("Yacine", AID.ISLOCALNAME))_; ms_g.setLan_gua_ge (" Fran_cais ");

ms_g.setOntolo_gy (" match")_;

ms_g.setContent ("le match de football est terminé ");

send (ms_g)_;

8.2. Reception d'un message.

Exemple : on bloque le comportement jusqu'a l'arrive du ms_g.

ACLMessa_ge ms_g = receive (); I f (ms_g! = null) {

// traiter le messa_ge

}Else { Block ();

}

. Conclusion

Le rôle de la plate-forme JADE est de réaliser la couche communication inter-agents de façon à pouvoir faire une argumentation sans l'intervention de l'humain et donc dans cette optique de les rendre autonome. On se sert pour cela du langage ACL pour que les agents s'échangent leurs messages.

Annexe B

~ La machine d'arithmitique ait des e~~ets qui approchentplus de la pensee que tout ce que ont les animaux mais elle ne ait rien qui puisse aire dire qu'elle a de la volonte, comme les animaux »-Blaise

Pascal.

AUML

Agent Unified Modeling Language

1. Introduction

Les faiblesses d'UML pour la représentation des systèmes multi-agents ont conduit une équipe de chercheurs travaillant dans différentes entreprises ou universités (Siemens, University Paderborn, Intelligent Automation, Fujitsu...) a concevoir AUML. L'objectif est de mettre au point des sémantiques communes, des méta-modèles et une syntaxe générique pour les méthodologies agents. AUML est un des fruits de la coopération entre FIPA (Foundation of Intelligent Physical Agents) et l'OMG (Object Management Group). Par rapport a UML, AgentUML propose des extensions pour la représentation des agents que nous détaillerons dans cette annexe.

2. Principes sur UML

UML (Unified Modeling Language) [Odell, 1 998] unifie et formalise les méthodes de plusieurs approches orientées objets. UML prend en charge plusieurs types de modèles :

· Les cas d'utilisation : la spécification des actions que le système ou la classe peut réaliser en interaction avec les acteurs extérieurs. Ils sont souvent utilisés pour décrire comment un utilisateur communique avec son logiciel.

· Les modèles statiques : ils décrivent la sémantique statique des données et des messages d'une manière conceptuelle et d'une manière plus proche de l'implémentation (il s'agit des diagrammes de classes et de packages).

· Les modèles dynamiques : ils incluent les diagrammes d'interaction (i.e., les diagrammes de séquence et les diagrammes de collaboration), les schémas d'état et les diagrammes d'activité.

· Les modèles d'implémentation : ils décrivent la répartition des composants sur différentes plateformes (i.e., les modèles de composants et les diagrammes de déploiement).

3. Déficiences d'UML

L'idée générale d'AUML est de combler les déficiences d'UML pour la modélisation des systèmes a agents. Parmi ces déficiences, on trouve [Marc03] :

· Des relations entre classes statiques (agrégation, généralisation, et association) mais qui semblent tout de même adéquats. Il est possible d'utiliser des associations de classes et des stéréotypes pour étendre UML avec des relations spécifiques pour les agents.

· Les accointances sont des relations importantes entres agents, Il s'agit d'une relation dynamique entre des instances et UML n'est pas très adapté pour les représenter.

· Un certain nombre de concepts de haut niveau (comme les engagements, les contrats, etc.) peuvent etre relativement bien représentés avec UML mais d'autres (comme les croyances et les intentions) ne le peuvent pas.

· Il est difficile de representer l'etat interne des agents. Il faudrait un modele proposant des concepts de haut niveau o cognitif » (BDI, BC, GAP, ...).

· UML n'est pas efficace pour representer des connaissances fonctionnelles (buts, planification, processus, etc.). Pourtant beaucoup de methodologies agents utilisent les buts et la decomposition de buts en sous-buts.

· Il n'est pas evident que les approches de modelisation à etats finis soient adaptees pour les agents. Les agents ont des espaces d'etats vastes qu'il n'est pas evident de partitionner en un plus petit nombre de macro-etats de plus haut niveau. Les agents peuvent apprendre et s'adapter à differentes choses et des parametres comme les croyances interagissent pour influencer le comportement de facons subtiles. Ces systemes sont dynamiques, non lineaires et ont un comportement emergeant.

4. AUML

AUML [Odell,00] est base sur la methode UML (Unified Modeling Language) qui est une methode de genie logiciel utilisee pour les developpements en langages orientes-objets. Elle est dejà largement utilisee par la communaute des concepteurs-objet et son succes continue de croitre.

Comme nous l'avons dejà vu, par rapport aux objets, les agents ont des activites autonomes et

des buts. C'est cette difference qui entraine l'insuffisance d'UML pour modeliser les agents et les systemes multi-agents. Aussi AUML remplace-t-il la notion de methode par celle de service. Ses principales extensions sont :

- Diagramme de classes d'agent qui est une reformulation du diagramme de classes d'objets,

- Diagramme de sequence qui permet une meilleure modelisation des interactions entre

agents,

- Diagramme de collaboration qui complemente le diagramme de sequences en proposant

une autre lecture et vision des interactions entre agents.

5. Presentation generale des extensions d'AUML 5.1. Le diagramme de classes d'agent

Une classe d'agent represente un agent ou un groupe d'agents pouvant jouer un role ou avoir un comportement determine, Une classe d'agent comporte :

-Description de la classe d'agent et des roles;

-Description de l'etat interne ;

-Actions, methodes et services fournis ;

-Messages echanges



Fig.1 : Diagramme de classe d'agent.

- Nom de la classe agent/ role1, role2,...: Un agent d'une classe donnée peut avoir plusieurs roles (un détaillent peut etre acheteur ou vendeur) .

- Description des états: Définition de variables d'instance qui refletent l'état de l'agent, - Actions (Plans): deux types d'actions peuvent etre spécifies: action pro-active exécutée

par l'agent lui meme si une pré-condition devient vraie, et ré-active résultant d'un message recu d'un autre agent. En d'autres termes les actions sont les plans qu'a un agent.

- Méthodes: Elles sont définies comme dans UML, avec éventuellement des pré-conditions, post-conditions ou invariants.

- Envoi et reception de messages: description des messages émis

et recus par l'agent en précisant les protocoles.



-Un automate : représente les changements d'état induits par les échanges de messages.

5.2. Protocoles d'interaction (AIP : Agent Interaction Protocol):

Exemple de representation :




· Un decoupage en couches :

Dans le protocole de la figure ci-dessus, aucune precision n'est donnee sur le traitement ou la construction des messages :

- La construction de la requete (par Submitter) peut etre un processus complexe decrit par un diagramme d'activites ;

- Le traitement de cette requete (par Solver) peut etre decrit par un autre diagramme d'activites ou de sequence.

- Ce decoupage en couches reifie les processus inter-agents et ceux internes a chaque agent.

La couche superieure : c'est le protocole qui est representee sous la forme de package ou de template.

- Un package agrege des morceaux de modeles pour former un ensemble conceptuel ;

- Un template est un modele ayant des parametres (Trois types de parametres : role, contraintes et actes de communication) qui sont specialises a l'instanciation.

La deuxieme couche : les echanges entre agents :

ü Diagrammes de sequences :

Nommage des acteurs : nom-agent/rOle:classe ;

- Les messages echanges ne sont plus des noms de methodes mais des actes de communication ; -Les threads d'interaction concurrents :

-emissions concurrentes : connecteur and ;

0 ou plusieurs emissions a la fois : connecteur or ;

1 seule emission parmi plusieurs candidates : connecteur xor

ü Diagrammes de collaboration :

Se construisent comme dans les modeles objets ;

Similaires aux diagrammes de sequences ;

ü Diagrammes d'activites :

Decrivent les operations entre agents et les evenements qui les declenchent ; Comparables aux reseaux de petri colores :

Representation graphique des processus ;

Representation des traitements concurrents et asynchrones ; Representation de communications simultanees avec divers participants

Diagrammes d'etats de transitions :

Decrit les changements d'etat lors des echanges entre agents ; Facilite la description des contraintes sur les protocoles.

La troisieme couche : les traitements internes de l'agent : -Diagramme d'activites pour chaque agent ;

-Diagramme d'etats-transitions pour chaque agent.

6. AUML et les autres methodologies

Les objectifs entre AUML et nombre de methodologies (Gaia, MaSE, etc.) orientees agent sont communs : partir de methodologies ou langages de modelisation orientes objet et les etendre au paradigme agent ;

Des representations (diagramme ou modele) entre AUML et diverses methodologies

7. Limitations d'AUML

-Les diagrammes sont desordonnes et peuvent etre mal interpretes ;

-L'expression de toutes les informations necessaires sur les protocoles peut les rendre illisibles ;

-Les cas de redondance sont difficiles a identifier et corriger ;

-La description des actions temporelles (telles que le timeout, deadline, ...) est difficile a exprimer ;

- La notion d'historique des echanges n'existe pas ;

-La terminaison des interactions n'est pas toujours specifiee.

8. Conclusion

Aujourd'hui AUML n'est pas encore un langage de modelisation fini et adopte par la communaute car aucune specification finale n'a ete publiee officiellement mais plusieurs publications sur des extensions d'UML ont etes publiees par les membres du groupe. Actuellement, leurs travaux se concentrent sur les interactions, plus specifiquement sur les protocoles d'interaction, mais aussi sur d'autres aspects connexes comme les langages d'interaction, la coordination, les roles des agents. D'autres travaux portent egalement sur les architectures, et les ontologies.