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


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

 > 

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

( Télécharger le fichier original )
par Yacine Sahraoui
Université Larbi Ben M'Hidi Algérie - Ingénieur d'état en informatique 2009
  

Disponible en mode multipage

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

    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 Med 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 ;
    041 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 système multi-agents pour les enchères en ligne qui permet d'automatiser les opérations commerciales aux acheteurs, en offrant un catalogue qui contient les produits mis en enchère afin de satisfaire les besoins du client.

    Le but essentiel c'est d'avoir un certain degré d'autonomie a l'aide de ces entités logicielles intelligentes ou tout simplement agents qui sont des programmes auxquels on peut déléguer une tache. Le système diffère du logiciel 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 système multi-agents oil les agents sont programmé en JAVA sous la plateforme JADE et se communiquent avec le langage commun FIPA-ACL.

    Notre travail consiste a comprendre le fonctionnement de deux architectures a savoir le paradigme client-serveur et celui des systèmes multi-agent 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, types de conceptions...).

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

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

    Chapitre 5 : nous arrivons dans ce chapitre a l'implémentation de notre systè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 : Systèmes Multi agents, la vente aux enchères, commerce électronique.

    Problématique et Objectifs

    Problématique :

    Les sites de vente en ligne 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 système de vente aux encheres ou les négociations se déroule selon un protocole anglais en se basons sur des agents 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 signaler au gagnant 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 (2) 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]

    (1).Programmes ournissant des acces a des ressources : utilisation CPU (ressources physiques), d'interrogation. (2).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 systeme 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(3) (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(4).

    [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(5).

    · 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.

    (5).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.

    · Systè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(6): 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 hybride 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.

    (6). 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.

    Fig.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.

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

    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 typologies 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(7).

    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 :

    .

    (7)*Inter ace utilisateur, logique de traitement et les données partagees

    Tab.3: Synthè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

    (8)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.

    (9) 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 10100comportements 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 , idGprod* , 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 logiciel de la vente aux encheres via Internet traite les offres des clients et apres un certain temps et sous le protocole d'enchere anglais choisit le gagnant. 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'analyse 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 systeme de vente aux encheres en ligne comprenant le paiement en ligne, mais nous avons réalisé juste la partie la plus importante dans notre sujet, qui est le processus d'enchere selon le modele anglais a base d'agents.

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

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

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

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

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

    10) 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 agents developpes sous la plate-forme Jade, sont entièrement ecrits en Java,

    Jade assure une communication transparente par echange de messages dans le langage normalise FIPA-ACL,

    Elle g~re le cycle de vie des agents de leurs naissances jusqu'a leurs morts (creation, mort,reprise,
    ·).

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

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

    n JAVA est un langage 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 systeme d'exploitation),

    n JAVA est un langage 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 dialogue),

    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 langage, 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 moyen d'une machine virtuelle.

    L'applet a pour avantage 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 chargement d'une applet peut etre long, les classes Java etant chargees 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 MySQL 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 integre (EDI).

    3. Architecture du prototype

    3.1. Architecture logicielle

    Fig.27 : Architecture logicielle du systeme.

    3.2. Caracteristiques du Systeme

    ü Portabilité : notre système est multi plateformes, c'est- à-dire qu'il peut etre execute sur plusieurs systè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 agent se fait par la programmation d'une classe qui herite de la classe jade.core.Agent. Cette classe doit posseder la methode setup() qui est appelee a l'initialisation de l'agent. A la creation de l'agent, 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 categories : OneShotBehaviours, CyclicBehaviour 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 figure 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 catalogue des produits, et d'enter en negociations.

    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 strategie utilise pour les negociations (infos prises en compte par l'AN) , l'agent negociateur

    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'agit de trois operations : ajouter, modifier et la suppression

    - la configuration du Serveur BDD.

    - de visionner les clients du systè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/ pattie@media.mit.edu

    [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 Agent DEvelopment Framework

    1. Introduction

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

    2. Bref description de JADE

    JADE (Java Agent DEvelopement framework) est une plate-forme multi-agent créé par le laboratoire TILAB et décrite par Belli femine et al. Dans [BEL 99], [BEL 00]. Elle permet le développement de systèmes multi-agents 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 agents. 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 agents. 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'enregistrent auprès de celui-ci des qu'ils démarrent. Le conteneur principal héberge les agents techniques de Jade (DF, AMS, RMA, DummyAgent, ...).

    La figure suivante représente des modules sous forme des services de base qui sont le Directory Facilitator (DF) et l'Agent Management System (AMS), mais le service (MTS) sera chargé a la demande, L'AMS est un autre composant important car ce service e ffectue la correspondance entre l'agent 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 packages suivantes :

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

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

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

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

    - 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 programmeurs 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 cycle de vie de la plate-forme et tous les agents 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 messages ACL et maintient une liste de messages ACL envoyés et recus. Cette liste peut etre examinée par l'utilisateur et chaque message peut etre vu en détail ou meme édité.ou bien le sauvegardé sur le disque et renvoyé 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 message ACL au DF lui demandant de charger 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 interagir 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 agent en accord avec la spéci fication de la FIPA :

    -Initiated : l'objet agent est créé mais n'est pas encore enregistré aupres du service de nommage (AMS).

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

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

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

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

    7. Les Behaviours (Comportements)

    Un comportement dé finie les taches qu'e ffectue un agent. Quelque soit le type 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 message.

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

    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 (gaspillage de CPU). Le Behaviour sera débloqué quand un nouveau message est inséré dans la file de l'agent.

    - 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 ACLMessage peuvent etre obtenus et modi fies par les methodes set/get(). Le contenu des messages 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 message a l'agent « Yacine » dans le but de l'in former que (Le match de football est termine)

    ACLMessage msg = new ACLMessage (ACLMessage.INFORM); msg.addReceiver (new AID ("Yacine", AID.ISLOCALNAME)); msg.setLanguage (" Francais ");

    msg.setOntology (" match");

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

    send (msg);

    8.2. Reception d'un message.

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

    ACLMessage msg = receive (); I f (msg! = null) {

    // traiter le message

    }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.






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








"I don't believe we shall ever have a good money again before we take the thing out of the hand of governments. We can't take it violently, out of the hands of governments, all we can do is by some sly roundabout way introduce something that they can't stop ..."   Friedrich Hayek (1899-1992) en 1984