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...)
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 indique une possibilité, un complément possible) 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...)
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).
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...)
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...)
