J’ai assisté à la plénière de NCrafts animée par Simon Brown (@simonbrown), auteur de l’ouvrage “The Art of Visualising Software Architecture”. Ce dernier nous explique selon lui les difficultés liées à l’architecte dans nos applications d’entreprise.

Ubiquitous language

Suite à une longue série de workshops, il se rend compte d’un certain nombre de problèmes. Il nous a montré différents schémas d’architecture qui ont tous en commun le syndrome du dessin de la boîte : on dessine tous des rectangles pour faire des schémas. Certaines boîtes sont nommées, d’autres pas. Un carré est une application ? Une brique logicielle ? Ou autre ?
On fait des flèches pour schématiser les échanges. Plusieurs se croisent, d’autres se perdent, certaines ont des noms et une grande majorité n’en ont pas.

sketch

Bref il met le point sur un problème fondamental en architecture : nous n’avons pas de langage commun pour décrire une application.

Il nous montre d’abord un plan d’appartement ou tout le monde reconnait aisément où se trouvent les toilettes. Pourquoi n’avons-nous pas les mêmes codes schématiques ?

Ensuite il nous montre la carte de la France. Si on zoome, on voit Paris. Si on zoome à nouveau, on voit les rues. De la même manière, il nous pose la question de ce représente le trait bleu. Tout le monde reconnait la Seine. Il est en effet intuitif sur une carte de reconnaître une rivière, car toutes les cartes respectent un formalisme commun.

Avec ces exemples il met l’accent sur deux notions : la codification et le fait d’avoir une vision macroscopique et microscopique de son système.

C4 model software architecture

Il nous demande ensuite qui utilise UML. Sur la salle entière, peu de personnes lèvent le bras. 9 personnes sur 10 n’utilisent pas UML. A tort ou à raison, d’ailleurs, car tout n’est pas à jeter dans UML. D’après Simon Brown, UML ne permet pas de designer efficacement une application d’entreprise.
Il nous explique aussi qu’un développeur sera intéressé par une vision du code. Néanmoins un décideur se cantonnera à une vision plus macroscopique et cherchera les interactions entre les hommes et l’application.

Pour cela il propose le modèle C4 (https://structurizr.com/help/static-diagrams). L’objectif est de générer la cartographie de l’application. Cette cartographie se décompose en plusieurs niveaux, du macro au micro.

Contexte

Le contexte donnera les interactions entre le système et les utilisateurs. Notre application est représentée par une boîte noire.

Conteneur

Notre boîte noire est ouverte. Ainsi on découvre un certain nombre de conteneurs. Chaque conteneur correspond à un programme, un site web, etc.

Components

On zoome encore, on rentre dans le détail. On ouvre nos conteneurs et on découvre l’intérieur. Un composant c’est par exemple un logger. C’est un namespace, un ensemble de classes.

Code/Classe

On zoome une dernière fois pour atteindre le code. Ainsi dans cette vision on découvre les interactions entre les différentes classes.

Il nous montre le résultat de ce genre de schéma. Tout comme pour une carte de la France, on peut descendre dans nos containeurs, composants, classes…

diagram-navigation[1]

Maintenir les schémas

Il est très difficile de maintenir et de tenir à jour un schéma d’architecture. C’est pourquoi Simon Brown propose un outil qui permet de générer à partir du code des modèles C4, mais pas à la manière d’un outil pour faire de la retro-documentation. Il propose un outil qui nous permet de décrire par le code les interactions entre nos différents containeurs, composants et classes.
Cela nous permet aussi de décrire des vues ainsi on peut effectuer le focus sur un sous ensemble de notre application.
L’outil est Structurizr (https://structurizr.com/) qui est dispo pour .Net et du Java.

Ex :

Person = User | A user of my software system. | | 142,64
SoftwareSystem = Software System | My software system. | | 
Container = Software System | Single Page Application | Does interesting things. | Web Browser & JavaScript | | 1687,64
Container = Software System | Backend For Frontend | Does interesting things too. | Apache Tomcat & Java | | 1687,674
Container = Software System | Database | Stores interesting data. | MySQL | Database | 1687,1284

Relationship = User | Uses | | Single Page Application | | 
Relationship = Single Page Application | Uses | HTTPS | Backend For Frontend | | 
Relationship = Backend For Frontend | Reads from and writes to | JDBC | Database | | 

Diagram = Container | Software System | A description of this diagram. | A5_Landscape

ElementStyle = Element   |  650 |  400 |         | #ffffff |  36 |            
ElementStyle = Person    |      |      | #08427b |         |     |            
ElementStyle = Container |      |      | #438dd5 |         |     |            
ElementStyle = Database  |      |      |         |         |     |            

RelationshipStyle = Relationship |  5 |         |       | Direct     |  32 |  400 |     

Et le résultat est le suivant :

StructorizrExpress

Un des grands avantages de cette approche est que la documentation est basée sur du code. Donc des fichiers textes. Donc facilement stockables et fusionnables dans un contrôle de source. Et ça, nous les développeurs, on aime bien.

En résumé

Simon Brown met l’accent sur quelque chose qu’il manque dans le monde de l’informatique, c’est le manque de langage commun pour créer des schémas d’architecture. C’est pourquoi il propose c’est d’uniformiser la représentation des schémas d’architecture. Sans aller aussi loin qu’UML, il propose un formalisme simple, compréhensible et multi-niveaux de façon à avoir UNE documentation accessible depuis plusieurs angles. Et il a le bon goût de proposer un outil permettant de générer et gérer cette documentation. Il mérite donc qu’on y jette un oeil.

Ci-dessous le replay de cette session :