Discussion :

[emmesse]

bonjour,

ce diagramme est-il bon ?

[bruno_pages]

bon à quel niveau ?

• s'il respecte la specification UML ?
• ou s'il est sémantiquement bon, mais pour cela il faudrait nous décrire ce que vous voulez modéliser

vos intitulés sont difficiles à lire avec les mots collés les uns aux autres, ajouter des espaces ou '_' s.v.p.

[emmesse]

s'il respecte la spécification UML ?

mis à part que les lignes de vie sont pointillées du haut jusqu'en bas (je l'ai fait avec plantuml), c'est ce que je voudrais savoir.
sinon, la sémantique aussi (j'ai voulu modéliser le tour d'un joueur du jeu cashflow)
qu'en pensez-vous?

[bruno_pages]

Au niveau notation

les lignes de vie sont pointillées du haut jusqu'en bas

c'est parfaitement légal, c.f. § 17.3.4.1 Lifeline page 572 de formal/2017-12-05 :

A Lifeline is shown using a symbol that consists of a rectangle forming its “head” followed by a vertical line (which
may be dashed) that represents the lifetime of the participant

Par contre la répétition des lifeline class/instance en bas est elle illégale, et je ne vois pas son utilité hormis dans le dans le cas où le diagramme est très haut c'est à dire en fait trop haut et donc difficile à lire, ce qui est le cas du vôtre

De façon générale sans l'affichage des ExecutionSpecification (voir § 17.2.4.4 page 569 de formal) et en utilisant une numérotation à un seul niveau il est impossible d'être certain de l'enchaînement des messages. Par exemple le message 32 est-il la conséquence du message 31 ou n'y a-t-il aucun rapport entre les deux ?

Au niveau sémantique

Je ne connais par le jeu cashflow dont les règles précises ne sont sans doute pas toujours les mêmes, donc difficile de vérifier en détail votre diagramme au niveau sémantique.

Par contre :

• les messages sont exécutés par le receveur et non l'émetteur, et donc par exemple lancer les dés(...) est demandé au dés eux même, ce qui est quelque peu bizarre puisque les dés sont lancés par le joueur. Le fait même que vous jugez utile de mettre le nom du receveur dans les messages montre qu'il y a un problème, le récepteur sait qui il est, pas besoin de le lui dire.
  
• Les libellés des message de retour sont également problématiques.Par exemple lancé des dés n'est pas judicieux, ce n'est pas leur lancé en eux même qui nous intéresse mais les résultats obtenus. Pareil dans le cas de demander si jour de paye, on s'attend à une réponse oui/non mais le résultat semble être le jour de paye lui même, ce qui n'est pas compatible avec le message initial qui devrait alors être quel est le jour de paye.

[emmesse]

Merci pour ces explications.

en ce qui concerne la répétition de l'instance en bas, je n'y peux rien, c'est plantuml qui fait ça.

jour_de_paye est bien un booléen. Je l'ai renommé en oui_non_jour_de_paye afin que l'on comprenne mieux.

qu'en pensez-vous comme ceci ? :

[bruno_pages]

