Discussion :

[ukanoldai]

Bonjour,
nous avons vu rapidement la modelisation uml dans le cadre d'un graduat et maintenant il s'agit maintenant de mettre cela en pratique, et c'est déja la panade lorsqu'il s'agit de déterminer les uses case ^^ , alors ne pas taper svp.

Un gros probleme pour moi est le suivant:

En résumé le projet:
Une societé gérant le pret de titre a des contreparties(organismes financiers), outre la gestion des prets, l'on dispose d'un stock qu'il s'agit de mettre a jour lors de diverses opérations et a divers moments.
c'est précisement le stock position qui me crée qques soucis.
- récupération du stock le matin auprès d'un acteur.
- récupération des intentions de ventes le matin de la journée et mise a jour du stock, d'autres intentions de ventes peuvent intervenir en cours de journée.
- récupération des intentions d'achat le matin de la journée et mise a jour du stock, d'autres intentions d'achat peuvent intervenir en cours de journée.
- récupération des ventes non reglées le matin auprès d'un dépositaire(organisme financier) et mise a jour du stock
- impacter le stock le matin en fonction des prets démarrant a la date du jour.
- impacter le stock lors de la cloture d'un pret.

au vu de cela, est ce que vous créeriez:
-un use case pour chacun de ces cas?
- ou bien tous les cas spécifiques qui ferait un extend sur un global "Impacter les positions"?
- juste un gros cas: impacter les positions?

- au départ avec mon groupe nous étions parti sur l'idée de faire un use case également pour la récupération des données, et de la faire un extend vers un use case global "Impacter position", mais est ce que la récupération de données est un besoin métier?

bref, faire son premier use case, c'est pas facile.

[pseudocode]

Personnellement, je ferai un UC pour chacun des cas que tu as decris.

Ca permet d'avoir des UC lisibles et comprehensibles par les parties prenantes () car il faudra surement faire une revue avec eux, histoire d'etre sur qu'on a bien compris le probleme

Apres, pendant la phase d'analyse, je m'occuperai de la generalisation/specification des UC. Donc de creer des "extends" si besoin.

Quand a la solution, un gros UC... Je l'ai fait un jour pour delirer sur un projet ou les besoins etaient plus que flous. Un seul UC: "acteur --> Utiliser le systeme". Je ne suis toujours pas sur qu'ils aient saisi l'humour...

[ukanoldai]

ha ben je suis déja vachement content de n'etre pas si si loin

et au niveau des récupérations de données aupres de l'acteur, est ce que cela mérite un use case, qui ferait un extend vers le use case de mise a jour du stock?

[pseudocode]

Ah. Les fameux "ET" dans les use-case: "récupérer (...) et mettre a jour (...)"

Dans ces cas la, je ne fais jamais confiance a l'enoncé des besoins
Parce que le "mettre a jour" du besoin 1 n'est p-e pas le meme que le "mettre a jour" du besoin 2, etc... Sans compter que le "ET" veut parfois dire "en meme temps", "seulement si le precedent a marché", ...

Donc je fais un UC independant pour chaque besoin. Pas de relations entre les UC (extends ou autre) avant la phase d'analyse.

La description du "mettre a jour" et son ordonancement sera ecrite dans le scenario. A partir de la, on pourra determiner si le "mettre a jour" est une activité commune ou un specialisation d'une activité plus generale. ET comme je viens de le mentionner, ce sera une activité, donc dans le diagramme idoine.

[Nip]

D'accord avec pseudocode quant a la separation des UCs. Par contre les UC type CRUD sont a regrouper dans un seul et meme UC "gerer" ou "traiter" ou ce que tu veux. Il ne faut pas detailler les UC a ce point: un UC n'est pas une fonction!

[pseudocode]

d'accord aussi avec Nip

Les UC ne sont pas les fonctions que le logiciel sait (saura) faire. Ce sont les "services" que doit (devra) rendre le logiciel pour répondre aux besoins du client. D'ou le terme "cas d'utilisation du logiciel".

Quand au CRUD, a priori il n'en a pas fait dans son schema...

[Nip]

Quand au CRUD, a priori il n'en a pas fait dans son schema...

mmmh c'est parce que j'ai lu en diagonal et que le premier UC decrit est "creer un pret"; reste que beaucoup d'UCs decrits sont de simples fonctions, mais je suis toujours d'accord avec toi pseudocode .

Ces UCs sont a revoir: il ne faut pas chercher a faire compliquer; il est preferable d'avoir des UCs simples (mais pas simpliste). Le document que tu presentes, ukanoldai, est illisible du fait que tu sois trop proche de la fonction.
Pour t'aider je te conseille tres fortement de lire l'intro de ego a ce sujet: http://ego.developpez.com/uml/tutoriel/casUtilisation/

[pseudocode]

Ces UCs sont a revoir: il ne faut pas chercher a faire compliquer; il est preferable d'avoir des UCs simples (mais pas simpliste). Le document que tu presentes, ukanoldai, est illisible du fait que tu sois trop proche de la fonction.
Pour t'aider je te conseille tres fortement de lire l'intro de ego a ce sujet: http://ego.developpez.com/uml/tutoriel/casUtilisation/

Excellent le tutoriel . Je sens que je vais m'en servir pour expliquer 2/3 trucs aux equipes de developpement de ma boite

Et c'est vrai que l'enumeration des fonctions ressemble plus a une solution possible qu'a une description du "besoin" sous-jacent. Mais bon, c'est souvent le cas... Les clients arrivent toujours avec une "solution" sous le bras plutot qu'avec un "probleme".