Discussion :

[smist]

bonjour tout le monde,
d'après mon prof il faut ignoré les cas d'utilisations qui n’interagit pas avec le système : aider-moi pour améliorer ma solution et merci d'avance.

[bruno_pages]

bonjour,

d'après mon prof il faut ignoré les cas d'utilisations qui n’interagit pas avec le système

Ce en quoi il a raison puisque par définition les UC décrivent le comportement du système étudié en fonction de stimulus externes

Plusieurs choses ne vont pas dans votre diagramme, déjà au niveau acteur, vous n'avez que l'acteur visiteur, ce qui est incompatible avec l'énoncé car ce que peut faire un visiteur est limité.
Comprenez bien qu'un acteur représente un rôle, et que par exemple une même personne peut avoir plusieurs rôles

Quelle différence y a-t-il entre les UC finaliser et valider l'inscription ?

Attention à l'utilisation des <<include>>, A ---<<include>--> B veut dire qu'à chaque activation de A alors B est activé, et donc par exemple à chaque édition de profil il y a une validation de l'inscription
Je pense que vous confondez inclusion et précondition

[smist]

bonjour,
merci pour la repense donc dans les use cases en met seulement les besoins des acteurs c'est vrai ?
voilà une correction de mon diagramme je demande toujours s'il est juste est merci .

[bruno_pages]

bonjour,

dans les use cases en met seulement les besoins des acteurs c'est vrai ?

c'est une curieuse façon de dire les choses, mais ok

ok pour les 2 acteurs

un visiteur ne peut pas consulter une annonce dans l'énoncé

utilisez l'impératif pour les actions, donc par exemple editer profil et non edition profil

je ne suis pas pour l'extend entre validation inscription et creation compte car ces deux actions sont totalement séparées, par contre la creation est un pré requis à la validation

vous devriez separer la consultation et la proposition d'annonce

meme remarque que dans ma réponse précédente concernant l'include, le but n'est pas que vous mettiez toutes les relations possibles dans le diagramme mais que celui-ci soit valide regardez ce que l'on dit de l'authentification dans les autres sujets

[smist]

bonjour,
d'après la dernière phrase de l'énoncé je pense qu' un visiteur peut consulter une annonce mais sont connaitre les membres du sites .
Voulez-vous dire ça : validation compte ---------include-----------> création compte ? dans ce cas si l'utilisateur est déjà crée le compte est veule seulement valider ce dernier il doit encore crée un autre compte non ?
je pense que : UCA-----include---->UCB signifie qu' a chaque fois que l'acteur veule accéder au UCA il a besoin de confirmer le UCB c'est le cas d'authentification que j'ai fait .sinon j'ai mal compris la modélisation avec le use case , je te remercie infiniment .

[bruno_pages]

bonjour,

d'après la dernière phrase de l'énoncé je pense qu' un visiteur peut consulter une annonce mais sont connaitre les membres du sites .

ah oui pardon, vous avez raison

Voulez-vous dire ça : validation compte ---------include-----------> création compte ? dans ce cas si l'utilisateur est déjà crée le compte est veule seulement valider ce dernier il doit encore crée un autre compte non ?

ce n'est pas parce que je ne voulais pas d'un extend que je préconisais un include

un UC ce n'est pas qu'un ovale avec des relations dans un diagramme, un UC doit aussi avoir une description textuelle, et cette description peut comporter des pré/post conditions

il n'y a pas de relation entre creation et validation, par contre la creation est une précondition pour la validation, si vous voulez le montrez dans un diagramme il faut simplement utiliser une note, mais avec le risque d'alourdir le diagramme

il en est de même de l’authentification qui n'est pas reliée aux autres UC par une relation include ou extend, encore une fois ce problème est abordé à de très très très nombreuses reprises dans les autres discussions à propos des UC, on aurait pu presque utiliser un extend mais cela n'est pas possible car un extend ne permet pas de mentionner le moment ou l'UC optionnel est exécuté