Discussion :

[kiwkcet]

J'ai dans mes cas d'utilisations, souvent le meme type de cas a savoir: ajouter, modifier, supprimer x.

Je sais que pour ces 3 cas-la, on conseille souvent de regrouper en un seul, gerer x.

Mais j'ai, par exemple, ajouter et modifier x qui extends ajouter y.

Ma question est donc: je laisse regroupé en faisant un "gerer x extends gerer y" ou je casse mes gerer x et y pour specifier exactement quels cas extends quels autres cas?

[bruno_pages]

...Je sais que pour ces 3 cas-la, on conseille souvent de regrouper en un seul, gerer x.

très franchement "gerer" n'est pas un mot particulièrement précis, et si tu mets cela dans un use case tu n'apportera pas beaucoup d'information

Mais j'ai, par exemple, ajouter et modifier x qui extends ajouter y.

Ma question est donc: je laisse regroupé en faisant un "gerer x extends gerer y" ou je casse mes gerer x et y pour specifier exactement quels cas extends quels autres cas?

es-tu certain de parler de use case ? cela fait plutot penser a une implementation

[kiwkcet]

je vais donner un exemple concret, ça sera ptet plus clair:

mon utilisateur doit pouvoir enregistrer, modifier et supprimer les dlls qu'il a créé ainsi que ses objets. Lors de la creation et de la modif de dll, il lui est possible de créer les objets.

donc j'ai schématisé ça comme suit(je fais comme je peux en texte) mais je sais pas si c'est valable.


a:user------UC:créer_dll------<<extends>>-|

------UC:créer_objet-----------------|

et j'aimerais savoir si il faut que je fasse cela pour chaque operation(enreg, modif, suppr) ou bien si il vaut mieux dans un uc: gerer dll qui extends gerer objet

[bruno_pages]

je fais comme je peux en texte

si tu veux éviter le texte installes toi un modeleur

mon utilisateur doit pouvoir enregistrer, modifier et supprimer les dlls qu'il a créé ainsi que ses objets. Lors de la creation et de la modif de dll, il lui est possible de créer les objets.

la première chose que tu dois te demander est quel est mon but ? qu'est-ce que je veux montrer dans mes uses cases ?, en te rappelant bien qu'un use case ne parle pas de choix d'implementation

tu dois indiquer que creer_dll extends creer_objet uniquement si cela a un sens pour l'utilisateur, pas pour des raisons d'imple.
Si c'est le cas pour les operations enreg, modif et suppr, alors oui tu dois avoir l'extend a chaque fois
Mets toi a la place de quelqu'un d'autre qui verrait un use case avec gerer_dll extends gerer_objet, est-ce que cela t'apporterait quelque chose ?

[pseudocode]

Il faut bien penser aux UC comme des "cas d'utilisation". La question a se poser c'est donc:

" Dans quels cas je vais utiliser ce logiciel ? "

- Cas n°1 : Quand je veux créer une dll
- Cas n°2 : ...


Les "extends" sont des sous-cas optionnels. Ils ne sont pas obligatoires, contrairement aux includes. Donc ton extend signifie:

" Quand je suis dans le Cas n°1 je peux optionnelement créer un objet"

A partir de la, 2 questions:
- Est-ce bien ce que tu voulais dire ?
- Est-ce que c'est interessant pour l'utilisateur final de le savoir ?

[kiwkcet]

plus j'y réfléchis plus je me perds donc je vais essayer de donner l'énoncé en large et expliquer comment je vois ça niveau UC

voila en fait l'énoncé du travail que je dois faire:

on veut créer une application qui permette de recenser les impacts de modification d'une application (en gros, trouver quelles sont les methodes qui appelent la methode que le développeur vient de modifier).

On veut que la bd se constitue au fur et à mesure des modifs effectuées par les developpeurs.

Par exemple, lorsqu'un developpeur modifie une méthode et qu'elle n'existe pas en bd, il l'encode lui-même, si elle apartient a un class module qui n'existe pas encore, il le créé, si le class module appartient à une dll qui n'existe pas encore, il la créé. Ensuite, il encode les methodes appelées dans cette methode, si ces methodes existent pas, le schema précédent se répète. Lors d'une modification, il est possible que des methodes précédemment appelées ne le soient plus donc il faut pouvoir les supprimer

j'arrive donc au schéma suivant



Sinon dites-moi si j'ai bien compris le concept de use case: c'est dire en schema les opérations qu'on va permettre à l'acteur de faire avec l'applic, puis ensuite dire exactement la marche à suivre afin d'accomplir le but via les scénarios