Discussion :

[Lolo19]

Bonjour à tous,

Je suis en train d'apprendre l'UML en autodidacte. L'UML m'a l'air vraiment utile et j'aimerai vraiment approfondir le sujet. Cependant c'est pas facile du tout !

Bref, je suis en train de réaliser un petit jeu de plateau. Une partie se joue à 2 joueurs en 1 contre 1. Chaque joueur dispose de 6 soldats et chaque soldat peut effectuer l'une des 3 actions suivantes :
- Se déplacer
- Tirer sur un autres soldat
- Soigner un soldat
Le but du jeu étant d'éliminer l'armée adverse.

J'en suis à la phase "cas d'utilisations" et déjà pour ce projet simple j'ai du mal à trouver les acteurs. En fait je me demande si je dois identifier mes cas d'utilisation par rapport à l'acteur joueur ou bien l'acteur soldat. (voire les 2 ?)

L'acteur joueur pourrait donc avoir ces cas d'utilisation:
- Faire une action avec un soldat
- Afficher les informations détaillée d'un soldat
- Discuter avec le joueur adverse

Pour l'acteur Soldat :
- Se déplacer sur le plateau de jeu
- Tirer sur un autre soldat
- Soigner un soldat

En écrivant ces lignes je me dis que peut être est-il intéressant d'avoir ces deux schémas de manière totalement indépendantes.

Qu'en pensez-vous ? Est-ce que je pars sur une mauvaise piste ?

Merci beaucoup

[montesq]

Bonjour à tous,

Je suis en train d'apprendre l'UML en autodidacte. L'UML m'a l'air vraiment utile et j'aimerai vraiment approfondir le sujet. Cependant c'est pas facile du tout !

Bref, je suis en train de réaliser un petit jeu de plateau. Une partie se joue à 2 joueurs en 1 contre 1. Chaque joueur dispose de 6 soldats et chaque soldat peut effectuer l'une des 3 actions suivantes :
- Se déplacer
- Tirer sur un autres soldat
- Soigner un soldat
Le but du jeu étant d'éliminer l'armée adverse.

J'en suis à la phase "cas d'utilisations" et déjà pour ce projet simple j'ai du mal à trouver les acteurs. En fait je me demande si je dois identifier mes cas d'utilisation par rapport à l'acteur joueur ou bien l'acteur soldat. (voire les 2 ?)

Avant de déterminer les cas d'utilisations (et a fortiori les acteurs), il faut que tu répondes clairement à la question:
"quel est le 'système' que je souhaite modéliser?"
La question que tu te poses est symptomatique d'un système pas/mal défini...

[Lolo19]

Bonjour,

Tout d'abord merci de ta réponse. Oui il est clair que c'est un peu flou dans ma tête, je ne suis pas très sûr du système que je veux modéliser.

En gros, voilà comment je vois mon projet :

Il s'agit en fait d'une application web. Une interface est affichée sur laquelle on affiche le plateau de jeu et les soldats qui sont positionnés dessus. Chaque joueur à tour de rôle a le droit d'utiliser un soldat en lui faisant exécuter une des 3 actions possibles.

Donc selon moi le système que je cherche à modéliser est "le déroulement d'une partie". Ou, est-il plus correct de dire que le système que je cherche à modéliser est "L'interface de jeu" ?

D'après ce que je viens de dire comment voyez-vous ça ?

cordialement

[montesq]

Il s'agit en fait d'une application web. Une interface est affichée sur laquelle on affiche le plateau de jeu et les soldats qui sont positionnés dessus. Chaque joueur à tour de rôle a le droit d'utiliser un soldat en lui faisant exécuter une des 3 actions possibles.

Donc selon moi le système que je cherche à modéliser est "le déroulement d'une partie". Ou, est-il plus correct de dire que le système que je cherche à modéliser est "L'interface de jeu" ?

