Analyse des interactions dans Monopoly : règles de tour, prison et scénarios variés

Ce document présente un examen portant sur l’analyse et la conception orientées objet appliquées à un jeu simplifié de Monopoly. Il évalue les compétences en modélisation UML, en analyse des besoins, en conception de diagrammes de classes, de séquences, d’activités et d’états, ainsi qu’en application de patrons de conception.

D'après le document Analyse des interactions dans Monopoly : règles de tour, prison et scénarios variés

Cet article a été rédigé automatiquement à partir du document source, puis vérifié avant publication.

Document source

Afficher l'aperçu du document

Consulter le document original →

Ce document présente un examen portant sur l’analyse et la conception orientées objet appliquées à un jeu simplifié de Monopoly. Il évalue les compétences en modélisation UML, en analyse des besoins, en conception de diagrammes de classes, de séquences, d’activités et d’états, ainsi qu’en application de patrons de conception.

Partie 1 : Expression des besoins (7 pts)

Question 1.1

Il s'agit de compléter les relations entre l’acteur « joueur » et les cas d’utilisation « Jouer son tour », « Vendre » et « Acheter », puis de décrire différents scénarios possibles en langage naturel, en tenant compte notamment de la prison.

1) Relations entre acteur et cas d’utilisation :

  • Le joueur est l’acteur principal qui interagit avec les cas d’utilisation.
  • Le cas « Jouer son tour » inclut potentiellement les cas « Acheter » et « Vendre » car durant un tour, un joueur peut acheter des propriétés ou vendre des constructions.
  • Les cas « Acheter » et « Vendre » sont liés au joueur qui décide de ces actions.

2) Description sommaire des scénarios :

  • Scénario nominal du cas « Jouer son tour » : Le joueur lance deux dés et avance son pion du total obtenu dans le sens des aiguilles d’une montre. S’il obtient un double, il réalise l’action liée à la case d’arrivée (payer loyer, tirer une carte chance, payer un impôt, etc.), puis relance les dés et avance à nouveau. Ce processus se répète tant qu’il obtient des doubles. S’il fait un double trois fois de suite ou s’il arrive sur la case « Allez en prison », il est envoyé immédiatement en prison, son tour s’arrête, il ne franchit pas la case « Départ » et ne reçoit pas 20 000 euros.
  • Visite simple de la prison : Si un joueur arrive sur la case « Prison » sans y être envoyé, il est en simple visite, sans pénalité, et peut jouer normalement au tour suivant.
  • Sortie de prison par double : Un joueur emprisonné peut sortir s’il obtient un double dans l’un des trois tours suivant son arrivée en prison. Il avance alors du nombre de cases indiqué par les dés, puis relance les dés et rejoue comme un joueur ayant obtenu un double.
  • Sortie de prison par paiement : Si le joueur n’a pas obtenu de double après trois tours, il paie une amende de 5 000 euros, avance du nombre de cases indiqué par les dés et continue son tour.
  • Achat d’une propriété : Lorsqu’un joueur s’arrête sur une case terrain sans propriétaire et dispose du capital nécessaire, il peut choisir de l’acheter.
  • Achat de maisons : Si un joueur possède tous les terrains d’un groupe de couleur, il peut acheter jusqu’à 4 maisons par terrain, à tout moment durant son tour, selon sa fortune.
  • Construction d’un hôtel : Si un joueur possède 4 maisons sur chaque terrain d’un groupe et souhaite construire un hôtel, il échange les 4 maisons d’un terrain contre un hôtel, paie le prix indiqué sur le titre de propriété et place l’hôtel sur ce terrain.
  • Revente : Durant son tour, un joueur peut revendre au prix d’achat des constructions, terrains nus, gares ou compagnies de distribution.

3) Diagramme de séquence système pour le scénario nominal « Jouer son tour » :

Le diagramme met en scène les interactions suivantes :

  • Le joueur lance les dés.
  • Le système calcule la nouvelle position du pion.
  • Le système exécute l’action liée à la case d’arrivée (payer, tirer carte, etc.).
  • Si le joueur a fait un double et n’a pas fait trois doubles consécutifs, il relance les dés et répète le processus.
  • Si le joueur fait trois doubles consécutifs ou arrive sur la case « Allez en prison », il est envoyé en prison et son tour se termine.

