Discussion :

[ifsera]

Salut

Je bosse actuellement sur un projet déjà "concrétisé".
J'ai besoin de réaliser le diagramme des cas d'utilisation et d'autres.

Je suis une bille en UML. Enfin, j'en ai jamais fait de façon assidue.
Aussi j'ai fait un petit truc.
Si quelqu'un pouvait y jeter un oeil, et me dire ce qui est bon, et ce qui cloche.

En gros, c'est une appli qui gère des données provenant d'un périphérique usb, d'ou le dock.

J'ai des doutes sur les extend. J'ai la sensation que je devrais en mettre un paquet. Pour ce qui est de la connexion, je sais pas s'il compte pour un ou pour 2 avec déconnexion.

Enfin je suis preneur de tous les retours.




Merci.
J'ai mis le fichier en pièce jointe.http://www.hostingpics.net/viewer.php?id=337438331.png


Bon j'ai mis un lien, la balise image ne retourne rien, no sé ...

[Metafire18]

Ma première remarque porte sur les noms des cas. Ils sont assez peu explicites à l'image du cas "dock" ou du cas "écrit".

Pour simplifier ton diagramme, tu peux créer un lien d'héritage entre l'administrateur et l'utilisateur. Les acteurs administrateurs hériteront ainsi des fonctionnalités offertes aux utilisateurs et ton schéma sera allégé.

Je ne sais pas si tu as réellement compris le sens du lien <<extend>>. Ce dernier, placé entre les cas A et B (A->B), signifie que le cas A étend les objectifs (ou le comportement) du cas B. Ainsi, on peut dire qu'un cas "Piloter un avion" étend le cas "Piloter un véhicule" par exemple.

Voilà pour l'instant. J'attends une nouvelle version de ton diagramme pour faire de nouvelles remarques

[ifsera]

Merci du retour.
Avec le lien d'héritage. Exact, ça fait plus propre.

J'ai deux questions.
1- Tous les cas d'utilisation de user et de user admin ont besoin d'être connecté. Ca veut dire des include pour chaque cas. Mais ça rend le diagramme un peu chaotique. Est ce qu'il y aurait moyen de faire autrement (le mettre comme un pré-requis dans la description du cas ou autre)?

2- Le service monitor est une servlet, donc du traitement informatique côté serveur. Du coup est ce que j'ai raison de le matérialiser sous cette forme, ou est ce qu'il y a un autre symbole genre computer. Ce n'est pas réellement le système vu qu'il s'agit d'une servlet.

http://www.hostingpics.net/viewer.php?id=372448792.png

[darkcrift]

bonjour,
Pour répondre à t'as première question tu dois en effet mettre la connexion en pré-requis de chaque UC l'utilisant. Une simple connexion/déconnexion (sans action complexe et spécifique impliquant l'utilisateur) n'est pas considéré comme un UC.
Autre petite remarque, une convention existe qui est de nommé les UC par un verbe à l'infinitif: "corrige les données d'un cahier" devient "corriger les données d'un cahier"

remarque: tous les UCs ne sont pas forcément en relation avec un utilisateur, il existe des UCs en relation interne. Je ne connais pas le fonctionnement de ton application en détail, mais par exemple je ne suis pas sûr que le UC "émet des alertes" (qui devrai se nommer "émettre des alertes") doive être en relation directe avec l'utilisateur "service Monitor"

pour plus d'info tu peux aller voir les cours de DVP sur UML 2.0 ici

Pour la deuxième question je te conseil d'aller voir le chapitre 2.5.1Comment identifier les acteurs ? du cours que je t'ai mis en lien. A toi de voir si tu considère l'acteur "service monitor" comme faisant partie du système ou pas.

cordialement

[benroux]

La première étape pour corriger ton shéma est d'identifier tes acteurs.
Un acteur représente un rôle joué par une entité
externe (utilisateur humain, dispositif matériel ou
autre système) qui interagit directement avec le
système étudié.
A toi de voir si "Service monitor" est un acteur du système que tu veux étudier. Si c'est la cas tu peux le représenter sous forme de rectangle stéréotypé "Actor".