Croquis et NoUML pour l'architecture de logiciels agiles

Si vous travaillez actuellement dans une équipe de développement logiciel agile, regardez autour de vous. Qu'il soit physique ou virtuel, il est fort probable qu'il y ait un mur de "stories" ou un tableau Kanban représentant le travail à effectuer, en cours ou terminé. Représenter le processus de développement de votre logiciel est un excellent moyen d'introduire de la transparence puisque tout le monde peut avoir, en un coup d’œil, un aperçu de son état d'avancement actuel. Dans notre secteur, nous sommes devenus - ces dernières années - experts dans la représentation du processus de développement de nos logiciels, bien qu'il semble que nous ayons oublié comment représenter le logiciel que nous sommes en train de créer. Je ne fais pas uniquement référence à la documentation post-projet, mais aussi à la manière de communiquer durant le cycle de vie du logiciel. L'agilité c'est être réactif et ceci nécessite une bonne communication, mais il est étonnant que beaucoup d'équipes éprouvent des difficultés à communiquer correctement la conception de leur logiciel.

Méthodes préconisées, modèles de processus et sémantiques formelles

Si vous regardez quelques années en arrière, les processus structurés et les sémantiques formelles fournissaient un point de référence pour le cycle de vie d'un logiciel et pour communiquer les diverses conceptions. Par exemple, le Rational Unified Process (RUP), le Structured Systems Analysis And Design Method (SSADM), l'Unified Modeling Language (UML), etc. Bien que le secteur du développement des logiciels ait avancé de plusieurs manières, il semblerait que nous avons oublié certaines bonnes choses qu'offraient ces anciennes approches. Dans le monde actuel de la livraison agile et du lean startup, certaines équipes logicielles ont perdu la capacité à communiquer sur ce qu'elles sont en train de créer et c'est sans surprise que ces équipes manquent d'un leadership technique, de direction et de cohérence. Si vous souhaitez être sûr que tout le monde collabore dans le même objectif final, vous devez pouvoir communiquer de manière efficace la vision de ce que vous êtes en train de créer. Et si vous souhaitez de l'agilité et avoir la capacité à être réactif, vous devez aussi pouvoir communiquer cette vision de manière efficiente.

Abandonner l'UML

Dans notre secteur, nous avons l'UML, qui est une notation formelle standardisée permettant d'exposer la conception de systèmes logiciels. J'utilise moi-même l'UML, mais je tends à l'utiliser avec parcimonie pour esquisser les aspects importants de la conception de bas niveau d'un système logiciel. Je ne trouve pas que l'UML soit adapté pour décrire l'architecture logicielle de haut niveau d'un système logiciel, et bien qu'il soit possible d'en débattre, la question est hors de propos parce que beaucoup d'équipes ont déjà abandonné l'UML ou ne le connaissent tout simplement pas. De telles équipes préfèrent à la place des croquis informels de type boîtes et lignes, mais souvent ces diagrammes n'ont aucun sens s'ils ne sont pas accompagnés une description détaillée, qui en définitive ralenti l'équipe. La prochaine fois que quelqu'un vous présente la conception d'un logiciel, focalisez-vous sur un ou plusieurs croquis informels, et demandez-vous s'il vous expose ce qu'il y a sur les croquis ou ce qui est encore dans sa tête.

(Cliquez sur l'image pour l'agrandir)

Abandonner l'UML est très bien, mais dans la course à l'agilité, de nombreuses équipes de développement ont aussi perdu la capacité à communiquer visuellement. Les exemples de croquis NoUML d'architecture logicielle (ci-dessus) illustrent de nombreuses approches typiques pour faire comprendre une architecture logicielle et ils souffrent des problèmes suivants :

• Le code-couleur n'est habituellement pas expliqué ou est souvent incohérent.
• La raison d'être d'éléments du diagramme (c.-à-d. différents types de boîtes et de lignes) n'est pas souvent expliquée.
• Les relations clés entre les éléments du diagramme sont souvent manquantes ou ambiguës.
• Les choix (ou options) technologiques sont généralement omises.
• Différents niveaux d'abstraction sont mélangés.
• Les diagrammes essayent souvent de montrer trop de détails.
• Les diagrammes manquent souvent de contexte ou d'un point de départ logique.

Quelques abstractions simples

