R3320

Un MessageFlow devrait partir d’un SendTask/ThrowEvent/ExternalParticipant et arriver sur un ReceiveTask/CatchEvent/ExternalParticipant.

L’idée derrière cette recommandation est que l’utilisateur lisant le modèle devrait toujours être capable de comprendre comment un processus interagit (ou pas) avec d’autres processus (MessageFlow).
Alors que les choses sont claires dans un diagramme de collaboration, où les MessageFlows sont affichés, elles le sont moins dans un diagramme de processus, dans lequel ces flux n’apparaissent pas. En regardant un diagramme de processus l’utilisateur n’a pas d’indices sur les interactions avec les autres processus, la norme BPMN ne fournit pas de tels indices. Pour améliorer la lisibilité des diagrammes de processus, la règle R3320 recommande d’utiliser des événements Throw/Catch dans les processus collaborant avec d’autres.

La bonne pratique pour représenter des messages entre processus consiste a :

Les participants "externes" représentant des processus sans détails internes sont autorisés à la fois en tant que source et cible des MessageFlows.

Si vous avez des MessageFlows reliant d’autres types d’éléments, vous devriez changer leurs origines/destinations.

Diagramme de collaboration initial

Dans le diagramme de collaboration suivant, les 3 MessageFlows M1, M2 et M3 entre les processus A et B sont parfaitement conformes à la norme.

Diagramme de processus initial de Process A

Avec ce diagramme, l’utilisateur ne peut pas savoir que le Process A interagit avec le Process B, ce qui peut être gênant.

Dans cet exemple, la règle R3320 signalera les MessageFlows M1 et M3 mais ne mentionnera pas M2 puisqu’il part d’une SendTask.

Pour M1 et M3, qui partent du Participant "Process A" et de la Task "task", la règle recommandera de corriger le modèle.

La correction consiste à insérer des Throw/Catch Events dans les processus "Process A" et "Process B" et les utiliser comme source/cible pour M1 et M3 :

Diagramme de processus de Process A corrigé

Diagramme de collaboration corrigé

Conclusion : Le principal bénéfice de cette correction est que le diagramme de processus du "Process A" seul est maintenant suffisant pour comprendre que des événements sont propagés à l’extérieur du processus, M1 et M3 y apparaissant. L’utilisateur lisant le modèle est donc invité à consulter le diagramme de collaboration dans lequel les messages M1 et M3 apparaissent explicitement.