Vues et points de vue : ISO/IEC/IEEE 42010, 4+1, Rozanski et Woods

Un système, de nombreuses vues

Aucun diagramme unique ne peut décrire un système réel. Un dessin qui montre comment le code de la plateforme de livraison de repas est découpé en modules ne dit rien des serveurs sur lesquels ils tournent ; un dessin des serveurs et des réseaux ne dit rien de ce qui se passe, étape par étape, quand un livreur accepte une course. Si vous essayez de tout mettre sur une seule page, vous obtenez l’affiche d’architecture bien connue : des dizaines de boîtes, des traits qui signifient six choses différentes, et personne capable d’y trouver la réponse à une question précise.

L’idée qui résout ce problème est ancienne et simple. Décrivez le système au moyen de plusieurs vues, chacune montrant un ensemble de structures pour un ensemble de préoccupations, de même qu’un bâtiment est décrit par un plan des pièces, une élévation, un plan électrique et un plan de plomberie. Chacune est une description partielle ; ensemble, elles décrivent le tout. Cette idée sous-tend la norme internationale, le modèle 4+1 de Kruchten, le catalogue de points de vue de Rozanski et Woods, l’approche Views and Beyond du SEI et, sous une forme légère, le modèle C4 de la section suivante. Cette section explique le vocabulaire qu’ils partagent et comment choisir les vues dont un système particulier a besoin.

Rappelez-vous, d’après la section 1.5, qu’une partie prenante est toute personne qui a un intérêt dans le système et qu’une préoccupation est toute question importante pour une partie prenante. Les vues existent pour répondre aux préoccupations. Une vue qui ne répond à la préoccupation de personne n’est que de la décoration.

Le modèle conceptuel de l’ISO/IEC/IEEE 42010:2022

L’ISO/IEC/IEEE 42010 est la norme internationale de description d’architecture. Son édition actuelle a été publiée en 2022 et a remplacé l’édition de 2011. Elle ne vous dit pas comment concevoir, quelle notation utiliser ni quelles vues dessiner ; elle définit les concepts qu’une description d’architecture doit contenir et la façon dont ils se relient, pour que des descriptions produites par des méthodes différentes puissent être comparées et vérifiées. Son modèle conceptuel est le squelette commun de presque toutes les approches de documentation de ce chapitre.

Le modèle part de l’entité d’intérêt : la chose dont on décrit l’architecture, qui peut être un système logiciel, un système de systèmes, une gamme de produits ou une entreprise (l’édition de 2011 l’appelait le système d’intérêt). L’entité a une architecture, et une description d’architecture l’exprime. Dans la description, les parties prenantes ont des préoccupations. Un point de vue est une spécification réutilisable de conventions pour construire et utiliser un type de vue : il nomme les préoccupations qu’il encadre, les parties prenantes typiques et les types de modèles (notations et conventions de modélisation) à utiliser. Une vue applique un point de vue à une entité particulière : elle répond à ces préoccupations pour ce système, et se compose de composants de vue, comme des diagrammes, des tableaux et des modèles, chacun régi par un type de modèle (l’édition de 2011 appelait les composants de vue des modèles d’architecture).

Deux autres éléments comptent en pratique. Les correspondances consignent les relations entre éléments de la description, le plus utilement entre vues : ce conteneur de la vue des conteneurs tourne sur ce cluster de la vue de déploiement ; cette exigence est traitée par cette décision. Et les décisions d’architecture et leur justification font partie de la description, reliées aux préoccupations auxquelles elles répondent. L’édition de 2022 définit aussi plus complètement deux concepts que l’édition de 2011 mentionnait déjà, les perspectives des parties prenantes (des façons de regrouper les préoccupations) et les aspects d’architecture (des caractéristiques de l’entité qui traversent les vues), renomme « architecture framework » en cadre de description d’architecture, et définit ce que doivent contenir les cadres de description d’architecture conformes, comme le modèle de documentation propre à une entreprise.

Le modèle de vues 4+1 de Kruchten

Philippe Kruchten, alors chez Rational Software, a publié Architectural Blueprints: The "4+1" View Model of Software Architecture dans IEEE Software en novembre 1995. Le modèle de vues 4+1 a été la première approche multivue largement adoptée et a été intégré au Rational Unified Process. L’argument de Kruchten était que les diagrammes uniques de l’époque cherchaient à saisir trop de choses à la fois, et que des parties prenantes différentes (utilisateurs finaux, développeurs, ingénieurs système, chefs de projet) ont besoin de vues différentes.

Voici les quatre vues. La vue logique décrit les fonctionnalités que le système offre aux utilisateurs finaux, généralement sous forme des abstractions clés et de leurs relations (en UML, des diagrammes de classes et d’états). La vue des processus traite des préoccupations d’exécution : processus et threads, concurrence, distribution, performances, scalabilité et tolérance aux pannes. La vue de développement (aussi appelée vue d’implémentation) décrit l’organisation du logiciel dans son environnement de développement : modules, sous-systèmes, couches et leurs dépendances, qui comptent pour les programmeurs et pour les managers qui planifient le travail. La vue physique (ou vue de déploiement) projette le logiciel sur le matériel et les réseaux. Le « +1 », ce sont les scénarios : un petit ensemble de cas d’utilisation importants, chacun suivi à travers les quatre vues, qui à la fois illustrent l’architecture et valident que les vues s’accordent entre elles.

