Discussion :

[PiNkjeLLy]

Salut à tous les grands maîtres de l'UML !!

En bonne noob de la modélisation que je suis, quelques questions me font venir à vous, puisque je n'arrive pas à trouver la réponse seule

Mais plutôt qu'un long discours, j'ai un schéma avec quelques commentaires, si vous pouviez m'éclairer ça serait super !

Merci pour les réponses


https://www.dropbox.com/s/pnsoli7l82..._uc%282%29.png

[PiNkjeLLy]

vu que mon sujet déchaîne les passions ( ) je me permet de rajouter un nouvel élément qui décrit plus clairement ce que doit faire mon système

mon plus gros problème étant que beaucoup de cas d'utilisations pourraient être traduits par un héritage entre les acteurs, mais pas toujours !

et à force de lire et de relire les tuto, cours et forums je crois que j'ai le cerveau à l'envers ...

si une âme charitable passe par là et peut m'éclaircir ... je suis preneuse !

Merci d'avance

[PiNkjeLLy]

Après une bonne nuit de sommeil, j'arrive enfin à produire un diagramme de Use Case (ouf !) mais qui ne me satisfait toujours pas !!

J'ai certains éléments qui se répètent, comme "commenter Publication", en fonction de l'acteur qui commente, il n'a pas accès aux mêmes publications. Du coup, pour me simplifier, j'ai créé 1 Use Case par action ...

Mais ça me semble pas propre ...

Un grand ninja pourrait m'aider ?
Merci

[bruno_pages]

je réponds même si je ne suis ni un nija ni grand, je n'ai regardé que votre dernier diagramme qui globalement tient la route, quelques remarques cependant :

boutique est un mauvais nom d'acteur car il ne désigne pas la boutique

le fait qu'un visiteur est accès à l'inscription en tant que gestionnaire me parait bizarre

je doute fort qu'un fournisseur hérite de boutique (quelque soi le nom de remplacement). Acteur1 <|--Acteur2 veut dire qu'Acteur2 peut tenir intégralement le rôle d'Acteur1

je ne comprends pas vraiment l'intéret de l'acteur gestionnaire et son UC associé

l'extension entre creer-publication et ajouter-visuel est semble-t-il dans le mauvais sens

[PiNkjeLLy]

merci pour la réponse !

alors tout d'abord j'explique mes intentions :

boutique est un mauvais nom d'acteur car il ne désigne pas la boutique

=> la Boutique désigne en fait 1 point de vente, qui est géré par un Gestionnaire. Un Gestionnaire peut gérer plusieurs Boutiques, alors qu'une Boutique ne peut avoir qu'un seul Gestionnaire.
J'ai différencié ces 2 entités pour bien faire la différence entre la personne physique (à contacter en cas de besoin) et le bénéficiaire du service.

le fait qu'un visiteur est accès à l'inscription en tant que gestionnaire me parait bizarre

=> Je laisse cette possibilité puisque ce système sera opé via le web. De cette façon, un internaute qui souhaite inscrire sa Boutique peut simplement entrer en contact avec le Fournisseur
J'aurai aussi du préciser que le mot Fournisseur est surement mal utilisé, mais en fait il me désigne moi et mes petits comparses, qui fournissent l'accès au services

je doute fort qu'un fournisseur hérite de boutique (quelque soi le nom de remplacement). Acteur1 <|--Acteur2 veut dire qu'Acteur2 peut tenir intégralement le rôle d'Acteur1

=> Je voulais simplement exprimer que le Fournisseur (moi) hérite de tout ! Je devrais surement remplacer Fournisseur par Admin ...

je ne comprends pas vraiment l’intérêt de l'acteur gestionnaire et son UC associé

