Discussion :

[CaptainChoc]

Bonjour,

Voici mon scenario :

j'ai 3 type de mail qui peuvent arriver,
-> soit c'est un mail a destination d'un destinataire : je stocke tout le mail et j'envoi une demande de confirmation,

-> soit c'est un mail de non remise : je stocke l'adresse erreur et je le supp

-> soit c'est une reponse a une demande de confirmation, jenvoi le mail (c'est un autre prog qui s'en occupe)

voici ce que j'ai fait en diagramme de de cas d'utilisation


Comment le trouvez vous ?

de plus :
doit il y avoir une dependance entre confirmation et mail normal? et la base de donne dois je la representer?

merci de votre aide

[efficks]

Il me semble que l'on écrit juste les acteurs qui effectuent l'action et non pas ceux qui sont affectés comme serveur sympo.
De plus, tous tes pourraient utiliser un même UC nommé "envoie Mail" avec un extend ou un include (je ne me rapelle plus la différence).

[ego]

Tout d'abord, il faudrait que tu nous dises quel est le système que tu étudies.
Ensuite, les UC ne décrivent pas le comportement interne de ton système mais les attendus de la part de ses acteurs.
J'ai l'impression que le seul UC est "Envoyer un mail". C'est dans la description de ce UC que tu diras que le système doit pouvoir demander une confirmation et pourra traiter des erreurs d'adresse.
Ensuite, tout le reste est affaire de gestion d'un protocole "mail", interne à ton application. Les UC ne sont pas adaptés pour cela.
Un diagramme d'états-transition et/ou d'activités sont plus appropriés pour cela.

[efficks]

Tous à fait d'accord avec ego

[CaptainChoc]

donc pour vous ce n'est pas le bon diagramme ?

et qu'entends tu par : "Tout d'abord, il faudrait que tu nous dises quel est le système que tu étudies. "

De plus, pour moi tout ce fait dans une seule classe, et donc je n'ai que des fonctions comme : RecupererMail, AnalyserMail, EnregistrerMail...


merci de votre aide

[efficks]

Un UC montre les actions que les utilisateurs peuvent faire avec le système. Comme on peut voir, une seule intéraction est possible soit l'envoie d'email. De plus, je laisserai un seul acteur au système avec un nouvel acteur qui représente un autre système de qui on reçoit les emails externes.
Donc tu n'as besoin que de deux scénarios, envoyer un email et recevoir un email. Et peut-être un troisième, lire un email.

[CaptainChoc]

mais moi ce que je veux representer c'est justement le fait qu'il y a plusieurs mails et en fonctions du mails je fait un autre traitement...

[CaptainChoc]

Voilà j'ai essayé de faire une diagramme d'activité :

voilà ce que ca donne :

[efficks]

Tu ne peux pas représenté cela dans un diagramme de UC. Le diagramme de UC montre les cas d'utilisation du système et non pas comment il fait le traitement. Un diagramme de séquence ou de collaboration est peut-être plus approprié.

[ego]

Le diagramme d'activités fait par CaptainChoc, au delà de petites remarques sur la forme UML (il faut un état de départ et un état de fin), est suffisant pour exprimer ce qu'il voulait.
Tu as décrit ce que doit faire ton système lors de la réception d'un email, c'est tout bon, non ?
Il faut ensuite préciser les exigences qui s'imposent peut être à chaque activité et expliquer ce que signifie précisément chaque activité

[CaptainChoc]

ok merci c'est bon alors