Discussion :

[wang_xue]

je suis en train de faire un projet sur le site eBay,
la première chose,il faut faire un diagramme use case.

j'ai du mal pour trouvé des fonctionnalités pour la transaction et archivage,est-ce qu'ils sont lié avec les acteurs direct ou pas.

Et aussi pour l'idendification,il peut faire un rôle de fonctionnalité ou pas ?

[hed62]

Généralement, l'identification est une précondition à la majorité des UC. Pour moi, ce n'est pas forcément un UC, une simple phrase suffit pour préciser les pre-co.

[wang_xue]

si je fais une fonctionnalité qui s'appelle group d'action,dans cette group d'action,il organise des inscriptions,vérification des paramètres, modification des informations,autorisation des ventes ou des achats par administrateur gérer des historiques des ventes,identifcation pour vendeur,achteur,administrateur,ça sera bon ou non.

[hed62]

J'ai du mal à te comprendre... Peux tu poster une ebauche de diagramme pour que cela soit plus clair ?

[wang_xue]

dsl,vous avez raison,je vais faire ce soir et fournir tout de suite

je fourni le petit schéma use case.mais je ne sais pas si c'est correct ou pas ????

[hed62]

Les UC (les 'ronds') doivent à mon sens contenir des verbes, non pas des noms. Sans être puriste, je ne sais pas trop si ton UC est "correct" pour te citer. Personnellement je le comprend très bien, mais peut être n'est'il pas standard.

Peux tu developper ton "groupe d'actions" ? Je ne vois pas très bien où tu veux en venir.

N'oublie pas qu'un acteur peut hériter d'un autre. Si A hérite de B, alors A peut faire tout ce que peut faire B, en plus d'autres choses.

Voila je pense que tu dois revoir pas mal de choses, même si dans l'esprit tout est clair

[wang_xue]

Je refais un UC avec 3 acteur acheteur vendeur et administrateur,je fais aussi 3 scenarii avec préconditions,vous pouvez voir et me donne quelque conseils.


1 Use Case : Participer vente
Niveau : But
Description : L'Acheteur participe vente sur le site eBay et peut enchérir sur les lots en vente.
Acteur primaire : Acheteur.
Pré-condition : L'Acheteur est identifié.
Scénario principal :
1. L'Acheteur rejoint la vente.
2. Le Système affiche le début de la vente.
3. Le Système affiche l'objet mis en vente et son prix.
4. L'Acheteur enchérit sur le lot.
5. Le Système reçoit l'enchère.
6. Le Système met à jour le prix du lot.
7. L'Acheteur devient l'acquéreur du lot.
8. Le Système adjuge le lot à l'Acheteur
Les étapes 3 à 8 se répètent tant qu'il y a des lots à vendre.
9. Use case se termine.

a. L’Acheteur quitte la vente
a.1. Use case se termine.
b. L’Acheteur discute.
4a. L'Acheteur n'enchérit pas sur le lot
4a.1. Use case continue au point 3.
7a. L'Acheteur n'est pas l'acquéreur du lot
7a.1. Use case continue au point 3.


2 Use Case : Gestion des Ventes
Niveau : But
Description : Un Administrateur se connecte au Système afin de gérer les nouvelles ventes. Il entre les informations concernant la vente et choisit le mode de fonctionnement (automatique ou prix de réserve). En fonction de ce choix(selon le type d'enchère). L'Administrateur doit spécifier en plus de la date d’ouverture,
la date de lancement de vente pour l'historique(consulter par l'acheteur ou le vendeur). Il sélectionne ensuite la liste des objets qui seront proposés à la vente.
Acteur primaire : Administrateur.
Pré-condition : Un Administrateur est identifié.
Scénario principal :
1. L'Administrateur crée une nouvelle vente.
2. L'Administrateur entre les informations sur la vente.
3. L'Administrateur gérer la vente en mode manuel.
4. L'Administrateur entre la date d’ouverture de la vente.
5. L'Administrateur sélectionne un objet pour la vente.
L’étape 5 se répète tant que l'administrateur le désire et qu’il reste des objets.
6. L'Administrateur valide la création de la vente.
7. Le Système informe l'administrateur que la vente est créée.
8. L'Administrateur quitte le serveur.
9. Use case se termine.

