Discussion :

[Celelibi]

Bonjour,

je tien avant tout à dire que je suis un pure débutant.

En fait j'aimerais juste m'exercer sur un exemple simple : une application web pour gérer mes mp3.
Actuellement il n'y a qu'un seul acteur : moi.
Et les cas d'utilisations sont (pour le moment) :

• gérer* les MP3
• gérer la liste des catégories
• gérer la liste des artiste
• faire une sélection et l'exporter au format de playliste de xmms

*gérer = Voir, Ajouter, Éditer, Supprimer

Mon problème se situ justement au niveau de "gérer", car Voir, Éditer et Supprimer impliquent une recherche, mais pas Ajouter.


Ma question est simple : est-ce-que je dois détailler "gérer" pour chacun des cas d'utilisation que j'ai actuellement pour mettre un include recherche ? Dans ce cas là ça ferait beaucoup de cas d'utilisation.


Merci d'avance.

[ego]

regardes dans les précédents threads, il y a qqu'un qui a posé une question similaire au sujet de 2 UCs qui inclus ou non un UC "Rechercher"


sinon, tu peux lire ceci : http://ego.developpez.com

[Celelibi]

si j'ai bien compris la question est de savoir si "rechercher" est un cas d'utilisation ou non.

en gros si j'ai bien compris ton article un cas d'utilisation c'est ce que le client qui n'y connais rien en informatique veut pouvoir faire avec le futur système qu'importe la façon dont ça sera fait.
Donc la recherche bien que précédent forcément les actions voir, éditer et supprimer, n'est pas un cas d'utilisation et ne doit pas figurer sur ce diagramme.

ego, tu dis dans ton article que tu trouve la relation de généralisation discutable, mais dans mon cas, ne serait-il pas utile de généraliser mes 3 premiers cas d'utilisations ?
car avec mes 3 cas d'utilisations distincts j'aurais 3 fois le même code php/html à quelques différence près.
la généralisation serait-elle utile ?

[ego]

tu as parfaitement compris le positionnement de "Rechercher"
pour la généralisation, cela ne va pas t'aider.
ce n'est pas parce que d'un point de vue solution des UCs se ressemble qu'il ne faut pas les identifier et les distinguer en amont du projet. L'identification des UCs sert à savoir ce que l'on a à faire et même si "Gérer X" ressemble à "Gérer Y" il y a bien une différence car X n'est pas Y. L'IHM correspondant à chacun des cas est probablement différente aussi (même si côté solution cela peut n'être qu'un paramétrage d'une solution générique).
Ce n'est pas non plus parce que tu as 3 UCs que côté solution tu auras des choses en double. Il va justement falloir éviter de faire 2 fois la même chose et même essayer de trouver une solution qui peut s'adapter facilement pour traiter aisément tous les UCs.
Mais c'est ça la conception !!

[Celelibi]

merci ego.

en fait au début je pensais faire une page php par cas d'utilisation (d'où ma question sur la généralisation), mais finalement ça n'a rien à voir.


Je pensais que les cas d'utilisation étaient tout ce qu'il y a de plus simple, mais en fait je me suis quand même posé des question (et des mauvaises questions).



ecore merci ego

[ego]

il n'y a pas de mauvaises questions !
ce sont ceux qui n'en posent jamais qui sont mauvais

je pense que tu as vraiment tout compris, c'est l'essentiel