Admin CliCours
Pour un système complexe, il vaut mieux se concentrer sur les fonctions essentielles puis passer aux cas moins importants.
Identification des principaux acteurs et recensement des cas d’utilisation essentiels L’acteur principal est évidemment le client. Il utilise le système pour obtenir de l’essence. Il est associé au cas d’utilisation « Se servir ». Rappel : dans un diagramme de cas d’utilisation, on ne détaille pas la séquence des opérations. Par exemple, le type d’essence choisi sera pris en compte quand on décrira le cas.
Imaginons le fonctionnement de la pompe : l’essence ne peut être distribuée que si la pompe est armée ; le client prend un pistolet ; sur le pupitre du pompiste est indiqué le type d’essence choisi ; le pompiste arme la pompe en appuyant sur un bouton de son pupitre, ce qui initialise la pompe.
Ainsi, le cas « Se servir » doit inclure l’armement de la pompe. Deux solutions sont possibles :
• La première utilise un cas unique (Se servir), et deux acteurs (Client et Pompiste), comme le montre la figure.
L’armement de la pompe est indispensable, sinon l’essence ne peut être distribuée, d’où la relation d’inclusion entre les cas « Se servir » et « Armer pompe ». L’armement de la pompe se fait en une seule action pour le pompiste : celle d’armer la pompe en appuyant sur un bouton. La description de l’armement se résume donc à une séquence très sommaire d’actions. Faut-il alors représenter cela par un cas d’utilisation ? L’argument qui fait pencher pour le maintien du cas « Armer pompe » est que l’armement est une opération bien isolée des autres fonctions : il s’agit d’initialiser la pompe et donc de piloter des périphériques (mécaniques, électroniques…). Vu sous cet angle, l’armement est suffisamment complexe et bien isolé des autres fonctions pour en faire un cas.
Le pompiste est un acteur secondaire du cas « Armer pompe » (c’est un cas interne pour lequel le pompiste est consulté). L’armement de la pompe n’est possible que si le niveau de la cuve est suffisant. Un détecteur de niveau (périphérique externe au système informatique) est nécessaire. Ce périphérique est représenté par l’acteur « Capteur niveau cuve pour armement ». Il est secondaire car l’information sur le niveau de la cuve ne lui est pas destinée. Si le niveau est trop bas, c’est le pompiste qui doit en être informé. Il saura ainsi ce qui empêche l’armement de la pompe. La vérification du niveau de la cuve est importante pour le système. De plus, cette opération constitue une transaction bien isolée des autres fonctions (il s’agit de contrôler un périphérique matériel). C’est la raison pour laquelle on décide de créer un cas « Vérifier niveau cuve pour armement ». Pour transmettre le niveau de la cuve au pompiste, il faut relier l’acteur Pompiste au cas « Vérifier niveau cuve pour armement ». Le pompiste est informé que le niveau est trop bas, mais la vérification doit être automatique pour que les pompes soient éventuellement bloquées. Une relation d’inclusion intervient donc entre les cas « Armer pompe » et « Vérifier niveau cuve pour armement ».
Recensement des cas de moindres importances
Après avoir trouvé les principaux cas, il est temps de se consacrer à ceux de moindre importance. Il ne faut pas oublier de couvrir tous les besoins et ne pas hésiter à introduire des cas auxquels le maître d’ouvrage n’a pas pensé. Il validera ou pas le modèle a posteriori.
L’énoncé n’aborde pas le problème du remplissage des cuves d’essence. Cette opération est réalisée par une entreprise tierce de livraison d’essence. Elle doit cependant être consignée dans le système informatique de la station-service. Une solution consiste à alerter le pompiste dès que le niveau des cuves descend au-dessous d’un certain seuil. Ce deuxième seuil, appelé « seuil de remplissage des cuves », doit être supérieur au seuil des 5 % de l’énoncé (celui qui empêche les pompes d’être armées). Quand il est atteint, le pompiste prévient l’entreprise de livraison d’essence de sorte à éviter de tomber au seuil des 5 %. Si la station- service est sur une autoroute, la livraison d’essence doit être garantie 24 heures sur 24. Il faut peut-être contacter la société de livraison automatiquement – sans passer par l’intermédiaire du pompiste – dès que le niveau devient trop bas. Le capteur du niveau de remplissage est représenté par un acteur appelé « Capteur niveau cuve pour remplissage » (figure 1.31). Il est associé au cas « Vérifier niveau cuve pour remplissage », lui-même associé à l’acteur Pompiste.
Abordons à présent le problème du paiement. De concert avec le maître d’ouvrage, le maître d’œuvre imagine un fonctionnement possible du système : dès que le client raccroche le pis- tolet, le montant à payer est calculé ; il s’affiche sur le pupitre du pompiste ; le client qui vient payer indique son mode de paiement (espèces, chèque ou carte bancaire) ; le pompiste sélectionne le mode de paiement choisi. À partir de là, les cas divergent :
• Pour un paiement en espèces, le pompiste encaisse le montant demandé, puis valide la transaction, qui est mémorisée dans le système informatique (le montant, la date de la transaction et le mode de paiement sont conservés).
• Si le paiement se fait par chèque, ce dernier est rempli automatiquement, puis le pompiste l’encaisse. La transaction est mémorisée dans le système informatique (en plus de la date, du montant et du mode paiement, sont conservés les références d’une pièce d’identité ou le numéro d’immatriculation du véhicule).
• Pour un paiement par carte bancaire, la banque de la station-service réalise une transaction avec la banque du client. Les seules informations à conserver dans le système informatique de la station-service sont le montant, la date de la transaction et le mode de paiement.
Comment représenter cela dans un diagramme de cas d’utilisation ? Une première solution (présentée à la figure 1.31) consiste à créer un cas général appelé « Payer », et trois cas particuliers reliés par une relation de spécialisation au cas « Payer ». Chacun des trois cas représente un mode de paiement.
Une autre solution (présentée à la figure 1.30) repose sur un cas, « Payer », qui se déroule jusqu’au choix du mode de paiement, puis, selon le type de paiement, un des trois modes est activé (« Payer en espèces », « Payer par chèque » ou « Payer par carte bancaire »). Ces trois cas sont typiquement des extensions du cas « Payer », où l’extension est soumise à condition.
Ces deux solutions sont possibles. Il est difficile de dire laquelle est la meilleure. La suite de l’exercice se fonde arbitrairement sur la représentation avec des relations de généralisation (figure 1.31). Le modélisateur se retrouve régulièrement face à ce dilemme. La réponse est souvent la même : peu importe la façon de modéliser un système du moment que le modèle est correct – un modèle est correct s’il montre une solution qui satisfait le maître d’ouvrage ainsi que les futurs utilisateurs du système.
Aboutir à une modélisation correcte
Il faut prendre le temps d’élaborer le diagramme de cas d’utilisation, bien qu’il soit généralement simple à bâtir, afin d’éviter les a priori qui peuvent conduire à une modélisation erronée.
À la relecture du fonctionnement du paiement tel qu’il est décrit précédemment, le pompiste devient l’acteur principal du cas de paiement. C’est un peu surprenant car on pourrait croire au premier abord qu’il s’agit du client. Or, la seule fois où le client intervient directe- ment sur le système informatique de la station-service est quand il saisit son numéro de carte bancaire. Toutes les autres situations nécessite l’intervention du pompiste. Attardons- nous un instant encore sur le paiement par carte bancaire. Il faut de toute évidence faire figurer un acteur supplémentaire qui représente la banque, car elle interagit avec le système sans en faire partie. C’est un acteur secondaire qui est sollicité uniquement pour confirmer le bon déroulement de la transaction. Quel est le rôle de cet acteur ? Le plus souvent, les solutions de paiement par carte bancaire sont disponibles clés en main sur le marché. Elles incluent un lecteur de cartes ainsi qu’un logiciel pour le piloter. Le maître d’œuvre doit pro- poser plusieurs solutions présentes sur le marché au maître d’ouvrage, et éventuellement une solution propriétaire si aucune solution du marché ne lui convient. Le maître d’ouvrage décidera. Dans le cadre de cet exercice, à défaut de pouvoir dialoguer avec un maître d’ouvrage, nous choisissons l’achat d’une solution clés en main pour le paiement par carte bancaire. Dans ce cas, le client, lorsqu’il saisit le code de sa carte, n’interagit plus directe- ment avec le système informatique de la station-service. Ainsi, quel que soit le mode de paiement, tout passe par l’intermédiaire du pompiste. Le client n’est donc pas un acteur du système.
Le calcul automatique du montant à payer peut se faire dès que le client raccroche le pistolet (ce qui intervient à la fin du cas « Se servir »). Pour indiquer le moment où le montant est calculé, on peut ajouter une relation d’extension entre les cas « Se servir » et « Payer », avec un point d’extension qui précise le moment où le calcul du montant intervient, comme le montre la figure 1.31. Le paiement peut aussi intervenir avant de se servir. Dans ce cas, il est possible d’ajouter un deuxième point d’extension (voir la figure 6.17 du chapitre 6).
Modélisation des concepts abstraits
Parfois, le langage UML peut paraître limité. Il faut alors trouver, parmi les éléments du langage, celui qui convient le mieux à une situation donnée.
Un dernier besoin n’est pas décrit par le diagramme de cas d’utilisation : c’est l’archivage en fin de journée des transactions. Faut-il prendre en compte ce cas et, si oui, quel acteur l’utilise ? Un cas d’utilisation est déclenché par un événement. Les événements peuvent être classés en trois catégories :
• Les événements externes. Ils sont déclenchés par des acteurs.
• Les événements temporels. Ils résultent de l’atteinte d’un moment dans le temps.
• Les événements d’états. Ils se produisent quand quelque chose dans le système nécessite un traitement.
Ici, il s’agit d’un événement temporel. Il est difficile de définir un acteur qui déclencherait cet événement. Comment le temps peut-il interagir avec un système ? Cela dit, l’archivage quotidien est une fonctionnalité essentielle. Il faut la faire figurer dans la modélisation du système. À quelle étape de la modélisation doit-on prendre en compte cette fonctionnalité ? Comme nous en sommes à produire le premier modèle du système et que cette fonctionna- lité est importante, nous choisissons, pour ne pas l’oublier, d’en faire un cas d’utilisation. Pour déclencher ce cas, nous introduisons un acteur appelé Timer qui, une fois par jour, déclenche un événement temporel. Timer est un acteur, il est donc en dehors du système. Cela signifie que l’heure est donnée par une horloge externe à notre système informatique (par exemple, l’horloge du système d’exploitation du système informatique).
La prise en compte des événements d’états est plus délicate puisque, par définition, ils se produisent à l’intérieur d’un système. Ils ne peuvent donc pas être déclenchés par un acteur, qui est forcément en dehors du système. Il est toutefois possible qu’un événement d’état active un cas d’utilisation à condition que ce cas soit interne au système. Une façon de représenter un cas de ce type consiste à le relier à d’autres cas via des relations d’extension et à faire figurer comme condition d’extension l’événement d’état. C’est cette solution qui a été adoptée entre les cas « Se servir » et « Payer », en considérant ce dernier comme un cas interne vis-à-vis du cas « Se servir ».