Extensions :
3a. L'Administrateur(ou le système) gérer la vente en mode manuel (mode automatique).
3a.1. L'adminstrateur entre la date de lancement de la vente.
3a.2. Use case continue en 4.
4a. L'Administrateur n’entre aucune date d’ouverture.
4a.1. Use case continue en 4.
5a. L'Administrateur ne sélectionne aucun objet.
5a.1. Use case se termine en erreur.


3 Use Case : Proposer l'objet
Niveau : But
Description : Le Vendeur propose un objet qu’il désire vendre. Il rentre les informations le concernant et transmet sa demande au Administrateur du site web.
Acteur primaire : Vendeur.
Pré-condition : Le Vendeur est identifié.
Scénario principal :
1. Le Vendeur entre le nom de l’objet.
2. Le Vendeur entre une description de l’objet.
3. Le Vendeur joint photographie(s) ou non.
4. Le Vendeur transmet la proposition d’objet au Administrateur du site web.
5. Le Système informe le Vendeur que sa proposition est en attente d’une validation.
6. Use case se termine.
Extensions :
1a. Le Vendeur n’entre pas de nom.
1a.1. Use case continue en 1.
2a. Le Vendeur n’entre pas de description.
2a.1. Use case continue en 2.

[hed62]

Ok, on s'approche d'un beau dossier

Ton premier "use case" n'en est pas vraiment un : tu devrais ne pas le présenter ainsi, mais en un simple paragraphe. Toutefois, la présentation des autres use case est très bien.

Dans ta description, tu dis qu'un administrateur valide les objets mis en vente, et dans ton diagramme tu dis qu'un vendeur peut valider des objets : il y a une petite contradiction. Je pense que seul un Administrateur peut valider un objet, non ?


Les deux use case "s'inscrire" et "s'identifier" peuvent etre factorisés :
-Acheteur hérite de user
-Vendeur hérite de user
-Administrateur hérite de user
-Acheteur, Vendeur, Administrateur ne peuvent ni s'identifier ni s'inscrire
- un User peut "s'inscrire" et "s'identifier"

"b. L’Acheteur discute." Je ne comprend pas trop cette ligne : tu devrais détailler un peu plus.

"Extensions :
1a. Le Vendeur n’entre pas de nom.
1a.1. Use case continue en 1.
2a. Le Vendeur n’entre pas de description.
2a.1. Use case continue en 2. "
Ces extensions ne sont pas réellement nécessaires, même si elles permettent de préciser l'obligation de saisir les informations.

[wang_xue]

)

Ton premier "use case" n'en est pas vraiment un .


