Visualiser l'architecture de vos projets

Quand il s'agit de visualiser l'architecture d'un projet, une équipe peut décider d'utiliser un formalisme bien connu : l'UML (Language de Modélisation Unifié).

Or, depuis l'avènement de l'agilité, la modélisation de l'architecte via UML est perçue comme une perte de temps, désuette, complexe à déchiffrer et difficile à maintenir.

La solution la plus souvent envisagée est d'utiliser ponctuellement un tableau blanc, de dessiner des boîtes, des flêches, de caler quelques infos, de prendre une photo puis de l'archiver.

UML, Cucumber and modeling reality - MPJ's Musings - Fun Fun Function par Mattias Petter Johansson (mpj)

L'approche semble valable de prime abord, malheureusement, on peut aboutir rapidement à ce résultat :

Sur le moment, l'équipe qui a produit le diagramme a une idée claire du système et se figure bien les interactions entre les différentes briques de l'application.

Sauf que le résultat, lui, est difficile (pour ne pas dire impossible) à exploiter.

Que manque t-il au juste ?

• Une légende, expliquant les codes couleurs et les différents symboles choisis,
• des labels, permettant de clarifier les interactions matérialisées par les flêches.
• le sens de circulation de l'information entre deux boîtes dans la plupart des cas,
• une façon claire de distinguer le type de chacune des boîtes (est-ce une application ? Un système de fichier ? Un algorithme ? Un composant logiciel ?)
• des informations sur les technologies utilisées pour les interactions et les briques applicatives,
• et j'en passe...

En somme, il nous manque un formalisme accessible qui laisse peu de place à l'interprétation.

Ce sont les problématiques que tente d'adresser le modèle C4 (C4 Model)

Le Modèle C4 (C4 Model)

Le modèle C4, créé par Simon Brown, vise a aider les équipes à décrire et communiquer l'architecture logicielle, lors des sessions de conception (up-front design), ainsi que rétrospectivement, pendant les phases de documentation, grâce à une notation semi-formelle accessible au plus grand nombre.

Le modèle permet de créer une cartographie du code, à différents niveaux de détails, à l'image d'une carte interactive qui permet de zoomer sur une zone d'intérêt.

Chaque niveau s'adresse à une audience bien définie.

Illustration des 4 niveaux de détails du modèle C4

Avant de plonger dans les formalismes du modèle C4 commençons par...

Distinguer la visualisation de la modélisation

Utiliser des outils généralistes comme draw.io, lucidchart ou encore un tableau blanc comme indiqué plus haut pour vos diagrammes apparaît en premier lieu comme une solution pertinente. Vous investissez du temps dans la réalisation de diagrammes pour exposer l'architecture de vos projets à votre audience.

Sans formalisme, on aboutit la plupart du temps, à des ensembles de boites et de flêches difficilement compréhensibles comme nous l'avons vu dans le préambule de cet article.

Cependant, même en introduisant un formalisme, il vous sera parfois difficile de ré-exploiter vos travaux et de les maintenir.

Concrètement, quand vous utilisez ce genre d'outils, que faites-vous ?

Vous couchez sur un support visuel ce que vous savez de l'architecture de vos projets. Ce savoir, la plupart du temps imparfait, vous l'avez acquis en vous basant sur vos contributions personnelles, sur le code que vous avez lu, en interrogant les différentes personnes qui participent à la conception des applications, en somme, vous avez construit un modèle mental de l'architecture de vos projets.

Voilà ! Nous y sommes. En réalité, ce qui compte c'est ce modèle, celui que vous interrogez mentalement pour réaliser vos diagrammes.

Modèle qu'il va falloir extraire pour permettre à toutes les personnes concernées de le maintenir, de l'enrichir et de le corriger au fil des évolutions de l'architecture.

Le professeur Dumbledore en pleine séance d'extraction de son modèle mental de l'architecture.

La modélisation permet de construire une représentation non visuelle des éléments qui composent notre architecture, de décrire des applications, des personnes et leurs interactions.

L'avantage de maintenir un modèle, est qu'il est possible de l'interroger programmatiquement ou via une interface graphique pour générer des diagrammes en fonction de ce que l'on souhaite communiquer.

• Quelle est la liste des applications maintenues par notre société ?
• Quelles personnes utilisent telles applications ?
• Quel protocole d'échange utilise-t-on entre ces deux applications ?
• Quels sont les services externes utilisés par telle application ?
• Sur quelles technologies repose mon application BackOffice ?
• Quels sont les composants métiers de telle application ?
• etc...

L'idée ici et de séparer le fond de la forme et d'accorder plus d'importance au contenu (que l'on souhaite exhaustif), qu'au contenant (nos futurs diagrammes).

Formalisme

Le modèle s'appuie sur un ensemble d'abstractions utilisées pour décrire la structure d'un ou de plusieurs systèmes logiciels.

