Analyse des cas d’utilisation Monopoly simplifié – Règles et interactions
Ce document présente un examen d’analyse et de conception orientée objet appliqué à un jeu simplifié de Monopoly. Il évalue la capacité à exprimer les besoins, modéliser les interactions et les structures, analyser un diagramme de classes, et appliquer des patrons de conception.
D'après le document Analyse des cas d’utilisation Monopoly simplifié – Règles et interactions
Cet article a été rédigé automatiquement à partir du document source, puis vérifié avant publication.
Document source
Programming, Math, etc. · PDF · 8 pages
Afficher l'aperçu du document
Ce document présente un examen d’analyse et de conception orientée objet appliqué à un jeu simplifié de Monopoly. Il évalue la capacité à exprimer les besoins, modéliser les interactions et les structures, analyser un diagramme de classes, et appliquer des patrons de conception.
Partie 1 : Expression des besoins (7 pts)
Question 1.1
1) Compléter les relations entre l’acteur « joueur » et les cas d’utilisation « Jouer son tour », « Vendre », « Acheter », ainsi qu’entre ces cas eux-mêmes.
Le joueur est l’acteur principal qui interagit avec les trois cas d’utilisation :
- Jouer son tour : Le joueur lance les dés, déplace son pion, effectue les opérations liées à la case d’arrivée, puis éventuellement relance les dés en cas de double.
- Acheter : Lorsqu’il s’arrête sur une case terrain sans propriétaire et qu’il dispose du capital nécessaire, il peut acheter ce terrain. Il peut aussi acheter des maisons ou hôtels s’il possède tous les terrains d’un groupe de couleur.
- Vendre : Le joueur peut revendre au prix d’achat des constructions, terrains, gares ou compagnies.
Relations entre cas d’utilisation :
- « Jouer son tour » inclut potentiellement « Acheter » (si le joueur s’arrête sur un terrain libre et décide d’acheter).
- « Jouer son tour » inclut aussi « Vendre » (le joueur peut vendre durant son tour).
- « Acheter » et « Vendre » sont des cas d’utilisation indépendants mais liés au tour du joueur.
2) Description sommaire des variantes de scénarios pour chaque cas d’utilisation, en tenant compte de la prison.
Cas d’utilisation : « Jouer son tour »
- Le joueur lance 2 dés et avance son pion du total obtenu dans le sens des aiguilles d’une montre.
- Si le joueur obtient un double, il effectue l’opération de la case d’arrivée, puis relance les dés et rejoue. S’il obtient un double trois fois de suite ou arrive sur la case « allez en prison », il est envoyé en prison immédiatement, son tour s’arrête, et il ne reçoit pas 20.000 euros pour le passage sur « Départ ».
- Si le joueur arrive sur la case « prison » en déplacement normal, c’est une simple visite sans pénalité.
- Un joueur emprisonné peut sortir de prison s’il obtient un double dans les trois tours suivants. Il se déplace alors normalement et rejoue.
- Si au bout du troisième tour en prison, il n’a pas obtenu de double, il paie une amende de 5.000 euros, se déplace selon le lancer, et continue son tour.
Cas d’utilisation : « Acheter »
- Le joueur peut acheter un terrain libre s’il a le capital nécessaire.
- Lorsqu’il possède tous les terrains d’un groupe de couleur, il peut acheter des maisons (jusqu’à 4 par terrain) à tout moment durant son tour.
- Pour construire un hôtel, il échange 4 maisons d’un terrain contre un hôtel en payant le prix indiqué.
Cas d’utilisation : « Vendre »
- Le joueur peut revendre au prix d’achat des constructions, terrains nus, gares ou compagnies durant son tour.
3) Proposer un diagramme de séquence système décrivant le scénario nominal du cas d’utilisation « Jouer son tour » sans envoi en prison.
Le scénario nominal se déroule ainsi :
- Le joueur lance les deux dés.
- Le système calcule la nouvelle position du pion en avançant du total des dés.
- Le système vérifie la case d’arrivée et effectue l’opération correspondante (paiement loyer, tirage carte, impôt, etc.).
- Si le joueur obtient un double (et pas trois fois de suite), il relance les dés et répète les étapes 2 et 3.
- Si le joueur n’obtient pas de double, le tour se termine.
Le joueur interagit avec le système en lançant les dés et en recevant les résultats et effets des cases.
Question 1.2
4) Proposer un diagramme d’activités illustrant la dynamique du jeu Monopoly.
Le diagramme d’activités doit représenter :
- Début du tour du joueur
- 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
- Si case normale, effectuer l’action (payer loyer, acheter, tirer carte, etc.)
- Si double obtenu, relancer les dés et répéter
- Sinon, fin du tour
Partie 2 : Analyse (7 pts)
Question 2.1
1) Ajouter les cardinalités manquantes dans le diagramme de classes.
Les cardinalités précises ne sont pas fournies dans le texte, mais on peut déduire :
- Un Jeu contient un Plateau (1..1)
- Un Plateau contient plusieurs Cases (1..*)
- Un Jeu contient plusieurs Joueurs (1..*)
- Un Plateau contient plusieurs Groupes (1..*)
- Un Groupe contient plusieurs Propriétés (1..*)
- Un Joueur possède plusieurs Propriétés (0..*)
2) Promouvoir les associations en compositions ou agrégations et justifier les choix.
| Association | Composition | Agrégation | Justification |
|---|---|---|---|
| Jeu - Plateau | X | Appartenance totale, cycles de vie dépendants | |
| Plateau - Case | X | Les cases appartiennent au plateau mais aussi aux groupes (cas propriétés) | |
| Case - Joueur | X | Appartenance faible, le joueur n’est pas contenu dans la case | |
| Jeu - Groupe | X | Appartenance totale, cycles de vie dépendants | |
| Jeu - Joueur | X | Appartenance faible, le joueur appartient au jeu mais pas contenu | |
| Joueur - Propriété | X | Pas de notion d’appartenance forte, mais le joueur possède la propriété | |
| Propriété - Groupe | X | Les propriétés appartiennent au plateau et aussi aux groupes |
3) Ajouter la modélisation de l’abstraction « Dé » et ses relations.
La classe « Dé » doit être ajoutée, avec une relation vers le Jeu ou le Plateau, car le dé est utilisé pour déterminer les déplacements des joueurs. La relation est une association simple entre Jeu et Dé, car le dé est un objet utilisé par le jeu.
4) Le diagramme de classes permet-il de représenter les énoncés suivants ?
- (a) Un joueur est en simple visite de la prison ou emprisonné.
Réponse : Non. Il faut ajouter un attribut à la classe Joueur pour préciser son état (simple visite, emprisonné, normal). - (b) À partir d’une Propriété donnée, il est possible de connaître que les Propriétés du même groupe appartiennent au même joueur.
Réponse : Oui. On peut naviguer de Joueur vers Propriété, puis Groupe, puis toutes les Propriétés du groupe, et vérifier leur propriétaire. - (c) Le nombre de constructions sur un terrain.
Réponse : Non. Il faut ajouter un attribut int nbre_construction dans la classe Terrain.
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, et la propriété Belleville, est actuellement à la compagnie des eaux.
- Joueur 2 : Zied, possède les compagnies d’électricité et des eaux, est actuellement à la case départ.
Le diagramme d’objets doit montrer :
- Instances Joueur : Ali, Zied
- Instances Propriété : Gare du Nord, Gare de Lyon, Belleville, Compagnie d’électricité, Compagnie des eaux
- Instances Case : Compagnie des eaux, Case départ
- Relations de possession entre joueurs et propriétés
- Position actuelle des joueurs sur les cases
- Instances Groupe : celles correspondant aux propriétés concernées
Ce diagramme illustre la répartition des propriétés et la position des joueurs sur le plateau.
Question 2.3
Donner un diagramme d’état-transition illustrant l’évolution de l’état d’un joueur.
Les états possibles du joueur sont :
- Normal (en jeu)
- En prison
- Simple visite (à la prison)
- Éliminé (état final)
Transitions :
- De Normal à En prison : si le joueur est envoyé en prison (triple double ou case « allez en prison »)
- De Normal à Simple visite : si le joueur arrive sur la case prison sans être emprisonné
- De En prison à Normal : si le joueur sort de prison (double obtenu ou paiement amende)
- De Normal ou En prison à Éliminé : si le joueur est éliminé (par exemple faillite, non précisé ici)
Partie 3 : Conception (6 pts)
Question 3.1
Limiter la navigation dans le diagramme de classes en précisant le sens de navigation.
Pour faciliter l’implémentation, la navigation doit être limitée :
- Le Jeu connaît le Plateau et les Joueurs (navigation Jeu → Plateau, Jeu → Joueur)
- Le Plateau connaît ses Cases et Groupes (Plateau → Case, Plateau → Groupe)
- Les Joueurs connaissent leurs Propriétés (Joueur → Propriété)
- Les Propriétés connaissent leur Groupe (Propriété → Groupe)
- La navigation inverse est limitée ou inexistante pour éviter les dépendances circulaires.
Question 3.2
1) Signification des contraintes de gestion sur les associations :
- Ordered : Les éléments de la 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écorer les associations du diagramme de classes avec ces contraintes.
Le document ne fournit pas le diagramme exact ni les annotations précises, mais on peut supposer :
- Les collections de Cases dans Plateau sont ordonnées (O).
- Les associations Jeu - Plateau et Jeu - Joueur sont frozen (F) car elles ne changent pas après création.
- Les liens entre Joueur et Propriété peuvent être addOnly (A) car on peut acquérir des propriétés mais pas forcément les perdre facilement.
- Les autres associations sont à annoter selon leur usage spécifique.
Question 3.3
1) Contexte et solution du patron de conception Singleton.
Problème : Garantir l’existence d’une seule instance d’une classe et fournir un point d’accès global à cette instance.
Solution : 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 requête. Le constructeur est privé ou protégé pour empêcher la création d’autres instances.
2) Proposer un diagramme de classes de conception utilisant le patron Singleton.
Le patron Singleton s’applique aux classes Jeu et Plateau :
- Ajouter une méthode statique getInstance() dans Jeu et Plateau.
- Rendre les constructeurs privés dans ces classes.
- Les autres classes restent classiques.
3) Objets nécessaires au déroulement normal de « jouer son tour ».
- 1 instance de Jeu (singleton)
- 1 instance de Plateau (singleton)
- 1 instance de Dé
- Instances de Case (dont types spécifiques : terrain, gare, compagnie, prison, départ)
- Instances de Joueur
4) Diagramme de séquence de « jouer son tour » avec ces objets.
Le diagramme montre :
- Le Joueur demande à l’objet Dé de lancer les dés.
- Le Dé retourne le résultat au Joueur.
- Le Joueur demande au Plateau de déplacer son pion selon le résultat.
- Le Plateau calcule la nouvelle Case d’arrivée.
- Le Joueur effectue l’action liée à la Case (payer loyer, acheter, tirer carte, etc.).
- Si double obtenu, le Joueur relance le Dé et répète.
- Sinon, fin du tour.
Méthode : techniques récompensées et erreurs pénalisées
Ce sujet valorise une démarche rigoureuse de modélisation orientée objet :
- Respecter les définitions et notations données, notamment pour les associations, compositions, agrégations et attributs.
- Justifier clairement chaque choix de modélisation (cardinalités, types d’association, attributs ajoutés).
- Présenter un raisonnement complet avec étapes intermédiaires, notamment pour les scénarios et diagrammes.
- Ne pas inventer d’informations non fournies dans l’énoncé.
- Utiliser correctement les patrons de conception, en expliquant leur contexte et leur application.
- Limiter la navigation dans les diagrammes pour faciliter l’implémentation.
- Éviter les erreurs classiques comme confondre composition et agrégation, ou oublier les états nécessaires dans les diagrammes d’état.
Les erreurs fréquentes pénalisées sont :
- Omettre des attributs indispensables pour modéliser un comportement (ex. état du joueur).
- Confondre les relations d’appartenance forte et faible.
- Ne pas justifier les choix de modélisation.
- Présenter des diagrammes incomplets ou incohérents avec l’énoncé.
- Ne pas respecter les contraintes imposées (ex. pas de navigation inverse non justifiée).
Commentaires
Aucun commentaire pour le moment. Posez la première question.