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 ?