Discussion :

[_Kiro]

Bonjour à tous, et a toutes

Je viens fraper à votre porte pour vous demander un petit conseil.

Voila, je fais en ce moment des diagrammes de Use Case pour un magasin physique qui a un site internet.

Les clients peuvent commander via internet ou par téléphone.

Ma question est la suivante :

Dois-je faire 2 Use case :

-Commander par téléphone
-Commander par internet

Ou alors un seul "Commander" et faire différents scénarii dans la déscription de celui-ci?


De plus, coté acteurs, dois-je mettre un seul acteur "Client" ou alors distinguer les "visiteurs" qui ne sont pas inscrit/logués des "clients"


Merci pour votre aide, et bonne nuit à ceux qui vont dormir

[TheLeadingEdge]

Bonjour,

-Commander par téléphone
-Commander par internet
Ou alors un seul "Commander" et faire différents scénarii dans la déscription de celui-ci?

Comment se passe 1 commande par téléphone ?
C'est le téléphone qui sert de terminal ? Ou la commande est faite via 1 opérateur interne ?
Dans le premier cas on peut (éventuellement) ne faire qu'1 ''commander''.
Dans le second il faut identifier l'acteur ''operateur'' car c'est lui qui va interragir avec le système.

De plus, coté acteurs, dois-je mettre un seul acteur "Client" ou alors distinguer les "visiteurs" qui ne sont pas inscrit/logués des "clients"

A priori Visiteur et Client sont des acteurs différents.Ils vont avoir des comportements différents.
1 ''visiteur'' ne commandera pas.
1 ''visiteur'' pourra créer 1 ''compte client''.

1 ''client'' pourra commander etc...

[bruno_pages]

Je suis d'accord avec TheLeadingEdge pour la distinction client / visiteur, de plus que l'on commande par téléphone et par internet aboutit à une commande, donc :

[ego]

Sans plus de détail sur les 2 UCs (ok pour 2 UCs), je ne pense pas que la modélisation de Bruno soit juste.
Ce n'est pas parce que les 2 UCs aboutissent finalement à la création d'une Commande que l'on doit utiliser l'include. Je dirai tout au plus que l'intersection des post-conditions des 2 UCs n'est pas vide, c'est tout.
Les 2 UCs correspondent à 2 intentions dont les scénarii d'utilisation de l'application sont a priori différents.

[_Kiro]

Salut

Pour la commande sur internet, c'est la manière classique, un client ajoute des produits au panier puis valide sa commande. (je suppose que je ne dois pas faire de UseCase pour 'ajouter' 'supprimer' 'modifier' les articles du panier, je décris ces différents options dans un diagramme d'activité , nan?


Par téléphone, c'est un robot qui prend en charge la commande, tout est automatisé.

Voila quelques précisions qui pourront vous aider.

Par contre je ne comprend pas bien la notion de système ici.
Pour moi le système serait la base de données et les client/employé interagissent avec cette dernière.
Si vous pouviez m'expliquer aussi cela, ca serait vraiment excellent


Edit : une autre question me turlupine la tête...

Si un employé veut passer une commande, comment fait-on dans ces cas la?
On dit qu'il doit etre client ou alors on le relie au useCase 'commander'??

MERCI en tout cas de passer du temps à m'aider

[bruno_pages]

Si un employé veut passer une commande, comment fait-on dans ces cas la?
On dit qu'il doit etre client ou alors on le relie au useCase 'commander'??

je suppose que tu parles d'un employé qui passe une commande à titre privé, dans ce cas il devient un client comme un autre, les acteurs ne représentent pas des personnes mais des rôles ... cette fois-ci je pense que Ego sera d'accord avec moi

note : Ego a écrit un tutoriel sur les use cases

[_Kiro]

je suppose que tu parles d'un employé qui passe une commande à titre privé

Oui c'est bien ca

les acteurs ne représentent pas des personnes mais des rôles ... cette fois-ci je pense que Ego sera d'accord avec moi

Ah oui c'est vrai, merci pour ce rappel concernant la définition des acteurs, je note ca bien précieusement pour plus poser ce style de question

Merci pour ton aide


Sinon, est-ce que quelqu'un pourrait répondre aux questions qui restent en suspen s'il vous plait?

[ego]

Absolument ok pour acteur = rôle
je suis d'accord avec Bruno

[_Kiro]

Bonjour à tous

