UNIVERSITE DE LA MANOUBA
-----¤¤¤¤-----
ECOLE NATIONALE DES SCIENCES DE
L'INFORMATIQUE
Matière : ACOO
A.U. : 2013-2014
Niveau : I.I. 2
Série N°3: Modélisation structurelle UML
Exercice 1
L’objectif de ce problème est de développer une application permettant de faire calculer à des
robots des itinéraires dans différentes zones géographiques. Un robot calcule un itinéraire lors de
son déplacement dans une zone géographique.
Chaque zone géographique dispose d’un certain
nombre d’obstacles dont le nombre et la position
de chaque obstacle sont connus à l’avance et fixes.
de
est
grille
le cadre de ce problème, une zone
Dans
géographique
forme
une
rectangulaire dont la taille est de NxM cases. Au
départ, le robot est situé sur une case désignée
par case de départ. Le robot calcule un itinéraire
formé d’une succession de cases qu’il peut visiter
pour se rendre à une case de la grille désignée par
case d’arrivée. Il convient de mentionner qu’une
case peut être visitée plus qu’une fois. Un
itinéraire peut être construit que
lorsqu’on
connaît les cases de départ et d’arrivée qui restent
inchangées. On suppose que
les robots se
déplacent dans l’une des quatre cases voisines à
la sienne (haut, bas, gauche, droite) à condition
qu’elle ne soit pas un obstacle (cercle noirci).
La figure à droite représente une zone géographique composée de sept obstacles avec un robot (nommé
Zulu) initialement dans une case de départ devant se rendre à une case cible (quadrillée).
Dans un premier temps, on se propose d’utiliser uniquement les 4 classes : Grille, Robot, Case et
Itineraire. Un développeur a réalisé le modèle de conception UML incomplet suivant :
1
Travail à faire
On se propose de comprendre, compléter et d’améliorer la modélisation UML proposée par le
développeur.
1. a) Vous remarquez l'utilisation d'un type particulier d'association dans le diagramme de
classes proposé par le développeur. Lequel ? Rappelez sa définition.
b) Commentez la signification de chaque association dans le diagramme proposé par le
développeur.
Grille-Robot (habitant) :
Grille-Case (Obstacle) :
Itineraire-Case (départ) :
Itineraire-Case (arrivée) :
Itineraire-Case (chemin) :
2. Elaborez le diagramme d’objets représentant la zone géographique présentée dans la
première figure (avec 1 zone géographique, 7 obstacles, un robot). Prenez les
conventions suivantes : la position 0,0 correspond au coin haut gauche de la grille, les
colonnes positives à droite, les lignes positives en bas.
3. De petites modifications s’avèrent nécessaires pour que la classe Robot puisse réaliser le
traitement de la méthode « atteindrePosition » assurant le calcul d’un itinéraire. Voici un
exemple de modification qu’il est possible d’apporter à la classe Robot :
i. Ajouter un attribut nommé zoneDuRobot dont le type est un pointeur sur la Grille
ii. Ajouter l’opération presenceObstacle qui retourne vrai en cas d’existence d’obstacle à
la position (x,y)
a) Reflétez cette modification sur le modèle UML en représentant que les classes concernées
par le changement.
b) Une instance de la classe Itineraire peut-elle reconnaître les obstacles ? Justifier votre
réponse.
4. Pour la compréhension de l’évolution du modèle objet, on se propose de décorer les
Publicité
associations par les contraintes de gestion : frozen, addOnly, ordered, notUnique.
a) Rappelez la signification de chacune de ces contraintes.
b) Décorez chaque association par le ou les contraintes de gestion appropriées. Il est
conseillé de donner une réponse textuelle : le ou les contraintes par association (une
ligne par association).
5. On rappelle que dans la question 3, on a rajouté l’opération presenceObstacle dans la classe
Robot. Est-il possible de déplacer cette opération dans une autre classe ? Justifiez votre
réponse.
6. On veut savoir s’il est possible de mémoriser les itinéraires suivis par chaque Robot. Est-il
possible de le faire avec l’association «habitant» entre les classes Grille et Robot et/ou une
autre association de la solution actuelle ? Justifiez votre réponse ?
7. On se propose d’ajouter la classe Application qui joue le rôle d’interface entre le programme
principal et les constituants du problème en question (Grille, Robot, Case, Itineraire). A cet
effet, on se propose aussi de transformer toutes les associations dans le diagramme de
classes réalisé par le développeur en introduisant, si c’est possible, un maximum
d’association de type composition ou à la limite des associations de type agrégation.
Rappelez la définition de ces deux concepts et donnez une proposition d’un nouveau
diagramme de classes incluant la classe Application.
Exercice 2
L’objectif de cet exercice est l’analyse et la conception, en partie, d’une version simplifiée d'un jeu
mettant en opposition un Pacman et plusieurs adversaires. Ce jeu permet à un joueur de déplacer
son Pacman dans un labyrinthe contenant des tonneaux. Lors de son passage, le Pacman peut boire
2
des potions d’énergie qui sont dans des tonneaux. La partie est gagnée quand le Pacman atteint une
case ‘jocker’. La partie est perdue quand le Pacman est tué par un adversaire.
Dans le cadre de ce problème, on suppose que le labyrinthe est composé d’un ensemble de cases (n
lignes, m colonnes) et, par conséquent, il est de forme rectangulaire. Les cases du labyrinthe
peuvent être de l’une de ces 3 catégories : ‘Simple’, ‘Prison’ ou ‘Jocker’. Chaque case de ce
labyrinthe peut contenir au plus un tonneau, mais peut abriter un nombre quelconque d’occupants :
le Pacman et/ou des adversaires. On suppose que chaque tonneau contient une quantité infinie de
potions d’énergie et ne change pas de place au cours du jeu. Si deux occupants de natures
différentes se trouvent sur la même case, ils s’attaquent et en fonction de leurs états respectifs, l’un
d’eux tue l’autre. On suppose aussi que le déplacement d’un occupant se fait sur l’une des quatre
cases voisines à la sienne. Dans le cas où le déplacement fait ressortir l’occupant du labyrinthe, ce
dernier réapparait sur le côté opposé du labyrinthe.
Le Pacman est initialement immobile. Le déplacement du Pacman est commandité par le joueur. Ce
dernier lui donne une direction (haut, bas, gauche, droite). Le Pacman se déplace à des fréquences
périodiques dans le couloir où il se trouve et dans la direction donnée par le joueur. Le Pacman ne
peut pas visiter la case "prison" et dans le cas où il la rencontre dans son chemin il s'arrête. Il est à
noter qu'un couloir est une succession de cases sur une même ligne (respectivement même colonne)
du labyrinthe.
Le Pacman est initialement dans un état ‘non agressif’. Dans cet état, il peut être attaqué par un
Adversaire. Mais, le Pacman peut à son tour attaquer quand il est à l’état ‘agressif’. Le Pacman
passe à l’état ‘agressif’ lorsqu’il passe par une case qui contient un tonneau et dans ce cas boit
systématiquement une potion d’énergie à condition qu’il ne cumule pas en même temps au-delà de
3 potions actives. L’effet d’une potion bue devient inactif après 10 secondes. Il est possible de
cumuler des potions d’un même tonneau.
Les adversaires, quant à eux, sont dirigés aléatoirement à des fréquences périodiques. Ils vont
poursuivre le Pacman dans le labyrinthe. Les adversaires apparaissent dans la case "prison" où ils ne
font rien, puis sont libérés par la suite, chacun à son tour. En se libérant, l'adversaire passe à l'état de
‘recherche’ d'un Pacman. Dans ce cas, il se déplace de manière aléatoire à l'intérieur du labyrinthe.
Lorsque le Pacman est dans l’état ‘non agressif’ et se trouve dans un même couloir que l’adversaire,
ce dernier passe à l'état de ‘poursuite’ et son déplacement se fait dans la direction du Pacman dans
l’espoir de le rattraper. Par contre, l’adversaire va tenter de fuir le Pacman quand ce dernier est à
l’état ‘agressif’, jusqu’à ce que le Pacman passe à l’état ‘non agressif’. Quand un adversaire est
mangé par le Pacman, il va être replacé dans la "prison" et en ressortira après 2 secondes.
Après, l’analyse de ce jeu, un développeur a commencé une embauche de la conception et a proposé
le diagramme de classes UML incomplet suivant :
3
• La méthode ‘MAJ ()’ de la classe 'Jeu' se charge de l’invocation des manœuvres
(déplacements et attaques) du ‘Pacman’ et celles des ‘Adversaires’ ainsi sue l’effet des
potions et ce à des fréquences périodiques.
• La méthode ‘déplacer ()’ de la classe Occupant permet de déplacer l'occupant dans le
labyrinthe. Dans le cas de la classe Pacman, le joueur choisit la direction de déplacement en
l'indiquant comme paramètre dans la méthode ‘choisir’ et dans le cas de l'Adversaire, le
choix de la direction est automatique selon l'état de ce dernier.
• La méthode ‘surUnMemeCouloir ()’ de la classe Adversaire permet de détecter la présence
du Pacman sur un même couloir (ligne ou colonne).
Les types ‘Direction’, ‘Etat_p’ et ‘Etat_adv’ sont des énumérations:
• Direction= {immobile, haut, bas, droite, gauche}
Publicité
• Etat_p= {agressif, non agressif}
• Etat_adv= {prisonnier, recherche, poursuite, fuite}
Travail à faire
On se propose de comprendre, compléter, améliorer la modélisation UML proposée par le
développeur.
Partie n°1 : Analyse
Question 1.1
Précisez les cardinalités manquantes des associations sur la portion de diagramme suivante
Question 1.2
On se propose de promouvoir dans la mesure du possible les associations en compositions ou en des
agrégations. Cochez LA bonne réponse pour chaque proposition en justifiant brièvement votre
réponse, puis reflétez ceci sur le diagramme de classes de la page précédente (question 1.1).
N’oubliez pas de proposez un nom à l’association s’il est impossible de la promouvoir :
Jeu- Labyrinthe: Association Composition Agrégation
Case-Labyrinthe: Association Composition Agrégation
Case-Tonneau: Association Composition Agrégation
Jeu- Occupant: Association Composition Agrégation
Case-Occupant: Association Composition Agrégation
Pacman-Tonneau: Association Composition Agrégation
4
Question 1.3
L’effet d’une potion bue dure pendant 10 secondes. Proposez une manière de représentation de
cette information dans le diagramme de classes. Commentez brièvement votre solution.
Question 1.4
Elaborez le diagramme d’objets conformément à vos réponses à la question (1.2) illustrant la
situation représentée par la figure ci-dessus
1
2
3
4
5
Adversaire et
Tonneau dans une
même Case
‘Simple’
Adversaire dans
une Case
"Prison"
1
2
3
4
5
Case
"Simple"
Pacman dans la
Case ‘Jocker’
Tonneau
Partie 2 : Conception
Question 2.1
Afin de faciliter l’implémentation des associations, on se propose de limiter au maximum possible
la navigation. Précisez le sens de navigation sur le diagramme de classes en bas de page (Q2.2).
Question 2.2
Pour comprendre les règles de gestion gouvernant l’évolution des liens entre les objets, on se
propose de décorer les associations par les contraintes {ordered}, {addOnly}, {frozen},
{notUnique}.
Décorez, directement sur le diagramme de classes ci-dessous, chacune des associations par les
contraintes de gestion appropriées. Vous pouvez tout simplement annoter le bout navigable de
chaque association par les symboles O, A, F, N (respectivement pour (O)rdered, (A)ddOnly,
(F)rozen et (N)otUnique).
5
Question 2.3
Donnez l’ordre de navigation sur les instances de classes concernées pour que :
1. la méthode ‘surUnMemeCouloir ()’ de la classe Adversaire puisse détecter la présence du
Pacman sur un même couloir (ligne ou colonne).
2. la méthode ‘déplacer()’de la classe Pacman puisse changer la position du Pacman
Question 2.4
Pour des besoins d’optimisation, on se propose de changer la conception comme suit : L’association
entre le labyrinthe est la case devient de cardinalité ‘1’ et non plus ‘*’.
Donnez le nouvel ordre de navigation sur l’ensemble des objets concernées de la méthode
Publicité
‘surUnMemeCouloir ()’.
Exercice 3
Le solitaire est un jeu de réflexion qui, comme l'indique son nom, se
pratique seul. Dans ce jeu, le joueur fait une partie qui consiste à
déplacer des billes placées initialement sur un tablier. Dans le cadre
de cet exercice, un tablier a la forme d'un octogone régulier qui
comporte 37 cases. La figure 1 illustre un tablier vide.
Chaque case comporte un trou qui peut contenir au maximum une
bille. Il convient de mentionner que le tablier est formé de 7 lignes et
de 7 colonnes. Chaque case est ainsi repérée par un couple (n° ligne,
n°colonne) (n° ligne dans [1..7], n°colonne dans [1..7].
- Remarque : certains couples (tq (1,1), (1,2)) ne correspondent pas à une case du tablier).
A chaque déplacement, le joueur joue en déplaçant une bille sur le tablier et à condition de
respecter les conditions suivantes :
• Une bille déplacée doit sauter sur une autre. La bille ne peut sauter que sur une bille adjacente
(immédiatement voisine) qui est suivi d’une case vide. Auquel cas, la première bille « saute »
par-dessus la seconde et rejoint la case vide. La seconde bille est alors retirée du tablier.
Figure 1. Tablier vide
• Le saut ne peut se faire que sur l’horizontale ou sur la verticale et bien sur à l’intérieur du tablier.
La partie se termine lorsqu’il ne reste plus de billes à déplacer. Ainsi, le joueur est déclaré :
• « Gagnant » quand il reste qu’une seule bille sur le tablier.
• « Perdant » quand il reste deux billes ou plus non adjacentes.
Gagner à ce jeu revient à résoudre un casse-tête assez compliqué. En effet, si un joueur fait un
mauvais choix de déplacement, il risque de perdre ses chances de victoires. C’est pourquoi, il est
parfois utile de faire des retours en arrière pour annuler certains déplacements.
Lors de la conception du jeu solitaire, un développeur a proposé le diagramme de classes UML
incomplet suivant :
6
Figure 2. Diagramme de classes
Travail à faire
On se propose de comprendre et compléter, la modélisation UML proposée par le développeur afin
de concevoir en partie le jeu en question.
Question 1
Élaborer deux diagrammes d’objets conformément au diagramme de classes proposé par le
développeur relatifs aux 2 situations suivantes :
reflétant une partie
comportant
a) Un
tablier
initialement 3 billes comme l’illustre la figure 3.
b) La terminaison de la partie susmentionnée dans le
cas où le joueur gagne.
- Remarque : Pour des raisons de clarté, on vous
demande de représenter que
les cases occupées
initialement ou lors du déplacement. Nommer vos objets
cases comme suit : ci,j (i est le n°de ligne et j est le n° de
colonne).
Question 2
Figure 3. Tablier comportant 3 billes
Pour comprendre les règles de gestion gouvernant l’évolution des liens entre les objets, on se
propose de décorer les associations par les contraintes {ordered}, {addOnly}, {frozen},
{notUnique}. Donner pour chacune de ces associations les contraintes appropriées tout en
justifiant votre réponse
Question 3
L’implémentation de l’association “Partie-Déplacement” nécessite l’utilisation d’une structure qui
implémente une collection (non définie dans le modèle UML proposé par le développeur). Choisir
parmi les collections suivantes: tableau statique, tableau dynamique, liste simplement chaînée, liste
doublement chaînée, pile). Justifier brièvement votre choix.
Question 4
Afin de faciliter l’implémentation des associations, on se propose de limiter au maximum possible
la navigation. Préciser autant de fois que possible le sens de navigations unidirectionnels sur le
diagramme de classes proposé par le développeur.
Question 5
On suppose que les méthodes de gestion des liens relatifs aux associations est à la charge du
développeur (design tip = {ignore}). Proposer, moyennant la notation UML, la signature des
méthodes de gestion relatives aux associations.
7