Discussion :

[Laidback]

Salut,
J'ai détaillé chaque cas d'utilisation présent dans les diagrammes "Gérer les droits d'accès" et "Gérer son compte" parce qu'il y a des exceptions même dans ces cas d'utilisation (comme mot de passe invalide pour modifier mot de passe) donc je ne pouvais pas détaillé tout simplement "Gérer son compte". Est-ce que c'est juste ?
Sinon, désolé pour le hors sujet, on met les exceptions dans les diagrammes de séquence ?

[bruno_pages]

Bonjour,

il peut effectivement y avoir des exceptions/erreurs dans le déroullement des UCs, celles-ci sont détaillées dans la description textuelle des UCs

1er diagramme : tel qu'il est l'acteur Utilisateur ne sert à rien car il n'est pas directement relié à un UC. Ce que vous vouliez faire c'est sans doute de le relier à l'UC gérer son compte, vous devez donc supprimer les liaisons de cet UC avec les deux autres acteurs et le relier seulement avec Utilisateur, les héritages entre acteurs restant. L'authentification n'est pas un UC mais une pré-condition, l'utilisation d'un extend ne permettant pas d'en forcer l'exécution avant l'UC étendu.

2ième diagramme : il y a trop d'extends, ca part dans tout les sens, et la séparation entre consulter les utilisateurs et rechercher les utilisateurs ne me parait par pertinente, utilisez un seul UC pour ces deux là et le diagramme se simplifiera

vous pouvez indiquer les exceptions dans un diagramme des séquence via des continuations par exemple, ou faire plusieurs diagrammes montrant le cas nominal et les cas d'exception/erreur

[Laidback]

Bonjour,

il peut effectivement y avoir des exceptions/erreurs dans le déroullement des UCs, celles-ci sont détaillées dans la description textuelle des UCs

1er diagramme : tel qu'il est l'acteur Utilisateur ne sert à rien car il n'est pas directement relié à un UC. Ce que vous vouliez faire c'est sans doute de le relier à l'UC gérer son compte, vous devez donc supprimer les liaisons de cet UC avec les deux autres acteurs et le relier seulement avec Utilisateur, les héritages entre acteurs restant. L'authentification n'est pas un UC mais une pré-condition, l'utilisation d'un extend ne permettant pas d'en forcer l'exécution avant l'UC étendu.

Si l'authentification n'est pas un cas d'utilisation, alors comment puis-je décrire les exceptions (mot de passe invalide, etc.) ?

2ième diagramme : il y a trop d'extends, ca part dans tout les sens, et la séparation entre consulter les utilisateurs et rechercher les utilisateurs ne me parait par pertinente, utilisez un seul UC pour ces deux là et le diagramme se simplifiera

Est ce que je metterai "Rechercher un utilisateur" dans le scénario alternatif du UC "consulter les utilisateurs" ? Sinon, les relations "extend" sont-ils justes ? Ce ne sont pas des "include" ?

vous pouvez indiquer les exceptions dans un diagramme des séquence via des continuations par exemple, ou faire plusieurs diagrammes montrant le cas nominal et les cas d'exception/erreur

Sinon, ma principale question est : "Pour la description textuelle, j'ai décrit chaque sous-cas d'utilisation à part ? comme par exemple, Modifier son mot de passe. Ou bien faut-il décrire tout le UC Gérer son compte et mettre les autres dans des scénarios alternatifs" ?

Est-ce que le UC "Gérer les dossiers clients" est juste ? Je crains avoir des confusions entre "include" et "extend"

Enfin, un GRAND MERCI pour vous

[Laidback]

Est-ce que le UC "Gérer les dossiers clients" est juste ? Je crains avoir des confusions entre "include" et "extend"

J'ai déjà inclu les recherches dans le scénario alternatif des UC consulter
Mon diagramme de CU serait comme cela.

[bruno_pages]

Si l'authentification n'est pas un cas d'utilisation, alors comment puis-je décrire les exceptions (mot de passe invalide, etc.) ?

désolé, il manquait des mots dans ma phrase, ce que je voulais dire c'est que l'authentification n'est pas un UC qui étend les autres, c.a.d. que c'est bien un UC, mais qu'il n'y a pas d'extend entre les autres UCs et lui, donc vous indiquez simplement que le fait que cet UC ai été exécuté est un pré-requit des autres UCs dans leur description textuelle

Sinon, ma principale question est : "Pour la description textuelle, j'ai décrit chaque sous-cas d'utilisation à part ? comme par exemple, Modifier son mot de passe. Ou bien faut-il décrire tout le UC Gérer son compte et mettre les autres dans des scénarios alternatifs" ?

il n'est pas nécessaire de creer un UC pour les 'détails', une simple description de ce que fait un UC dans sa description textuelle suffit, et cela allège les diagrammes d'UC en évitent des UCs et extend à la pelle

typiquement avoir un UC consulter les dossiers et un autre consulter les info dossier ne sert à rien à part complexifier les choses, donc retirez consulter les info dossier

Est-ce que le UC "Gérer les dossiers clients" est juste ? Je crains avoir des confusions entre "include" et "extend"

je ne comprends pas que vous vous posiez la question, cet UC n'est relié qu'à l'authentification, liaison qui doit disparaitre

A---extend--->B veut dire que l'exécution de B peut impliquer celle de A
A<----------------B veut dire que l'exécution de B implique forcément celle de A

votre avant dernier diagramme est horriblement compliqué, ne cherchez pas la petite bête en rentrant trop dans les détails

[Laidback]

typiquement avoir un UC consulter les dossiers et un autre consulter les info dossier ne sert à rien à part complexifier les choses, donc retirez consulter les info dossier

Oui, mais dans l'interface de gestion des dossiers clients, il y a tous les dossiers clients, l'acteur choisit un seul dossier et puis, il y a des informations générales sur le dossier saisi et à côté tu peux sélectionner soit les pièces, soit les intervenants, soit l'historique des dossiers comme le montre la figure
Du coup, j'ai détaillé chaque cas d'utilisation à part, avec la recherche comme des scénarios alternatifs, c'est faux ?

[bruno_pages]

faux non, mais je reste septique quand à la pertinence de la chose, à vous de voir et decider

[Laidback]

D'accord. Thanks!