=> Dans la logique métier, un Gestionnaire peut s'inscrire dans le système. La création d'un compte Gestionnaire implique que le Fournisseur (ou plutôt l'Admin, donc encore notre joyeuse compagnie) recontacte cette personne afin d'envisager la possibilité d'y inscrire une Boutique

l'extension entre creer-publication et ajouter-visuel est semble-t-il dans le mauvais sens

=> il est vrai, je l'ai modifié

dsl le post est un peu long mais j'espère avoir réussi à faire comprendre mes intentions ...

[bruno_pages]

visiblement il faut revenir à l'étape n° 1, quel 'système' définissez-vous ?
je pensais que le 'système' était la boutique, mais ce n'est visiblement pas le cas

pour information notez que par définition les acteurs doivent être externes au système décrit.

[PiNkjeLLy]

visiblement il faut revenir à l'étape n° 1, quel 'système' définissez-vous ?
je pensais que le 'système' était la boutique, mais ce n'est visiblement pas le cas

=> dans mon cas, je crois pouvoir dire que suis le Système, ce que j'ai auparavant exprimé comme Fournisseur ou Admin.
je donne (ou pas) accès aux services pour des utilisateurs qui aurons comme rôle
- soit un simple client qui veut visualiser ses boutiques préférées,
- soit un gestionnaire qui veut inscrire sa ou ses boutique(s)
- soit une boutique qui veut communiquer avec ses clients par le biais de publications ou de messages "privés"

mon rôle sera également de régulièrement communiquer avec les boutiques et les gestionnaires en créant également des publications pour les aider à garder un certain dynamisme dans leurs propres publications, les informer de nouveautés sur le site ... un genre de newsletter

pour information notez que par définition les acteurs doivent être externes au système décrit.

=> il semble donc que tous ces acteurs soient bien externes. c'est moi (fournisseur ou admin peu importe comment je le nomme) qui ne doit pas apparaître dans ce diagramme, n'est-ce pas ?

[bruno_pages]

je doute fort que vous soyez le système à décrire via les UCs

qu'êtes-vous en train de faire, un exercice ? pouvez-vous donner l’énoncé ou une partie de celui-ci ?

[PiNkjeLLy]

en fait, je suis actuellement en stage dans une entreprise qui souhaite proposer un nouveau produit, un outil de communication à destination des petits commerces et qui leur permettrait de régulièrement donner des news à leurs clients
les visiteurs du site (non inscrits et non identifiés) peuvent seulement avoir un apperçu des infos proposées par les boutiques

un gérant a au moins une boutique, et peut donc en avoir plusieurs

une boutique peut ajouter du contenu (genre des promos, montrer des nouvelles collections ...) et le publier

boutique et client peuvent donc commente le contenu publié

un client peut contacter en privé une boutique, mais une boutique ne peut d'elle même contacter un client, elle peut seulement lui répondre

un client peut s'affilier à une boutique pour recevoir automatiquement une notification en cas de nouvelle publication

et moi dans tout ça, je dois dégrossir le schéma de modélisation

[bruno_pages]

C'est donc ce nouveau produit - l'outil de communication - que vos UCs doivent décrire.

une boutique peut ajouter ...

non, ce n'est pas la boutique qui ajoute ou autre, utilisez des noms qui aient un sens sinon c'est incompréhensible

un client peut contacter en privé une boutique, mais une boutique ne peut d'elle même contacter un client, elle peut seulement lui répondre

contacter une boutique ne veut rien dire, je suppose que cela veut dire que le client via l'outil peut saisir un 'mail' (ou autre moyen similaire pour entrer un message), et une personne de la boutique (rôle à définir) y répondra toujours via l'outil

je vous conseille de réécrire correctement vos énoncés, le passage en Ucs et le choix des acteurs sera ensuite beaucoup plus facile

[PiNkjeLLy]

j'avoue que votre dernier post résonne fort dans ma tête ...

puis-je tout de même demander un éclaircissement ?

1. les acteurs d'un système sont des entités externes qui interagissent avec lui ? càd qui envoient des évènements et/ou reçoivent des informations ?

2. les cas d'utilisation décrivent ce que les acteurs attendent du système ? càd dans quel but ou avec quel objectif l'acteur utilise le système ?

dans ce cas, je ne comprend as ce que vous voulez dire par
"non, ce n'est pas la boutique qui ajoute ou autre, utilisez des noms qui aient un sens sinon c'est incompréhensible"
puisque c'est bien cet acteur qui ajoute un contenu qui lui est propre, et que ce contenu est ensuite diffusé, l'intention d'acteur par bien de la boutique ?

de même que
contacter une boutique ne veut rien dire
l'acteur qui démarre cette intention est ici un client, et la finalité est de contacter la boutique ? (le moyen n'est pas encore déterminé mais tout de même le résultat sera le même)

[bruno_pages]

1. les acteurs d'un système sont des entités externes qui interagissent avec lui ? càd qui envoient des évènements et/ou reçoivent des informations ?

qui interagissent oui, même si on peut ne pas savoir comment à ce niveau

2. les cas d'utilisation décrivent ce que les acteurs attendent du système ? càd dans quel but ou avec quel objectif l'acteur utilise le système ?

les UCs décrivent ce que fait le système, l'objectif des acteurs c'est déjà autre chose et le système ne peut ni ne doit le savoir. Prenons le cas d'une machine à café, les UCs prennent en compte le paiement - sélection du café - distribution (avec tous les cas d'erreurs / annulation / retour monnaie ...) mais rien concernant le but de l'acteur-client, on ne sait pas s'il va finalement le boire ou autre, et on s'en moque au niveau des UCs et de la conception.

je ne comprend as ce que vous voulez dire par
"non, ce n'est pas la boutique qui ajoute ou autre, utilisez des noms qui aient un sens sinon c'est incompréhensible"
puisque c'est bien cet acteur qui ajoute un contenu qui lui est propre, et que ce contenu est ensuite diffusé, l'intention d'acteur par bien de la boutique ?

la boutique n'est pas un acteur

qu'est-ce qu'une boutique pour vous ?

pour moi une boutique c'est un magasin réel/virtuel, et donc une boutique est un concept non agissant.