Voici une esquisse des UseCase que je viens de réaliser.

Si vous pouviez me dire ce que vous en pensez

Merci !

[ego]

je supprimerai "S'identifier" et je préciserai la notion de recherche

[bruno_pages]

si tu laisses le UC s'identifier tu dois retourner la dépendance avec commander par internet

et je ne pense pas que l'UC creer compte client inclue s'identifier, ou alors ce n'est pas la meme que pour commander par internet car l'utilisateur n'effectue pas exactement les meme actions.

[_Kiro]

Merci pour vos réponses.


Suivant vos conseils, je devrais retirer le UC "s'identifier".

Je suis d'accord, cela signifierait que
-Le rôle de client considère que le membre s'est déjà identifié identifié ==> simplifie la déscription du scénario vu qu'il n'y aura alors pas de scénario tel "si le client a oublié de s'identifier et qu'il a déja rempli un caddie..."

-Le rôle de visiteur considère aussi bien l'utilisateur non client que le client non identifié (vu que le client non identifié ne peut alors pas passer commande)


Donc je pense que le schéma deviendrait alors le suivant (voir pièce jointe)

[ego]

"uses" inutile
Les flèches que tu utilises ne sont pas les bonnes
Pour l'identification, tu peux mettre cela en pré-condition des UCs ou le préciser simplement au début du scénario du UC

[Nip]

J'arrive un peu apres la bataille mais il y a un probleme avec l'include creer un compte client. En effet il etend un UC accessible seulement a l'acteur client... qui a deja un compte.

Sinon, est il necessaire de creer un compte client pour commander par telephone?
Un acteur est en trop car tous les UC sont accessibles par celui actuellement appele "client" (qu'il sera necessaire de renommer) et Visiteur sera a supprimer: un seul acteur est suffisant.

Ensuite, Employe devrait aussi etre un acteur secondaire des UC commander; d'ailleurs, pour moi, ces 2 UC commander par internet et par telephone ne representent qu'un seul et meme UC commander; c'est a peu pres la meme chose que de savoir quel mode de paiement va adopter le client. Ca n'ajoute pas de valeur dans ce cas, ca serait donc a simplifier. Par contre tu peux les preciser dans la description textuelle.
J'ai du mal a voir l'interet de l'UC "finaliser commande": ca s'apparente plus a une action qu'a un cas d'utilisation . Ca serait plutot un UC "Traiter une commande", avec eventuellement le client en acteur secondaire (mais ce n'est peut etre qu'une question de vocabulaire dans ce cas).

Il faudrait renommer l'UC "Rechercher produit sur le site" en "Rechercher produit". Tu peux aussi, comme de l'a deja indique ego, specialiser ton UC Rechercher en precisant les differents types de recherches accessibles par exemple.

Pour l'UC s'identifier il est aussi possible de le mettre en cas d'utilisation inclus.

[ego]

Absolument ok pour la remarque sur l'include. Cette relation est fausse.
Pour la différenciation entre les différents canaux (téléphone ou internet), tout dépend de la dynamique des UCs. S'il n'y a pas de différence, ne faire qu'un UC mais s'il y a des différences, faire 2 UCs. Dans ma boite, une banque, les UCs en fonction des canaux sont souvent très différents, il y a aussi des règles de gestion qui peuvent être applicables qu'à certains canaux, aussi il est préférable dans ce cas de différentier les UCs par canal.

Qu'y a t-il derrière le UC Finaliser Commande ? = quel en est son objectif ?

Pour le UC "Rechercher un produit sur le site", perso je n'ai pas de reproche sur le "sur le site". Maintenant, est-ce que l'intention est de rechercher un produit ou de "Consulter le catalogue produits" ? Mais bon, ce point n'est pas super important.

[ypicot]

Par contre je ne comprend pas bien la notion de système ici.
Pour moi le système serait la base de données et les client/employé interagissent avec cette dernière.

Le système est ce que tu dois modéliser. C'est ce sur quoi agissent les acteurs, qui eux sont en dehors du système.

Dans ton cas, le système est une partie de la base de données, les règles métiers et les IHM.
Pourquoi "une partie" des BdD ? Tout simplement parce que je suppose (peut-être à tord) que ta BdD va contenir des infos sur la livraison, peut-être le suivi client, etc... Ces éléments ne faisant pas parti de ta modélisation, ils sont en dehors du système.

Yvan