1. Isoler la couche métier pour prévoir la réutilisabilité des classes du domaine . Un découpage possible en sous-systèmes est présenté à la figure 6.39. Il y a quatre couches :

•   Tout en haut, la couche de présentation  contient  l’interface homme  machine du pompiste.

•   Les classes contrôleurs  (SessionDePriseDeCarburant, SessionDePaiement et Gestionnaire- DesArchivages) constituent la couche applicative.

•   La logique métier est composée des classes du domaine (représentées ici par les paquetages qui les contiennent).

•   La gestion des périphériques  (capteurs  de niveau des cuves, gestion des pompes et du terminal de paiement) est incluse dans la couche de services.

À noter la relation de dépendance qui existe entre la couche applicative et la couche de services : elle indique que l’archivage dans la base de données (non  représentée)  est directe- ment géré par le gestionnaire de la persistance (GestionnairePersistance) sans passer par la couche métier.

Augmenter la réutilisabilité par partie du logiciel. Le découpage  en couches précédent  a permis d’isoler la partie métier (les classes du domaine) afin de ne pas l’encombrer avec les détails de l’application. Une autre  partition du  logiciel est possible par  fonctionnalités. D’ailleurs, bien souvent, ces deux types de découpage sont réalisés simultanément.

Une  partition  fonctionnelle  a déjà été réalisée quand  nous  avons séparé les classes du domaine en deux paquetages (figure 6.11). Il est possible d’isoler les paquetages en les plaçant dans un classeur structuré (voir l’annexe B). La figure 6.40 présente un classeur structuré qui contient le paquetage ServiceCarburant.

Le classeur PriseCarburant interagit  avec son environnement via des ports  (figure 6.41). Certains reçoivent l’état des capteurs pistolet et gâchette, d’autres servent d’interface avec le pompiste ou avec le moteur  de la pompe, d’autres encore servent à récupérer la quantité d’essence pompée.

Ces interfaces ont été élaborées à partir des classes contenues dans le paquetage du classeur structuré.Par exemple, la classe SessionDePriseDeCarburant contient  une opération destinée au pompiste, deux opérations qui servent d’interface avec le pistolet, et deux opérations qui sont reliées à la gâchette.

On retrouve  ces trois ensembles d’opérations  dans les trois interfaces : InterfacePompiste, InterfacePistolet et InterfaceGâchette (figure 6.43). Ainsi, une seule classe interne à un classeur structuré peut être accessible via plusieurs interfaces.

La figure 6.44 montre comment le classeur structuré PriseCarburant interagit avec son environnement quand  un client appuie sur une gâchette. Cette information est transmise au composant CapteurGâchette, puis circule via l’interface InterfaceGâchette jusqu’au classeur structuré PriseCarburant. Ce classeur est alors considéré comme une boîte noire (le compo- sant CapteurGâchette n’a pas accès à sa structure  interne). Il adopte un certain comporte- ment qui engendre éventuellement une commande sur son port de sortie. Cette commande est répercutée jusqu’au moteur de la pompe en passant par le composant Pompe qui implémente l’interface InterfacePompe (figure 6.45).

Le classeur PriseCarburant doit parfaitement s’insérer dans l’application. Pour le vérifier, les scénarios issus de l’analyse de l’application peuvent être repris afin de montrer  comment le classeur interagit avec son environnement.

Utiliser un classeur structuré muni de ports permet d’isoler la structure interne du classeur de son environnement. Le but étant de pouvoir facilement réutiliser ce classeur dans un environnement qui se conforme  aux interactions  imposées par ses ports. Le découpage opéré avec le classeur PriseCarburant pourrait  être reproduit  pour la gestion des transactions. Le système informatique  de la station-service  ainsi découpé gagne en modularité. Chaque sous-système, qui est isolé dans un classeur structuré, peut être facilement extrait du contexte de l’application courante et utilisé dans une autre application..

2. Le modèle des états d’un système est généralement  utilisé pour repérer  les objets qui s’exécutent en parallèle : deux objets s’exécutent potentiellement en parallèle s’ils peu- vent recevoir des événements en même temps sans interagir. Si les événements ne sont pas synchronisés, ces objets ne peuvent pas être traités dans le même thread de contrôle.

Dans notre cas, les événements qui concernent  la prise de carburant par un client ainsi que le paiement sont séquentiels. En revanche, chaque client doit avoir sa propre session de prise de carburant et de paiement. Les instances des classes SessionDePriseDeCarburant et SessionDePaiement s’exécutent toutes  en  parallèle sans interagir, sauf au  moment de l’archivage des  transactions.  L’archivage est  sous  le contrôle  d’un  objet  du  type GestionnaireDesArchivages (figure 6.35). Que se passe-t-il alors si un client paye après s’être servi de l’essence à minuit,  au moment  où l’archivage se déclenche ? L’archivage utilise une instance des TransactionsDuJour (figure 6.35) et cette même instance peut être utilisée concurremment par une session de paiement pour y ajouter la transaction  d’un client (figure 6.34). Le diagramme de la figure 6.47 utilise l’opérateur d’interaction par pour  montrer  que le gestionnaire  des archivages et la session client peuvent accéder concurremment à l’instance de TransactionsDuJour (le deuxième opérande est extrait de l’interaction de la figure 6.34, où seul le message « Ajouter la transaction client » est pris en considération).  Pour que la session de paiement ne vienne pas perturber  l’archivage, cette fonction  est réalisée dans une  section critique  grâce à l’opérateur  d’interaction ritical (voir Clicours.com).