Discussion :

[kais1600]

Bonjour,

J'effectue un projet dans lequel il faut implementer un logiciel de supervision réseau (Nagios) sur le reseau de notre entreprise et puis developper une interface PHP entre nagios et une base de donnee d'une plate forme(VisualGSM) qui permet d'envoyer des SMS en cas d'incident dans le reseau

Je viens de faire le diagramme suivant pour mon projet mais je sens qu'il n'est pas juste

SVP aider moi pour ce diagramme et pour les autres diagrammes possibles (etat, activites ...)

Merci

[bruno_pages]

Bonjour,

detecter un problème n'est pas un UC si cela est fait par le système de lui même c.a.d. en dehors d'une demande de l'administrateur, ne pas oublier que les UCs ne décrivent pas l'implémentation

recevoir notification sms me parait bizarre, est-ce que cela ne devrait pas plutôt être quelque chose du genre afficher notification sms ?

[kais1600]

oui vous avez raison la détection du problème se fait automatiquement par Nagios.
pour la notification SMS, je sais pas , l'administrateur reçoit automatiquement des SMS en cas de problèmes !
SVP proposez moi des diagrammes pour que je puisse corriger le mien
je vous donne quelques indications sur mon projet:
Nagios détecte automatiquement les problèmes sur le réseau
Nagios envoie les notifications mails a travers un relais Postfix (logiciel)
Nagios envoie les notifications SMS a travers un logiciel VisualGSM (j'ai effectue un developpement de script PHP qui permet d'inserer les donnees de Nagios dans la base de donnee de visualGSM)
le démarrage de Nagios se fait sans authentification, mais l'accès a l'interface web de Nagios pour la supervision se fait par authentification.
la configuration de Nagios se fait manuellement par l'administrateur

[bruno_pages]

Bonjour,

oui vous avez raison la détection du problème se fait automatiquement par Nagios.

alors ce n'est pas (directement) un cas d'utilisation

SVP proposez moi des diagrammes pour que je puisse corriger le mien

si je fais cela vous n'apprendrez rien

Nagios envoie les notifications mails a travers un relais Postfix (logiciel)

celui-ci est donc un acteur secondaire ... et ce n'est pas le seul, à vous de chercher

[kais1600]

SVP Monsieur l'admin aide moi demain il faut que je retourne mon rapport et toute la partie de conception est manquante

Voila ma 2eme proposition

[pascalfares]

Bonsoir,

Je vais te donner quelques indications en espérant que ceci t'aidera à trouver ta solution (Qu'il faut que tu trouves seul!)

But du diagramme de UC
Définir les fonctionnalités du système du point de vue des utilisateurs
Délimiter le système
- ce qui est extérieur et qui communique avec le système
- ce qui est interne au système

Un acteur = Entité externe au système qui interagit avec lui.


Les UCs sont des actions

Les acteurs interagissent avec les UCs

Pour chaque UC il faut pouvoir définir les points suivants:
• Nom
• Description
• Pré-conditions
• Enchaînement normal
• Enchaînement(s) alternatif(s)
• Exceptions
• Diagramme d’activités
• Questions ouvertes

[kais1600]

d'apres ce que je comprends mes 2 diagrammes précédents sont faux ?

[s.toubal]

Bon, je rencontre aussi quelque difficultés à propos de certains diagrammes, mais je pense que je peut d'aidé un peut avec quelque indications

• je pense que tu n'a pas compris encore l'intérêt des UC
• je pense aussi que ta fait la conception, t même passé au codage de ton programme, et ce n'est qu'a la fin que tu veut faire la conception qui normalement doit être faite après la conception, donc tu veut faire un UC qui riflette ce que ta programmé, et ca c'est "contre nature", mais tu peut t'en-sortir quand même si tu applique les notions du modèle a la lettre, ou au moin les plus pertinentes d'entre elles :
• UN diagramme de cas d'utilisation est censé décrire les BESOINS de l'utilisateur, pas décrire le système à réaliser !!!! déjà la , je te vois entrain de te rendre compte que tu veux utilisé le diagramme pour en faire quelque chose pour la quelle il n'est pas destiné
• les cas d'utilisation représente les processus métiers de l'utilisateur, ce pour quoi il est payé, ce pour quoi il se lève le matin pour allé au boulot, les cas d'utilisations : appuyer sur le bouton, lancer l'impression, afficher la page, sont a proscrire, je vois mal le mec se levé le matin pour allé au boulot pour appuyer sur le bouton , il y vas pour travailler, donc concentre toi sur les processus métiers, pas les petites actions.
• pour les relations entre cas d'utilisations, je te conseil de ne pas en abusé beaucoup cas ca ne sert qu'a compliquer ton modèle, c plus des artifices d'informaticiens qu'autre chose et le gain final ne justifie pas leur profusion, a part la relation entend qui exprime une réelle sémantique et qui pourras t'aider plus tard a bien organiser l'enchainement entre les différentes options dans ton application.
• pour finir je te conseil vivement de lire ce tinctorial qui traite spécialement de ce diagramme et qui dit l'essentiel en 2 ou 3 pages : http://ego.developpez.com/uml/tutoriel/casUtilisation/
• si tu tien a exprimer comment ton programme fonctionne, c le diagramme d'activité qui te permettras de le faire et pas les UC

[kais1600]

Merci Beaucoup M Toubal
J'essayerai de suivre vos conseils pour m'aider a améliorer mes aptitudes en UML
Merci beaucoup pour le lien