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