Soit un robot modélisé comme suit ¹⁾ :

Le robot dispose d’un bras articulé se terminant par une pince.
Le robot peut rapporter des objets. Pour rapporter un objet le robot doit déplier son bras, puis saisir l’objet avec sa pince, puis replier son bras et enfin lâcher l’objet.

Dessiner le diagramme de séquence correspondant à ce cas d'utilisation. Vous prendrez pour élément déclencheur de “rapporterObjet” un autre programme, que vous nommerez main(Principal).

Soit un jeu vidéos avec des Personnages.

Les Personnages ont un nom, une force et une expérience.
Ces deux dernières caractéristiques sont des entiers positifs ou nuls.
L’expérience vaut 0 quand le personnage débute.
1- Dessiner le diagramme de classe correspondant à cette définition de Personnage

Un personnage peut partager son experience dans une certaine mesure (une valeur entiere d'expérience pour le TD) avec un autre Personnage.
2- Compléter le diagramme de classe correspondant à cette définition de Personnage.

Un joueur lance une partie de démonstration.
Dans cette version de démonstration, lancer une partie consiste à :

1. demander le nom, la force et l'experience d'un personnage,
2. à créer ce personnage,
3. demander le nom, la force et l'experience d'un personnage,
4. à créer ce nouveau personnage,
5. à demander quel personnage va partager son expérience et quelle partie d'expérience partager,
6. à partager l'expérience
7. à montrer que le personnage a bien reçu de l'expérience en plus.

3- Dessiner un diagramme de séquence correspondant à lancer une partie.

4- Compléter le diagramme de classes en conséquence. Pour représenter un constructeur vous sélectionnez isStatic dans la definition de la méthode, elle apparait alors soulignée.

Les personnages peuvent acquerir ou voler des choses.
Une chose est définie par une expérience requise.
Une chose peut appartenir à au plus un personnage.
Une chose peut être acquise par un personnage, uniquement si le personnage a assez d'expérience et si la chose n'appartient à personne.

5- Compléter le diagramme de classe avec ces informations.

Il est possible de voler une chose, mais on ne peut pas savoir à qui appartient la chose. Mais pour cela, il faut : 1) avoir assez d'expérience pour posséder la chose, 2) avoir plus de force que le personnage qui possede la chose. Seulement seule la “chose” a toutes ces informations. Voici le diagramme de séquence imaginé par le concepteur.

6- Complétez votre diagramme de classes en conséquence.

Certaines choses sont payantes. Elles ne peuvent être acquises par un personnage que s'il a assez d'argent. Par contre, il peut toujours les voler s'il a assez d'expérience.

7- Complétez votre diagramme de classes en conséquence.

Les armes sont des “Choses Payantes” qui ne peuvent être acquises que si on a assez de force pour s'en servir. On considére que l'expérience ne suffit plus.

8- Complétez votre diagramme de classes en conséquence.

Les pouvoirs sont des choses qu'il n'est pas possible de voler; elle se contente de ne pas transmettre le pouvoir, jamais, mais en silence ou si vous avez prévu un boolen en retour elle renvoie toujours faux.

9- Complétez votre diagramme de classes en conséquence.

On considère à présent que les choses peuvent donner de la force au personnage qui les possèdent. Ainsi la force d'un personnage est la force intrinseque du personnage multipliée par la somme des forces que lui donnent les choses qu'il possède. C'est à dire :

Que se passe-t-il si vous n'aviez pas prévu d'accéder à la force d'un personnage par une méthode?

10- Complétez votre diagramme de classes en conséquence.

Certains personnages, les apprenants acquierent de l'expérience lorsqu'ils acquierent des choses. Ainsi les choses ne leur donnent pas seulement de la force mais également de l'expérience. Seulement eux savent en profiter.

Soit un apprenant a, lui ajouter une chose cO (a.addChose(co)) augmente son expérience de cO.getExperienceDonnee().

Par défaut les choses ne donnent aucune expérience. Les livres et les pouvoirs sont des choses qui donnent de l'expérience.

11- Complétez votre diagramme de classes en conséquence.

Etude Fil rouge : Cohérence entre Diagrammes de cas d'utilisation, de séquences et Diagrammes de classes

Ces exemples sont issus et très fortement modifiés de http://bliaudet.free.fr/IMG/pdf/TD-UML-1-2-3-4-Corriges.pdf

Pour aider ceux qui auraient du mal