Discussion :

[lerab51]

Bonjour à toutes et à tous,
J' ai un projet a faire pour un examen
Je dois faire un programme qui permette d aller chercher des infos sur chaque machine connectées et ça sur differents reseaux
Pour la preentation je dois faire le diagramme de cas d utilisation
j en ai fait en cours mais des tres simples et la je coince un peu

voici les grandes lignes pour le programme:
-L utilisateur lance le programme ou alors le programme pourra se lancer automatiquement
-En premier lieu on ping toutes les adresses des diferents reseaux (les ping sont gere par IPangry et nous retourne les resultats)
-Suivant les resultats nous saurons si c est une machine windows ou non
-pour les windows sera lancer psinfo puis nmap au cas ou il y aurait des non windows dedans
-pour les non windows seront lancées des requetes snmp puis nmapsi les requetes echoues ou pour plus de details
-on recuperera les resultats dans des fichiers csv et dans une base de donnees Mysql


voila en tres succint le deroulement du programme

si vous pouviez me donner quelques conseils quelques pistes car la je suis un peu dans le jus

merci
usecase2.doc

[ego]

Tu as déjà presque décrit ton cas d'utilisation !!! Il suffit d'être précis dans les informations que tu veux récupérer c'est tout et préciser quels interactions tu attend avec l'utilisateur (là il faut savoir s'il y a un utilisateur ou non, c'est primordiale pour ton application)

[hed62]

En effet, il faut decider si tu as un utilisateur 'réel' ou non.
Dans tous les cas, tu peux également faire un diagramme de séquence système : place un 'objet' par type de machine et d'utilisateur. Tu peux ensuite spécifier la nature (synchrone ou non, etc...) et le contenu des messages envoyés. Notamment, en UML 2 , tu peux spécifier si cela se passe en parallèle ou en série, etc...

[lerab51]

je pense que je vais mettre un utilisateur car le programme devra etre executable manuellement et automatiquement
sinon j ai 3 possibilités soit je scan que les windows soit que les non windows ou bien les deux
alors je pense que je dois faire 3 diagrammes d utilisation differents
mais je ne suis pas sur
merci de votre aide a bientot

[lerab51]

bonjour
En fin de compte j ai tout regroupé dans le meme diagramme
je vous laisse mon diagrame en piece jointe si vous avez des commentaires n hesitez pas
je laisse le superviseur car le programme peut etre lancé manuellement
merci et bon dimanche

[hed62]

Ton approche est BEAUCOUP , BEAUCOUP trop fonctionnelle !

Il faut raisoner en scénarri, cas d'utilisation en non en termes de fontion C, fonction système, ou autres

Le but d'une analyse est de décrire le besoin sans dépendre de l'implémentation : adieu les MySql, Ping, snmp et autres ! L'analyse doit être fortement découplée de l'implémentation.

D'autre part, tu devrais parler de "Consulter les résultats d'analyse", "Lancer l'analyse" par exemple, plutot que "traiter les resultats des requetes snmp" etc...

L'acteur Ressource ne doit pas exister : elles seront jointes par le superviseur via ton application. Au mieux, tu peux placer un acteur secondaire (en forme de "carré" ).

Si réellement les IPangry, PSInfo et autres sont des systèmes complexes et qu'une communication inter système est importante à représenter, alors place des acteurs secondaire, mais cela est "bancal" selon moi.

si tu as des questions...

[lerab51]

Bonjour
Voila mon prof vient de me dire que le use case tenait sur deux trois bulles du coup je n ai plus que ça
est ce que c est mieux?
merci

[hed62]

Oui c'est mieux, dans el sens où c'est une approche haut niveau et du point de vue user.

Par contre, pourquoi différencier les deux UC ? pour moi les deux doivent être semblables.

[ego]

Perso, j'aurai fait un seul UC "Superviser les machines du réseaux" et j'y expliquerai ce que l'on veut récuperer comme infos.
Il y aurait un second UC si les infos étaient stockées en base et que l'on pouvait simplement aller consulter l'historique des informations.

[hed62]

Un seul UC me parait léger... Ca limite l'interêt du diagramme : en coupant ainsi en deux, il peux séparer la description de l'analyse de la consultation des résultats.

Sinon en effet, pourquoi ne pas avoir un dernier UC : Consultation historiques, ou similaire?

[ego]

Mais il ne s'agit pas de faire un dessin "joli" ou dire qu'il n'est "joli" ou utile que s'il y a au moins 2 UCs.
Il s'agit de savoir quelle est l'intention de l'acteur. Si techniquement on ne fait que lancer un programme et regarder ce qu'il nous dit, j'ai le sentiment qu'il n'y a qu'une intention. Cette intention peut être "complexe" et donc nécessiter pas mal de description mais ce n'est pas pour cela qu'il faut découper en "sous-UC"

[hed62]

Mais il ne s'agit pas de faire un dessin "joli" ou dire qu'il n'est "joli"

Là je suis d'accord, et je n'ai d'ailleurs jamais dit ça

utile que s'il y a au moins 2 UCs

Bon, nous divergeons ici, mais ce n'est pas très grave.

Personnellement, je préfère dénaturer **légèrement** le diagramme UC et dire que l'utilisateur peut lancer l'analyse sans regarder le résultat (pour X raisons: stockage auto en base, consultation via autre outil, que sais-je encore), ou d'autre part lancer l'analyser pour en voir le résultat ensuite.

Mais cela reste personnel et si on veut être le plus exact possible, ego a raison, il faut spécifier les UC en fonction des objectifs de l'utilisateur.

[ego]

Mais ce que tu dis est censé si c'est bien ce qu'attend l'utilisateur.
Si l'utilisateur n'attend que les résultats, dire qu'il lance l'appli, via le UC lancer, c'est de la décomposition fonctionnelle. Perso, je ne dis jamais que lancer l'application est un UC car cela est hors scope de l'application, justement (sauf cas particulier d'une application qui servirai à en lancer d'autres).