Révisions des principes d'UML...

En général, l'examen approchant, le stress monte, et on a tendance à croire que l'on a tout oublié !
J'ai fait cette page pour vous permettre de tester vos capacités, ainsi que pour vous rappeler certain concepts d'UML...

1) les Uses Case (cas d'utilisation)

A quoi ça sert ?

Avec un diagramme de cas d'utilisation, on cherche à décrire le comportement du système (actions et réactions), selon le point de vue de l’utilisateur.
On va donc chercher à décrire le système, ainsi que les relations entre le système et l’environnement.

On peut donc dire que les diagrammes de cas d'utilisations :

• Permettent de délimiter les frontières du système
  ce qui nous intéresse, et ce que l'on ne fera pas
• Constituent un moyen d’exprimer les besoins d’un système
  simple à interpréter
• Utilisés par les utilisateurs finaux pour exprimer leurs attentes et leurs besoins
  permet de communiquer efficacement avec des non-informaticiens
• Permettent d’impliquer les utilisateurs dès les premiers stades du développement
  en dessinant des petites ronds avec des flèches, ils ont l'impression de s'impliquer dans le processus de développement
• Constituent une base pour les tests fonctionnels
  une fois l'application presque terminée, on se réfère à ce diagramme pour voir si ce qu'on a fait correspond aux attentes

Comment les construire ?

La création de ces diagrammes n'est pas facile. La première des erreurs vient du fait que l'on essaye de dire trop de chose dans un seul diagramme. Pour qu'il reste visible, il vaut mieux en faire 2-3, plutôt que d'en faire un seul avec des flèches et des cas d'utilisations partout. Donc, ne pas hésiter à découper un diagramme.

Pour qu'un diagramme de cas d'utilisation soit bien fait, il faut qu'il réponde à ces questions :

• Quelle partie je veux représenter ?
  le guichet par exemple
• Qui utilise ce que je décris ?
  ce sera les acteurs, représentés par des bonhommes
• Que puis-je faire avec mon objet ?
  c'est les cas d'utilisation - les ronds

Les principales erreurs viennent de ces trois questions... Commencez donc par y répondre, sans chercher à le traduire en diagramme.

Par ailleurs, essayez d'utiliser des verbes pour vos cas d'utilisation.

Petit exercice

Répondez aux trois questions précédente pour la situation suivante :

Un client arrive à la caisse avec des articles à acheter. Le caissier enregistre les articles et prend le payement. Le client peut ensuite partir avec les articles.
Solution (cliquez-moi...)

• Quelle partie je veux représenter ?
  On va représenter la caisse... C'est la machine qui réuni tous les acteurs, et ces acteurs font des actions sur cette machine...
• Qui utilise ce que je décris ?
  Y'a le client... Le caissier utilise aussi la machine. On pourrait aussi faire figurer le groupement bancaire qui valide le payement...
• Que puis-je faire avec mon objet ?
  Avec la caisse, on peut : déposer des articles, enregistrer les articles, payer, mais aussi reprendre les articles (pour les emporter chez soi ;-)

Ajouter du détail

Bon, en répondant aux 3 questions, on a déjà une base... Mais ça ne suffit pas pour avoir une bonne note. Il faut rajouter du détail.
En général, il faut essayer de placer au moins un "include" ou un "extends" ! En effet, quand on fait un exercice (nous les salauds de profs), on cherche à utiliser le plus de choses vues en cours...

Donc pour placer ces liens particuliers, il faut essayer de répondre aux questions suivantes :

• Peut-on séparer en deux un cas d'utilisation ?
  (prend le payement peut être séparé en deux : encaisser et vérifier solde)
• Y a-t-il des liens entre les cas d'utilisation ?
  lien d'extension (qui précise l'objectif, le comportement) ou d'inclusion (qui a besoin ou qui utilise l'objectif)

Suite et fin de l'exercice

Avec tous ces éléments, faites le diagramme de cas d'utilisation de l'exemple donné plus haut.
Solution (cliquez-moi...)

Je vous propose une des solutions de l'exercice (il est possible d'en faire d'autre).
J'ai rajouté du détail qui n'était pas fournit par l'énoncé. Attention, suivant les profs, c'est pas très bien vu, et surtout c'est source d'erreur, donc à éviter. Si j'ai fait ça, c'est pour mettre le plus d'infos et que vous compreniez bien les notions d'extends et d'include.

2) les Diagrammes de classe

Les diagrammes de classes font parti des diagrammes les plus importants. En effet, dans votre vie de programmeurs, vous aurez souvent besoin de les utiliser (mais aussi de les créer).

A quoi ça sert ?

Les diagrammes de classe expriment la structure statique du système en termes de classes et de relations entre ces classes.
Rappel : Une classe est un type abstrait caractérisé par des propriétés (attributs et méthodes) communes à un ensemble d'objets et permettant de créer des objets ayant ces propriétés.

Précisions.

Dans un diagramme de classe, ne pas représenter les attributs ou les méthodes d'une classe n'indique pas que cette classe n'en contient pas. Il s'agit juste d'un filtre visuel, destiné à donner un certain niveau d'abstraction à son modèle. C'est notamment utile lorsque l'on a beaucoup de classes, et que l'on veuille toutes les représenter.
De même, ne pas spécifier les niveaux d’accès des membres d'une classe ne veut pas dire qu'on ne représente que les membres publics

Pour un modèle complexe, plusieurs diagrammes de classes complémentaires doivent être construits.

On peut par exemple se focaliser sur :