Les scénarios sont la partie la plus souvent oubliée et sans doute la plus précieuse. Une vue isolée peut paraître nette tout en cachant une lacune ; suivre un scénario réel comme « le client passe une commande » à travers les vues logique, des processus, de développement et physique révèle les éléments manquants et les hypothèses incohérentes. La même idée réapparaît dans la vue d’exécution d’arc42, dans les diagrammes dynamiques C4 et, à la section 4.8, dans le conseil d’expliquer un système en suivant une requête.

Rozanski et Woods : points de vue et perspectives

L’ouvrage de Nick Rozanski et Eóin Woods Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives (2e édition, Addison-Wesley, 2012) propose un catalogue de sept points de vue destiné aux grands systèmes d’information, ainsi qu’une seconde idée, complémentaire : les perspectives.

Leurs sept points de vue sont : contexte (les relations du système avec les personnes, les systèmes et les entités externes qui l’entourent), fonctionnel (les éléments fonctionnels d’exécution, leurs responsabilités, leurs interfaces et leurs interactions principales), information (comment les données sont stockées, gérées, possédées et distribuées), concurrence (quelles parties s’exécutent en parallèle et comment elles sont coordonnées), développement (ce dont ont besoin les développeurs, les testeurs et ceux qui construisent le logiciel : structure des modules, traitements communs, normes et organisation des lignes de code), déploiement (l’environnement d’exécution et la façon dont le logiciel s’y projette) et opérationnel (comment le système est installé, migré, administré, supervisé et pris en charge en production).

Une perspective est leur nom pour une préoccupation de qualité qui traverse toutes les vues, comme la sécurité, les performances et la scalabilité, la disponibilité et la résilience, ou l’évolution (leur catalogue comprend aussi l’accessibilité, les ressources de développement, l’internationalisation, la localisation, la réglementation et l’utilisabilité). Une perspective n’est pas une vue de plus à dessiner. C’est un ensemble de questions, de tactiques et de vérifications appliqué à chaque vue : pour la sécurité, vous examinez la vue de contexte pour les acteurs externes et les frontières de confiance, la vue d’information pour les données sensibles, la vue de déploiement pour les zones réseau, et ainsi de suite. Cela saisit ce que des vues isolées ne peuvent pas saisir : les qualités émergent du système entier, elles doivent donc être vérifiées partout (comparez avec les modèles de qualité du chapitre 2).

Le point de vue opérationnel mérite une attention particulière, car de nombreuses approches le sous-estiment. Qui installe le système, comment les données sont migrées depuis l’ancien, comment la configuration est gérée, ce que supervisent les opérateurs et comment ils sont alertés : ce sont des questions architecturales dont les réponses façonnent le système, et les repousser juste avant la mise en service est une cause classique de lancements ratés.

Les trois catégories du SEI : module, composants et connecteurs, allocation

Le chapitre 1 a présenté le regroupement des structures du SEI en trois types (voir la section 1.1). Documenting Software Architectures: Views and Beyond utilise le même regroupement pour organiser les vues, et c’est le moyen le plus utile de vérifier qu’un ensemble de vues est complet.

Les vues des modules montrent des unités d’implémentation (paquets, bibliothèques, espaces de noms) et des relations comme fait partie de, dépend de et est un. Les styles typiques sont les vues de décomposition, d’utilisation, de généralisation, en couches et de modèle de données. Les vues composants et connecteurs (C&C) montrent les éléments présents à l’exécution (services, clients, bases de données, files d’attente) et les connecteurs par lesquels ils interagissent (appels HTTP, messages, données partagées) ; les styles typiques sont client-serveur, publication-abonnement, tubes et filtres, données partagées et multiniveau. Les vues d’allocation projettent des éléments logiciels sur des choses non logicielles : sur le matériel et l’infrastructure cloud (déploiement), sur le système de fichiers et les artefacts de build (implémentation et installation) et sur les équipes (affectation du travail).

Les trois catégories correspondent naturellement aux autres approches. La vue de développement de Kruchten est une vue des modules, sa vue des processus une vue C&C et sa vue physique une vue d’allocation. Les points de vue fonctionnel et de concurrence de Rozanski et Woods relèvent surtout du C&C, leur point de vue de développement du module, et leurs points de vue de déploiement et opérationnel de l’allocation. Les diagrammes de conteneurs et de composants C4 de la section suivante sont des vues C&C avec une touche de module, et les diagrammes de déploiement C4 sont des vues d’allocation. Quand vous assemblez un ensemble documentaire, vérifiez qu’il contient au moins une vue de chaque catégorie, car chacune répond à des questions auxquelles les autres ne peuvent pas répondre.

Faire correspondre parties prenantes, préoccupations et vues

L’outil le plus pratique issu de la norme est un simple tableau : listez les parties prenantes et leurs principales préoccupations, puis nommez la ou les vues qui répondent à chaque préoccupation. Les lacunes (une préoccupation à laquelle aucune vue ne répond) montrent où la description est incomplète ; les vues dont personne n’a besoin sont candidates à la suppression. Le tableau ci-dessous est une première version pour la plateforme de livraison de repas.

Choisir l’ensemble minimal de vues

Une fois que l’on sait qu’il existe de nombreux points de vue, la tentation est de tous les produire. Résistez-y. Chaque vue doit être maintenue cohérente avec le système et avec les autres vues ; chacune ajoute donc un coût de maintenance. Le but est le plus petit ensemble de vues qui réponde aux préoccupations importantes des parties prenantes importantes, selon la règle de la section 4.1 : écrire pour le lecteur. Views and Beyond décrit une procédure semblable : construire un tableau parties prenantes-vues, combiner les vues lorsqu’un seul diagramme peut servir plusieurs besoins, puis prioriser.