question sur des cas regroupés en un

salut à tous.
s'il vous plait, j'ai des préoccupations sur les cas d'utilisations tel que gérer élèves, gérer les utilisateurs même après avoir lu et parcouru longtemps des discussions.
est ce qu'on peut faire une première vue globale du diagramme de cas de d'utilisation regroupant les cas: gérer élèves, gérer enseignant,gérer utilisateurs....
et revenir zoomer sur chaque cas pour le décomposer tel que pour gérer élèves on aura: ajouter un élève,modifier élève, supprimer élève, consulter les élèves...
voivi le diagramme global
Pièce jointe 519158
ensuite gerer les eleves devient apres zoom:
Pièce jointe 519160
maintenant est ce juste de travailler ainsi? comme mon diagramme est énorme.comment puis je faire les scenarios? doit on faire plutôt pour chaque sous cas: ajouter un élève, modifier un élève, supprimer élèves ...
Pour le diagramme de séquence système,faire pour tous les sous cas ou bien?
même question pour le diagramme d'activité.
même après avoir parcouru beaucoup de discussion et critique, certains disent qu'il faut détailler, d'autres non,d'autres utilisent "gérer élèves" avec un scenario nominal "ajouter élève" et des alternatifs "modifier élève, supprimer eleve,je suis vraiment confus. veuillez s'il vous plait me préciser pour que je puisse continuer mon projet.
s'il vous plait aider moi à comprendre cela? s'il vous plait...

Bonjour,

administration est un curieux nom de rôle, sans doute voulez vous dire administrateur ?

Un UC gérer XXX est un UC très global, gérer c'est vague et cela peut vouloir dire beaucoup de choses, si vous voulez l’utiliser vous devez par ailleurs le détailler pour dire que dans le cas présent gérer signifie finalement ajouter/modifier/retirer/consulter, donc à moins que vous n'ayez globalement beaucoup d'UC il est préférable d'avoir des UC plus précis correspondant à votre second diagramme.

Peut être avez aussi besoin d'un UC rechercher un élève car pour supprimer/modifier un élève il faut d'abord l'avoir trouver, à moins que les UC de modification/suppression inclue la recherche, mais dans ce cas cela veut dire que vous ne pouvez pas modifier/supprimer un élève lors de la la consultation, et que vous devez le chercher alors qu'il est affiché ce qui ne sera pas pratique pour votre administrateur, on peut aussi considérer que la suppression est un cas particulier de modification et donc pourquoi pas cela :

Pièce jointe 519213

Pour les diagramme de séquence/activité tout dépend de ce que vous voulez montrer, mais il est bien évident que si au niveau implémentation vous avez juste une opération "gérer" autant ne rien faire

merci M. bruno_pages pour votre reponse rapide, j'admire.

Concernant le nom de rôle, j’hésitais entre agent administratif et administrateur! je veux dire que c'est un rôle pour le département de l'administration d'un établissement scolaire.

merci pour votre suggestion, j'admire et c'est une solution, mais le probleme mon système est énorme, je me retrouve avec 19 cas d'utilisation de haut niveau donc global(tous des gérer XXXX),sans le cas interne d'authentification.
comme mon système est énorme, est ce que je peux faire ainsi comme vous avez dit:
Pièce jointe 519306
et puis faire ainsi le scenario de gerer eleves:
Pièce jointe 519303
ou bien forcement je détaille chaque cas gérer XXXX comme vous l'avez fait dans le diagramme.

re bonjour

Citation:

---

Envoyé par Ben's49

mais le probleme mon système est énorme, je me retrouve avec 19 cas d'utilisation de haut niveau donc global(tous des gérer XXXX),sans le cas interne d'authentification.

---

19 cas d'utilisations ce n'est pas énorme du tout

Avez -vous besoin de différentier elève et enseignants au niveau UC ?

Citation:

---

Envoyé par Ben's49

Pièce jointe 519306

---

Attention l'<<include>> indique authentification est faite à chaque fois que vous faites gerer xx ce qui est faux car l’authentification est un pré requis, d’ailleurs cela se voit dans votre tableau plus bas car il est indiqué "pré requis" (ok) et "sub use case" (ko)