Les croquis informels de boites et lignes peuvent bien fonctionner, mais il y a de nombreux pièges associés à l'explication de conceptions logicielles de cette manière. Mon approche est d'utiliser un petit ensemble de diagrammes simples dont chacun montre une partie différente de la même histoire. Pour ce faire, il est néanmoins nécessaire que vous vous mettiez d'accord sur une manière simple de penser au système logiciel que vous êtes en train de créer. En supposant un langage de programmation orienté objet, la manière dont j'aime penser à un système logiciel est la suivante : un système logiciel est constitué d'un certain nombre de conteneurs, qui eux-mêmes sont constitués de composants, lesquels sont à leur tour implémentés par une ou plusieurs classes. Il s'agit d'une hiérarchie simple de composants logiques qui peut être utilisée pour représenter la plupart des systèmes logiciels que j'ai croisés.

• Classes : dans un monde Orienté Objet, les classes sont le plus petit type de composants de nos systèmes logiciels.
• Composants : les composants (ou services) sont habituellement composés d'un nombre de classes qui collaborent, cachées derrière une interface grossière. Comme par exemple, un "calculateur de risque", un "composant d'audit", un "service de sécurité", un "service d'email", etc. cela dépendant de ce que vous êtes en train de construire.
• Conteneurs : un conteneur représente quelque chose dans lequel sont exécutés les composants ou où les données résident. Cela peut aller d'un serveur web ou d'application à une application client riche, une base de données ou un système de fichiers. Les conteneurs sont typiquement les choses qui ont besoin d'être en cours d'exécution/disponibles pour que le système logiciel fonctionne dans son ensemble. L'essentiel pour comprendre un système logiciel du point de vue des conteneurs est d'avoir conscience que toute communication inter-conteneur exige probablement une interface distante tel qu'un appel à un web service, l'invocation d'une méthode distante (RMI), le passage de messages, etc.
• Système : Un système est le plus haut niveau d'abstraction et représente quelque chose qui répond aux besoins des utilisateurs finaux par exemple.

Résumer la structure statique de votre logiciel avec du NoUML

En utilisant un ensemble d'abstractions pour penser un système logiciel, nous pouvons à présent dessiner de simples croquis composés de boîtes et lignes pour résumer la structure statique de ce système logiciel (vous pouvez voir quelques exemples sur Flickr) :

