BPMN: les pools, les couloirs et la collaboration

Le pool, le participant et le flux de message appartiennent à la même clause du standard, celle de la collaboration¹. Le couloir se définit avec le processus, dont il est une sous-partition².

Le pool

Un pool est la représentation graphique d’un participant dans une collaboration³. Le standard le trace en rectangle à coins droits, d’un trait plein unique, avec une étiquette placée librement à l’intérieur, séparée du contenu par une ligne³.

Pour la clarté du diagramme, un pool s’étend sur toute la longueur de celui-ci, horizontalement ou verticalement. Ni sa taille ni sa position ne sont contraintes: un pool peut être comprimé pour tenir dans un écran ou sur une page imprimée³.

Une partie de la littérature francophone traduit pool par piscine, et le mot revient dans certains outils. Cette référence garde pool, comme la fiche que le site publie déjà.

La bordure du pool

Le pool est le conteneur des flux de séquence qui relient les activités du processus³.

Un flux de séquence traverse la bordure entre les couloirs d’un pool³. Il ne franchit jamais la bordure du pool lui-même: un processus est entièrement contenu dans son pool³. Le standard le redit à propos des processus privés, qu’une notation à couloirs enferme dans un pool unique⁴.

L’interaction entre pools passe donc par les flux de message³. Le chapitre sur les flux et les artefacts en donne le symbole.

Le pool sans bordure

Un diagramme peut présenter un pool, et un seul, sans bordure. Dès qu’il en compte plusieurs, les autres doivent porter la leur³. Le cas visé est le processus interne, que le modélisateur ou son organisation exécute et qu’il n’est pas obligatoire d’entourer³.

Le marqueur d’instances multiples

Le standard définit un marqueur pour le pool: trois traits verticaux parallèles, centrés au bas de la forme, quand le participant du pool est à instances multiples³. Un fabricant qui demande une offre à plusieurs fournisseurs en est l’exemple⁵.

La multiplicité se paramètre par minimum et maximum. Le marqueur s’affiche quand maximum n’est pas renseigné ou vaut deux ou davantage⁵.

Le participant

Un participant est une entité partenaire précise, une entreprise par exemple, ou un rôle partenaire plus général, acheteur, vendeur ou fabricant⁵. Il est souvent responsable de l’exécution du processus enfermé dans son pool, et un pool peut être défini sans processus⁵.

Ses attributs disent le reste: name, processRef qui identifie le processus affiché dans le pool, partnerRoleRef et partnerEntityRef qui peuvent être définis tous les deux, interfaceRef pour les interfaces qu’il prend en charge et endPointRefs pour l’adresse des services concrets qui le réalisent⁵.

Silver rappelle la conséquence sur le fichier: le modèle sémantique ne connaît que le participant, le pool étant la forme graphique qui pointe vers lui. Comme un participant référence au plus un processus, il lui équivaut en pratique, et un pool boîte noire est un participant sans référence de processus⁶.

Le nom du pool

Les exemples du standard nomment les pools d’après des organisations³.

Silver conteste cet usage pour les pools qui contiennent un flux: nommer un pool d’après un département encourage à découper un processus unique en plusieurs processus indépendants. Un pool de processus porte donc le nom du processus; un pool boîte noire porte le nom du rôle ou de l’entité, Client, Vendeur, Prêteur⁶.

eCH-0158 pose des conventions de nommage pour l’administration publique suisse. Un pool y désigne un participant à une collaboration: une unité d’organisation, un participant au processus pris comme rôle ou un autre processus. Les unités d’organisation et les participants reçoivent un substantif; les processus, un substantif suivi d’un verbe à l’infinitif⁷. Le standard suisse ajoute qu’un seul processus complet est modélisé par pool développé et qu’un pool n’apparaît qu’une fois par diagramme⁷.

Le couloir (lane)

Un couloir est une sous-partition d’un processus, le plus souvent à l’intérieur d’un pool, qui s’étend sur toute la longueur du niveau de processus, verticalement ou horizontalement².

Le trait est celui du pool, rectangle à coins droits d’un trait plein unique. La différence tient à l’étiquette: celle d’un couloir se place où le modélisateur veut, sans être séparée du contenu par une ligne, sauf s’il contient des sous-couloirs².

La sémantique du couloir

Les couloirs servent à organiser et à catégoriser les activités d’un pool: leur signification appartient au modélisateur, et BPMN ne spécifie pas leur usage². Ils portent souvent des rôles internes, un responsable ou un collaborateur, des systèmes tels qu’une application d’entreprise ou des départements comme l’expédition et les finances².

Un couloir n’a donc aucune sémantique d’exécution propre². Silver relève que le standard ne pose aucune règle sur les flux de séquence qui traversent la bordure d’un couloir⁸.