Réponse finale : Le scénario nominal est une boucle de lancer de dés, déplacement, exécution d’action, avec gestion spécifique des doubles et de la prison.

Question 1.2

Proposition d’un diagramme d’activités illustrant la dynamique du jeu Monopoly :

  • Début du tour
  • Lancer des dés
  • Avancer le pion
  • Vérifier la case d’arrivée :
    • Si « Allez en prison » ou triple double → envoyer en prison et fin du tour
    • Sinon exécuter action de la case (payer loyer, tirer carte, etc.)
  • Si double obtenu et pas trois doubles consécutifs → relancer les dés (retour à « Lancer des dés »)
  • Sinon fin du tour

Réponse finale : Le diagramme d’activités doit représenter la boucle des doubles, les conditions d’envoi en prison, et les actions liées aux cases.

Partie 2 : Analyse (7 pts)

Question 2.1

Il faut compléter le diagramme de classes en ajoutant les cardinalités manquantes, promouvoir les associations en compositions ou agrégations, et modéliser la classe « Dé ».

1) Cardinalités manquantes :

Le document ne fournit pas explicitement les cardinalités manquantes, il faut donc les déduire :

  • Un Jeu possède un Plateau (cardinalité 1).
  • Un Plateau contient plusieurs Cases (cardinalité 1..*).
  • Un Jeu contient plusieurs Joueurs (cardinalité 2..*).
  • Un Jeu contient plusieurs Groupes (cardinalité 1..*).
  • Un Joueur possède plusieurs Propriétés (cardinalité 0..*).
  • Une Propriété appartient à un seul Groupe (cardinalité 1).

2) Composition ou agrégation :

Association Composition Agrégation Justification
Jeu - Plateau X Appartenance totale, cycles de vie dépendants : le plateau n’existe pas sans le jeu.
Plateau - Case X Les cases appartiennent au plateau mais peuvent être considérées comme indépendantes.
Case - Joueur X Le joueur appartient au jeu, pas à une case : appartenance faible.
Jeu - Groupe X Appartenance totale, cycles de vie dépendants.
Jeu - Joueur X Le joueur appartient au jeu, pas en composition stricte.
Joueur - Propriété X Il n’y a pas de notion d’appartenance stricte, donc association simple.
Propriété - Groupe X Les propriétés appartiennent au plateau et aussi aux groupes.

3) Modélisation de la classe « Dé » :

Il faut ajouter une classe « Dé » représentant le dé à deux faces (ou deux dés). Cette classe est liée au Jeu et au Joueur :

  • Le Jeu possède une instance de Dé (composition).
  • Le Joueur utilise le Dé pour lancer les dés durant son tour.

4) Représentation des trois énoncés :

  1. (a) Un joueur est en simple visite de la prison ou emprisonné :

Non, le diagramme ne le permet pas. Il faut ajouter un attribut dans la classe Joueur précisant l’état (simple visite, emprisonné, normal).

  1. (b) À partir d’une propriété, connaître les autres propriétés du même groupe appartenant au même joueur :

Le diagramme permet cette navigation via les associations Propriété-Groupe et Joueur-Propriété, en suivant les liens pour vérifier la possession.

  1. (c) Le nombre de constructions sur un terrain :

Le diagramme ne le précise pas explicitement. Il faudrait ajouter un attribut ou une classe associée à Propriété pour stocker le nombre de constructions.

Question 2.2

Représenter un diagramme d’objets illustrant la situation suivante :

  • Joueur 1 : Ali, possède la gare du Nord, la gare de Lyon, la propriété Belleville, est sur la case Compagnie des eaux.
  • Joueur 2 : Zied, possède les compagnies d’électricité et des eaux, est sur la case Départ.

Le diagramme d’objets doit montrer :

  • Instances des joueurs Ali et Zied.
  • Instances des propriétés possédées par chaque joueur.
  • Instances des cases où se trouvent les joueurs.
  • Instances des groupes concernés (gares, compagnies, groupe de Belleville).

Réponse finale : Le diagramme d’objets illustre les liens de possession et la position des joueurs sur le plateau, en ne représentant que les instances concernées.

Question 2.3

Donner un diagramme d’état-transition illustrant l’évolution de l’état d’un joueur.

États possibles :

  • Normal
  • Simple visite de la prison
  • Emprisonné

