Discussion :

[nicofromChina]

Bonsoir,

J'aurais souhaité avoir votre avis sur mon diagramme de use cases.
Mon application sera un logiciel de gestion de biens immobiliers. Pour ce diagramme, l'acteur est "Admin" et peux faire les différentes actions suivantes:
- Se logger
- Se délogger
- Créer un nouvel utilisateur
- Modifier les informations concernant un utilisateur
- Supprimer un utilisateur
- Ajouter un nouveau bien immobilier
- Modifier les informations d'un bien immobilier
- Supprimer un bien immobilier
- Chercher un bien immobilier
- Afficher les information d'un bien immobilier

Alors en fait je ne suis pas sûr de plusieurs choses:

Est-il mieux de regrouper les actions "Modifier", "Ajouter" et "Supprimer" en une seule action appelée "Gestion" ?
Aux niveau des utilisateurs (ceux que l'on créé et gère, pas les acteurs) il y en aurait de deux types: un simple utilisateur et un autre avec des privilèges en plus. Dois je faire un use case pour chacun ou cela va-t-il tel quel ?
Les use cases "Log In" et "Log Out" sont-ils ok ou serait-il mieux d'en faire des includes étant donnée que toutes les fonctions pour l'admin ne sont disponibles que lorsque l'acteur est identifié en tant qu'admin ?

Concernant la frontière du système (le cadre dans lequel sont tous les use cases), faut-il le nommer ? Si oui, comment ? Est-ce une frontière par acteur ?

Enfin si vous voyez un truc qui peut être amélioré ou qui est faux je suis preneur.

Merci de votre aide et bonne soirée

[nicofromChina]

Aucune critique à faire ?
Je doute fort qu'il soit parfait

[bruno_pages]

bonjour,

puisque tu insistes je pense que ton diagramme est trop simpliste car il correspond simplement a la liste "Se logger" ... "Afficher les information d'un bien immobilier"
il n'y a ni acteur secondaire, ni decomposition ou regroupement (extend, include ...), bref on n'apprend pas grand chose en lisant ton diagramme à part une liste d'actions possibles

[nicofromChina]

Ok donc il faudrait que je fasse un "include" de tous les use cases sur "Log In" (sauf Log Out) non ?

Merci pour ton aide.
Sinon concernant les autres questions que j'avais posées, une idée ?

Est-il mieux de regrouper les actions "Modifier", "Ajouter" et "Supprimer" en une seule action appelée "Gestion" ?
Aux niveau des utilisateurs (ceux que l'on créé et gère, pas les acteurs) il y en aurait de deux types: un simple utilisateur et un autre avec des privilèges en plus. Dois je faire un use case pour chacun ou cela va-t-il tel quel ?

Concernant la frontière du système (le cadre dans lequel sont tous les use cases), faut-il le nommer ? Si oui, comment ? Est-ce une frontière par acteur ?

Bonne journée

[nicofromChina]

Bonsoir,

Bon alors je l'ai "un peu" modifié. Qu'en pensez-vous maintenant ?





Une question cependant:
Cela est-il gênant que le use case "Register" lorsqu'il "extends", il ne le fasse que pour un seul acteur (en l'occurence "User") et pas les autres alors que le use case qu'il "extends" est partagé entre tous les acteurs ?

Merci encore pour votre aide.