• Schéma contextuel : un diagramme de très haut niveau montrant votre système par une boîte au centre, entouré par d'autres boîtes représentants les utilisateurs et tous les autres systèmes avec lesquels les interfaces du système logiciel communiquent. Le détail n'est pas important ici puisqu'il s'agit d'un zoom arrière montrant une vue d'ensemble du système. L'accent devrait être mis sur les personnes (acteurs, rôles, personnages, etc.) et les systèmes logiciels plutôt que sur les technologies, protocoles et autres détails de bas niveau. C'est le type de diagramme que vous pourriez montrer aux non-spécialistes.
• Diagramme de conteneurs : un diagramme de haut niveau montrant les différents serveurs web, serveurs d'applications, applications lourdes, bases de données, systèmes de fichiers, etc. qui composent votre système logiciel avec les relations/interactions entre eux. C'est le diagramme qui illustre vos choix technologiques de haut niveau. Concentrez-vous à monter les conteneurs logiques et oubliez les autres diagrammes (par exemple les diagrammes d'infrastructure et de déploiement) pour montrer les instances physiques et les cartographies de déploiement.
• Diagramme de composants : un diagramme (un par conteneur) montrant les composants/services logiques majeurs et leurs relations. Des informations additionnelles telles que les choix technologiques connus pour l'implémentation du composant (par exemple Spring, Hibernate, WCF, F#, etc.) peuvent aussi être ajoutées au diagramme de manière à ancrer la conception dans la réalité.
• Diagramme de classes : c'est un niveau optionnel de détail et généralement je ne dessine qu'un petit nombre de diagrammes de classes UML de haut niveau si je souhaite expliquer comment un pattern ou composant particulier sera (ou a été) implémenté. Les facteurs qui me poussent à dessiner des diagrammes de classes pour certaines parties du système logiciel sont la complexité du logiciel, plus la taille et l'expérience de l'équipe. Tous les diagrammes UML que je dessine ont tendance à être des croquis plutôt que des modèles complets.

(Cliquez sur l'image pour l'agrandir)

Un diagramme peut vite devenir encombré et confus, mais un ensemble de diagrammes simples vous permet de présenter simplement le logiciel à partir de différents niveaux d'abstraction. Et c'est un point important car ce ne sont pas uniquement les développeurs de l'équipe qui ont besoin d'informations au sujet du logiciel. Il y a d'autres acteurs et consommateurs aussi ; allant des experts du domaine non-technique, testeurs et du management au personnel technique de l'exploitation et du support. Par exemple, un diagramme montrant les conteneurs est particulièrement utile aux personnes des équipes d'exploitation et du support qui souhaitent certaines informations techniques au sujet de votre système logiciel, mais qui ne souhaitent pas nécessairement tout connaître du fonctionnement interne.

Idées d'organisation, pas une norme

Cette simple approche de croquis fonctionne pour moi et de nombreuses équipes de développement avec lesquelles je travaille, mais il s'agit ici de fournir des idées organisationnelles et des recommandations plutôt que de créer un standard normatif. Le but est d'aider les équipes à communiquer leurs conceptions logicielles d'une manière efficace et efficiente plutôt que de créer un modèle complet de notation. Il vaut la peine de répéter que des croquis informels de boîtes et lignes fournissent de la flexibilité aux dépens de la cohérence du diagramme puisque vous créez votre propre notation au lieu d'utiliser un standard tel que l'UML. Mon conseil est de faire attention au code-couleur, à l'apparence des lignes, des formes, etc. et de laisser un certain nombre d'éléments de la notation évoluer naturellement au sein votre équipe. Inclure sur chaque diagramme une légende simple expliquant la notation aidera aussi.

Il semble y avoir une fausse idée reçue que "les diagrammes d'architecture" doivent présenter seulement une vue conceptuelle de haut niveau. Par conséquent, il n'est pas surprenant que les développeurs logiciels les considèrent souvent comme inutiles. De la même manière que l'architecture logicielle devrait être synonyme de code, coaching et collaboration plutôt que de tour d'ivoire, les diagrammes d'architecture logicielle devraient aussi être ancrés dans la réalité. Inclure des choix (ou options) technologiques est habituellement un pas dans la bonne direction et aidera à éviter que les diagrammes ressemblent à une architecture de type tour d'ivoire où un tas de composants conceptuels collaborent magiquement pour former un système logiciel.

"Juste assez" de conception

Pour conclure, Grady Booch a une excellente explication des différences entre l'architecture et la conception dans laquelle il dit que l'architecture représente les "décisions importantes", où l'important est mesuré par le coût du changement. Les schémas contextuelles, les diagrammes de conteneurs et de composants montrent ce que je considère être l'importance structurelle des éléments d'un système logiciel. Cependant, outre le fait d'aider les équipes avec un outil de communication efficace et efficient, adopter cette approche de représentation peut aussi aider les équipes qui luttent en faisant soit trop de conception, soit pas assez. En partant d'une feuille blanche, de nombreux systèmes logiciels peuvent être dessinés et illustrés, sous forme de composants de haut niveau, en quelques heures ou jours, plutôt qu'en plusieurs semaines ou mois. Illustrer la conception de votre logiciel peut être une tâche rapide et simple, qui lorsqu'elle est bien réalisée peut vraiment aider à mettre en place une direction technique et susciter une vision technique commune à laquelle toute l'équipe peut adhérer. Faire un croquis devrait être une compétence dans la boîte à outils de tout développeur logiciel. C'est un moyen fantastique pour visualiser une solution et la communiquer rapidement, de plus cela prépare le chemin pour une conception collaborative et une propriété collective du code.

A propos de l'auteur

Simon Brown habite à Jersey (Îles Anglo-Normandes) et travaille en tant que consultant indépendant, spécialisé sur des sujets tels que l'architecture logicielle, la direction technique et leur équilibre avec l'agilité. Simon intervient régulièrement à des conférences internationales de développement logiciel et fournit des conseils/formations à des sociétés à travers l'Europe, des petites startups aux entreprises de tout premier rang. Il est le fondateur de Coding the Architecture (un site web pragmatique sur les pratiques de l'architecture logicielle) et l'auteur de Software Architecture for Developers (un e-book qui est publié sur Leanpub et mis à jour régulièrement). Il continue aussi à coder. Vous pouvez retrouver Simon sur Twitter @simonbrown.