Examen Principal du 1er Semestre - Analyse et Conception Orientées Objets

Ce document présente un examen principal du premier semestre en Analyse et Conception Orientées Objets. Il porte sur la modélisation d’un jeu simplifié de Monopoly et teste les compétences en analyse des besoins, modélisation UML, conception orientée objets, et compréhension 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 que les relations entre ces cas.

Le joueur est l’acteur principal qui interagit avec les trois cas d’utilisation. Chaque cas d’utilisation représente une fonctionnalité accessible au joueur :

• Jouer son tour : le joueur lance les dés, se déplace, effectue les actions liées à la case d’arrivée.
• Acheter : le joueur peut acheter une propriété libre ou construire des maisons/hôtels.
• Vendre : le joueur peut revendre des constructions ou des propriétés au système.

Relations possibles :

• Jouer son tour inclut potentiellement les cas Acheter et Vendre, car durant son tour, le joueur peut décider d’acheter ou de vendre.
• Le joueur est lié à chacun des cas d’utilisation par une relation d’association simple, car il initie ces actions.

Schéma relationnel résumé :

• Joueur — association —> Jouer son tour
• Jouer son tour — inclut —> Acheter
• Jouer son tour — inclut —> Vendre
• Joueur — association —> Acheter
• Joueur — association —> Vendre

2) Description sommaire des variantes de scénarios pour chaque cas d’utilisation, en tenant compte de l’entrée et sortie de prison :

• Jouer son tour : Le joueur lance les dés. S’il obtient un double, il rejoue. S’il obtient trois doubles consécutifs, il va en prison et son tour s’arrête. S’il est en prison, il peut tenter de sortir en faisant un double ou payer une amende au troisième tour. Lorsqu’il avance, il peut passer par la case départ et recevoir 20 000 euros. Selon la case d’arrivée, il achète, paie un loyer, tire une carte chance ou caisse de communauté, ou va en prison.
• Acheter : Le joueur peut acheter une propriété libre s’il a assez d’argent. S’il possède tous les terrains d’un groupe, il peut construire des maisons ou échanger 4 maisons contre un hôtel.
• Vendre : Le joueur peut revendre des constructions, des terrains, des gares ou des compagnies au système au prix d’achat, notamment s’il est endetté.

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

Le scénario nominal suit ces étapes :

1. Le joueur lance deux dés.
2. Le système calcule le total et déplace le pion du joueur sur le plateau.
3. Si le joueur passe par la case départ, le système lui crédite 20 000 euros.
4. Le système détermine l’action liée à la case d’arrivée (achat, paiement de loyer, tirage de carte, impôt, prison, etc.).
5. Le joueur effectue l’action demandée.
6. Si le joueur obtient un double et n’a pas fait trois doubles consécutifs, il relance les dés et recommence.
7. Si le joueur fait trois doubles consécutifs, il est envoyé en prison et son tour s’arrête.

Ce diagramme montre l’interaction entre le joueur, le système de jeu, le plateau, les cases, et les cartes chance ou caisse de communauté.

Partie 2 : Analyse (7 pts)

Question 2.1

1) Ajouter les cardinalités manquantes dans le diagramme de classes proposé.

En se basant sur la description :

• Jeu - Plateau : Un jeu possède exactement un plateau (1..1).
• Plateau - Case : Un plateau contient 40 cases (1..40).
• Case - Joueur : Plusieurs joueurs peuvent se trouver sur une même case (0..*).
• Jeu - Groupe : Un jeu possède 10 groupes de propriétés (1..10).
• Jeu - Joueur : Le jeu comporte de 2 à 6 joueurs (2..6).
• Joueur - Propriété : Un joueur peut posséder plusieurs propriétés (0..*), chaque propriété appartient à un seul joueur ou à aucun (0..1).
• Propriété - Groupe : Une propriété appartient à un seul groupe (1..1), un groupe contient plusieurs propriétés (1..*).