contacter une boutique ne veut rien dire
l'acteur qui démarre cette intention est ici un client, et la finalité est de contacter la boutique ? (le moyen n'est pas encore déterminé mais tout de même le résultat sera le même)

on ne contacte pas une boutique en tant que tel, pas plus que je contacte une boite aux lettres lorsque j'y glisse un courrier-papier, ce que décrit l'UC c'est le fait qu'un client puisse ajouter un message via le système

[tonton16]

Bonsoir,

Personnellement je suis tout à fait d'accord avec Bruno Pagès.

Le rôle boutique ne peut pas être considéré comme un rôle vis-à-vis du système.

Il faut considérer dans votre cas le rôle que peuvent jouer les utilisateurs employés de la boutique sur le système à développer. Exemple :
Employé si tout le monde est concerné par le système au même niveau;
Commercial pour toute la partie publication ;
Directeur (ou patron) pour la partie statistiques.
On pourrait trouver un rôle de Modérateur...

[PiNkjeLLy]

Merci pour vos réponses.

Je vais re-potasser mon modèle, j'y vois de nouveaux éléments que vous m'avez apportés, et dès que possible je vous re-montre mon schéma.

Merci encore

[PiNkjeLLy]

Bonjour !!

Alors avant de me re-lancer dans un diagramme, j'ai revu selon vos conseils mes cas d'utilisations. Et voila ce que ça donne.

Un avis sur ma jolie liste ?

Merci

[tonton16]

Bonjour,

Les noms des cas d'utilisation doivent être orientés intention de l'acteur qui le déclenche. Donc "inscrire client" n'est pas un bon nom. Cela revient à dire que c'est le le système qui inscrit les clients et non les clients qui s'inscrivent.

Idem pour la gestion des profils.

L'encart rouge à droite parle d'include de l'authentification.
Non, il ne faut pas mettre d'include pour l'authentification. C'est une pré-condition aux différents cas d'utilisation. D'ailleurs, quelle est la différence entre s'authentifier et se connecter ?

[PiNkjeLLy]

Merci pour la réponse

Quand vous dites :

"inscrire client" n'est pas un bon nom

Que voulez-vous dire par là ? J'ai noté de cette façon afin de nuancer et d'indiquer qu'il est seulement possible de s'inscrire en tant que Client, et non Gestionnaire ou Employé.
C'est également pour cette raison que j'ai nuancé les 2 UC "gérer profil ..."
Donc je ne peux pas afficher ces différenciations dans la liste des UC ?

L'encart rouge à droite parle d'include de l'authentification.
Non, il ne faut pas mettre d'include pour l'authentification. C'est une pré-condition aux différents cas d'utilisation.

OK je le déplace dans la bonne section.

D'ailleurs, quelle est la différence entre s'authentifier et se connecter ?

C'est une erreur de ma part, les deux sont identique, je n'ai pas repris le même terme, mais je le modifie de suite

[tonton16]

Quand vous dites :
Que voulez-vous dire par là ? J'ai noté de cette façon afin de nuancer et d'indiquer qu'il est seulement possible de s'inscrire en tant que Client, et non Gestionnaire ou Employé.
C'est également pour cette raison que j'ai nuancé les 2 UC "gérer profil ..."
Donc je ne peux pas afficher ces différenciations dans la liste des UC ?

Si le client est le seul acteur qui peut déclencher le cas d'utilisation "s'inscrire", il est inutile de préciser que c'est le client, car dans la description, client sera mis en acteur principal et ce sera clair.

De plus, dans la formulation, Client-----(Inscrire client), on a l'impression qu'un client peut inscrire un autre client. Alors que si on met Client-----(S'inscrire), on voit ici que le système offre au client la possibilité de s'inscrire.
D'ailleurs, ce ne serait pas le visiteur qui devrait s'inscrire ?

Pour la partie "Gérer profil", effectivement c'est un autre cas. On peut garder la différentiation par l'acteur.

[PiNkjeLLy]

Re-bonjour !

Alors voici ma production de la journée.
Ceci dit, je me pose encore une question quant à la conformité de mes UC.

Je trouve que bcp d'entre eux se répètent (comme créer une Publication Boutique ou créer une Publication Admin Site).

Si je réfléchis comme ce que j'ai compris de mes cours, on doit créer un UC pour chaque intention d'acteur, ce qui est le cas ici puisque l'émetteur de la Publication est soit une Boutique (Gestionnaire ou Employé) soit l'Admin Site, chacun ayant des destinataires différents (Boutique publie pour Client alors que Admin Site publie pour Boutique).

Mais tout de même l'action de créer une Publication est toujours la même, la constante étant que chaque Émetteur a sa propre liste de Destinataires.

(je suis pas tout a fait sûre d'être claire là ...)

Sinon pour ceux qui ont compris, je fais 1 ou 2 UC ?

[PiNkjeLLy]

une petite réponse à mon dernier message ?