1. Pour spécifier l’interface homme-machine, on en construit souvent une maquette (figure 6.24). Elle représente l’écran principal auquel fait face le pompiste. Il est composé de n zones, chacune appelée « Pompe i » (pour i allant de 1 à n). Chaque zone est constituée de quatre boutons qui permettent au pompiste de demander l’armement d’une pompe. Si le niveau d’essence dans les cuves est suffisant, la pompe est armée et le bouton correspondant reste enfoncé. Si, au contraire, le niveau d’essence est insuffisant, le bouton de la pompe apparaît en rouge. Dès que le client a fini de se servir (il a raccroché le pistolet), le bouton de la pompe correspondant au type d’essence qu’il a pris clignote. Les boutons correspondant aux types d’essence choisis peuvent être dans l’un des états suivants :
• non enfoncé (pompe désarmée) ;
• enfoncé (pompe armée) ;
• rouge (armement impossible) ;
• clignotant (fin de prise de carburant).
Dès que le pompiste appuie sur un bouton clignotant, la zone de l’écran correspondant à la pompe est remplacée par une zone servant au paiement (figure 6.25).
Le pompiste peut choisir, via l’interface présentée à la figure 6.25, le type de paiement désiré par le client (carte bancaire, chèque ou espèces). Le bouton correspondant au mode de paiement choisi reste enfoncé une fois sélectionné. Le pompiste peut appuyer sur le bouton qui valide la transaction dès que le client a payé.
À partir de cette maquette la démarche consiste à bâtir un diagramme de classes qui doit refléter les échanges de données véhiculées entre cette interface et le cœur du logiciel.
La construction de ce diagramme suit les étapes habituelles suivantes :
• dresser une liste de classes ;
• trouver les associations entre les classes ;
• etc.
Ayant déjà réalisé une étude similaire pour construire le diagramme de classes du domaine, l’étude des classes de l’interface utilisateur n’a pas été reproduite.
2. Notre logiciel doit être interfacé avec des périphériques matériels : des capteurs de niveau d’essence dans les cuves, un terminal de paiement, etc. Nous nous contenterons d’étudier les périphériques qui gèrent le niveau de carburant dans les cuves. Vous pourrez facilement en déduire les autres cas par analogie.
La figure 6.26 est extraite du diagramme de déploiement de la figure 6.4. Seuls les nœuds permettant la gestion des capteurs de niveau sont représentés. Le périphérique de gestion des cuves est externe au système informatique de la station-service. Il s’agit par exemple d’un boîtier dont les extrémités sont raccordé à un capteur de niveau et à l’unité centrale. Un composant qui pilote le périphérique de gestion des cuves est chargé de fournir à une classe du domaine le niveau du carburant via une interface (appelé PiloteGestionCuve).
La figure 6.27 détaille l’interface InterfaceCuve et montre que la classe Cuve extraite du diagramme de classes de la figure 6.10 est cliente de cette interface.
3. En plus des classes qui se trouvent à la périphérie d’un système et celles qui gèrent l’inter- face homme-machine, un logiciel est constitué d’objets qui le contrôlent. Chaque objet contrôleur est dédié à une fonction particulière. Dans notre cas, il s’agit de trois fonctions bien distinctes : la prise d’essence, le paiement et l’archivage des transactions. Pour commencer, tentons d’imaginer un objet qui puisse contrôler la prise d’essence.
Session de prise d’essence. Dès qu’un client décroche un pistolet, des instances des classes Pistolet, Gâchette et DispositifDePompage sont prêtes à activer le périphérique matériel qui pompe l’essence. Les états des instances vont changer en fonction des actions des clients qui sont perçues par le système au travers de capteurs. Si N clients prennent du carburant simultanément, il y aura N ensembles d’instances de Pistolet, de Gâchette et de dispositifDePompage. Pour contrôler ces trois instances, nous créons une classe appelée SessionDePriseDeCarburant.
Le diagramme des objets présenté à la figure 6.28 montre deux clients qui se servent du super 98 simultanément, chacun ayant sa propre session.
Pour illustrer comment la session d’un client interagit avec les instances des classes Pistolet, Gâchette et DispositifDePompage, on définit une collaboration (figure 6.29).
Cette collaboration est décrite plus en détail à la figure 6.30. Elle débute par la création d’une session pour un client (instance de la classe SessionDePriseDeCarburant). Ensuite, des instances des classes Pistolet, Gâchette et Pompe sont créées à leur tour. C’est là un parti pris. Nous avons en effet décidé que ces instances n’existaient pas avant que le client décroche un pistolet. Une autre solution aurait consisté à disposer d’un pool d’objets prêts à l’emploi dans lequel on aurait pris à volonté des instances. Ce choix relève plutôt de la conception que de l’analyse. Considérons-le comme un scénario de conception possible. La figure 6.30 montre que les instances du pistolet et de la gâchette sont détruites dès que le client raccroche le pistolet. Deux autres diagrammes servant à illustrer l’armement de la pompe et la prise du carburant sont référencés.
L’armement de la pompe est illustré par le diagramme de la figure 6.31. On y voit que, avant d’armer la pompe, il faut tester si plusieurs pistolets ne sont pas décrochés, puis vérifier le niveau de la cuve. L’acteur CapteurNiveauPourArmement n’est pas représenté ici : il est sollicité implicitement par l’instance de la cuve.
La figure 6.31 fait référence au diagramme TestAutrePistoletPris qui n’est pas représenté (il s’agit simplement de demander à l’instance de l’EnsemblePompe de vérifier à l’aide d’une boucle qu’il n’y a pas plusieurs pistolets décrochés).
Le diagramme reproduit à la figure 6.32 détaille l’interaction ActivationPompe qui est référencée à la figure 6.30.
Session de paiement. Intéressons-nous à présent au paiement, et imaginons un objet pour le contrôler. Si la session de prise de carburant (instance de la classe SessionDePriseCarbu- rant) était prolongée de manière à englober le paiement, un objet pourrait alors contrôler le service de prise d’essence de « bout en bout », depuis le décrochage du pistolet jusqu’à la fin du paiement. Ce serait la session complète d’un client. Or, les classes du domaine ont été partitionnées en deux paquetages pour accroître la modularité du logiciel : un paquetage concerne la prise d’essence, l’autre le paiement. Une session client unique serait donc partagée entre les deux paquetages (elle débuterait avec la prise de carburant pour se terminer par le paiement). C’est pourquoi nous avons décidé de créer une nouvelle classe contrôleur (SessionDePaiement) qui se charge du paiement.
La figure 6.33 établit une collaboration entre des instances de PriseDeCarburant, de TransactionBancaire, de TransactionsDuJour et de SessionDePaiement. Les connecteurs entre les instances de PriseDeCarburant, de TransactionBancaire et de TransactionsDuJour représentent les associations du diagramme de classes du domaine (figure 6.10).
La figure 6.34 illustre les interactions au sein de la collaboration précédente. La session de paiement débute au moment où le pompiste demande, via son terminal, à encaisser la prise d’essence relative à une pompe et à un type de carburant. Le montant de la transaction est calculé à l’aide du type de carburant (qui permet d’avoir le prix du litre) et de la quantité d’essence prise. Le diagramme se poursuit par le déroulement du scénario nominal de paiement par carte bancaire. Une instance de TransactionBancaire est créée le temps de réaliser une transaction avec la banque. Dès que le pompiste valide la transaction, celle-ci est ajoutée aux transactions du jour pour être finalement détruite. La session de paiement se termine juste après, par la destruction de l’instance correspondante.
Un gestionnaire pour l’archivage. Après avoir trouvé des objets contrôleurs pour assurer les fonctions de prise d’essence et de paiement, intéressons-nous aux autres fonctions du logiciel. Pour cela, revenons au diagramme de cas d’utilisation de la figure 6.16. Deux cas n’ont pas été traités : « Vérifier niveau cuve pour remplissage » et « Archiver les trans- actions ». Le premier cas n’est pas étudié dans cet ouvrage car il ne présente pas un grand intérêt. L’archivage des transactions est plus intéressant.
Le diagramme de la figure 6.35 montre comment, en fin de journée, les transactions du jour sont archivées. Pour réaliser cette fonction, nous ajoutons une nouvelle classe, Gestionnaire- DesArchivages. Une seule instance de cette classe est nécessaire pour faire fonctionner l’archivage. L’objet correspondant est actif une fois par jour (à minuit). Il demande l’archivage des transactions du jour ; après quoi l’instance de la classe TransactionsDuJour est détruite pour être recréée aussitôt (et initialiser ainsi une nouvelle journée de transactions).