Dans ta description, tu dis qu'un administrateur valide les objets mis en vente, et dans ton diagramme tu dis qu'un vendeur peut valider des objets : il y a une petite contradiction. Je pense que seul un Administrateur peut valider un objet, non ?.[/


le premier use case,je veut juste expliquer un petit démarche ou un petit introduction global.
Dasn la description,j'ai oublié de rajouter une phrase pour dire le vendeur peut valider sa proposation sur l'objet à vendre,c'est pour ça je crée un lien entre le vendeur et valide l'objet.Mais j'accepte votre conseil,parce que le vendeur peut faire une demande pour participer mise en vente ou proposer l'objet,mais il ne peut pas valider son choix par propre main,il faut toujours demande l'administrateur au 1er temps,donc je supprime le lien entre les deux et je fournis au autre schéma.



Les deux use case "s'inscrire" et "s'identifier" peuvent etre factorisés :
-Acheteur hérite de user
-Vendeur hérite de user
-Administrateur hérite de user
-Acheteur, Vendeur, Administrateur ne peuvent ni s'identifier ni s'inscrire
- un User peut "s'inscrire" et "s'identifier"

mais le pb est si je fais user et tous les autres acheteur hérite,je dois faire un lien entre user et s'inscrire et s'identifier ou pas,on je laisse comme ça,vous aller voir mon nouveau schéma.

"b. L’Acheteur discute." Je ne comprend pas trop cette ligne : tu devrais détailler un peu plus.

cela veut dire l'acheteur peut augment le prix s'il désire de obtenir l'objet forcément.
"Extensions :
1a. Le Vendeur n’entre pas de nom.
1a.1. Use case continue en 1.
2a. Le Vendeur n’entre pas de description.
2a.1. Use case continue en 2. "
Ces extensions ne sont pas réellement nécessaires, même si elles permettent de préciser l'obligation de saisir les informations.
je vais supprimer cette extension.

[hed62]

a. L’Acheteur quitte la vente
a.1. Use case se termine.
b. L’Acheteur discute.

Ok, je comprend mieux cette partie. Il faut juste la rattacher au scénario nominal, comme tu l'as fait ici :

4a. L'Acheteur n'enchérit pas sur le lot
4a.1. Use case continue au point 3.
7a. L'Acheteur n'est pas l'acquéreur du lot
7a.1. Use case continue au point 3.

Pour le User (je me suis mal exprimé, je devrais parler d'Utilisateur puisque tout ton diagramme est en francais... désolé pour cet anglisisme... Considère que User devient Utilisateur)

je dois faire un lien entre user et s'inscrire et s'identifier ou pas

Oui tout à fait :
Ajoute les flèches Utilisateur -> s'identifier et Utilisateur->s'inscrire
et retire les flèches
Vendeur -> s'inscrire,
Vendeur -> s'identifier,
Acheteur -> s'identifier,
Acheteur -> s'inscrire,
Administrateur -> s'inscrire,
Administrateur -> s'identifier

tu ne devrais pas avoir un Administrateur -> Valider inscription ?

[hed62]

D'autre part, les relations d'héritage ne portent pas de nom. Elles signifient toutes la même chose: si A hérite de B , alors la flèche signifie : "A est un B".

le premier use case,je veut juste expliquer un petit démarche ou un petit introduction global.

Oui, ca confime ce que je disais : ne le présente pas comme un use case, mais comme un paragraphe rédigé, qui va introduire ton système.

[wang_xue]

Scénario principal :
1. L'Acheteur rejoint la vente sur le site.
2. Le Système affiche le début de la vente.
3. Le Système affiche le prochain d’objet mis en vente et son prix.
4. L'Acheteur enchérit sur l’objet.
5. Le Système reçoit l'enchère.
6. Le Système met à jour le prix d’objet
7. L'Acheteur devient l'acquéreur du lot.
8. Le Système adjuge le lot à l'Acheteur
Les étapes 3 à 8 se répètent tant qu'il y a des lots à vendre.
9. Use case se termine.
Extensions :
a. L’Acheteur quitte la vente
a.1. Use case se termine.
b. L’Acheteur discute.
Les étapes 4 à 7 se répètent tant que un autre acheteur veut enchéit l’objet qu’il désire.
4a. L'Acheteur n'enchérit pas sur le lot
4a.1. Use case continue au point 3.
7a. L'Acheteur n'est pas l'acquéreur du lot
7a.1. Use case continue au point 3.
je modifie un peu sur la extension,si c'est bon???
vous voulez dire,il faut avoir une fonctionnalité "Valider inscription" si j'ai compris.
je modifie mon schéma vous voyez si c'est bon

par contre pour l'utilisateur,comment je peux expliquer cet acteur,pour l'acheteur,je peux expliquer qu'il veut participer vente et le vendeur veut proposer l'objet,vous pouvez m'expliquer un peu la explication pour l'utilisateur.

CF mon image UC