L'objectif de cet article est de nous intéresser au lien entre une représentation UML de moins en moins utilisée et pourtant essentielle dans la représentation d’une architecture logicielle : le diagramme de contexte, et l’architecture “Ports & Adapters” plus connue sous le nom d’architecture hexagonale.
Diagramme de contexte
Le diagramme de contexte est l’un des premiers diagrammes pouvant être réalisé afin de décrire à haut niveau le futur système en mode boîte noire. Il permet de se concentrer sur l’identification des différents acteurs interagissant avec lui. Il est aussi possible de représenter les interactions entre acteurs si cela semble pertinent pour la compréhension globale du système. Lors de sa réalisation on ne parle ni d’implémentation, ni de solution, mais seulement de son contexte d’utilisation.
fig1. Diagramme de contexte
Au centre, nous avons le système dans son ensemble et gravitant autour on retrouve les acteurs. Ils ne sont pas, comme peut le laisser penser leur représentation, forcément des acteurs physiques. Ils peuvent aussi être d’autres systèmes, des instruments etc…
Ce qu’il faut noter c’est le sens des flèches :
- Lorsqu’elles pointent vers le système on parlera des acteurs primaires :
Ils sont à l’origine de nos futurs “Use Cases”.
- Lorsqu’elles pointent vers l’extérieur on parlera des acteurs secondaires :
Il s’agit des interactions avec l’extérieur du système afin de, par exemple, récupérer de l’information, ou pour réaliser des notifications.
Ce que l’on va comparer avec l'architecture, c’est justement le lien avec ces deux différents types d’acteurs.
Architecture hexagonale
Le but de cette partie n’est ni de rentrer dans les détails de l’architecture, ni d’expliquer dans quels cas on peut l’utiliser, mais d’effectuer le survol nécessaire à la compréhension du lien avec les acteurs primaires et secondaires.
L’architecture hexagonale est une architecture présentée par Alistair Cockburn dans son blog sous la forme d’un hexagone.
Pour l'anecdote, la forme de l’hexagone est un choix arbitraire d'Alistair Cockburn qui souhaitait obtenir une symétrie dans son architecture et le carré ne lui convenait pas car cette représentation lui laissait l’impression de devoir se limiter à une architecture en couches traditionnelle. Au final l’architecture n’est pas complètement symétrique d’où le nom plus approprié d’architecture “Ports & Adapters”.
fig2. Architecture Hexagonale
L’architecture “Ports & Adapters” se base comme son nom l’indique sur des “Ports”. Ce sont des portes d’entrées de l’application utilisées par des “Adapters” dits “Driving Adapters”, et des portes de sorties implémentées par des ”Adapters” dits “Driven Adapters”.
Dans le cadre de cet article, c’est l’utilisation de l’hexagone comme moyen de modélisation qui nous intéresse. Il permet de se concentrer sur les “Use Cases” et les acteurs sans rentrer dans les détails de l’implémentation.
Modélise-t-on les mêmes acteurs avec l’hexagone qu’avec le diagramme de contexte ?
Modélisations équivalentes ?
A première vue, on peut remarquer que d’une part les acteurs qui interagissent avec les “Driving Adapters” sont dans le monde UML des acteurs dits primaires, et sont à l’origine des “Use Cases”. D’autre part, les acteurs qui sont appelés depuis les “Driven Adapters” sont dans le monde UML des acteurs dits secondaires car ce sont des appels vers l’extérieur.
On peut alors se demander si les deux représentations sont équivalentes?
Si nous prenons un peu de recul, on remarque que ce qui se trouve au centre des deux modélisations n’est pas du même niveau de granularité et d’abstraction.
En effet, le système entier est représenté par le diagramme de contexte qui utilise le plus haut niveau d’abstraction. Il peut être composé de plusieurs applications alors que dans l’hexagone on retrouve une seule application.
Dès lors, les acteurs dans l’architecture “Ports & Adapters” peuvent ne pas se trouver dans le diagramme de contexte et peuvent se trouver dans les détails du système.
fig3. L’Hexagone se cache dans les détails
La figure ci-dessus en est l’illustration avec des acteurs qui émergent quand on zoome dans le système :
On notera que dans le cas particulier où le système est composé d’un seul composant applicatif alors les acteurs des deux modélisations coïncident.
Les deux types de modélisation ne représentent pas le même niveau d’abstraction et ne possèdent pas, dans la majorité des cas, les mêmes acteurs. En revanche, elles se complètent en intervenant à deux moments différents durant le processus d’architecture logicielle.
fig4. Modélisation possible durant le processus d’architecture logicielle
Le diagramme de contexte intervient au début et reste un incontournable permettant de saisir à haut niveau, et en une représentation, l’ensemble des différents acteurs interagissant avec un système. La modélisation sous la forme d’hexagone peut intervenir dans la suite du processus avec un niveau plus détaillé (use cases). Ce moment peut être lors de la réalisation de diagrammes de composants, lorsque la décomposition en briques applicatives est déjà réalisée.
Conclusion
Le diagramme de contexte est une modélisation permettant de mettre en avant les acteurs à haut niveau du système. Il s’agit d’une représentation UML compréhensible pouvant être construite et validée en collaboration avec les PMs et les POs du projet. Le diagramme de contexte permet de s’assurer que le contexte du système a bien été saisi avant d’aller plus de l’avant.
La représentation sous forme d’hexagone est une modélisation d’une application faisant partie d’un système plus large. Cette modélisation s’adresse à un public plus technique et permet dans le cas où l’architecture “Ports & Adapters” est utilisée de réduire ce qu’on appelle le “model-code gap” (Just Enough Architecture - George Fairbanks) en faisant apparaître les “ports”, les “adapters” et les “use cases” à implémenter directement dans le code.
