Discussion :

[ducker88]

Bonjour à tous,

Je suis dans le cas ou j'ai défini plusieurs cas d'utilisation qui sont :
Afficher une liste de contacts.
Afficher une liste d'interventions.
Afficher une liste de produits.

Etc...

Ces listes fonctionnent de la même manière, c'est à dire qu'elles peuvent être filtrée et trié (toujours ma la même action utilisateur).

Malgré que les types de données ne soient pas les mêmes, ais-je le droit de généraliser ces cas d'utilisation en créant un cas d'utilisation "Afficher une liste" lié les différentes listes à cet UC avec la généralisation ?

Merci de votre aide.

Vincent.

[bruno_pages]

Bonjour,

attention, les UCs décrivent ce qui doit être fait, pas comment ce sera implémenté

il n'y a donc pas de type de données au sens classe à ce niveau

si les listes affichées sont triées il est inutile/faux de dire comment, il faut simplement mettre dans la description textuelle associée aux UCs que l'affichage ou autre les donne triées

[ducker88]

Bonjour Bruno,

Merci pour ta réponse, effectivement j'ai mis "afficher une liste de contacts" et les autres en tant que Cas d'utilisation. Le Filtre et le tri sont défini dans le scénario de mon cas d'utilisation.
Pour être plus clair sur ma question, ce que je voudrais savoir c'est s'il est possible de généraliser des cas d'utilisation, dans mon cas l'affichage de liste.

[bruno_pages]

on peut effectivement avoir une généralisation entre UCs, mais j'avoue que je n'aime pas trop et que je n'ai que rarement vu de cas où cela apportait vraiment quelque chose

dans votre cas qu'est-ce que cela apporterait ? est-ce que l'UC afficher une liste à suffisamment de propriétés et/ou inclue/est étendu par d'autres UCs justifiant cela ?

à noter qu'un UC n'est pas paramétrable (template/generique)

[ducker88]

Je pense que c'est moi qui ai mal compris le principe de généralisation.
Pour moi la généralisation est une sorte d'heritage" au niveau fonctionnel.

Pour mon cas personnel, l'UC Afficher une liste aura très peu de lien include et extend, ceux-ci étant rattaché aux UCs qui sont généralisé dans Afficher une liste.
Par contre comme je le disais dans mon post précédent, je vais avoir beaucoup d'UCs permettant l'affichage de liste et toutes auront le même comportement.

[hegros]

"Afficher une liste" est un cas qui ne passe pas le test des cas d'utilisation donc la généralisation est mauvaise. Je pense de toute façon que le verbe afficher ne convient pas pour un cas d'utilisation car ce n'est pas un verbe d'acton


Les tests des cas sont toujours les mêmes

1/ test du patron : est-ce que le patron est content si tu lui réponds que tu as passé tes journées à afficher des listes ? Pour moi non.

2/Test du processus élémentaire métiers : est-ce qu'afficher une liste est un processus élémentaire métier ? Pour moi non.

[ducker88]

Bonjour et merci pour vos réponses.
Si le "Afficher" ne convient pas quel serait le meilleur terme à utiliser ?

[hegros]

Bonjour et merci pour vos réponses.
Si le "Afficher" ne convient pas quel serait le meilleur terme à utiliser ?

bonjour,

Dans un modèle de cas utilisation fonctionnel (parce que l'on peut aussi avoir un modèle de cas d'utilisation technique) on s'attend à avoir des verbes qui sont parlants et significatifs pour un fonctionnel. Un verbe qui apporte une plus value à un domaine fonctionnel en somme

Je ne peux pas dire quel terme convient le mieux puisque je ne sais pas ce qui est attendu comme fonction mais je t'ai donné une façon de tester ces noms par rapport à ce qui est attendu dans un cas d'utilisation

Afficher une liste de contacts ou d'intervenants n'a en principe pas besoin d'un cas d'utilisation, et ce n'est pas un verbe qui connote une fonction d'un processus ou business d'entreprise, puisqu'il s'agit d'une opération élémentaire d'une base de données (select) et d'autres parts parce qu'afficher ne passe pas le test du patron et du processus élémentaire métiers.

[Hephaistos007]

Juste pour compléter ce que dis hegros, je me permet de ressortir une remarque fort-à-propos d'un de nos collègues de developpez.com :

Le UC doit avant tout représenter une unité d'intention complète de l'acteur vis-à-vis du système. Il faut donc se demander ce que les acteurs font faire du point de vue de leur métier avec ton application.

Pour en revenir à la question d'origine, de mémoire, il existe une relation de généralisation entre les acteurs, pas entre les UCs. En effet, il semble logique qu'un acteur plus spécifique "hérite" de toutes les cas d'utilisation de son parent.
L'ambiguïté vient de la relation "extend" qui existe entre les UCs, et qui n'a rien à voir avec de la généralisation et in-fine rien à voir avec de l'héritage. Il sert à décrire un point d'extension, sous condition. Par exemple, "Demande réapprovisionnement du stock" serait un UC en extension de l'UC "Validation commande client". La condition serait "le dernier produit en stock vient d'être commandé".

[markjl]

EA (Entreprise Architect) permet la généralisation de cas d'utilisation.

Ne peut-on entendre dans une analyse fonctionnelle un sens à cela pour dénoter la subordination de certains cas par d'autres de la même manière que l'on subordonne des classes?

En clair: quand on veut décomposer un cas d'utilisation, doit on faire recours à une diagramme d'activités ou des 'sous cas d'utilisation'?

On peut très bien dire: ce cas d'utilisation est composé de sous briques, sous étapes, sous processus?

Ex: cas d'utilisation 'prendre une commande'. est composé d'étapes 1,2,3 : ouvrir le logiciel, créer un client, remplir la commande etc.

Comment feriez vous pour modéliser cela?

[bruno_pages]

On peut très bien dire: ce cas d'utilisation est composé de sous briques, sous étapes, sous processus?

Ex: cas d'utilisation 'prendre une commande'. est composé d'étapes 1,2,3 : ouvrir le logiciel, créer un client, remplir la commande etc.

Comment feriez vous pour modéliser cela?

est composé de ne se modélise pas via une généralisation

dans le cas d'UCs il faut utiliser les dépendances stéréotypée include, et s'il y a une ordre à respecter il faut l'indiquer dans les descriptions textuelles associées aux UCs