Architecture logicielle : pourquoi séparer les responsabilités

L'architecture logicielle d'une application est son organisation d'ensemble : les parties qui la composent, le rôle de chacune et les règles qui disent qui a le droit d'appeler qui. Une bonne architecture ne change pas ce que fait l'application ; elle change le temps qu'il faut pour la comprendre, la corriger et la faire évoluer. Ce chapitre part d'un code mal rangé pour arriver aux trois idées qui guident tout le cours : séparer les responsabilités, réduire le couplage, augmenter la cohésion.

Le point de départ : un fichier qui fait tout

Voici la première version de la page de réservation de ResaSalles, écrite d'un seul jet par un stagiaire. Elle fonctionne.

<?php
// reserver.php : tout dans un seul fichier (à NE PAS reproduire)
session_start();
$pdo = new PDO('mysql:host=localhost;dbname=resasalles;charset=utf8mb4', 'root', 'root');

$salle = $pdo->query('SELECT * FROM salle WHERE id = ' . $_GET['id'])->fetch();

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $debut = $_POST['debut'];
    $fin = $_POST['fin'];
    if (strtotime($fin) - strtotime($debut) > 4 * 3600) {
        echo '<p style="color:red">4 heures maximum</p>';
    } elseif ($_POST['participants'] > $salle['capacite']) {
        echo '<p style="color:red">Salle trop petite</p>';
    } else {
        $pdo->exec("INSERT INTO reservation (salle_id, employe_id, debut, fin, objet, participants)
                    VALUES ({$salle['id']}, {$_SESSION['id']}, '$debut', '$fin', '{$_POST['objet']}', {$_POST['participants']})");
        echo '<p>Réservation enregistrée</p>';
    }
}
?>
<h1>Réserver la salle <?= $salle['nom'] ?></h1>
<form method="post">
  <input type="datetime-local" name="debut"> <input type="datetime-local" name="fin">
  <input name="objet"> <input type="number" name="participants">
  <button>Réserver</button>
</form>

Compte ce que fait ce fichier : il ouvre la connexion à la base, avec le mot de passe écrit en clair ; il lit les paramètres de la requête ; il applique deux règles de gestion ; il écrit du SQL ; il produit du HTML ; il affiche des messages. Six métiers différents dans trente lignes. C'est ce qu'on appelle du code spaghetti : tout est emmêlé, et tirer sur un fil fait bouger tout le reste.

Ce que ce code coûte

Le jour où il faut le modifier, les ennuis arrivent.

• Trouver. La règle « 4 heures maximum » est enfouie au milieu du HTML. Sur un projet de 40 pages, où est la règle qui refuse les réservations le week-end ? Il faut tout relire.
• Réutiliser. La direction veut une application mobile, ou un import des réservations depuis un fichier. Les règles sont coincées dans la page : il faudra les recopier, et les copies finiront par diverger.
• Tester. Pour vérifier la règle des 4 heures, il faut démarrer un serveur web, une base, se connecter et remplir le formulaire. Personne ne le fait à chaque modification.
• Sécuriser. Les valeurs saisies sont collées dans le SQL (injection SQL) et dans le HTML sans échappement (faille XSS). Quand le SQL est éparpillé dans 40 pages, il suffit d'un oubli pour ouvrir une faille (les injections).
• Travailler à plusieurs. Deux développeurs qui modifient la même page, l'un le design, l'autre une règle, se retrouvent en conflit Git à chaque fusion.
• Changer de technologie. Passer de MySQL à PostgreSQL, ou de pages HTML à une API JSON, oblige à réécrire chaque page.

La séparation des responsabilités

Le remède s'appelle la séparation des responsabilités (separation of concerns) : chaque partie du code s'occupe d'un seul sujet. Dans ResaSalles, on distingue au moins quatre sujets :

Chaque sujet change pour des raisons différentes : le design change quand on refait la charte graphique, les règles quand la direction change de politique, l'accès aux données quand on change de base. Si chaque sujet vit dans ses propres fichiers, chaque changement ne touche qu'un endroit.