2) Promouvoir les associations en compositions ou agrégations avec justification :

Association	Composition	Agrégation	Justification
Jeu - Plateau	✓		Le plateau n’existe que dans le contexte du jeu, il est une partie intégrante et ne peut exister indépendamment.
Plateau - Case	✓		Les cases appartiennent exclusivement au plateau et ne peuvent exister sans lui.
Case - Joueur		✓	Un joueur peut être sur une case, mais la case n’est pas responsable du joueur ; la relation est faible.
Jeu - Groupe		✓	Les groupes sont des collections logiques de propriétés, ils peuvent exister indépendamment du jeu.
Jeu - Joueur		✓	Les joueurs existent indépendamment du jeu (conceptuellement) et peuvent être ajoutés ou retirés.
Joueur - Propriété		✓	Le joueur possède des propriétés, mais celles-ci peuvent devenir libres si le joueur fait faillite.
Propriété - Groupe		✓	Une propriété appartient à un groupe, mais le groupe n’est pas responsable de la propriété.

3) Modélisation de l’abstraction « Dé » :

La classe « Dé » doit être ajoutée pour représenter les dés utilisés par les joueurs. Elle est liée au joueur (ou au système de jeu) qui lance les dés. La relation est une association simple :

• Un joueur utilise deux dés pour jouer son tour.
• Chaque dé peut avoir une valeur de 1 à 6.

Le diagramme doit donc inclure une classe « Dé » associée au joueur ou au tour de jeu, avec une multiplicité de 2.

4) Le diagramme de classes permet-il de représenter :

1. (a) Un joueur est en simple visite de la prison ou emprisonné :
   Non, le diagramme ne montre pas explicitement l’état du joueur (visite ou emprisonné). Il faudrait ajouter un attribut ou un état pour différencier ces deux situations.
2. (b) Partant d’une propriété donnée, connaître les propriétés du même groupe appartenant au même joueur :
   Oui, car chaque propriété est liée à un groupe et à un joueur. On peut parcourir les propriétés du groupe et vérifier leur propriétaire.
3. (c) Le nombre de constructions sur un terrain :
   Non, le diagramme ne modélise pas explicitement les constructions (maisons, hôtels) associées à un terrain. Il faut ajouter une classe « Construction » ou un attribut dans la classe « Terrain » pour stocker ce nombre.

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 :

• Deux instances de Joueur : Ali et Zied.
• Instances de Propriété : Gare du Nord, Gare de Lyon, Belleville, Compagnie d’électricité, Compagnie des eaux.
• Relations de possession : Ali possède Gare du Nord, Gare de Lyon, Belleville ; Zied possède Compagnie d’électricité et Compagnie des eaux.
• Instances de Case : Compagnie des eaux (Ali), Départ (Zied).
• Instances de Groupe : uniquement ceux correspondant aux propriétés citées.

Ce diagramme illustre la situation dynamique des joueurs, leurs possessions, et leurs positions sur le plateau.

Question 2.3

Diagramme d’état-transition illustrant l’évolution de l’état d’un joueur :

Les états possibles du joueur sont :

• En jeu normal : le joueur joue son tour normalement.
• En prison : le joueur est emprisonné et doit tenter de sortir.
• En simple visite : le joueur est sur la case prison sans pénalité.
• Faillite : le joueur a perdu et quitte le jeu.

Transitions :

• De « En jeu normal » à « En prison » : si le joueur fait trois doubles consécutifs ou arrive sur la case « Allez en prison ».
• De « En jeu normal » à « En simple visite » : si le joueur arrive sur la case prison par déplacement normal.
• De « En prison » à « En jeu normal » : si le joueur sort de prison en faisant un double ou en payant l’amende au troisième tour.
• De « En jeu normal » ou « En prison » à « Faillite » : si le joueur ne peut plus payer ses dettes.

Partie 3 : Conception (6 pts)

