Modélisation structurelle UML

Exercice 1 - Calcul d'itinéraires de robots

Question 1.a - Type d'association particulier

Il est impossible de répondre avec certitude absolue à cette question car le diagramme de classes mentionné dans l'énoncé ("le modèle de conception UML incomplet suivant") est absent du texte source.

Cependant, au vu du contexte de l'exercice (une grille contenant des cases, des itinéraires passant par des cases), il est très probable que le "type particulier" soit une association qualifiée (par exemple, naviguer de la Grille vers une Case grâce à un qualificatif de coordonnées [x, y]), ou bien une classe d'association (utilisée entre Itineraire et Case pour stocker le numéro d'ordre de passage, étant donné qu'une case peut être visitée plusieurs fois).

Définition académique à retenir :

• L'association qualifiée permet d'identifier un ou plusieurs objets cibles à l'aide d'une clé (le qualificatif).
• La classe d'association permet de porter des attributs propres à la relation entre deux classes (ici, l'ordre de passage d'une case dans un itinéraire précis).

Question 1.b - Signification des associations

Bien que le diagramme soit absent, la sémantique métier permet de définir clairement les rôles de chaque association listée :

• Grille-Robot (habitant) : Indique qu'un ou plusieurs robots se trouvent physiquement à l'intérieur de la grille pour y évoluer.
• Grille-Case (Obstacle) : Identifie les cases spécifiques de la zone géographique qui sont infranchissables.
• Itineraire-Case (départ) : Désigne l'unique case initiale depuis laquelle le robot entame ce trajet spécifique.
• Itineraire-Case (arrivée) : Désigne l'unique case cible (la destination finale) que le robot cherche à atteindre à la fin de cet itinéraire.
• Itineraire-Case (chemin) : Représente la collection ordonnée de cases successives que le robot doit parcourir pour aller de la case de départ à la case d'arrivée.

Question 2 - Diagramme d'objets de la zone géographique

Cette question est impossible à traiter car la figure représentant la zone géographique (illustrant la position exacte des 7 obstacles, du robot Zulu et de la case cible) est absente du document source. Il est par conséquent impossible de créer les instances de type Case avec les bonnes coordonnées (x,y) et d'établir les liens corrects.

Question 3.a - Modification du modèle pour la classe Robot

Pour refléter cette modification en UML :

1. Il faut tracer une association dirigée (flèche de navigation) de la classe Robot vers la classe Grille, et nommer le rôle du côté de la grille zoneDuRobot (avec une multiplicité de 1, puisqu'il s'agit d'un pointeur vers LA grille).
2. Il faut ajouter la signature de l'opération presenceObstacle(x: Entier, y: Entier): Booléen dans le troisième compartiment (celui des opérations) de la classe Robot.

Question 3.b - Reconnaissance des obstacles par une instance Itineraire

Non, une instance de la classe Itineraire ne peut pas reconnaître les obstacles. Justification : L'itinéraire est une simple structure de données qui mémorise des points de passage (départ, arrivée, chemin). Elle n'embarque pas la logique métier de la zone, n'a pas connaissance de l'ensemble des cases existantes, et n'a pas accès à la méthode presenceObstacle (qui vient d'être attribuée au Robot). C'est le robot qui possède la méthode d'analyse de l'environnement.

Question 4.a - Définitions des contraintes de gestion

• frozen (gelé) : Les liens de l'association, une fois instanciés entre les objets, sont immuables. Ils ne peuvent plus être modifiés ou supprimés.
• addOnly (ajout seulement) : On peut ajouter de nouveaux liens à l'association, mais les liens existants ne peuvent pas être supprimés ou modifiés (typiquement utilisé pour un historique).
• ordered (ordonné) : Les liens de l'association (lorsque la multiplicité est supérieure à 1) sont maintenus dans un ordre strict et séquentiel.
• notUnique (non unique) : Un même objet peut apparaître plusieurs fois en tant que cible dans la collection de liens (similaire à un "sac" ou "bag" mathématique).

Question 4.b - Décoration des associations

