Comment faire la difference entre un CU Global et un CU Raffiné

[Garrix_dev]

Bonjour a vous ,

je suis a la recherche depuis quelques jours de comment faire la différence entre un Cas d’utilisation Global et un cas d’utilisation Raffiné ?

1. Est-ce que le Cas d’utilisation Global ne doit pas avoir des ‘’ Extends " ?

2. Est-ce que le Cas d’utilisation Global ne doit pas avoir comporter des héritages ?

sinon,comment puis-je faire la différence entre un CU Global et un CU Raffiné ?

je vous prie de ne pas me jetez un lien directement en me demandant de voir et de lire quelques cours UML ou D’autre car j’ai tous fait presque et je n’ai pas trouvé une réponse exacte et direct a mes questions

Merci

[amirouche]

Aucune idee. Je ne sais pas de quoi tu parles. C’est de l’UML avec de l’oriente objet?

[abelar_s]

D’une manière générale tu parles de toutes façons de quelque chose de subtil :

1. quand on spécifie et qu’on documente il y a toujours “vue de loin / vue de près” “vision globale / détails” ou “vision métier / technique”. Je n’ai pas de règle pour te dire si tu es en train d’écrire “trop large” et que je veux des détails ou “trop pointu” et que tu ne devrais pas t’embêter avec ça.

2. tu as un souci avec le mot Use Case parce que tu as une méthodo à la mode (Scrum) et une méthodo un peu plus vieille et solide (UML) qui utilisent tous les deux le même mot, bien entendu pour ne pas définir la même chose. Fais attention entre les Use Case de UML (diagramme de cas d’utilisation, bien définis par UML) et les Use Case de Scrum (User Stories, là aussi bien définis par Scrum)

Ce qui m’embête c’est que je ne comprends pas ton besoin : personne n’a “besoin” de différencier des Use Cases. Tu as besoin de les lire, de les comprendre, de les faire… auquel cas tu peux parler avec les gens pour comprendre leur “vrai” besoin et t’adapter.

Comme tu sembles être “à fond dans la méthodo” je vais supposer que tu es en plein dans le RUP (Rational Unified Process) https://fr.wikipedia.org/wiki/Unified_process et si tu lis le processus et que tu imagines ça dans le temps…

des DCU (Diagrammes de Cas d’Utilisation), on doit tirer les modèles d’analyse, de conception, de déploiement. Ce sont eux qui sont implantés et ce sont les cas d’utilisation prévus qui vont présider à l’élaboration des lignes de tests : les cas d’utilisation doivent finalement être permis par le nouveau logiciel. Les DCU sont les modèles garantissant la cohérence du processus du développement. Ce sont eux qui unifient.

… tu comprends bien qu’on “commence” par parler d’un logiciel en se disant “comment on va l’utiliser” (cas d’utilisation “global” : comment je parle à ma banque par exemple) et que, mine de rien, à un moment, tu dois te poser la question du “détail” (comment on fait, en vrai, devant l’écran d’accueil, pour aller faire un virement).

Peut-être que cette page peut t’aider pour voir les niveaux stratégiques ou autre, et la portée des cas d’utilisation.
https://fr.wikipedia.org/wiki/Cas_d’utilisation#Niveaux_d’objectif

Aussi, les gens qui parlent d’UML eux-mêmes vont te dire que tu peux très bien utiliser UML pour un projet entier, ou bien pour un morceau de projet, voire carrément pour modéliser plusieurs applis/services d’un coup. Le niveau de détail va évidemment s’adapter à chaque cas.

Voilà, je te laisse avec davantage de questions que de réponses mais je pense que ça t’aidera à te positionner :)

[loganm]

Je connais pas les termes de “Global” et “Raffiné” mais cela me rappel les notions “Main” (Principaux), “Alternative” et “Exception” de RUP.

Contrairement à des User Stories qui partent d’un (possible) vécu utilisateur. Par exemple, pour retirer de l’argent tu pourrais prendre le choix par défaut ou saisir un montant personnalisé. Idem tu pourrais te tromper et revenir en arrière.

Dans RUP, les cas principaux sont directs. Dans le cas principal, on suppose que l’utilisateur choisit le choix par défaut, puis effectuer des opérations régulières et que tout se passe bien jusqu’au bout.

Ensuite on introduit les alternatives ou les exceptions. C’est ce qui introduit des sous-ensembles qui seront extend/include.

Il y a également la notion de System Use Case qui définit globalement les interactions entre (sous-)système interne/externe. L’idée était plutôt l’identification des systèmes qui interagissent plus que le détail de leurs interactions.