Question 3.1

Limiter la navigation dans le diagramme de classes pour faciliter l’implémentation des associations.

Pour réduire la complexité :

• Navigation unidirectionnelle de Jeu vers Plateau, Groupes, Joueurs.
• Navigation de Joueur vers Propriétés possédées.
• Navigation de Plateau vers Cases.
• Navigation limitée de Propriété vers Groupe, mais pas nécessairement inverse.
• Navigation de Joueur vers Dé (pour lancer les dés).

Cette limitation évite les cycles de navigation et facilite la gestion des relations.

Question 3.2

Signification des contraintes de gestion sur les associations :

• Ordered : la collection d’objets est ordonnée.
• AddOnly : seuls des ajouts sont permis, pas de suppression.
• Frozen : la collection est immuable après sa création.
• NotUnique : les objets peuvent apparaître plusieurs fois dans la collection.

Décoration des associations avec ces contraintes :

• Jeu - Plateau : {frozen} (un seul plateau fixe)
• Plateau - Case : {ordered} (les cases sont ordonnées sur le plateau)
• Case - Joueur : {notUnique} (plusieurs joueurs peuvent être sur la même case)
• Jeu - Groupe : {frozen} (groupes fixes)
• Jeu - Joueur : {addOnly} (joueurs ajoutés mais rarement supprimés en cours de partie)
• Joueur - Propriété : {addOnly} (propriétés acquises mais peuvent être revendues, donc à discuter)
• Propriété - Groupe : {frozen} (propriétés fixes dans un groupe)

Question 3.3

1) Contexte et solution d’usage du patron Singleton :

Problème : garantir l’existence d’une seule instance d’une classe et fournir un point d’accès global.

Solution : stocker l’instance unique dans une variable statique de la classe, fournir une méthode statique pour accéder à cette instance, et rendre le constructeur privé ou protégé pour empêcher la création d’autres instances.

2) Diagramme de classes de conception utilisant Singleton :

La classe « Jeu » peut être un singleton, car il n’y a qu’un seul jeu en cours. Elle possède :

• Une méthode statique getInstance() qui retourne l’unique instance.
• Des méthodes pour gérer les joueurs, le plateau, les groupes, etc.

Les autres classes restent normales, mais l’accès au jeu se fait via cette instance unique.

3) Objets nécessaires au déroulement normal de « jouer son tour » :

• Instance du Jeu (singleton).
• Instance du Joueur courant.
• Instances des Dés (2 dés).
• Instance du Plateau.
• Instance de la Case d’arrivée.
• Instances des Cartes Chance ou Caisse de communauté si tirées.

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

1. Le joueur demande au jeu de lancer les dés.
2. Le jeu utilise les dés pour obtenir un total.
3. Le jeu déplace le pion du joueur sur le plateau.
4. Le jeu vérifie si le joueur passe par la case départ et crédite 20 000 euros.
5. Le jeu interroge la case d’arrivée pour déterminer l’action (achat, loyer, carte, prison, etc.).
6. Le joueur effectue l’action demandée.
7. Si double, le joueur relance les dés et recommence.
8. Si trois doubles consécutifs, le jeu envoie le joueur en prison et termine le tour.

Méthode

Ce sujet récompense une analyse rigoureuse des besoins et une modélisation précise des relations entre objets. Il faut respecter les définitions du problème, notamment les règles du jeu Monopoly simplifié, et appliquer correctement les concepts UML (cas d’utilisation, diagrammes de classes, séquences, états). La clarté dans la justification des choix (composition vs agrégation, cardinalités, contraintes) est essentielle. Les erreurs fréquentes incluent l’oubli des états spécifiques (comme la prison), la mauvaise attribution des cardinalités, ou la confusion entre composition et agrégation. Enfin, la maîtrise des patrons de conception, notamment Singleton, est valorisée, ainsi que la capacité à limiter la navigation pour simplifier l’implémentation.