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.
Le système a donc été découpé en couches horizontales. L’application, essentiellement con- tenue dans la couche applicative, permet, grâce aux classes contrôleurs, de réaliser les cas d’utilisation. Sans ses classes contrôleurs, couche applicative et couche métier seraient mélangées à tel point que la réutilisabilité des classes de la couche métier serait compromise. La séparation entre logique applicative et logique métier permettra à une autre application de réutiliser les classes du domaine.
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).
Je voudrai apprendre l’uml par la pratique
Merci