Ne cherchez pas à indiquer une relation entre l'UC d'identification et les autres UC dans le(s) diagramme(s)
A noter qu'un <<extend>> à partir de chaque autre UC dessine un plat de spaghetti et pose problème car l'authentification doit être faite avant ce qu'un extend ne permet pas de préciser

A noter que l'acteur s’authentifiant a le rôle le plus 'faible', pas besoin d'être un administrateur ou autre

Citation:

---

Envoyé par Ben's49

et puis faire ainsi le scenario de gerer eleves:
Pièce jointe 519303
ou bien forcement je détaille chaque cas gérer XXXX comme vous l'avez fait dans le diagramme.

---

Outre le sub use case à retirer la postcondition n'est pas correcte car elle ne s'applique pas aux cas de suppression/modification

Citation:

---

Envoyé par bruno_pages

re bonjour

---

merci vos reponses m'aident à mieux assimuler la chose la:D:D

Citation:

---

19 cas d'utilisations ce n'est pas énorme du tout

---

ok c'est compris

Citation:

---

Avez -vous besoin de différentier elève et enseignants au niveau UC ?

---

bon je considère comme deux cas d'utilisations differents. ou bien? suggestion s'il vous plait.

Citation:

---

Attention l'<<include>> indique authentification est faite à chaque fois que vous faites gerer xx ce qui est faux car l’authentification est un pré requis, d’ailleurs cela se voit dans votre tableau plus bas car il est indiqué "pré requis" (ok) et "sub use case" (ko)

---

ok donc je dois retirer le cas d'authentification et le laisser dans le pré-requis comme dans le tableau? mais il sera un cas d'utilisation a part ou NON?

Citation:

---

Ne cherchez pas à indiquer une relation entre l'UC d'identification et les autres UC dans le(s) diagramme(s)
A noter qu'un <<extend>> à partir de chaque autre UC dessine un plat de spaghetti et pose problème car l'authentification doit être faite avant ce qu'un extend ne permet pas de préciser

---

ok c'est noter

Citation:

---

A noter que l'acteur s’authentifiant a le rôle le plus 'faible', pas besoin d'être un administrateur ou autre
Outre le sub use case à retirer la postcondition n'est pas correcte car elle ne s'applique pas aux cas de suppression/modification

---

ok donc sub usecase à retirer, mais la post condition je mets quoi?ou j'enleve la post condition?

s'il vous plait voici mon diagramme de cas d'utilisation globale de haut niveau!
a noter je viens d'enlever l'include avec le cas d'authentification.
bref j'ai besoin de votre avis sur ce premier diagramme global.
le voila en version pdf.
merci M. pages

Citation:

---

Envoyé par Ben's49

bon je considère comme deux cas d'utilisations differents. ou bien?

---

Si la description des UCs est la même pour les deux et donc qu'enseignant et élève sont interchangeables au niveau UC alors inutile de les différentier

Citation:

---

Envoyé par Ben's49

ok donc je dois retirer le cas d'authentification et le laisser dans le pré-requis comme dans le tableau?

---

Oui

Citation:

---

Envoyé par Ben's49

... mais il sera un cas d'utilisation a part ou NON?

---

Oui

Citation:

---

Envoyé par Ben's49

la post condition je mets quoi?ou j'enleve la post condition?

---

Si l'UC est "gérer" et que vous voulez garder une post condition alors il va falloir la détailler pour par exemple les sous-cas de gestion ajouter/supprimer ... mais rien que cela montre que "gérer" n'est pas assez précis

Citation:

---

Envoyé par Ben's49

s'il vous plait voici mon diagramme de cas d'utilisation globale de haut niveau!
a noter je viens d'enlever l'include avec le cas d'authentification.
bref j'ai besoin de votre avis sur ce premier diagramme global.
le voila en version pdf.

---

On voit distinctement que même si vous restez avec des "gerer" le diagramme doit être découpé au minimum en 3 diagrammes distincts
Si vous détaillez plus les UCs utilisez plus de diagrammes
Chaque diagramme doit avoir un but ou pour reprendre la terminologie UML un "sujet", ce dernier étant représenté par un rectangle contenant des UCs

