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 ».