Discussion :

[atome]

Salut,

J'aurais besoin d'aide à propos d'un diagramme de cas d'utilisation que je suis en train d'élaborer.

Voici la description du système, et ma proposition de diagramme :

• L'application permet à un vendeur de faire des devis.
• Une fois un nouveau devis créé, le vendeur peut y ajouter des produits à partir d'un catalogue.
• Le vendeur peut supprimer un produit ajouté à partir d'un catalogue
• Une autre façon d'ajouter des produits au devis consiste à importer une liste de produit à partir d'une autre application.
• Les produits provenant de cette autre application peuvent être configurés (choix d'options, etc.)
• Le vendeur peut accorder une remise sur tous les produits du devis.

Est-ce que le diagramme vous semble correct ? Je doute un peu vis à vis des <extends>.

Si non, que proposeriez-vous pour modéliser les use cases de ce même système ?

Merci beaucoup.

PS : Cet exemple est volontairement simplifié, et les use cases volontairement verbeux. Si vous m'aidez déjà pour cette étape je reviendrai sans doute avec de nouveaux uses cases à gérer pour ce système.

[Nip]

Tu descends beaucoup trop bas en terme de granularite; par definition, un uc represente un ensemble de sequences d'actions et doit seulement montrer ce que doit realiser le systeme et pas la maniere de faire. La multiplication des extends montre que tu decomposes trop ton UC, qui en devient par ailleurs limite incomprehensible. Ensuite j'imagine que ton appli ne se limite pas a creer des devis: si tu decomposes a chaque fois autant tes UC, tu t'imagines le nombre de relations que ca va faire?
Les UC ne correspondent qu'a la capture des besoins fonctionnels; ca te permet, outre d'analyser les besoins et de faciliter la communication avec ton client (ce qui, avec le diagramme que tu presentes, pourra s'averer difficile), d'identifier tes classes metiers, or ajouter, supprimer, selectionner ou meme creer ne fait pas une classe!

Dans ton cas tu peux te limiter a 2 UC:
1-Traiter un devis
2-Gerer les produits
Tu peux ajouter une relation extend 2->1

Le fait que tes uc soient verbeux est par ailleurs une bonne chose.

[Joshua Beharia]

Hy,

pas vraiment mieux que Nip, ton truc est trop axé développement fonctionnel à cause de tous ces <<extend>>.
Il faut savori interpréter les besoins: ajouter, supprimer sont en fait cacher dans l'UC "Gérer".

Je ne vois rien d'autre à ajouter, mais tu peux nous faire parvenir le truc en entier, ça peut être constructif!

Voili.
@+.

[atome]

Je comprends bien vos remarques, et je ne suis pas supris.

Seulement ici, la granularité est volontairement fine. Ce schéma entier est un zoom sur le use case de plus haut niveau "créer un devis". Il faut bien comprendre que chacun des cas d'utilisation ici peut encore être fractionné. Ce n'est peut-être pas visible ici, puisque j'ai travesti mon problème originel en quelque chose d'exagérément commun : une gestion de devis.

J'ai peut-être pensé un peu naïvement que vous arriveriez à lire entre les lignes sans faire attention à la nature de l'exemple. J'aurais dû être plus clair, et je m'excuse donc.

Voici ce que je cherche indirectement à savoir :

• Est-ce que, conceptuellement parlant, il est correct de considérer que le use case "supprimer produit" étend le use case "ajouter produit" ?
• Est-ce que, toujours de la même façon, il est correct de considérer qu'un use case peut en étendre deux autres ?
• Est-ce qu'il est préférable de toujours préciser l'extension point lorsqu'on utilise une relation "extend" ?

Vous vous demandez sans doute pourquoi j'ai choisi un exemple, au lieu de poser clairement les questions qui me préoccupaient. En fait, c'était pour que vous puissiez proposer des modélisations différentes sur le même exemple de base. C'eut été directement parlant je crois.

Gardez également en tête que les diagrammes de uses cases ne sont pas forcément des diagrammes avec 1 acteur et 3 uses cases. La plupart des cas concrets sont largement plus complexes que les exemples des tutorials ou des projets de fac... En cherchant un peu, on trouve rapidement des diagrammes comme celui-ci. Ce n'est pas forcément ce qu'il faut faire, et on préfèrera généralement faire plusieurs sous-diagrammes, mais si on s'arrange pour garder un diagramme exagérément simple il perd de fait son intérêt.

Merci en tout cas pour avoir pris de le temps de poster. Si vous avez d'autres remarques ou des réponses, je suis preneur.

[Nip]

Je dois t'avouer que j'ai un peu de mal a te suivre; quel est l'interet pour toi de detailler autant tes UC, surtout pour nous faire discuter sur un faux exemple sense simplifier ton cas reel? Parle nous directement de ton cas plutot que de tourner autour du pot, parce que a la vue de l'exemple donne, je ne vois pas ce que je pourrais changer a ma precedente intervention. Je me repete mais il n'y en a aucun interet a detailler tes UC: tu perds tout l'interet de concision, qui te permet de facilement identifier tes futurs controleurs metiers et classes, tu perds en visibilite et tu vas te retrouver a detailler des etapes que ce type de diagramme ne peut pas detailler; pour ca tu as la description textuelle, qui est indispensable et tu as suffisemment d'autres diagrammes en UML beaucoup plus specialises (entre autres les diagrammes d'activite, de sequence et d'etats).

Sinon pour tenter de repondre a tes questions (qui par rapport a ton diagramme n'ont pas vraiment lieu d'etre mais il est quand meme interessant d'en discuter):

* Est-ce que, conceptuellement parlant, il est correct de considérer que le use case "supprimer produit" étend le use case "ajouter produit" ?

Toujours dans mon idee, non, puisque il n'est sense y avoir qu'un UC "gerer les produits", et non aussi parce que je ne vois aucun cas ou "ajouter produit" impliquerait "supprimer produit" .

* Est-ce que, toujours de la même façon, il est correct de considérer qu'un use case peut en étendre deux autres ?

Ca ne pose pas de probleme, mais tout depend de tes UC.

* Est-ce qu'il est préférable de toujours préciser l'extension point lorsqu'on utilise une relation "extend" ?

Absolument pas, tout depend du cas d'utilisation. Exemple dans ton cas si tu cree un devis associer a un client alors que ce client n'existe pas encore tu peux preciser par un extend et un point d'extension la creation de ton nouveau client:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  Gerer le devis
--------------------   <--------  Gerer les clients
Extension: nv client

Dans d'autres cas cette precision sera inutile.

La plupart des cas concrets sont largement plus complexes que les exemples des tutorials ou des projets de fac...

C'est une evidence, mais ce n'est pas une raison pour complexifier un sujet qui n'a pas raison de l'etre.

En cherchant un peu, on trouve rapidement des diagrammes comme celui-ci. Ce n'est pas forcément ce qu'il faut faire, et on préfèrera généralement faire plusieurs sous-diagrammes

L'UC que tu indiques en exemple est difficilement lisible, non de par sa complexite mais par sa qualite d'image , il vaut mieux aller voir la (le meme en plus gros ): http://storm.prohosting.com/charyiu/...s/image001.jpg
Faire des sous diagrammes peut etre une bonne chose pour eviter d'avoir un seul et unique enorme diagramme, mais detailler a mort des UC est une autre histoire.
Concernant cet exemple et sans aller plus loin, je suis serieusement sceptique quand je vois des UC Add ou Delete; representer les fonctions de base (CRUD) par des UC, je n'ai jamais vu ca.

mais si on s'arrange pour garder un diagramme exagérément simple il perd de fait son intérêt.

Un diagramme trop complexe encore plus!

[Hephaistos007]

Juste une petite intervention pour dire que les relations "extends" sont inappropriées dans ce UC. Toujours bien réflechir à la sémantique des relations avant de les utiliser...

[ego]

histoire d'en rajouter une couche et parce qu'on est jamais aussi bien servi que par sois-même cf. http://ego.developpez.com/uml/tutoriel/casUtilisation/

Pour info, je vis actuellement une expérience où les gens ont appliqué sans réfléchir les principes de Alistair Cockburn sur les UC. Il en résulte des schémas comme tu as présenté et résultat, les MOA ne comprend même plus son métier !! le comble non ?

Mon point de vue est que ce type de décomposition des UC en sous UC puis sous-sous UC est le fruit d'un manque de connaissance de ce qui est fait après les UC = analyse, conception,implémentation. On veut, dès les UC, faire le boulot de l'équipe de "conception" et les "aider" à faire de la décompostion fonctionnelle. Et là, on se trompe complètement d'objectif.

[bruno_pages]

C'est le paradoxe des UCs : ils devraient être la partie la plus simple d' une modélisation et c'est finalement une source inépuisable de discussion

[ego]

je confirme !