L'analogie du restaurant aide à s'en souvenir. La salle (la présentation) accueille le client et lui présente la carte. Le serveur (la coordination) prend la commande, la transmet en cuisine, rapporte l'assiette. La cuisine (les règles et les données) connaît les recettes et les stocks. Le serveur ne cuisine pas ; le cuisinier ne vient pas en salle. On peut refaire la décoration de la salle sans changer les recettes.

Couplage et cohésion

Deux mots reviennent dans toutes les discussions d'architecture, et la commission d'E6 les apprécie quand ils sont bien employés.

Le couplage mesure à quel point une partie dépend des détails d'une autre. Le formulaire du stagiaire est fortement couplé à MySQL : il contient le nom des tables, le mot de passe, la syntaxe SQL. Un formulaire qui demande seulement « enregistre cette réservation » à une autre classe est faiblement couplé : il ignore comment elle s'y prend.

La cohésion mesure à quel point ce qui est rangé ensemble sert le même but. Un fichier ReservationRepository qui ne contient que les requêtes des réservations a une forte cohésion. Le fichier reserver.php du stagiaire a une faible cohésion : il mélange six sujets.

Le principe de responsabilité unique (le S de SOLID, Single Responsibility Principle) dit la même chose à l'échelle d'une classe : une classe ne devrait avoir qu'une seule raison de changer. Si tu modifies une classe à la fois parce que le format d'affichage change et parce qu'une règle de gestion change, elle porte deux responsabilités. Les principes SOLID sont présentés dans le cours de programmation orientée objet (les principes SOLID).

Style d'architecture, patron de conception, framework

Ces mots se mélangent souvent dans les copies. Ils ne sont pas au même niveau.

MVC est à la frontière : on l'appelle tantôt patron de conception (il est né à la fin des années 1970, au centre de recherche Xerox PARC, pour organiser les interfaces graphiques à l'échelle de quelques classes), tantôt patron d'architecture (il structure aujourd'hui des applications web entières). Les deux réponses sont acceptées si tu sais expliquer ce que MVC sépare.

La différence entre framework et bibliothèque tient en une phrase : tu appelles une bibliothèque, un framework t'appelle. C'est l'inversion de contrôle. Express appelle ta fonction quand une requête arrive sur une route ; toi, tu appelles PDO quand tu veux exécuter une requête.

Les qualités qu'une architecture recherche

On ne choisit pas une architecture pour faire joli : on la choisit pour obtenir des qualités. Ce sont les exigences non fonctionnelles, celles qui ne disent pas ce que fait l'application mais comment elle doit le faire.

La dernière ligne compte autant que les autres. Une architecture trop riche pour le besoin coûte cher elle aussi : dix microservices pour une application de réservation de salles, c'est dix déploiements à surveiller pour rien. Le chapitre 13 t'apprend à doser.

La place de l'architecture au BTS SIO

Dans le bloc 2 SLAM du référentiel, la compétence « Concevoir et développer une solution applicative » commence par l'analyse du besoin, puis par « Participer à la conception de l'architecture d'une solution applicative ». Concrètement, la commission de l'E6 attend que tu saches :

• fournir, dans ton dossier, un schéma de l'architecture de chaque réalisation : ce qui tourne sur le poste de l'utilisateur, sur le serveur, dans la base ;
• dire, quand tu analyses le besoin écrit par la commission, dans quelle couche se trouve la fonctionnalité à faire évoluer, et donc quels fichiers modifier ;
• justifier tes choix : pourquoi une API, pourquoi un client lourd, pourquoi ce découpage ;
• respecter l'organisation existante quand tu ajoutes du code pendant l'heure de réalisation.

Le cours Épreuve E6 SLAM détaille l'environnement technologique exigé. Il impose plusieurs situations d'exécution (poste fixe, navigateur, terminal mobile, serveur) et des appels à des services distants : ce sont des contraintes d'architecture, traitées au chapitre 13.

Exercices