Transitions :

  • De Normal à Emprisonné : si le joueur fait trois doubles consécutifs ou arrive sur la case « Allez en prison ».
  • De Normal à Simple visite : si le joueur arrive sur la case Prison sans y être envoyé.
  • De Emprisonné à Normal : si le joueur fait un double dans les trois tours suivants ou paie l’amende au troisième tour.
  • De Simple visite à Normal : au tour suivant, le joueur joue normalement.

Réponse finale : Le diagramme d’état-transition doit représenter ces trois états et les transitions conditionnées par les événements décrits.

Partie 3 : Conception (6 pts)

Question 3.1

Limiter la navigation dans le diagramme de classes pour faciliter l’implémentation des associations. Il faut préciser le sens de navigation, c’est-à-dire quels objets connaissent ou accèdent à quels autres objets.

Réponse : Par exemple, le Joueur connaît ses Propriétés, mais pas forcément l’inverse. Le Jeu connaît le Plateau, les Joueurs, et le Dé. Le Plateau connaît ses Cases. La navigation doit être minimale et cohérente avec les responsabilités.

Question 3.2

1) Signification des contraintes :

  • Ordered : les éléments d’une collection sont ordonnés.
  • AddOnly : on peut ajouter des liens mais pas en supprimer.
  • Frozen : les liens sont fixés à la création et ne changent plus.
  • NotUnique : plusieurs liens identiques peuvent exister entre deux objets.

2) Décoration des associations :

Sur le diagramme de classes, chaque association doit être annotée au niveau de la navigation par les symboles :

  • O pour Ordered
  • A pour AddOnly
  • F pour Frozen
  • N pour NotUnique

Par exemple, la collection de cases dans un plateau peut être {ordered} car l’ordre des cases est important.

Question 3.3

1) Contexte et solution du patron Singleton :

Le problème est de garantir qu’une seule instance d’une classe existe et d’en fournir un point d’accès global.

La solution consiste à stocker l’objet singleton dans une variable statique de classe et à fournir une méthode statique getInstance() qui crée l’instance à la première demande. Le constructeur est privé ou protégé pour empêcher la création d’autres instances.

2) Diagramme de classes avec Singleton :

  • Les classes Jeu et Plateau sont transformées en singletons.
  • Chaque classe a une méthode statique getInstance() qui retourne l’instance unique.
  • Les constructeurs de ces classes sont privés.

3) Objets nécessaires pour « jouer son tour » :

  • 1 instance de Jeu
  • 1 instance de Plateau
  • 1 instance de Dé
  • Des instances de Case (ou ses sous-classes selon le type de case)
  • Des instances de Joueur

4) Diagramme de séquence de « jouer son tour » :

Le diagramme met en scène l’instance Joueur qui demande à l’instance Dé de lancer les dés, puis interagit avec le Plateau pour avancer le pion, déclencher l’action de la case, gérer les doubles, et éventuellement la prison.

Méthode : techniques récompensées et erreurs sanctionnées

  • Récompenses : Une analyse rigoureuse des besoins avec prise en compte des règles spécifiques du Monopoly (gestion des doubles, prison, achats et ventes).
  • La modélisation précise des associations avec cardinalités et choix judicieux entre composition et agrégation.
  • La capacité à représenter les états et transitions des joueurs, ainsi que les scénarios dynamiques par des diagrammes d’activités et de séquences.
  • L’application correcte des contraintes de gestion ({ordered}, {addOnly}, {frozen}, {notUnique}) sur les associations.
  • La bonne utilisation du patron Singleton pour garantir l’unicité des instances Jeu et Plateau.
  • Une démarche claire et détaillée dans les réponses, avec justification des choix.
  • Erreurs sanctionnées : Omettre la gestion des cas particuliers (trois doubles, prison), oublier les cardinalités ou mal justifier les compositions/agrégations.
  • Ne pas modéliser l’état du joueur pour la prison ou le nombre de constructions sur un terrain.
  • Confondre les contraintes de gestion ou ne pas les annoter correctement.
  • Ne pas respecter la limitation de la navigation dans les associations, rendant l’implémentation difficile.
  • Ne pas appliquer correctement le patron Singleton ou oublier de rendre le constructeur privé.

Partager

Commentaires

Aucun commentaire pour le moment. Posez la première question.

Les commentaires sont relus avant publication. Votre e-mail n'est jamais affiché.

← Toutes les révisions