Discussion :

[lesultan2007]

salut, comme je vous l'ai signifié dans le message précedent, je suis commis à la modélisation d'une application web de gestion de fournitures informatiques (pour le compte d'une entreprise) en UML.Et je vous soumet mon diagrammes des cas d'utilisation.J'ai découpé mon système en 4:gestion des demandes, gestion des commandes, gestion du magasin, administration

[bruno_pages]

bonjour,

l'extend entre passer commande et consulter stock est à l'envers (rappel : quand UCA - - -extend - - -> UCB alors UCA peut être fait lorsque UCB l'est). Donc c'est une sorte d'include non obligatoire et dessiné a l'envers. tu ne seras ni le premier ni le dernier à faire l'erreur, d'ailleurs moi-même ...

les deux includes de gestion utilisateur vers creation compte et gestion droit d'acces ne sont pas correct (rappel : quand UCA - - -include- - -> UCB alors UCB est forcement fait quand UCA l'est).

je suppose qu'il faudrait egalement pouvoir détruire un compte

Sinon on ne voit aucun lien entre ces UCs, ce qui est à la fois bien et 'mal' : je doute que ces personnes travaillent de facon totalement separees , c'est à dire qu'on peut alors retirer n'importe quel de tes diagrammes sans impact sur les autres. Tout cela pour dire qu'il pourait y avoir des acteurs secondaires

Bruno

P.S. : j'ai la berlue, ou tu as dessiner les diagrammes à la main ?

[bambi98]

Bonjour à tous

je ne sais pas si Bruno a négligé ces remarques mais je trouve que:
1.l'objectif des UC(représenter les besoins utilissateur) est un peu mis à coté en faisant 4 diagrammes. Moi je ferais un Diagramme comportant les 4 UC.Les UC sont trop détaillés.
2.que passer commande, ajoute fournisseur, ajouter matériel, sortie matériel et and so on ne sont pas des UC.Sauf si je me trompe un UC c'est un processus.

j'ai la berlue, ou tu as dessiner les diagrammes à la main ?

IL ya des outils gratuits sur le site et BOUML en est un qui te sera d'un très grand apport

[bruno_pages]

1.l'objectif des UC(représenter les besoins utilissateur) est un peu mis à coté en faisant 4 diagrammes. Moi je ferais un Diagramme comportant les 4 UC.Les UC sont trop détaillés.
2.que passer commande, ajoute fournisseur, ajouter matériel, sortie matériel et and so on ne sont pas des UC.Sauf si je me trompe un UC c'est un processus.

là je ne suis pas d'accord avec toi bambi98, ce qu'il a représenté sont bien des UC et ces acteurs sont bien des utilisateurs (en tout cas c'est comme cela que je l'ai compris)
de plus mettre les 4 en un ferait un UC trop compliqué, et ce n'est donc pas souhaitable
désolé de te contredire

IL ya des outils gratuits sur le site et BOUML en est un qui te sera d'un très grand apport

là par contre on est d'accord

[Nip]

Premiere remarque: garde la meme norme pour la creation des UC, un verbe a l'infinitif.
Effectivement les includes et extends sont mals definis.

Sinon de mon cote j'ai un avis partage sur la question:
-certains de tes UCs sont clairement trop detailles: Gerer utilisateur est un UC englobant la creation de compte, suppression,
Tu peux creer un autre UC gerer les droits d'acces si c'est une composante essentielle de ton logiciel. Par ailleurs l'UC "traitement" ca ne veut rien dire.
-UC "s'identifier" est inutile a representer, ca semble etre une precondition a l'execution de tous tes UCs; pas besoin de surcharger, tu passes ca en description textuelle.
-Consulter stock est un UC a part entiere pour la magasinier et le secretaire mais un extend pour le responsable?
-"Ajouter demande" - "editer demande": un seul et meme UC: "gerer demande" (incluant les CRUD)

[ego]

Pour reprendre ce qu'a dit Nip, je dirai qu'il faut se dire que les UC ne sont avant tout pas un dessin UML mais plutôt une description textuelle : la fiche de cas d'utilisation.
Il est préférable d'avoir autant de UC graphiques que de fiches de UC; c'est un moyen de voir si on ne découpe pas trop les choses.
Donc dans ta première version, as-tu prévu de rédiger un document pour chaque ovale que tu as dessiné ?

[lesultan2007]

merci à tous pour vos remarques. J'en tiendrai compte.Effectivement, j'ai prévu une description textuelle pour chaque use case. Je vous enverrai aussi mon diagramme des classes pour avoir vos avis.merci...

[siplusplus]

Bonjour,
Tu peux simplifier les schéma de chaque acteur en supprimant l'identification.
Car chaque acteur spécifié sera un bien un acteur identifié.
En gros, le premier UC ne devrait contenir que ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Transformation d'un acteur.

Utilisateur -> s'identifier -> (Magasinier, Resp. achat, Administrateur, ...)

Les diagrammes UC sont habituellement accompagnés du texte descriptif (ou
l'inverse pour ceux qui préfèrent )
de façon à indiquer avec un maximum de détail le cas concerné.
Le fait de faire des petits diagrammes est très bien car cela évite de surcharger l'ensemble et permet de faire certains diagrammes/textes plus
précis pour les besoins de l'analyse.
Rien n'empêche par après de faire un diagramme général mais ne représentant
que les paquetages.

[sisi20]

Bonjour,

J'ai besoin de ton diagramme de classe pour m'inspirer car j'ai un TP à rendre sur un système de gestion de commande pour une entreprise qui commercialise du matériel informatique

PS: Je dois rendre le TP dimanche prochain