gracias M. pages, cela m'aide énormément, vous n'avez pas idée de la confusion que cela me faisait.
en bref si je me trompe pas, je découpe mon gros diagramme en 3.
si je veux faire comme dans votre diagramme.
a partir des 3 diagrammes découpés, j'entre dans chaque découpage à un niveau plus bat pour faire comme dans votre diagramme détaillé.
une fois cela fais, je reviens faire mes scenarios pour les cas d'utilisations de bats niveau?
mais juste une précision, si je veux continuer dans ce sens, dans mes scenarios, je fais pour chacun: ajouter un élève, modifier un élève,supprimer un élève, consulter les élèves???d’où chacun un diagramme séquence système différent, et un diagramme d'activité???
mais si je garde les gérer XXX? pour faire directement la description textuelle du cas global comme dans le tableau ci-dessus. malgré j'ai fais, les "gérer XXX" me dérangent car pour un cas d'utilisations dans sa définition, sa doit apporté un plus à l'utilisateur, avec un début et une fin et une post condition bien claire.


si je vois bien. il faut respecter les normes, trouver son angle d'approche, choisir le niveau de détail qui nous convient selon la taille du projet, et frapper une modélisation, elle ne peut être totalement fausse du moment on respecte les normes. y'a pas une solution fixe. vraiment l'UML:roll::roll::roll:....

Citation:

---

Envoyé par Ben's49

en bref si je me trompe pas, je découpe mon gros diagramme en 3.
si je veux faire comme dans votre diagramme.
a partir des 3 diagrammes découpés, j'entre dans chaque découpage à un niveau plus bat pour faire comme dans votre diagramme détaillé.
une fois cela fais, je reviens faire mes scenarios pour les cas d'utilisations de bats niveau?
mais juste une précision, si je veux continuer dans ce sens, dans mes scenarios, je fais pour chacun: ajouter un élève, modifier un élève,supprimer un élève, consulter les élèves???d’où chacun un diagramme séquence système différent, et un diagramme d'activité???

---

Encore une fois vos diagrammes doivent avoir un but/sujet, et ils doivent être lisibles c'est à dire pas trop complexes, s'il y a trop de choses découper encore

Citation:

---

Envoyé par Ben's49

Mais si je garde les gérer XXX? pour faire directement la description textuelle du cas global comme dans le tableau ci-dessus. malgré j'ai fais, les "gérer XXX" me dérangent car pour un cas d'utilisations dans sa définition, sa doit apporté un plus à l'utilisateur, avec un début et une fin et une post condition bien claire.

---

Ce qui est vrai pour un diagramme est aussi vrai pour un UC, un UC a un but et ne doit pas être trop complexe, s'il est trop complexe découpez le en plusieurs UCs

Inversement il ne doit pas y avoir 1000 UC/acteurs/diagrammes pour rien, le 'bon' niveau n'est pas toujours aisé à trouver

Une bonne façon de faire est de vous mettre à la place de quelqu'un qui regarderai votre modélisation, et de vous demander ce qu'il en penserait et s'il peut la comprendre facilement

Citation:

---

Envoyé par Ben's49

si je vois bien. il faut respecter les normes

---

Tant qu'à faire oui :lol:

Citation:

---

Envoyé par Ben's49

frapper une modélisation, elle ne peut être totalement fausse du moment on respecte les normes

---

Il ne suffit pas de respecter les normes pour que la modélisation doit correcte, respecter la norme concerne la forme mais le fond peut être faux malgré cela.
UML est un langage, "je suis un chat" respecte les règles de la langue française et c'est portant totalement faux ;)

Citation:

---

Envoyé par Ben's49

... y'a pas une solution fixe. vraiment l'UML:roll::roll::roll:....

---

Bien-sûr que non, et il n'y en a pas plus au niveau programmation

:D Merci beaucoup vraiment. je bosse déçu et une fois fini avec, je reviendrais vers vous d'ici la. donc surement je vais vous solliciter encore.
au moins j'ai pu me fixer et cela m'aide à prendre mes décisions pour la suite.:D
merci encore une fois pour vos précieuse réponses et conseils.... sa m'aide beaucoup.