Le modèle C4 s'intéresse à représenter des systèmes logiciels composés de conteneurs, scindés en composants qui s'expriment par du code. On matérialise également les personnes utilisant ces systèmes et les différentes relations qu'entretiennent les élements de l'architecture.

Notation

L'idée derrière le modèle C4 est de laisser peu de place à l'interprétation. Les diagrammes générés à partir du modèle doivent être autoporteurs ; il ne doit pas être nécessaire de les accompagner d'une documentation ou d'un discours.

• Chaque boîte porte un nom, un type et une description.
• Chaque relation porte une description accompagnée si nécessaire de la technologie utilisée pour le transport de l'information quand il s'agit d'une relation technique.
• Les relations sont unidirectionnelles. Et ce pour éviter de masquer involontairement des interactions.

Les principaux diagrammes

On identifie 4 niveaux d'abstractions

Niveau 1: System Context (Contexte Système)

Ce diagramme permet d'obtenir la vision d'ensemble d'un système.

La boîte centrale matérialise un système logiciel, entouré des ses utilisateurs et des systèmes avec lesquels il interagit.

Element principal: Un système logiciel. Elements de support: Des personnes, des systèmes en relation avec le système observé. Audience: Tout le monde.

Niveau 2: Container (Conteneur)

Une fois que l'on situe un système dans son environnement, la prochaine étape est de zoomer dans les frontières de ce dernier (system boundaries) pour matérialiser les conteneurs qui le composent.

Un conteneur est un élément qui peut être exécuté/déployé individuellement comme :

• Une Application Web,
• une API,
• un CLI,
• une SPA (single page application),
• une Application Mobile,
• une Base de Données,
• un Système de Fichiers,
• etc...

Éléments principaux: Des conteneurs au sein d'un système logiciel. Éléments de support: Des personnes, des systèmes en relation avec les conteneurs observés. Audience: Intervenants techniques.

Niveau 3 : Component (Composant)

Quand on zoome sur un conteneur, on observe les composants nécessaires à son fonctionnement, ainsi que leurs interactions.

On y retrouve :

• Les points d'entrée de l'application (controllers, cli, workers, etc...),
• les services métiers (email, sécurité, gestionnaire d'équipements, etc...),
• et les couches d'accès à la donnée (repositories, message bus, api clients, etc...).

Elements principaux: Des composants à l'intérieur des frontières d'un conteneur. Elements de support: Des personnes, des conteneurs, et des systèmes externes directement attachés aux composants observés. Audience: Architectes et développeurs.

Niveau 4: Le Code

Pour finir, en zoomant sur un composant, on accède à son implémentation.

Pour décrire une implémentation, l'UML est le langage à privilégier sachant qu'à ce niveau de détails, on s'adresse essentiellement à des développeurs.

Pour les traitements jugés triviaux (exemple: un CRUD), il est inutile de descendre jusque-là.

Il est par contre utile pour visualiser des algorithmes ou des flux de travaux (workflow) complexes.

Vous n'êtes pas obligé pour ce niveau d'utiliser systématiquement des diagrammes de classes, vous pouvez tout aussi bien utiliser un diagramme d'activité ou encore un logigramme (flowchart).

Les Diagrammes Secondaires

Software Landscape (Paysage Applicatif)

Permet de visualiser plusieurs applicatifs maintenus par l'entreprise et leurs interactions avec des systèmes et des personnes, qu'ils soient internes ou externes à l'entreprise.

Deployment (déploiement)

Fait correspondre les conteneurs (éléments individuellement déployables) à l'infrastructure matérielle du SI.

Les outils

La page officielle du modèle C4 référence déjà un certains nombres d'outils, mais c'est clairement sur Structurizr qu'il faut porter votre attention.

C'est actuellement le seul outil qui vous permet de modéliser et de maintenir un modèle d'architecture, via du code (java, .net, typescript ou php) ou depuis son interface graphique et qui offre la possibilité de générer des diagrammes à partir de ce dernier.

Ajout d'éléments via l'interface Structurizr

Édition des styles via l'interface Structurizr

Création de vues via l'interface Structurizr

Le workflow de l'outil est le suivant :

1. Vous renseignez votre modèle d'architecture (éléments d'architectures, personnes et relations),
2. vous configurez des règles de styles qui s'appliquent en fonction du type d'un élément ou de leurs tags,
3. vous créez des vues (diagrammes) en interrogent votre modèle,
4. puis vous faites de la mise en page depuis l'interface graphique.

Si vous souhaitez décrire un projet Java, Structurizr propose également des extensions permettant :

• de faire de l'introspection sur une base de code pour extraire les composants d'architecture (documentation et exemples pour Spring et SpringBoot)
• d'utiliser des annotations pour déclarer votre modèle d'architecture (documentation et exemple).

De la théorie à la pratique

Dans l'article suivant, je vous proposerai différentes astuces de modélisation, en attendant, je vous invite à consulter la foire aux questions du modèle C4 qui offre déjà pas mal de pistes de réflexions.