C'est difficile de t'aider sans proposer de solution...
Il est important dans l'étude du système que tu distingues le besoin et la solution.
Quand tu parles d'application web, il s'agit déjà d'une solution. Tu expliques comment satisfaire un besoin du système alors que justement le diagramme des UC permet se focalise sur les besoins du système.
Concernant le système lui-même, je pense qu'il s'agit simplement de modéliser "un jeu de plateau"...
Sachant cela, je penses que tu auras facilement les acteurs, non?

[hegros]

Il faut bien garder en tête qu'un use case c'est comme une classe et que les instances de classes ce sont les scénarios. Si cela est plus facile de partir des scénarios pour déduire les cas et les acteurs je te conseille vivement d'utiliser une approche méthodologique comme RUP.

Une instance de use case (donc un scénario) est écrit sous cette forme plus ou moins formelle : (on peut parler d'échanges conversationnel entre acteurs et système modélisé)

[Acteur][Verbe d'action] texte
Le Système[Verbe d'action] texte

Par exemple

Le joueur se connecte à une partie
Le système présente le plateau avec les unités
Le joueur lance une attaque avec un soldat x sur un ennemi y
Le soldat x tire une flèche sur y
L'ennemi encaisse ou pare l'attaque de x
Le système mets à jour les points de combat et de vie au soldat x et y
..

Une fois décris, à la guise de l'imagination, tu peux facilement extraire les acteurs et les cas d'utilisations. Dans l'idée c'est bien un scénario dans le sens d'une histoire comme si tu racontais ta journée complète donc à un moment tu vas avoir "le joueur chate avec un autre joueur en réseau..."

Il faut par contre que tu saches bien pourquoi tu utilises des use case ?

[Lolo19]

Bonjour,

Merci pour vos réponses. Alors j'ai essayé de faire comme hegros m'a indiqué, à savoir le découpage d'un use case en étapes.

Par exemple pour le déplacement d'un soldat j'ai une série d'étapes comme ceci :

- Le joueur clique sur l'un de ses soldat.
- Le système demande au soldat de combien de cases il peut se déplacer
- Le soldat indique qu'il peut se déplacer de x Cases
- Le système met en surbrillance les cases vers lesquelles le soldat peut se déplacer
- Le joueur clique sur une de ces case
- Le système met à jour la position du soldat.
- Le système rafraichit l'affichage du plateau de jeu.

Alors pour moi, il semble bien y avoir deux Acteurs : Joueur et Soldat. Par contre ce qui m'embrouille un peu c'est que joueur est "humain" et soldat n'en est pas un.

Du coup est-ce correct de représenter le cas que je viens de décrire comme ceci :

Joueur ---- Déplacer Soldat ------ Soldat

Ou au contraire, il ne faut pas faire apparaitre l'acteur soldat.

Merci pour votre aide

[hegros]

Oui cela est correcte dans la mesure où joueur est l'acteur primaire(principal) et le soldat un acteur secondaire. Il peut être intéressant (en restant dans un cadre rup) d'identifier les acteurs qui sont parties prenantes. Par exemple un voleur sur le chemin que doit emprunter un soldat.

Aussi je vois joueur plus comme un acteur abstrait. Celui qui vraiment lancer l'ordre de déplacement de soldat se sera par exemple le capitaine de l'équipe ou de l'armée mais bon là c'est du chipotage pour développer un peu plus le modèle de cas

Garder aussi à l'esprit une approche méthodologique et n'oubliez que le diagramme de classe, de séquence, d'activités et de déploiement (composant)sont des bons supports pour modéliser les cas d'utilisations et réaliser une conception et architecture générale.

[montesq]

Oui cela est correcte dans la mesure où joueur est l'acteur primaire(principal) et le soldat un acteur secondaire.

Non je ne suis *pas* d'accord. Cela dépend évidemment de la définition du système, mais si je comprends bien ton cas, les soldats font clairement parti du système...

Je ne suis pas non plus d'accord avec ta méthodologie:

Si cela est plus facile de partir des scénarios pour déduire les cas et les acteurs

L'écriture des scenarii va plutôt permettre d'isoler les classes métiers de ton système. Or sachant que tu vas trouver dans ta description ET les acteurs ET les classes métiers, tu vas probablement mélanger les uns et les autres (comme dans ce cas)

[hegros]

Non je ne suis *pas* d'accord. Cela dépend évidemment de la définition du système, mais si je comprends bien ton cas, les soldats font clairement parti du système...

Pas d'accord avec toi non plus. On peut voir ou pas le soldat comme un acteur ou pas.

Je ne suis pas non plus d'accord avec ta méthodologie:

Voit cela avec ceux qui ont inventé RUP...

[montesq]

Pas d'accord avec toi non plus. On peut voir ou pas le soldat comme un acteur ou pas.

Pour un système donné, soit le soldat est interne au système dans ce cas là, il apparaît dans ton diagramme de classes. Soit il est externe au système et alors il sera un acteur.
Tout dépend donc du périmètre du système. Personnellement je suis parti du postulat que le système que l'on cherche à modéliser est "un jeu de plateau". Quel est ton système?

Voit cela avec ceux qui ont inventé RUP...

Je ne suis *pas* expert RUP. Toutefois d'après mes différentes lectures
et si je regarde sur la toile, par exemple: http://www.beroux.com/france/documen...rup.php?part=2
les phases résumées sont:
1. Identifier les acteurs et les cas d'utilisation
2. Construire le modèle de cas d'utilisation
3. Décrire la suite d'événements principale menant au succès
4. Identifier les relations
5. Décrire les suites d'événements alternatifs
6. Trouver les objets potentiels (regarder dans les noms)
7. Sélectionner les objets proposés (supprimer: synonymes, hors propos, rôles, non-unique, vague, actions ou attributs)

Donc si tu penses que dans RUP tu peux faire 3. pour avoir 1. et si tu y arrives ainsi, tant mieux pour toi. Mais c'est contre toute logique et contre la méthodologie RUP...

[montesq]

Au passage, rien ne vous interdit de lire les tutoriels du site, en particulier celui-ci : http://ego.developpez.com/uml/tutoriel/casUtilisation/ évoque très spécifiquement la problématique de ce topic...

[Lolo19]

Bonjour tout le monde,

Merci pour vos réponses et pour le lien vers le tutoriel.

En ce qui me concerne, je vois ma modélisation comme ceci :
Système : moteur de jeu
Acteur principal : le joueur
Acteur secondaire : les soldats

Donc si je reprend mon exemple de cas d'utilisation :
Joueur ---- Déplacer un soldat ------ Soldat

Pour moi cela signifie que Joueur participe bien au cas "déplacer un soldat" et que soldat participe également à ce cas d'utilisation. En fait c'est bien le joueur qui demande l'action de déplacement puis le système et le soldat qui vont communiquer ensemble pour échanger des données (point de mouvement restant, position du soldat etc.)

Pour un système donné, soit le soldat est interne au système dans ce cas là, il apparaît dans ton diagramme de classes. Soit il est externe au système et alors il sera un acteur

Je ne suis pas certain d'avoir compris cette phrase, que veux tu dire par "interne au système ?"

Encore une fois, merci pour votre aide

[montesq]

Je ne suis pas certain d'avoir compris cette phrase, que veux tu dire par "interne au système ?"

Oui, je vois très bien (depuis ma commentaire #2) que tu n'as pas compris/saisis la notion de système. Or, si on ne sait pas définir le système et son périmètre, on est certain de ne pas identifier les bons acteurs, puisque par définition les acteurs sont les entités qui interagissent avec le système!

Prenons un exemple: une application web. Si ton appli web se limite à la consommation de web-services provenant d'autres systèmes alors il faut considérer l'utilisateur ET les systèmes hébergeant les web-services comme des acteurs du système.
Par contre, si ton application web est constituée d'une partie métier et d'une base de données alors tout cela forme ton système et il n'y a plus qu'un acteur qui est l'utilisateur.

Quand tu fais ton diagramme d'UC, il faut considérer le système comme une boîte noire et tu expliques pourquoi les acteurs utilisent cette boîte noire.

[hegros]

Pour un système donné, soit le soldat est interne au système dans ce cas là, il apparaît dans ton diagramme de classes. Soit il est externe au système et alors il sera un acteur.
Tout dépend donc du périmètre du système. Personnellement je suis parti du postulat que le système que l'on cherche à modéliser est "un jeu de plateau". Quel est ton système?

C'est un jeu manifestement comme système, je pars du principe qu'un soldat est potentiellement un joueur (en réseau) et comme le joueur est un acteur sans aucun doute alors un soldat est aussi un acteur.

je disais plutôt oui à la question postée par le PO de modéliser un soldat comme un acteur sans l'exclure pour autant de le modéliser ou/et aussi comme un concept ce qui laisserait apparaître dans un diagramme de classe beh 2 classes avec le même nom sauf que l'un stéréotypé en actor et l'autre en entity


Je ne comprends pas pourquoi tu cherches à savoir ce qui est interne au système, nous sommes ici en boîtes noir d'ailleurs dans le scénarii c'est très explicite la différentiation( puisque c'est du conversationnel entre le système et les acteurs)

Donc si tu penses que dans RUP tu peux faire 3. pour avoir 1. et si tu y arrives ainsi, tant mieux pour toi. Mais c'est contre toute logique et contre la méthodologie RUP...

En fait RUP c'est une méthodologie fondée sur des bests pratices et l'esprit agile donc l'ordre n'a aucune importance, c'est conventionnel. Je te conseille de prendre plutôt comme référence le site de IBM tant qu'à faire

C'est très rigide, et contraire à rup, comme vision de dire que l'ordre à de l'importance et que mettre 3 à la place de 1 est illogique au contraire c'est tout à fait réaliste car dans une approche utilisant RUP il est illogique de suivre toute la méthode que se soit toutes les étapes ou dans l'ordre et d'autant plus en ce qui concerne de fournir les artifacts.

[montesq]

C'est un jeu manifestement comme système, je pars du principe qu'un soldat est potentiellement un joueur (en réseau) et comme le joueur est un acteur sans aucun doute alors un soldat est aussi un acteur.

Il a dit qu'il s'agissait d'un jeu de plateau, donc, à ma connaissance des jeux de plateau, un joueur n'est pas un soldat...

je disais plutôt oui à la question postée par le PO de modéliser un soldat comme un acteur sans l'exclure pour autant de le modéliser ou/et aussi comme un concept ce qui laisserait apparaître dans un diagramme de classe beh 2 classes avec le même nom sauf que l'un stéréotypé en actor et l'autre en entity

1° Quel intérêt de faire figurer un acteur dans un diagramme de classes?
2° On va éviter de donner le même nom à des choses qui correspondent à des concepts différents...

Je ne comprends pas pourquoi tu cherches à savoir ce qui est interne au système, nous sommes ici en boîtes noir d'ailleurs dans le scénarii c'est très explicite la différentiation( puisque c'est du conversationnel entre le système et les acteurs)

J'essaye d'expliquer -a priori maladroitement, même si je pense que tu fais une erreur d'interprétation de l'énoncé- que le soldat ne peut être un acteur du système (puisqu'interne au système).

En fait RUP c'est une méthodologie fondée sur des bests pratices et l'esprit agile donc l'ordre n'a aucune importance, c'est conventionnel. Je te conseille de prendre plutôt comme référence le site de IBM tant qu'à faire

C'est très rigide, et contraire à rup, comme vision de dire que l'ordre à de l'importance et que mettre 3 à la place de 1 est illogique au contraire c'est tout à fait réaliste car dans une approche utilisant RUP il est illogique de suivre toute la méthode que se soit toutes les étapes ou dans l'ordre et d'autant plus en ce qui concerne de fournir les artifacts.

Ca c'est ce que tu penses parce que tu as déjà une certaine expérience en modélisation et que tu n'as pas besoin de formaliser la définition/périmètre du système, la définition des acteurs, les UC, l'identification des classes métiers...
Mais pour un débutant qui a besoin de comprendre l'enchaînement des étapes, il est nécessaire de suivre le schéma indiqué. Car si le système n'est pas défini, l'authentification des acteurs sera probablement incohérente.
Si on a pas les bons acteurs, on aura assurément pas non plus les bons UC...

Demande à un débutant de faire un diagramme des classes d'une application sans les autres diagrammes précédents: pas de problème, il va te faire des rectangles partout avec des noms de classe et des attributs. Pourtant est-ce qu'il est sûr que les classes identifiées sont les bonnes et sont exhaustives, que les relations entre classes sont les bonnes...
Si on suit l'ordre que j'ai donné précédemment (et si les étapes sont données dans cet ordre, c'est qu'il y a bien une logique!) alors il sera plus simple au débutant de comprendre le cheminement intellectuel de la modélisation qui consiste ni plus ni moins à exprimer dans un premier temps les besoins du système et ensuite à concevoir une solution "logicielle" adaptée.

[hegros]

Il a dit qu'il s'agissait d'un jeu de plateau, donc, à ma connaissance des jeux de plateau, un joueur n'est pas un soldat...

Comme expliqué précédemment, pour ma part, un joueur ce n'est qu'un acteur abstrait. En jouant à certains jeux certes je me connecte en tant que joueur mais je choisis bien mon rôle (soldat, fée, mort vivants, etc...) hors en UML les acteurs correspondent à des rôles pas à des personnes physiques(comme le serait ici dans notre cas le joueur plus que le soldat)

Je ne suis pas convaincu que cette divergence change grand chose au modèle final, tu peux toujours t'amuser à nous expliquer le delta du changement

1° Quel intérêt de faire figurer un acteur dans un diagramme de classes?

Et quel intérêt de ne pas le faire figurer ?

2° On va éviter de donner le même nom à des choses qui correspondent à des concepts différents...

Un soldat qui soit acteur ou pas cela reste le même concept, ce ne sont pas des choses différentes...

J'essaye d'expliquer -a priori maladroitement, même si je pense que tu fais une erreur d'interprétation de l'énoncé- que le soldat ne peut être un acteur du système (puisqu'interne au système).

Je ne vois pas ce qui te permet de conclure qu'un soldat est interne au système alors que l'on ne regarde pas à l'intérieur du système (boîte noir)

Mais pour un débutant qui a besoin de comprendre l'enchaînement des étapes, il est nécessaire de suivre le schéma indiqué.

...

Si on suit l'ordre que j'ai donné précédemment (et si les étapes sont données dans cet ordre, c'est qu'il y a bien une logique!) alors il sera plus simple au débutant de comprendre le cheminement intellectuel de la modélisation

Je ne pense pas qu'il faut être rigide, même (surtout) en étant débutant pour suivre un plan à la lettre c'est relativement absurde et personne ne le fait vraiment.

Dans l'esprit de la méthode on peut faire un peu de l'étape 1 (sans la finir complètement) puis sauter la 2 et passer au 3. En avançant un peu la 3 on se débloque un peu la 2 et un peu plus le 1 etc...et au final on finit toutes les étapes. Je préfère indiquer cette possibilité méthodologique pour aider quelqu'un sur le forum à avancer son projet plutôt que de lui dire finit d'abord parfaitement toute l'étape 1 avant de passer à la 2 etc...


De plus les étapes que tu as donné sont sorti de nulle part, tu as pris quelle phase l'inception ou l'élaboration ? Bref, ces étapes ne correspondent vraiment pas à un cas de développement pratique RUP, les écrans ne sont même pas présents ! (de plus la site que tu donnes n'est franchement pas une référence surtout lorsque c'est écrit métodologie à la place de méthodologie)


C'est cela à mon sens qui est nécessaire d'apprendre aux débutants (et aux plus expérimentés)pour qu'ils comprennent bien que l'enchaînement n'est pas séquentiel (sauf en théorie sur le papier)comme dans les cycles en cascades

[Lolo19]

Bonjour,

Oui attention, il faut bien faire la distinction, nous avons le joueur qui est en fait l'utilisateur qui est en train de jouer au jeu et les soldats qui sont des pièces du jeu placées sur le plateau.

J'en suis arrivé à deux schémas qui me semble aussi bien correct l'un que l'autre, c'est ça le problème

Un soldat étant en quelques sorte une pièce du jeu, il fait donc parti du système. Donc dans mon 2ème schéma je ne l'ai pas représenté comme acteur. Mais du coup je trouve que c'est moins clair car on perd l'information comme quoi le système communique avec un soldat.

Que pensez-vous de ces deux premiers schéma ?

Autre question : Est-il intéressant d'ajouter un cas d'utilisation "Sélectionner un Soldat" ?
En effet, je trouve que c'est une actions trop simple (l'utilisateur clique sur un soldat) mais qu'en j'y pense cette actions cache en fait plusieurs étapes importantes (ex : Affichage des actions possibles, affichage des informations du soldat, mise en surbrillance des cases de déplacement etc.)

Merci beaucoup

bon week-end

[montesq]

Comme expliqué précédemment, pour ma part, un joueur ce n'est qu'un acteur abstrait. En jouant à certains jeux certes je me connecte en tant que joueur mais je choisis bien mon rôle (soldat, fée, mort vivants, etc...) hors en UML les acteurs correspondent à des rôles pas à des personnes physiques(comme le serait ici dans notre cas le joueur plus que le soldat)

Je ne suis pas convaincu que cette divergence change grand chose au modèle final, tu peux toujours t'amuser à nous expliquer le delta du changement

Le problème c'est que tu penses à un jeu de rôle alors que Lolo19 parle d'un jeu de plateau type risk ou colonisation... Relis le sujet du topic, regarde tout cela d'un oeil nouveau et après on en reparle...

Et quel intérêt de ne pas le faire figurer ?

Parce que ce n'est pas le rôle du diagramme de classes qui doit représenter les classes du système! Et donc pas de ce qui est externe au système...

Un soldat qui soit acteur ou pas cela reste le même concept, ce ne sont pas des choses différentes...

Ill y en a un qui est externe au système et l'autre qui est interne... Donc ce n'est pas du tout la même chose.

Je ne pense pas qu'il faut être rigide, même (surtout) en étant débutant pour suivre un plan à la lettre c'est relativement absurde et personne ne le fait vraiment.

Dans l'esprit de la méthode on peut faire un peu de l'étape 1 (sans la finir complètement) puis sauter la 2 et passer au 3. En avançant un peu la 3 on se débloque un peu la 2 et un peu plus le 1 etc...et au final on finit toutes les étapes. Je préfère indiquer cette possibilité méthodologique pour aider quelqu'un sur le forum à avancer son projet plutôt que de lui dire finit d'abord parfaitement toute l'étape 1 avant de passer à la 2 etc...

Oui ça s'appelle travailler de manière itérative. N'empêche que tu suis bien le chemin 1, 2, 3... même si rien ne t'empêche d'itérer et revenir aux étapes précédentes pour revoir/affiner ta modélisation.

De plus les étapes que tu as donné sont sorti de nulle part, tu as pris quelle phase l'inception ou l'élaboration ? Bref, ces étapes ne correspondent vraiment pas à un cas de développement pratique RUP, les écrans ne sont même pas présents ! (de plus la site que tu donnes n'est franchement pas une référence surtout lorsque c'est écrit métodologie à la place de méthodologie)

C'est cela à mon sens qui est nécessaire d'apprendre aux débutants (et aux plus expérimentés)pour qu'ils comprennent bien que l'enchaînement n'est pas séquentiel (sauf en théorie sur le papier)comme dans les cycles en cascades

Le site que je t'ai fourni (pris sur la première page google sur la méthodo rup) n'est pas le seul à préconiser cette succession des étapes.
Lis des livres sur UML, par exemple ceux de Pascal Roques (qui est quand même l'un des gurus fr sur le sujet):
- [ame="http://www.amazon.fr/UML-action-lanalyse-besoins-conception/dp/2212121040/ref=sr_1_1?ie=UTF8&qid=1296326580&sr=8-1"]UML 2 en action : De l'analyse des besoins à la conception: Amazon.fr: Pascal Roques, Franck Vallée, Pierre-Alain Muller: Livres@@AMEPARAM@@http://ecx.images-amazon.com/images/I/41DuvwSnNTL.@@AMEPARAM@@41DuvwSnNTL[/ame]
- [ame="http://www.amazon.fr/UML-Mod%C3%A9liser-une-application-web/dp/2212121369/ref=sr_1_1?ie=UTF8&qid=1296326628&sr=1-1"]UML 2 : Modéliser une application web: Amazon.fr: Pascal Roques: Livres@@AMEPARAM@@http://ecx.images-amazon.com/images/I/516a29BALfL.@@AMEPARAM@@516a29BALfL[/ame]
ou bien encore le cours de Laurent Audibert sur ce même site:
- http://laurent-audibert.developpez.c...tml/index.html

Tous utilisent cet ordre:
- définition du système
- définition des acteurs
- identification des UC
- descriptions des UC (scénarii)
- diagramme de classes

[hegros]

Il me semble avoir clairement exprimé ma pensée : les 2 sont acceptables d'un point de vue modélisation. La question est qui va lire ces diagrammes ? Et plus généralement quel objectif a t-il dans ton approche de développement ?

Si tu es le seul à le lire alors utilise celui qui est le plus parlant pour toi sinon utilises celui qui sera le plus parlant pour le lecteur.

Oui c'est intéressant le cas "sélectionner un soldat" car c'est un cas qui représente un processus élémentaire du système(jeu) et comme on le devine assez bien cache plusieurs étapes. Une fois de plus tu peux décrire les scénarios(ou les modéliser avec un diagramme d'activité) de ce cas autant dire ce que tu cites tu peux ajouter des maquettages écrans

[hegros]

Le problème c'est que tu penses à un jeu de rôle alors que Lolo19 parle d'un jeu de plateau type risk ou colonisation... Relis le sujet du topic, regarde tout cela d'un oeil nouveau et après on en reparle...

Oui aussi mais tu confonds modélisation avec une méthode comme rup et modélisation avec UML dont l'identification des acteurs n'est pas aussi formelle. Le PO n'utilise pas RUP à la base, je lui propose comme support

Oui ça s'appelle travailler de manière itérative. N'empêche que tu suis bien le chemin 1, 2, 3... même si rien ne t'empêche d'itérer et revenir aux étapes précédentes pour revoir/affiner ta modélisation.

Pas seulement, tu peux complètement ne pas réaliser certaines étapes et certains artifacts. Chercher à réaliser toutes les étapes et tous les artifacts est une absurdité

Tous utilisent cet ordre:
- définition du système
- définition des acteurs
- identification des UC
- descriptions des UC (scénarii)
- diagramme de classes

Je n'ai pas l'impression que tu maîtrise ce dont tu parles. Tu parles de l'ordre de quoi de quelle phase ? Tu as lu le support présent sur le site de IBM ?

Parce que là c'est un peu un mélange de tout, que vient faire un diagramme de classe dans une étape c'est un artifact réalisé en paralléle de la description des uc.

Donc désolé mais je ne reconnais pas ce dont tu cites avec un ordre précis et des noms de phases et étapes imprécises.

PS : j'ai lu nombres d'ouvrages sur rup notamment par ceux qui l'ont inventé et l'ont mis en pratique de même que j'ai une expérience avec. Je mettrais une liste ou une ou deux références ou une description des phases tirés de la bibliothèques best pratices de ibm. Pascal roques ne fait pas parti de ceux dont j'ai tiré le meilleur parti de uml et encore moins de rup..