Quel diagramme UML dois-je utiliser pour documenter une architecture système axée sur les messages qui utilise des EIP?

Depuis l'introduction de enterpriseintegrationpatterns.com:

Le profil UML pour EAI [UMLEAI] enrichit la sémantique de diagrammes de collaboration pour décrire les flux de messages entre les composants. Cette notation est très utile comme description visuelle précise d'un système qui peut servir de base à la génération de code dans le cadre d'un architecture basée sur un modèle (MDA).

Les diagrammes de collaboration sont remplacés dans UML 2 par Diagrammes de communication

Cependant, l'introduction de enterpriseintegrationpatterns.com se poursuit en disant:

Nous avons décidé de ne pas adopter cette notation ... {parce que} ... l'UML Le profil ne capture pas tous les modèles décrits dans notre modèle langue.

Au moment de la rédaction du présent rapport (avril 2019), il semble que la dernière fois que le profil EAI pour UML a été publié était mars 2004 . Ceci est antérieur aux extraits de enterpriseintegrationpatterns.com, qui, selon le chemin du retour, a été publié pour la première fois en août 2015 .

Cela suggère que UML 2 est mal équipé pour décrire les architectures système basées sur les messages qui incarnent des EIP.

Vous pouvez utiliser un diagramme de composants et / ou un diagramme de structure composite. Si, dans votre cas, chaque microservice n'est instancié qu'une seule fois, vous n'avez besoin que d'un de ces diagrammes. Sinon, il serait bon d'avoir un diagramme de composants montrant le niveau de classe et un diagramme de structure composite le niveau d'instance. Voir la question Dépendance du diagramme de composants vs assemblage .

Une file d'attente de messages peut être modélisée comme un composant séparé avec le stéréotype <>, ou comme une interface avec le stéréotype <>. La modélisation d'une file d'attente en tant que composant distinct est le meilleur choix si la file d'attente n'appartient pas à un service. Cependant, s'il est possédé (un seul service y met / publie des messages), alors un composant de file d'attente séparé encombre le diagramme et il serait préférable de le modéliser comme une interface, fournie par le producteur de messages et requise par les consommateurs de messages. .

Quand vous dites EIP, je suppose que vous voulez dire Modèles d'intégration d'entreprise , c'est-à-dire. une collection variée de modèles d'intégration d'applications d'entreprise tels que Message Router , Message Broker , Message Channel , Service Call et ainsi de suite, comme indiqué dans plusieurs livres et journaux populaires. Si tel est le cas, alors votre référence au modèle Message Channel a du sens et je pense comprendre ce que vous voulez dire.

L'UML est un ensemble de langages à usage général et peut être utilisé pour représenter de nombreux aspects différents de votre architecture, de sorte que la réponse à votre question dépend de ce que vous essayez de montrer et à quel niveau d'abstraction. Si vous vous concentrez sur la messagerie (synchronisation des messages, classement, etc.), vous devez utiliser l'un des langages comportementaux dans l'UML; si vous souhaitez représenter des messages (structure, types, contenu, etc.), vous pouvez le faire avec un langage structurel . La réponse de 8bitjunkie suggère des diagrammes de communication pour le côté comportemental, mais vous pouvez également utiliser des diagrammes de séquence, des diagrammes d'activité et des graphiques d'état en fonction de votre objectif / besoin. Les diagrammes de séquence vous permettent d'identifier les aspects de synchronisation plus clairement que les diagrammes de communication. Pour la structure du message, je recommanderais les diagrammes de classes. L'UML peut également être étendu via des valeurs marquées et des stéréotypes pour inclure une plus grande spécificité et ajouter des détails structurés si vous le souhaitez; il n'y a pas de réelle limite aux informations structurées que vous pouvez capturer dans un modèle UML.