Discussion :

[Arjuna]

Bonjour,

une petite question concernant les cas d'utilisation et plus particulièrement des scénarios qu'ils induisent.

Est-il possible qu'un scénario alternatif puisse renvoyer au scénario d'un autre cas d'utilisation ?

Est-ce "propre" ou est-ce considéré comme une erreur de conception ?

Exemple : Un scénario alternatif récurent peut-il faire l'objet d'un cas d'utilisation afin d'éviter les répétitions (surtout que cette alternative possède elle-même des alternatives).

Merci.

[tonton16]

Bonjour,

Ce n'est pas une erreur. Un des intérêts de la description d'un cas d'utilisation est de pousser la réflexion sur celui-ci et dans certains cas, de détecter des bouts de processus qui se répètent entre plusieurs UC.

Dans ces cas là, il faut faire ressortir ces parties et les représenter sous la forme de cas d'utilisation et liés par une relation <<include>> au cas d'utilisation parent. C'est de la mutualisation et c'est une bonne pratique.

[Arjuna]

Merci Tonton16

T'as réponse me conforte dans la compréhension des relations <<include>> (et <<extend>>).

[ego]

Attention à ne pas rentrer dans de la décomposition fonctionnelle qui conduirait à créer un labyrinthe.
Il n'est pas "normal" fonctionnellement de faire la même chose dans 2 cas d'utilisation différents. C'est comme si 2 personnes différentes faisait un travail redondant dans 2 activités métier différentes.

As-tu un cas concret pour en discuter ? (si tu le veux...)

[tonton16]

Effectivement, la décomposition fonctionnelle est un risque.

Cela dit, prenons le cas d'une bibliothèque, un adhérent qui veut effectuer un emprunt (de manière électronique) et un bibliothécaire qui veut modifier les informations d'un livre auront besoin chacun de rechercher un livre dans la base.

Cette fonction de rechercher un livre, commun aux 2 cas d'utilisation peut être sorti et mis en commun avec l'utilisation d'un <<include>>.

Bien sûr, tout dépend du processus interne de cette fonctionnalité. Ce n'est pas applicable dans tous les cas.

[ego]

La recherche est l'exemple donné par beaucoup mais c'est un "bout" du cas d'utilisation très petit en général qui ne nécessite pas de réelle factorisation.

Sauf cas super compliqué tu as souvent un truc du genre :

1- Ce cas d'utilisation démarre quand le bibliothécaire demande à modifier les informations d'un livre. Le bibliothécaire renseigne les informations permettant la recherche du livre :
- Numéro ISBN
ou
- Titre du livre et ou Auteur

2- Le système recherche le ou les livres en fonction des informations saisies. Si aucun livre n'est trouvé, le casd'utilisation se termine.

3- Le bibliothécaire choisi parmis le ou les livres trouvés par le système


blabla, blabla....

On peut factoriser si on veut mais ce n'est pas essentiel et on ne trouve généralement que des fonction "transverses" du genre de celle que tu viens de donner pouvant être communes à plusieurs CU. Mais les "vraies" fonctionnalités métier ne sont généralement pas communes à plusieurs CU

[tonton16]

Je suis d'accord avec toi, factoriser des sous-fonctionnalités n'apporte pas grand chose dans la compréhension du métier.

Maintenant, tout dépend du niveau de granularité que l'on veut mettre dans notre analyse.

Il est vrai dans dans des diagrammes de cas d'utilisation d'un niveau assez général, je n'ai jamais d'<<include>> et très peu, voire pas d'<<extend>>. L'inconvénient, c'est qu'ils sont souvent difficiles à décrire.
Dans un deuxième temps, je "zoome" sur ces cas d'utilisation et je fais intervenir les liaisons entre cas d'utilisation. Par contre dans ce cas là, la description est plus détaillée mais demande plus (trop) de temps.

Maintenant, je pense que dans certains cas il est possible d'avoir des fonctionnalités suffisamment importantes pour être factorisées, mais je n'ai pas d'exemple.

[Arjuna]

Salut tt le monde,

Pour ce qui est du cas concret qui m'occupe actuellement, il s'agit de schématiser un processus automatisé qui se répète très souvent lors de la moindre interaction d'un utilisateur avec le système (échange de clés entre un Agent d'Authentification, le navigateur web et un Serveur SSO).

Après peut-être qu'un élément système ne doit pas être représenté dans un use case (même si ce dernier fait partie du domaine d'étude) ?