• les classes qui participent à un cas d'utilisation (cf. collaboration)
• les classes associées dans la réalisation d'un scénario précis
• les classes qui composent un paquetage
• la structure hiérarchique d'un ensemble de classes

Transformation d'un diagramme de classe en C++

Lorsque l'on a fini de faire un diagramme de classe, on souhaite bien souvent le traduire en C++. C'est une étape cruciale et très facile, à condition de respecter un certain nombre de règles...
Détaillons un peu tout ça :

Les classes.

Comment transformer la classe Conducteur en C++?

Tout d'abord, occupons nous de la visibilité. "+" veut dire public, "-" veut dire private et "#" veut dire protected.
Ensuite, par soucis de lisibilité, écrire le code C++ qui correspond aux les attributs avant les méthodes (ça marche dans le désordre, mais pour s'y retrouver après...).
Enfin, faites attention à renverser l'ordre des types (en UML, c'est le nom puis le type, en C++ c'est l'inverse).

Resultat (cliquez-moi ;-).

Attention, les liens entre Conducteur et Voiture n'apparaissent pas encore...

Les liens "simples"

L'un des avantages des diagrammes de classe se trouve dans la possibilité de représenter les liens entre les classes. Mais quand on doit passer à du code (C++ ou Java), on a bien souvent bien du mal à savoir comment transformer ces liens. De plus, il n'y a pas de règle absolue, la norme UML n'explique pas comment les transformer. Cependant, avec un peu de logique, on peut s'en sortir ;-)

Donc comment transformer un lien "simple". (par lien "simple", je veux dire tout ce qui n'est pas héritage, ni agrégation, ni... Un lien "simple" quoi ;-).
Pour bien comprendre, reprenons le diagramme donné un peu plus haut. Comment implémenter le fait qu'un conducteur peut conduire 0 ou plusieurs voitures ?

Attention : ne pas se mélanger les pinceaux !
J'en vois 2-3 au fond de la classe qui se préparent à me dire "Comment ça plusieurs voitures? Il peut en conduire plusieurs en même temps ???".
La question du "en même temps" ne se pose pas : un diagramme de classe, c'est statique et donc le temps n'existe pas.

Intuitivement, on va se dire (ou pas ;-) : "0 ou plusieurs, avec ça, on va se faire un tableau de Voiture!".
Et on aurait presque raison. Le problème avec les tableaux, c'est qu'il y a un nombre de cases max connu dès le début. Et notre * est là pour nous mettre des bâtons dans les tableaux. Règle : les tableaux ne peuvent pas servir quand on a une étoile en cardinalité.

"Bon... On pourrait utiliser un pointeur vers la classe Voiture ?". Encore raté. Le pointeur ne montre pas assez qu'il y a potentiellement plusieurs Voitures... Cependant, on se rapproche de la solution.

La solution que je trouve la plus juste revient à utiliser les vecteurs en C++. Un petit effort de mémoire pour vous souvenir des classes vector...

L'avantage de cette classe est qu'elle permet d'ajouter, d'enlever ou de modifier des cases à la volé. Donc l'esprit du "0 ou plusieurs" est conservé !

On aurait pu aussi faire une liste chainée de Voiture, mais ça alourdirait le code... Autant se servir de la classe vector qui est en réalité une liste chainée améliorée !

Règles de conversion des liens "simples".

• Lien 0 :
  il n'y a pas besoin de faire figurer la classe distante dans la classe source.
• Lien N (N étant un nombre fini : 2,4 100...)
  Utiliser un tableau simple du type de la classe distante.
• Lien 0..N ou M..N (M et N étant des nombres fini : 2,4 100...)
  Utiliser un vecteur, ou un tableau simple de pointeur sur la classe distante.
• Lien 0..* ou M..* (M et N étant des nombres fini : 2,4 100...)
  Utiliser un vecteur.

Appliquez ces concepts sur les deux classes Conducteur et Voiture...
Solution (cliquez-moi...)

J'ai mis les attributs en protected, mais c'est totalement arbitraire. Vous pouvez les mettre en public ou en private, ça dépend de ce que vous voulez en faire.

Règles de conversion des compositions et des agrégations.

Si on a bien compris ce que c'est qu'une agrégation et une composition, ça ne devrait pas poser de problème.

Le seul truc à bien comprendre, c'est que dans le cas d'une agrégation, la vie des objets est indépendante, tandis qu'avec une composition, c'est lié.
Donc, on peut dire que le truc qu'apporte en plus ces deux types de liens, c'est de l'information sur la durée de vie...

La durée de vie d'un objet, c'est savoir quand un objet est créé et quand il est détruit. Donc rappels :

• Création d'un objet :
  Pour les pointeurs, c'est lorsque l'on fait un new.
  Pour le reste, c'est dans le constructeur.
• Destruction d'un objet :
  Pour les pointeurs, c'est lorsque l'on fait un delete.
  Pour le reste, c'est dans le destructeur.

Donc, à la lumière de ces informations, déduire ce qu'il faut rajouter pour faire figurer ces infos dans le code C++.
Solution (cliquez-moi...)

• Agrégation :
  On ne doit ni créer, ni détruire les objets agrégés en même temps que l'objet agrégat.
  On doit donc utiliser les pointeurs. Donc dans les règles énoncées plus haut, il faut essayer de mettre du pointeur un peu partout...
• Composition :
  On doit créer et détruire les objets composés en même temps que l'objet qui contient les autres.
  Si on veut utiliser les pointeurs, il faut faire un new dans le constructeur et un delete dans le destructeur. Mais il est aussi possible d'utiliser les tableaux simple (qui s'auto-crééent dans le constructeur et s'auto-détruisent dans le destructeur).