Le couloir est aussi un élément du modèle. Les couloirs sont contenus dans un laneSet, lui-même contenu dans un processus, et un processus peut en contenir plusieurs: chaque laneSet partitionne les mêmes nœuds de flux d’une autre manière². Un couloir porte un name, un élément de partition qui permet à l’outil de déterminer ce qui lui revient, un childLaneSet pour les couloirs imbriqués et la liste flowNodeRefs des nœuds qui lui sont attribués². Tous les couloirs d’un même laneSet doivent définir un élément de partition de même type².

Pour Silver, les couloirs sont des éléments sémantiques à part entière, BPMN 2.0 ayant généralisé la classification à tout critère choisi par le modélisateur. Les laneSet multiples sont autorisés et rarissimes. Dès qu’un niveau de processus emploie des couloirs, tous ses nœuds de flux appartiennent à l’un d’eux⁸.

Il ajoute que le couloir concerne d’abord les tâches utilisateur, les passerelles et les événements pouvant être placés là où c’est commode⁸.

Les couloirs imbriqués

Un couloir peut contenir un childLaneSet, dont les couloirs enfants se dessinent emboîtés dans le parent: un jeu extérieur pour les départements, un jeu intérieur pour les rôles de chaque département². Le standard admet aussi une organisation en matrice².

Dumas donne le partage d’usage le plus courant: le pool modélise une classe de ressources, une partie prenante entière par exemple; le couloir la partage en sous-classes ou en ressources individuelles, comme un département, une équipe, un système ou un équipement⁹. En matrice, une activité placée à l’intersection est exécutée par la ressource qui satisfait les deux couloirs, puisque chaque activité n’est exécutée que par une seule ressource⁹. Il déconseille enfin de nommer un couloir d’après une personne, les individus changeant souvent, là où un rôle ou un système dure⁹.

eCH-0158 resserre l’usage pour l’administration publique: un couloir y représente les rôles et les responsabilités dans un processus, s’étiquette le plus souvent d’un nom de rôle au singulier, ne porte jamais le même nom qu’un pool et s’imbrique sur trois niveaux au maximum¹⁰.

La collaboration

Une collaboration réunit des participants, dessinés en pools, et leurs interactions, dessinées en flux de message. Elle peut aussi contenir les processus des pools et des chorégraphies entre les pools¹. Elle compte d’ordinaire deux pools ou davantage¹¹.

Un pool y prend l’une de trois formes: vide, boîte noire ou porteur d’un processus. Toutes les combinaisons de pools, de processus et de chorégraphie sont admises¹¹. Un participant peut contenir un processus sans y être tenu¹².

isClosed, à faux par défaut, dit si des flux de message absents du modèle peuvent survenir pendant l’exécution de la collaboration: à vrai, ils ne le peuvent pas¹.

Les règles de la collaboration

Trois règles décident si une collaboration est valide.

• Un flux de séquence reste dans son pool. Il circule librement d’un couloir à l’autre et s’arrête à la bordure du pool³.
• Un flux de message relie deux pools distincts. Il se raccorde à la bordure du pool ou à un objet de flux situé à l’intérieur, et il ne relie jamais deux objets d’un même pool¹³.
• Trois éléments seulement peuvent être source ou cible d’un flux de message: le pool avec son participant, l’activité et l’événement¹³. Le standard les rassemble sous le nom de nœud d’interaction (interaction node)¹⁴.

Le couloir ne figure dans aucune de ces listes: les flux de message se raccordent au pool qui le contient.

Le pool boîte noire (black box)

Un pool n’est pas tenu de contenir un processus³. Le standard lui reconnaît deux formes: la boîte blanche (white box), qui expose son contenu, et la boîte noire (black box), qui le cache. Aucun flux de séquence ne s’associe à un pool boîte noire, et des flux de message peuvent se raccorder à sa bordure³. L’étiquette d’un tel pool se place n’importe où à l’intérieur, sans ligne de séparation³.

Le client de la figure précédente en est un: l’organisation qui traite la demande connaît les messages qu’elle reçoit de lui et ceux qu’elle lui envoie, sa logique interne lui restant invisible.

Silver en fait une règle de méthode. Un pool qui contient des éléments de flux est par définition un pool de processus, et il doit représenter un processus complet, du début à la fin. Poser une activité Remplir le formulaire dans le pool du client oblige donc à modéliser tout son processus d’achat, y compris la réception de la facture et des notifications ultérieures, que le vendeur ignore le plus souvent. Le pool boîte noire évite cette obligation. Dans sa méthode, il est le seul auquel un flux de message peut se raccorder par la bordure, règle plus stricte que celle du standard, qui admet ce raccordement sur n’importe quel pool¹⁵.