• Grille-Case (Obstacle) : {frozen} (l'énoncé précise que le nombre et la position de chaque obstacle sont "connus à l'avance et fixes").
• Itineraire-Case (départ) : {frozen} (l'énoncé indique que les cases de départ et d'arrivée "restent inchangées" une fois connues).
• Itineraire-Case (arrivée) : {frozen}.
• Itineraire-Case (chemin) : {ordered, notUnique} (l'ordre des cases est crucial pour former un chemin continu, et l'énoncé précise "qu'une case peut être visitée plus qu'une fois").

Question 5 - Déplacement de l'opération presenceObstacle

Oui, il est nettement plus pertinent de déplacer cette opération dans la classe Grille (ou éventuellement Case). Justification : Selon le principe de répartition des responsabilités (patron "Expert en information" de GRASP), la classe Grille possède la liste complète des cases et connaît celles qui sont affectées au rôle d'obstacle. C'est donc à la grille d'indiquer si des coordonnées données (x,y) tombent sur un obstacle. Le robot devrait simplement interroger sa grille : zoneDuRobot.presenceObstacle(x, y).

Question 6 - Mémorisation des itinéraires

Non, ce n'est pas possible avec l'association habitant actuelle ni avec les autres associations existantes. Justification : L'association habitant ne relie que Grille et Robot. Aucune association structurelle n'existe actuellement entre Robot et Itineraire pour représenter l'"historique". Pour mémoriser les itinéraires suivis, il faudrait ajouter une nouvelle association (ex: rôle itineraireHistorique, multiplicité 0..*) directement entre Robot et Itineraire.

Question 7 - Ajout de la classe Application et notions d'Agrégation/Composition

Définitions :

• Composition (losange plein) : Relation contenant-contenu très forte. Le cycle de vie des composants est strictement lié à celui du composite. Si l'objet composite est détruit, tous ses composants le sont aussi.
• Agrégation (losange vide) : Relation contenant-contenu faible. Le composant peut exister indépendamment de son agrégat (il survit à la destruction de l'agrégat).

Proposition de conception textuelle (faute d'éditeur de schéma) :

• Application compose Grille (losange plein côté Application) : L'application est propriétaire du jeu de données.
• Grille compose Case (losange plein côté Grille) : Une grille rectangulaire est intrinsèquement constituée de cases. Une case n'existe pas hors d'une grille.
• Application compose Robot (losange plein côté Application).
• Itineraire agrège Case (losange vide côté Itineraire) : Un itinéraire est constitué d'une suite de cases, mais ces cases existent indépendamment du trajet (elles appartiennent avant tout à la grille).

Exercice 2 - Jeu Pacman

Question 1.1 - Cardinalités manquantes

Cette question est impossible à traiter : la portion de diagramme source mentionnée dans l'énoncé est absente.

Question 1.2 - Promotion des associations

• Jeu - Labyrinthe : Composition. Justification : Une instance de jeu englobe strictement son labyrinthe. Si la partie (le Jeu) s'arrête et est détruite en mémoire, son labyrinthe n'a plus de raison d'exister.
• Case - Labyrinthe : Composition. Justification : Les cases forment l'infrastructure du labyrinthe. Elles n'ont aucune existence sémantique indépendante du labyrinthe.
• Case - Tonneau : Composition (ou forte Agrégation). Justification : L'énoncé indique que les tonneaux "ne changent pas de place". Ils font donc partie intégrante de la topologie de leur case respective.
• Jeu - Occupant : Composition. Justification : Les adversaires et le Pacman sont les entités créées pour la partie. Ils naissent et meurent avec l'instance du Jeu.
• Case - Occupant : Association (nommée Localisation). Justification : Un occupant est très mobile, il transite sans cesse. La case n'est ni propriétaire ni responsable du cycle de vie de l'occupant.
• Pacman - Tonneau : Association (nommée Consommation). Justification : Simple interaction éphémère. Le Pacman n'est pas "constitué" du tonneau.

Question 1.3 - Représentation d'une potion d'énergie

Pour modéliser l'effet limité (10 secondes) et cumulable (jusqu'à 3), on peut ajouter un attribut tempsRestantPotions: Entier[0..3] (un tableau de timers) directement dans la classe Pacman. Commentaire : À chaque appel périodique de la méthode MAJ() de la classe Jeu, celle-ci décrémente les valeurs du tableau pour chaque Pacman. Si au moins une valeur est supérieure à 0, l'état reste agressif.

Question 1.4 - Diagramme d'objets (Jeu Pacman)

Cette question est impossible à traiter. L'énoncé fait référence à une figure ("représentée par la figure ci-dessus") montrant un état du labyrinthe avec des cases simples, prison, joker, et les positions des occupants, mais la grille visuelle n'a pas été extraite dans le document.

Question 2.1 - Sens de navigation

Bien que le diagramme soit absent, l'implémentation logique dicte les navigabilités suivantes pour limiter les dépendances :

• Jeu pointe vers Labyrinthe et vers Occupant (le jeu orchestre les éléments).
• Labyrinthe pointe vers Case (il connaît sa matrice).
• Occupant pointe vers sa Case actuelle (il doit savoir où il est).
• Case pointe vers son Tonneau éventuel.

Question 2.2 - Contraintes de gestion

Faute de diagramme sur lequel annoter, voici l'application des règles métier :

• Association Labyrinthe-Case : {F} (Frozen), car le labyrinthe a une géométrie de n lignes et m colonnes qui ne bouge pas.
• Association Case-Tonneau : {F} (Frozen), car le texte affirme que le tonneau "ne change pas de place".

Question 2.3 - Ordre de navigation des méthodes

1. Méthode surUnMemeCouloir() (depuis Adversaire) : Adversaire navigue vers sa Case actuelle pour lire son (n° ligne, n° colonne). Ensuite, il faut obtenir la Case du Pacman. Si Jeu est accessible globalement, on fait Jeu -> Pacman -> Case pour obtenir la ligne/colonne du Pacman et comparer.
2. Méthode déplacer() (depuis Pacman) : Pacman interroge la direction choisie. Il navigue vers sa Case actuelle, puis demande à la structure globale (ou via des liens de voisinage si modélisés) la Case adjacente ciblée. Le Pacman met alors à jour son association pour pointer vers cette nouvelle Case.

Question 2.4 - Nouvel ordre de navigation avec Labyrinthe-Case de cardinalité '1'

Si le labyrinthe ne possède plus la collection multiple des cases, cela inverse la logique de recherche. L'Adversaire doit naviguer de la manière suivante : Adversaire -> Case -> Labyrinthe. Une fois sur l'objet Labyrinthe, il ne peut plus redescendre directement vers l'ensemble des cases. Il devra passer par le contexte global : Labyrinthe -> Jeu -> Pacman -> Case.

Exercice 3 - Le Solitaire

Question 1 - Diagrammes d'objets (Tablier à 3 billes / Terminaison)

Cette question est impossible à traiter car la "Figure 3" illustrant les cases initialement occupées par les 3 billes est absente du document. Il est impossible de nommer correctement les objets cases (c_i,j) sans connaître leurs coordonnées exactes sur l'image.

Question 2 - Contraintes sur les associations

• Partie - Déplacement : {ordered, addOnly}. Justification : L'historique des actions d'une partie doit conserver un ordre chronologique strict (ordered) pour permettre les retours en arrière exacts. De plus, on ne fait qu'y ajouter de nouveaux coups joués au fil de l'eau, sans altérer rétroactivement le milieu de la liste (addOnly).
• Tablier - Case : {frozen}. Justification : La forme en octogone régulier et les 37 cases du tablier sont physiquement immuables.

Question 3 - Collection pour l'association Partie-Déplacement

Il faut utiliser une Pile (Stack). Justification : Le jeu requiert de "faire des retours en arrière pour annuler certains déplacements". Le mécanisme d'annulation d'actions successives répond intrinsèquement à la structure LIFO (Last In, First Out : Dernier entré, premier sorti). La dernière action jouée (empilée) sera la première à être annulée (dépilée).

Question 4 - Sens de navigation

De nouveau, s'agissant d'un diagramme absent (Figure 2), voici le sens de navigation qui limite le couplage pour ce jeu :

• Partie navigue vers Tablier (la partie pilote la surface de jeu).
• Partie navigue vers Déplacement (la partie garde l'historique en pile).
• Tablier navigue vers Case (le tableau donne accès à l'état du plateau).
• Déplacement navigue vers Case (le mouvement sait de quelle case il part et où il arrive).

Question 5 - Signatures des méthodes de gestion

Pour l'association Partie-Déplacement (implémentée via une Pile) :

+ empilerDeplacement(d: Deplacement)
+ depilerDeplacement(): Deplacement

Pour l'association Case-Bille :

+ ajouterBille(b: Bille)
+ retirerBille()

Méthode

Voici comment aborder ce type d'épreuve de conception UML à base de textes et de diagrammes à trous :

1. Traquez les mots-clés du domaine : Les substantifs du texte deviennent vos classes (Grille, Tonneau, Bille), les verbes d'action lourds deviennent souvent des associations ou des méthodes (se déplacer, mémoriser).
2. Analysez le cycle de vie pour les agrégations/compositions : Posez-vous toujours la question fatidique : « Si je détruis l'objet A, l'objet B a-t-il encore un sens métier et doit-il continuer à vivre en mémoire ? ». Si B doit disparaître avec A (ex: les cases d'un labyrinthe ou d'un tablier), c'est une Composition (losange plein). S'il survit, c'est une Agrégation simple ou une Association.
3. Contraintes {frozen, ordered, addOnly} : Cherchez dans l'énoncé des termes de temporalité. "Ne change pas de place" ou "fixes" impliquent {frozen}. "Succession", "itinéraires", ou "annuler le dernier coup" hurlent {ordered} ou l'utilisation d'une Pile.
4. Défaillance des documents : En situation d'examen (et particulièrement lors de la numérisation de vieux sujets), des figures peuvent être tronquées. Dans votre copie, comme fait dans ce corrigé, énoncez explicitement qu'il manque l'annexe au lieu d'inventer des données. Apportez tout de même la théorie qui aurait permis de traiter la figure si elle avait été présente.