Discussion :

[ftrifiro]

Bonjour,

Nouvelle question, qui je pense, peut générer des avis différents... Je me lance puisque justement, je souhaite des avis !

Imaginez un système qui gère des clients, des commandes... Peu importe. Au niveau des cas d'u, quelle maille choisir ?
1 - gestion des clients, gestion des commandes...
ou
2 - création client, modification client, ..., création commande, modification commande.

D'instinct, je partirais sur l'optique 1 pour ne pas démultiplier les cas qui finalement concourent à traiter un tout fonctionnel, la gestion d'un domaine. Si mon choix est le bon, faut-il considérer que la création, la modification, la consultation d'un client sont des scénarii du cas gestion des clients ?

Merci

[ftrifiro]

En fait, j'ai ma réponse et je vous la livre car elle peut intéresser d'autres concepteurs je pense.

En gros, un cas d'utilisation correspond à un but. Identifier les buts de chaque acteur identifié permet d'avoir une première liste de cas d'utilisation.

Il existe des exceptions, justement dans mon cas, où on peut considérer que créer, modifier et supprimer sont des buts que l'on regroupe dans un seul cas nommé usuellement "gérer X".

Voilà !

[YAMKI]

Par défaut je pense que le premier cas est le bon.

Maintenant, le but des cas d'utilisation est de faire comprendre sa vision du problème. Si tu considère qu'il est important de mettre explicitement en avant le fait que ton acteur peut créer, modifier quoi que ce soit alors indique. Sinon, précise le uniquement dans la description de ton usecase

[ftrifiro]

Au niveau des scenarii alors, je dois distinguer un scenario pour chacune des actions ? Existe-t-il dans ce cas un scénarion principal et d'autres alternatifs ?

[YAMKI]

un scénario est un déroulement possible dans ton usecase. Il en existe plusieurs pour décrire ton usecase. Plus tu a réaliser tes usecase avec un niveau d'abstraction élevé, plus tu auras de scénario.

Je ne pense qu'à ce niveau il y ai vraiment des règles à suivre. Garde seulement dans ta tête que ta modélisation à pour but de rendre plus clair la problématique et de faire comprendre ton interprétation. Tant que tu reste dans cette idée ce que tu fais sera bon.

Attention ceci est mon point de vue personnel et surement très divergeneat des vrai puriste UML.

[Yveke]

Normalement il faut un diagramme de séquence pour chaque scénario mais concrètement tu peux bidouiller en mettant des labels.

[ftrifiro]

En gros, lorsque je veux décrire au sein de mon cas d'u "créer client", "modifier client" et "consulter historique client", je ne sais pas :

- si je traite trois scénarii principaux (est-ce que ça a un sens d'ailleurs ?!)

- si je traite trois sous cas d'u avec chacun un scénario principal.

Je veux bien admettre au final que ça ne change pas grand chose mais c'est une question de vocabulaire (et donc de sens) et de présentation également...

Si je ne suis pas clair, n'hésitez pas à me l'écrire !

[Liverkod]

Hello,

ftrifiro j'aimerais vraiment pouvoir t'aider mais....

Si je ne suis pas clair, n'hésitez pas à me l'écrire

tu n'es vraiment pas clair
De manière générale, je trouve que le problème initial est loin d'être clair.
Je ne vois vraiment pas ce que je peux faire, désolé....

[YAMKI]

Je suis d'accord avec LiverKod, il est un peu dure de cerner ton pb.

Par contre si ca peut t'aider. Rien ne t'empêche de faire un diagre de cas d'utilisation d'un niveau d'abstraction assez élevé (en utilisant des gérer...) et apres pour décrire chaque cas d'utilisation refaire un nouveau diagramme de cas d'utilisation plus détaillé.

Pour le coup, j'espère que c moi qui ai été clair

[ego]

La première réponse de ftrifiro est la bonne !
Tu peux lire ceci si tu le veux :

http://ego.developpez.com/uml/tutori...ation-v1.3.pdf

[ftrifiro]

Euh, merci !

Mais j'ai raison en disant quoi ?! ?

Je n'ai pas vu le lien avec mon propos dans le document en lien ; mais pê que je devrais aller me coucher !

A+, Fred

[tiboleo]

Pour une Nième relance sur ce sujet...
Pardon par avance.

J'ai posté qqchose à :
http://www.developpez.net/forums/vie...124778#2124778

Mais rien n'est vraiment clair (mais ma demande est surement mal formulée)

Si on reprend l'exemple ci dessus, on auraiit :

UC : geston des clients

Qu'est ce qu'on met dedans?
Comment distinguer ajouter/modifier/supprimer?

Comment "en parler" depuis l'UC "geston des clients"
Faut-il faire des sous UC : ajouter un client, modifier un client,...?


Et dans mon cas (cf lien ci dessus), mon utilisateur peut de façon indépendante:
créer un nouveau salarié
modofier la fiche d'un autre
créer une fiche contrat pour un 3ème salarié

Donc, selon moi, un UC "gerer salariés" est trop vague...
Et en même temps, faut-il écrire:
Ajouter salarié
Modifier salarié...

Pleins de questions qui me gênent un peu pour démarrer...

Merci beaucoup de votre aide...

[ego]

La bonne question à se poser et que fait mon acteur le matin en lançant l'application ? quelle est son intention métier ?

S'il y a 3 intentions métier derrière ajouter, modifier et supprimer un client, tu dois faire 3 UCs. Bien sûr, tu centralisera les caractéristiques du client à un seul endroit, disons dans un fiche "exigence", et tu référencera cette fiche depuis tes 3 UCs. Si des séquences action acteur / réaction application sont similaires dans tes 3 UCs, tu pourras les factoriser dans un UC que tu "includeras" dans les 3 autres.

[lepierre]

Bonjour,
je me permet de relancer se post.

Je souhaiterais savoir se que vous entendez par "fiche exigence" ?

Comment elle se présente et comment doit-on l'appellé depuis l'UC ?
Cette fiche d'exigence a t-elle un nom particulier en UML ?

Vous serrait-il possible de me donner un exemple.

Merci pour votre aide.
Pierre

[ego]

Une fiche d'exigence n'a pas d'existence en UML
C'est un simple doc word où est décrit une seule exigence du genre règle de gestion. Ces fiches sont numérotées + nommées et c'est donc son numéro+nom que l'on référence dans la fiche de UC