Les participants, pool,

voies
Processus simple Processus collaboratif
Les voies/Lanes/couloirs
Les tâches de cet exemple ont été assignées à des personnes via des voies (lanes) . Nous pouvons déduire
la description de processus suivante à partir des affectations :
- Si Christian a faim, il choisit une certaine recette. Selon ce que Christian choisit, il peut soit s'en charger
lui-même (cuisiner des pâtes), soit embarquer ses colocataires. Dans ce cas, Falko cuisine un steak et
Robert prépare une salade. A la fin, Christian mange. Les trois voies (Christian, Falko, Robert) sont
réunies en un seul pool (piscine) flat-sharing community.
Les voies/Lanes
Dans l'exemple, les voies correspondent à des personnes. Vous pouvez désigner les voies comme vous le
souhaitez. En pratique, les voies sont souvent utilisées pour attribuer :
- Postes dans l'organisation principale.
- Rôles dans l'organisation secondaire, par exemple, responsable de la protection des données.
- Rôles généraux, par exemple, client.
- Les départements, par exemple, les ventes.
Les voies/Lanes
La gestion des voies est souvent délicate. Dans notre petit processus, par exemple, nous supposons que
les tâches sont clairement réparties. Mais que faire si Falko et Robert veulent manger aussi ?
Une représentation comme celle de la figure ci-dessous serait syntaxiquement erronée. Il n'est pas
permis d'avoir un objet de flux (activité, événement, passerelle) positionné en dehors d'une seule voie.
Les voies/Lanes
La solution pour garder Falko et Robert heureux est de dupliquer la tâche de manger le repas et
d'attribuer cette tâche à chaque personne.
Cela a également du sens du point de vue du contenu, car la tâche est en réalité terminée trois fois.
Les voies/Lanes
Dans BPMN, les voies peuvent également s'entrelacer pour illustrer des responsabilités raffinées.
Les voies/Lanes
Le séparateur n’est plus permis dans BPMN 2.0
 Pool / Piscine / Bassin
Les voies existent toujours dans un pool et les limites du pool représentent les limites du processus du début à la
fin. Pour BPMN, le pool représente une instance de rang supérieur par rapport à ses voies.
Le pool assume le contrôle du processus en d'autres termes, il attribue les tâches. Il se comporte comme le chef
d'orchestre. Ce type de processus est appelé orchestration.
Dans la figure ci-dessous, le chef d'orchestre s'arrange pour que Falko traite la tâche 2 dès que Robert a terminé la
tâche 1. Le chef d'orchestre a le contrôle le plus élevé du processus et chaque instrument de l'orchestre joue l'air
qu'il a choisi.

De
Pool / Piscine / Bassin
Coordonner la coopération avec BPMN nécessite une modélisation explicite. Vous attribuez
chaque tâche worker un pool séparé, et le processus passe de l'un à l'autre en tant que flux
de messages. En principe, cela crée quatre conducteurs indépendants. Ceux-ci ont contrôle
sur leurs mini-processus respectifs, mais ils ne peuvent rien faire d'autre que d'envoyer
messages qui déclenchent leurs processus successeurs.
Pool / Piscine / Bassin
Vous pouvez éliminer les pools et travailler uniquement avec des voies, en modélisant l'échange de
messages comme des tâches normales. C'est traditionnel, et c'est une solution pragmatique pendant,
une période de transition qui permet à vos collègues de s'adapter.
Cependant, à moyen et long termes, éviter les pools vous prive d'un dispositif puissant pour augmenter
l'importance des modèles de processus.
Pool / Piscine / Bassin
Lorsque vous travaillez avec des pools et des flux de messages, vous pouvez modéliser les
éléments suivants :
- Capture d'événements de messages, dans lesquels les flux de messages entrent (catch),
- Lancer des flux de messages, flux de messages sortent (throw),
- Tâches, flux de messages entrent ou sortent,
- Sous-processus (développés), flux de messages entrent ou sortent.
L'art de collaborer
Considérez maintenant la situation dans son ensemble et réfléchissez à la façon dont ce
processus se déroule à partir du point de vue du service de livraison de pizza.
L'art de collaborer
Dès que nous recevons une commande, nous cuisons la pizza. Notre livreur l'apporte au client
et perçoit l'argent, et le processus se termine avec succès.
L'art de collaborer
Un aperçu du processus de pizza avec une piscine et plusieurs voies.

une
mauvaise
Solution
L'art de collaborer
Nous voulons lier les deux processus, c'est-à-dire examiner l'interaction client et service de livraison
d'un point de vue neutre.
Les deux processus dans la représentation combinée ressembleraient à ce qu'ils étaient auparavant,
mais maintenant ils se connectent via flux de messages. BPMN appelle cette forme de visualisation un
diagramme de collaboration. Il montre deux processus indépendants collaborant.
L'art de collaborer
En ce qui concerne les messages de collecte d'argent, il y a une faille dans le modèle du processus
client :nous devons payer la pizza avant de la manger. Nous l'avons ajouté à la figure suivante, et nous
pouvons maintenant connecter les flux de messages directement à la tâche payer pour la pizza.
Piscines qui s'effondrent
Il arrive souvent que nous ne connaissions pas en détail les processus de toutes les parties.
On connaît peut-être le processus de notre propre entreprise, par exemple, mais pas ceux
d'une entreprise partenaire. Tant que notre partenaire et nous adhérons aux interfaces
convenues, telles que la réception ou l'envoi de certains messages, les choses peuvent encore
fonctionner en douceur.
En tant que clients du service de livraison de pizzas, nous nous attendons à ce que le
livreur :

- Accepte les commandes de pizza,

- Livrer les pizzas commandées et récupérer l'argent,
- Soit disponible pour les demandes de renseignements.
Piscines qui s'effondrent
En tant que clients, nous nous intéressons peu au processus interne du livreur. Peut-être qu'il
cuisine puis livre la pizza ; peut-être que lorsqu'il n'a plus de fournitures, il obtient un autre
service de pizza pour cuire la pizza et la livrer. C'est son problème — nous nous attendons
simplement à recevoir notre Pizza.
Dans la modélisation de tels cas, nous pouvons masquer le processus du livreur et réduire le
pool (boite noire pour le livreur).
 Piscines qui s'effondrent
Nous pourrions aller plus loin et réduire également le pool du client.
Maintenant, nous ne voyons que les messages à échanger, en supposant que nous étiquetons les
flèches pour nous donner l'idée générale. L'inconvénient est que nous ne pouvons plus reconnaître les
interdépendances. Nous ne pouvons pas voir si la demande sort toujours, ou n'a lieu que sous certaines
conditions.
BPMN a corrigé ce problème dans la version 2.0 en introduisant un nouveau type de diagramme, le
diagramme dit de chorégraphie.