Diagrammes de déploiement, de composants, de paquetages et d'objets

Quatre diagrammes de structure complètent le diagramme de classes. Le diagramme de déploiement montre sur quelles machines s'exécute chaque partie de l'application et comment elles communiquent. Le diagramme de composants découpe le logiciel en blocs reliés par des interfaces. Le diagramme de paquetages montre comment le code est rangé, en couches ou en modules. Le diagramme d'objets montre des objets précis, avec leurs valeurs, à un instant donné. Ils tombent moins souvent à l'examen, mais ils sont précieux pour expliquer l'architecture d'une réalisation dans ton dossier d'E6. Ce chapitre les présente sur l'exemple d'AppliFrais.

Le diagramme de déploiement

Le diagramme de déploiement représente l'architecture physique : les nœuds (machines, serveurs, conteneurs, environnements d'exécution), les artefacts installés dessus (fichiers exécutables, archives, scripts, bases) et les chemins de communication entre les nœuds, avec leur protocole.

Ce diagramme répond aux questions que se pose l'équipe d'exploitation : quels serveurs installer, avec quels logiciels, quels flux ouvrir dans le pare-feu (443 depuis l'extérieur, 3306 seulement entre le serveur applicatif et la base). C'est le point de rencontre entre l'option SLAM et l'option SISR : le développeur dit ce dont son application a besoin, l'administrateur dit où et comment il l'installe.

Le diagramme de composants

Un composant est une partie remplaçable du système, qui fournit des services par des interfaces et en requiert d'autres. Le diagramme de composants montre l'architecture logique : de quels blocs est fait le logiciel, et qui dépend de qui.

• Un composant se dessine par un rectangle avec le stéréotype «component» (ou une petite icône à deux languettes).
• Une interface fournie se dessine par une « sucette » (lollipop) : un trait terminé par un cercle, avec le nom de l'interface.
• Une interface requise se dessine par une « prise » (socket) : un trait terminé par un demi-cercle.
• Quand la prise d'un composant s'emboîte dans la sucette d'un autre, le premier utilise ce que le second fournit.

Pour AppliFrais : le composant Front visiteurs (React) requiert l'interface API Fiches ; le composant API AppliFrais (Node.js) la fournit, et requiert l'interface Stockage, fournie par le composant Base gsb_frais. L'application Compta (C#) requiert aussi API Fiches. On peut remplacer le front React par une application mobile sans toucher à l'API, tant que l'interface reste la même : c'est exactement ce que le diagramme rend visible. Le contrat de l'interface API Fiches, ce sont les routes de l'API, documentées avec OpenAPI (cours API REST).

Le diagramme de paquetages

Un paquetage (package) regroupe des éléments du modèle : des classes, des interfaces, d'autres paquetages. Il se dessine par un dossier à onglet. Le diagramme de paquetages montre l'organisation du code et les dépendances entre paquetages, par des flèches pointillées.

La règle que ce diagramme permet de vérifier : les dépendances vont dans un seul sens, des couches hautes (l'interface) vers les couches basses (le modèle). Le modèle ne dépend de rien : on peut le tester seul, ou le réutiliser dans une autre interface. Une dépendance qui remonte (le modèle qui appellerait une vue) crée un cycle, et les cycles rendent le code impossible à faire évoluer morceau par morceau. Les architectures en couches et le modèle MVC sont détaillés dans le cours Architecture MVC (architecture en couches, client-serveur et n-tiers).

En C#, un paquetage correspond à un espace de noms (namespace AppliFrais.Modele), souvent à un dossier du projet, parfois à un projet séparé de la solution. En TypeScript, c'est un dossier de modules ; en PHP, un espace de noms.

Le diagramme d'objets

Le diagramme d'objets montre des instances à un instant précis : chaque objet est un rectangle titré nom : Classe (souligné), avec les valeurs de ses attributs, et les liens (instances d'associations) qui le relient aux autres objets. Il n'a ni opérations ni multiplicités : un lien relie exactement deux objets.

Le diagramme d'objets sert à trois choses :

• vérifier un diagramme de classes sur un exemple concret : si l'on n'arrive pas à dessiner une situation réelle avec les classes et les multiplicités prévues, le diagramme de classes est faux ;
• expliquer une structure complexe (une association réflexive, une classe-association) avec un cas que tout le monde comprend ;
• préparer des tests : un diagramme d'objets est un jeu de données de départ.

Ne le confonds pas avec le diagramme de classes : fiche : FicheFrais (souligné, avec des valeurs) est un objet ; FicheFrais (en gras, avec des types) est une classe.

Exercices

Exercice 1 sur 4 Lire le diagramme de déploiement Réussi À revoir

À partir du diagramme de déploiement d'AppliFrais :

1. Quels ports faut-il ouvrir sur le pare-feu entre Internet et les serveurs ? entre le serveur applicatif et le serveur de base de données ?
2. Le poste du comptable se connecte-t-il directement à la base de données ? Pourquoi est-ce un bon choix ?
3. GSB veut ajouter une application mobile pour les visiteurs. Que faut-il ajouter au diagramme ?

Voir la réponseMasquer la réponse de l'exercice 1

1. Depuis Internet : le port 443 (HTTPS) vers le serveur web et vers le serveur applicatif. Entre le serveur applicatif et la base : le port 3306 (MySQL), uniquement sur le réseau interne ; la base n'est jamais exposée à Internet.
2. Non, il passe par l'API en HTTPS. Les règles métier et les contrôles d'accès sont centralisés dans l'API ; la base n'accepte qu'un seul client, le serveur applicatif, avec un compte aux droits limités ; et le poste n'a pas besoin des identifiants de la base, qui pourraient fuiter.
3. Un nœud «device» Smartphone (multiplicité *) contenant l'artefact de l'application mobile, relié au serveur applicatif par un chemin HTTPS (443). Rien ne change côté serveur si l'application mobile utilise la même API.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 4 Trouver le cycle Réussi À revoir

Dans une application, le paquetage Modele contient une classe Commande dont la méthode Valider() appelle FenetrePrincipale.AfficherMessage("Commande validée"), une classe du paquetage Vues. Dessine les dépendances entre Vues, Controleurs et Modele, explique le problème et propose une correction.

Voir la réponseMasquer la réponse de l'exercice 2

Dépendances : Vues ┈▸ Controleurs ┈▸ Modele, et la nouvelle Modele ┈▸ Vues. Elles forment un cycle : on ne peut plus compiler, tester ou réutiliser le modèle sans les vues. Un test unitaire de Commande.Valider() ouvrirait une fenêtre.

Correction : Valider() ne fait que changer l'état de la commande (et lève une exception si c'est impossible). C'est le contrôleur, après l'appel, qui demande à la vue d'afficher le message. Si le modèle doit vraiment prévenir l'extérieur, il expose un événement ou utilise une interface définie dans le modèle et implémentée ailleurs, ce qui inverse la dépendance.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 4 Diagramme d'objets et multiplicités Réussi À revoir

