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.
Pièce jointe 238752
Version imprimable
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.
Pièce jointe 238752
bonjour,
Ce en quoi il a raison puisque par définition les UC décrivent le comportement du système étudié en fonction de stimulus externesCitation:
d'après mon prof il faut ignoré les cas d'utilisations qui n’interagit pas avec le système
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
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 .
Pièce jointe 239067
bonjour,
c'est une curieuse façon de dire les choses, mais okCitation:
dans les use cases en met seulement les besoins des acteurs c'est vrai ?
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
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 ;).
bonjour,
ah oui pardon, vous avez raisonCitation:
Envoyé par smist
ce n'est pas parce que je ne voulais pas d'un extend que je préconisais un includeCitation:
Envoyé par smist
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é
