BPMN et diagramme d'activité UML

Commençons par ce qui ne fait pas débat. Les deux notations décrivent un jeton qui circule le long d'un flux : il part d'un début, traverse des morceaux de travail, se divise à une branche, attend à une jointure et finit par s'arrêter. Ce modèle vient du même endroit dans les deux cas, et c'est pourquoi les deux diagrammes d'un simple processus d'approbation sont visiblement le même dessin avec un mobilier différent.

Si votre processus est une ligne droite avec deux décisions, la comparaison s'arrête ici et vous devriez tracer celle que vos lecteurs connaissent déjà. Les différences ci-dessous ne mordent qu'à partir du moment où participants, interruptions ou automatisation entrent en scène - c'est-à-dire, il faut l'avouer, dans la plupart des processus réels.

1. Le couloir est une règle, pas une étiquette. C'est la différence qui compte le plus et que l'on remarque le moins. Une partition d'activité UML dit qui exécute une action et rien de plus, si bien que le flux de contrôle franchit ses frontières aussi librement que n'importe quoi d'autre. Un couloir BPMN est un participant entièrement distinct doté de son propre processus, et BPMN interdit au flux de séquence de le franchir : l'interaction entre couloirs doit être un flux de message. Cette seule règle explique qu'un diagramme BPMN de deux organisations soit une affirmation sur leur indépendance, tandis que l'équivalent UML est une affirmation sur la répartition des rôles.

2. L'interruption est de première classe en BPMN. Attachez un événement frontière à une tâche et vous avez dit, d'une seule marque, que ce travail peut être interrompu par une échéance, une erreur ou un message entrant - et si le chemin initial se poursuit ensuite. UML peut exprimer la même chose avec une région d'activité interruptible et une action d'acceptation d'événement, mais la construction est rarement enseignée, rarement tracée et rarement bien lue. En pratique, si le processus est plein d'escalades et de délais, BPMN le dessinera avec un tiers de l'encre. Le vocabulaire d'événements est l'essentiel de ce que vous achetez.

3. UML tient dans un modèle plus large. Un diagramme d'activité partage son modèle avec le diagramme de classes voisin : une action peut donc consommer un objet d'un type défini ailleurs, et un outil peut vérifier que ce type existe. BPMN a des objets de données, mais ils sont locaux au processus par construction et ne portent rien qui ressemble à un modèle de classes. Si la description du processus doit s'aligner sur une conception système, ce vocabulaire partagé vaut plus que n'importe quelle fonctionnalité de notation.

4. Seul BPMN est exécutable. BPMN 2.0 définit une sérialisation XML que les moteurs de workflow consomment directement, ce qui permet au même fichier d'être une image pour le métier et un artefact de déploiement pour l'ingénierie. UML a fUML, un sous-ensemble exécutable à la sémantique définie, et presque aucun moteur qui l'accepte. Traitez cela comme la seule contrainte dure de la liste : s'il y a un moteur au bout de la chaîne, la notation est BPMN et le reste de cet article n'est que contexte.

La décision est presque toujours prise par le lecteur et non par le processus. Les deux notations peuvent exprimer n'importe quel processus que vous aurez à tracer ; une seule sera lue d'emblée par les gens qui doivent le valider.

Là où le public est vraiment mixte - et sur un projet de taille quelconque il l'est généralement - tracez le processus une fois en BPMN pour ceux qui en sont propriétaires, et gardez le diagramme d'activité pour les parties du flux qui relèvent vraiment de l'algorithme et non du processus. Cette séparation suit le public au lieu de le combattre, et se défend bien plus facilement en revue qu'un diagramme unique que la moitié de la salle ne sait pas lire.

Les conversions dans les deux sens sont courantes, et la façon honnête d'en mener une est de décider à l'avance ce que l'on accepte de perdre. De BPMN vers UML, le flux de contrôle se transfère presque parfaitement : les tâches deviennent des actions, les passerelles exclusives des nœuds de décision et de fusion, les passerelles parallèles des fourches et des jointures, et les règles de passerelle se correspondent une à une. Ce que vous abandonnez, c'est tout ce qui touche aux participants et aux événements.

Dans l'autre sens, les pertes sont plus faibles mais les ajouts sont du travail : BPMN voudra un événement de début, un événement de fin et un couloir pour chaque acteur que vous aviez modélisé en partition, et il refusera de laisser le flux de séquence traverser ces couloirs. C'est en général ce refus qui rentabilise l'exercice, car il force une question que le diagramme d'activité vous laissait éviter : est-ce un processus ou deux ?

Quel que soit le sens, le coûteux est le redessin - et c'est précisément ce qu'un outil adossé à un modèle supprime : gardez participants et travail comme éléments de modèle et la seconde vue cesse d'être un second dessin. Pour le voir plutôt que le lire, le modèle de départ BPMN ouvre un processus avec couloirs et lignes d'eau, événements déjà posés, et la démo de quinze secondes rend un vrai fichier à la fin.