Pour Dumas, le choix relève de la pertinence: une organisation expose son comportement interne quand le projet en a besoin. Modéliser la fourniture de matières premières en boîte blanche se justifie lorsqu’un retard du fournisseur ralentit la fabrication; ailleurs, la boîte noire suffit et se dessine en pool réduit (collapsed pool), un rectangle vide portant son nom au milieu⁹.

Le processus public (public process)

Le standard distingue le processus privé (private process) non exécutable, le processus privé exécutable⁴ et le processus public. Ce dernier ne retient que les activités qui communiquent avec les autres participants ainsi que leur ordre, et cache les activités internes: il montre au monde extérieur les messages nécessaires pour interagir avec lui et leur séquence¹⁶. Ce type portait le nom d’abstrait dans BPMN 1.2¹⁶.

Silver le situe entre le pool boîte noire, qui n’a pas de processus, et le processus privé entièrement défini. Il le décrit comme un dispositif de commerce interentreprises, où les types et les séquences de messages autorisés sont fixés d’avance par un standard sectoriel ou un accord entre partenaires. Hors de ce cas, il recommande le pool boîte noire¹⁵.

Le système comme participant

Un système peut apparaître de trois façons.

En couloir, quand il appartient à l’organisation qui exécute le processus. C’est le cas du couloir Système de notation plus haut: la tâche qui y est placée devient une tâche de service. Dumas approuve cet emploi pour un progiciel de gestion, dont la durée de vie est longue là où les personnes changent⁹.

En pool, quand il est extérieur. Le standard donne le mécanisme pour la tâche de service: le participant dont le service est utilisé peut être identifié en reliant la tâche à ce participant par un flux de message, dans la collaboration définitionnelle du processus¹⁷.

Sans symbole, enfin, quand le modèle n’a pas à montrer le système. Le pool ajoute un participant au diagramme, et l’omettre reste un choix légitime.

Silver départage le couloir et le pool: quand l’alignement des instances le permet, les unités d’organisation internes se modélisent en couloirs d’un pool de processus unique, puisque des pools séparés impliquent des processus indépendants. À défaut d’alignement, une facturation mensuelle face à des commandes facturées une à une par exemple, des pools séparés se justifient¹⁵. Il note enfin que certains modélisateurs réservent un couloir aux tâches de service, un pour tous les systèmes ou un par système; la question reste pour lui une affaire de préférence⁸.

La ressource et l’exécutant (resource, performer)

Une activité mobilise parfois plus d’un acteur, et le couloir n’en désigne qu’un. BPMN répond par ce que Dumas appelle la perspective des ressources, qui existe dans le modèle sans symbole au diagramme⁹.

Une ressource se déclare une fois pour le modèle et se référence depuis les activités qui l’emploient, ressources humaines comprises. Sa définition reste abstraite, sans dire comment les identifiants réels s’y rattachent à l’exécution, et plusieurs activités peuvent partager la même ressource¹⁸. L’affectation se fait par un resourceRef ou une expression évaluée à l’exécution¹⁹.

L’exécutant se déclare par la classe Performer, qui définit la ressource qui exécutera l’activité ou en portera la responsabilité. Le standard admet quatre formes: un individu précis, un groupe, un rôle ou une position dans l’organisation, enfin une organisation entière²⁰.

Aucun de ces éléments ne porte de symbole. Un outil qui veut en afficher un passe par le mécanisme d’extension, qui permet d’attacher des attributs et des éléments supplémentaires aux éléments standard. Le modèle reste conforme et interchangeable, seuls les ajouts pouvant se perdre lors d’un échange²¹. Un diagramme qui affiche un acteur supplémentaire repose donc sur une convention d’outil, que le lecteur d’un autre outil ne verra pas nécessairement.

Les classes de conformité

Le vocabulaire de la collaboration se trouve entièrement dans la sous-classe descriptive, la plus restreinte des trois. Le tableau des éléments descriptifs porte participant (pool) avec id, name et processRef, laneSet avec id et le couloir muni de son nom, de son childLaneSet et de ses références d’éléments de flux, ainsi que messageFlow avec id, name, sourceRef et targetRef²².

Le standard précise que la clause consacrée à la collaboration est exigée pour la conformité de modélisation de processus, celle de chorégraphie et la conformité complète, et qu’elle ne l’est pas pour les deux conformités d’exécution¹. Un moteur peut donc être conforme sans rien connaître des pools, là où un outil de modélisation ne le peut pas.

Au-delà du pool

Le chapitre sur les données rendra visible ce que les messages transportent. La chorégraphie et la conversation, les deux diagrammes que le standard place autour de la collaboration, ont leur propre chapitre. Les conventions suisses citées ici prennent leur sens complet dans le chapitre consacré au standard eCH.

Le chapitre suivant

BPMN: les données. Objet de données, état entre crochets, collection, magasin de données, entrées et sorties, associations de données: la perspective données de BPMN 2.0.

Notes et références