comme je l'ai déjà dit le diagramme est trop complexe, il doit être découpé en plusieurs ou simplifié en retirant ce qui n'est pas pertinent (s'il y a lieu)

vous n'avez pas tenu compte du fait que les messages vers "X" contiennent à tord "X" dans leur intitulé, et pareil les réponses de "X" n'ont pas à dire qu'elles viennent de "X"

le fait que la réponse de demander_si_jour_de_paye contienne les deux réponses possibles (oui et non) est invalide, une interaction décrit un cas concret d'exécution, si je fais le parallèle avec les classes on n'est pas au niveau diagramme de classe mais au niveau diagramme d'instances.

la numérotation de vos messages laisse à penser que tout ce que fait le joueur partenaire n'a aucun rapport avec ce que fait le joueur (principal), et j'en doute fort.

vos différent tas de carte sont vraiment bizarres, il y a vraiment un tas de carte de grosses opportunités et un autre de petites opportunités et un autre de marchés et un autre d'imprévus ?

[emmesse]

Bon, je vais y aller petit peu par petit peu
que penses-tu de ça ?
(déjà, j'abandonne plantuml pour umlet)

[emmesse]

il y a bien 4 tas

[emmesse]

2 joueurs qui jouent sur la même carte ne jouent pas ensemble

[emmesse]

puis-je dire "eurêka !" ?

[emmesse]

que penses-tu de ça ?

[emmesse]

au final, se-peut-il que cela soit comme ça ?

[bruno_pages]

J'ai honte de ne pas l'avoir fait, mais la 1ère chose que j'aurais dû penser à vous demander c'est de savoir quel est le but de votre diagramme, ce que voulez-vous modéliser, à priori je dirai un exemple d'utilisation vue du joueur humain ou non.

Bon, je vais y aller petit peu par petit peu
que penses-tu de ça ?

Ici comme ailleurs, *joueur* semble-être la classe représentant un joueur dans le jeu, pas la personne (vous par exemple) qui être en train de jouer et d'interagir avec le jeu via les boutons ou autre.

• si c'est le cas cela pose un certain problème car en faire un acteur le place par définition en dehors du système modélisé, qui est donc le jeu sans ce qui représente le joueur dans le jeu, ce qui est vraiment artificiel
• si par contre l'acteur joueur vous représente alors il y a un autre problème, car cela veut dire que c'est bien vous qui faites les différentes actions et donc avez un attribut tour_rédaction_personnel ou avez un nouvel enfant par exemple, et j'ai vraiment du mal à y croire.

Le plus probable est donc que ce joueur ne soit pas un acteur mais une classe comme une autre. J'en profite pour vous dire que je vous recommande d'utiliser une majuscule au début de chaque (sous) mot nommant vos classes.

Mais peut être faut-il aussi avoir un acteur représentant un joueur humain. C'est le cas si le déroulement du jeu peut dépendre de décision du joueur, s'il y a des phases du jeu où on a le choix entre plusieurs actions. Je ne parle pas du résultat d'un lancé de dés, le joueur doit lancer les dés (avec des vrais ou des faux et le jeu fait le tirage une fois que le joueur a appuyé sur un bouton par exemple), mais par exemple du fait que le joueur peut soit lancer les dés soit tirer une carte etc.

Concernant ce diagramme il est clair que vu que tour_réduction_personnel est non nul alors il vaut obligatoirement 1 car dès qu'il vaut 2 il est remis à 0 => le second opt est inutile car obligatoirement effectué. Au final l'utilité de la chose m'échappe donc et il doit y avoir ailleurs quelque chose permettant à tour_réduction_personnel de ne pas être nul, ce qui manque si le diagramme final est complet, mais il ne reprends pas ce sous diagramme.

puis-je dire "eurêka !" ?

oui peut être si cela est compatible avec les règles du jeu, c'est juste un peu bizarre si on est sensé faire parti du personnel remercié, ou alors il s'agit de chômage technique temporaire sur un tour.

que penses-tu de ça ?

pourquoi pas, si c'est compatible avec les règles

au final, se-peut-il que cela soit comme ça ?

• je ne vois pas la conséquence de l'activation de la charité pendant trois tours, ne devrait-il pas y avoir un opt [charité active] ou un truc du genre ?
• tirer une carte cette fois c'est plutôt une action demandé par un vrai acteur (vous) que par la classe acteur interne au système, mais bon ce n'est pas rédhibitoire, sauf si comme je l'ai dit au départ il doit y avoir véritablement un acteur joueur qui vous représente.
  [*tas imprévu etc c'est quand même pas fantastique comme nom, trouver autre chose, surtout qu'il s'agit d'un gestionnaire à qui on peut demander une action et peut en déclencher sur d'autres classes
• il semble qu'umlet ne sache gérer qu'un niveau d' ExecutionSpecification, c'est bien dommage car cela retire des informations et nous laisse supposer des choses.
• lorsque les deux joueurs sont impliqués, ils doivent impérativement effectuer leur action l'un après l'autre, ou il peuvent faire en parallel mais à priori il faut que les deux finissent avant de pouvoir continuer ?

[emmesse]

je peux appeler Pile_cartes_imprévus?

c'est un tour de jeu une fois que les dés sont lancés. La charité permet de lancer deux dés au lieu d'un. opt charité sera placé au niveau du lancé de dés

réduction personnel, c'est le chômage technique.

les 2 joueurs jouent l'un après l'autre

[bruno_pages]

je peux appeler Pile_cartes_imprévus?

c'est effectivement plus une pile qu'un tas (ou des cartes pourraient être les une à côté des autres), mais à part cela je ne voit pas la différence entre les deux. Encore une fois je vois plutôt un gestionnaire, n'oublier pas que la 'chose' peut effectuer des action et en demander à d'autre, une pile ce ne sait faire que push/pop/top

c'est un tour de jeu une fois que les dés sont lancés. La charité permet de lancer deux dés au lieu d'un. opt charité sera placé au niveau du lancé de dés

ok, mais peut être plutôt *loop* (avec la bonne portée) que *opt* si finalement le joueur joue deux tours d'affilé

réduction personnel, c'est le chômage technique.

ok, chômage partiel serait donc plus clair

les 2 joueurs jouent l'un après l'autre

je parle de chose comme effectuer opportunité

[emmesse]

c'est effectivement plus une pile qu'un tas (ou des cartes pourraient être les une à côté des autres), mais à part cela je ne voit pas la différence entre les deux. Encore une fois je vois plutôt un gestionnaire, n'oublier pas que la 'chose' peut effectuer des action et en demander à d'autre, une pile ce ne sait faire que push/pop/top

c'est bien une classe avec un vector de carte qui donne un numéro de carte, l'objet imprévus et son coût

ok, mais peut être plutôt *loop* (avec la bonne portée) que *opt* si finalement le joueur joue deux tours d'affilé

non, le joueur sous l'éfet de la charité lance deux dés en une seule fois, à chacun des trois tours (il doit attendre que les autres ayent fini leur tour pour relancer les deux dés), si il le désire. Je verrai plustôt un attribut entier charité qui indique le nombre de tours restant en charité et un booléen pour son désir de lancer deux dés.

je parle de chose comme effectuer opportunité

oui tu as raison, la carte n'indique pas la même opprtunité selon qu'il soit lanceur de dés ou un autre. J'ai pensé mettre un numéro à la carte qui indiquerai dans l'objet joueur ce qu'il doit faire, ça risque d'être un peu fastidieux à implémenter, mais je relève.

[emmesse]

qu'en penses-tu ?

[bruno_pages]

Le diagramme est arbitrairement trop haut à cause d'espaces vides inutiles, c'est aussi le cas en largeur même s'il y a moins de gachi dans le diagramme mais par contre une immenses marge gauche dans l'image, à cause de cela je suis obligé de scroller quand je le regarde à l'échelle 1 (zoom = 100%), si ce n'est pas la même chose pour vous c'est que vous avez un écran d'un mètre de haut. Un diagramme c'est quand même fait pour être vu !

Typo : il manque un 'r' dans Carte grosse opportunité

L'autre joueur est certainement un Joueur lui aussi, pas une instance de la classe tout_autre_joueur, au lieu de changer de nom de classe, changer de nom d'instance, initialement c'était un partenaire (mais via un acteur ce qui n'était pas correct)

objet et prix de l'imprévu est une valeur de retour, dessinez le comme tel

Attention à la hauteur de vos rectangles pour les ExecutionSpecification, ce n'est pas que du 'dessin', elles font parti du langage UML et il y a une sémantique associée

• puisque vos messages sont synchrones il est impossible que l'exécutions d'effectuer opportunité se terminent avant celle des Cartes X opportunité
• celle du cas case marché déborde dans le cas case opportunité

[emmesse]

que penses-tu de ceci ?

[emmesse]

certaines lignes de vie s'interrompent sur le graphique, mais pas dans ma tête,
umlet a tout effacé, je dois le refaire à nouveau. J'ai l'intention de faire des cadres d'interactions (sd dans le cartouche), un par type de case, et de les référencer dans le reste du tour après déplacement du pion, lorsqu'il arrive sur une case.