Le diagramme de classes d'une médiathèque indique Adherent "1" ──── "0..5" Emprunt et Emprunt "0..*" ──── "1" Exemplaire. Pour chaque situation, dis si un diagramme d'objets peut la représenter.

1. L'adhérent Paul a 6 emprunts en cours.
2. Un emprunt concerne deux exemplaires.
3. L'exemplaire n° 4521 n'a jamais été emprunté.
4. Un emprunt n'est relié à aucun adhérent.

Voir la réponseMasquer la réponse de l'exercice 3

1. Non : la multiplicité 0..5 limite un adhérent à 5 emprunts. Si la règle de gestion permet 6 emprunts, le diagramme de classes est faux.
2. Non : un emprunt concerne exactement 1 exemplaire. Pour emprunter deux exemplaires, il faut deux emprunts.
3. Oui : un exemplaire est relié à 0..* emprunts, zéro compris.
4. Non : un emprunt a exactement 1 adhérent.

C'est l'usage typique du diagramme d'objets : confronter le diagramme de classes à des situations concrètes pour trouver les multiplicités fausses.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 4 sur 4 Brancher le service de paie Réussi À revoir

Le service de paie de GSB expose une API de virements, API Virements, hébergée sur son propre serveur. La mise en paiement des fiches validées, déclenchée par un comptable dans l'application Compta, doit désormais l'appeler.

1. Complète le diagramme de composants : où places-tu la sucette et la prise de API Virements ? Justifie ton choix entre « Compta appelle l'API Virements » et « l'API AppliFrais appelle l'API Virements ».
2. Complète le diagramme de déploiement : nouveau nœud, artefact, chemin de communication et protocole.
3. Quelle règle de pare-feu faut-il ajouter ?

Voir la réponseMasquer la réponse de l'exercice 4

1. Un nouveau composant Service de paie fournit l'interface API Virements (la sucette). C'est le composant API AppliFrais qui la requiert (la prise), pas Compta : Compta continue d'appeler seulement API Fiches, par exemple une route de mise en paiement, et l'API AppliFrais appelle à son tour API Virements. Trois raisons : les identifiants d'accès à l'API de paie restent sur le serveur au lieu d'être copiés sur chaque poste comptable ; le changement d'état des fiches (Validée → Mise en paiement) et l'appel de paiement se font au même endroit, ce qui permet de les journaliser ensemble ; et si le service de paie change d'API, une seule application est à modifier. C'est la même logique que pour la base de données : un seul client par ressource sensible.
2. Un nœud «device» Serveur de paie, géré par le service de paie, contenant l'artefact api-virements ; un chemin de communication HTTPS (443) entre le serveur applicatif et ce nouveau nœud. Aucun chemin entre le poste du comptable et le serveur de paie.
3. Une règle qui autorise le serveur applicatif, et lui seul, à ouvrir des connexions sortantes en HTTPS (443) vers le serveur de paie. Les postes comptables n'en ont pas besoin.

Tu avais trouvé ?

Oui, j'avais bonPas encore