BPMN: les tâches et leurs types
La tâche est le symbole du travail. Le type précise comment ce travail se fait, par une personne, par un logiciel ou par un échange de message, et une icône dans le coin supérieur gauche le dit au lecteur. Un marqueur au bas du rectangle s'y ajoute quand la tâche se répète ou quand elle sert à défaire un travail déjà fait.
Le chapitre précédent a posé la tâche comme le rectangle à coins arrondis. Celui-ci en donne les huit variantes et les marqueurs qui s’y ajoutent.
La tâche abstraite (abstract task)
Une tâche dont le type n’est pas précisé s’appelle la tâche abstraite1. Elle ne porte aucune icône.
Ce symbole s’appelait none task dans BPMN 1.21, et le nom survit dans certains outils et une partie de la littérature.
La tâche abstraite appartient à la classe de conformité descriptive2, la plus restreinte des trois, et un modèle destiné à des lecteurs métier peut n’utiliser qu’elle.
Les types de tâche
Sept types complètent la tâche abstraite. Chacun se signale par une icône dans le coin supérieur gauche du rectangle, la forme et le trait restant ceux de la tâche1. Le standard décrit quatre de ces icônes en toutes lettres et renvoie à ses figures pour les trois autres; Silver les nomme toutes3.
Cette liste peut être étendue, avec les indicateurs correspondants1. Un outil qui affiche un type absent d’ici reste donc conforme.
La tâche utilisateur (user task)
Une tâche utilisateur est la tâche de workflow typique: une personne l’exécute avec l’assistance d’une application, et elle lui est attribuée par une liste de tâches1. L’icône est un buste. Une demande qui apparaît dans la corbeille d’un gestionnaire est une tâche utilisateur.
La tâche manuelle (manual task)
Une tâche manuelle s’exécute sans l’aide d’aucun moteur d’exécution de processus ni d’aucune application. Le standard en donne pour exemple un technicien qui installe un téléphone chez un client1. L’icône est une main.
Les deux sont faites par un humain, et seule la tâche utilisateur est suivie par un moteur.
La tâche de service (service task)
Une tâche de service utilise un service, qui peut être un service web ou une application automatisée1. L’icône est un engrenage.
Le participant dont le service est utilisé peut être identifié en le reliant à la tâche par un flux de message, dans la collaboration du processus1. Le chapitre sur les pools et la collaboration reprend ce mécanisme.
La tâche de script (script task)
Une tâche de script est exécutée par le moteur de processus lui-même: le modélisateur écrit un script dans un langage que le moteur interprète, et la tâche s’achève quand le script est terminé1. L’icône est un rouleau de parchemin.
Silver réserve ce type aux modèles exécutables: dans un modèle qui ne l’est pas, la tâche de service couvre tout travail automatisé4.
La tâche de règle métier (business rule task)
Une tâche de règle métier soumet des données à un moteur de règles et en récupère le résultat du calcul1. L’icône est un tableau à barre supérieure.
Le symbole marque l’endroit où une décision codifiée s’applique, un barème ou une grille d’éligibilité. La règle elle-même se décrit avec DMN, un standard que l’OMG publie séparément5.
La tâche d’envoi (send task)
Une tâche d’envoi envoie un message à un participant extérieur au processus, et elle est achevée dès que le message est parti1. L’icône est une enveloppe pleine.
La tâche de réception (receive task)
Une tâche de réception attend l’arrivée d’un message venu d’un participant extérieur, et elle est achevée dès que le message est reçu1. L’icône est une enveloppe vide. La même attente peut se noter avec un événement intermédiaire de message, et le chapitre sur les événements compare les deux écritures.
Les marqueurs d’activité
Les marqueurs occupent le bas du rectangle, centrés. Deux d’entre eux disent combien de fois la tâche s’exécute, le troisième la sort du flux normal.
La boucle standard (standard loop)
Le marqueur de boucle est une petite ligne qui s’enroule sur elle-même et se termine par une pointe de flèche6. La tâche se répète tant qu’une condition reste vraie.
Trois attributs la paramètrent7. loopCondition porte la condition. testBefore indique
si elle s’évalue au début ou à la fin de l’itération, ce qui décide si la tâche s’exécute au moins
une fois. loopMaximum plafonne le nombre d’itérations. Le comportement peut rester sous-spécifié,
le modélisateur se contentant de documenter la condition, auquel cas la boucle ne peut pas être
exécutée formellement7.
Les instances multiples (multi-instance)
Le marqueur d’instances multiples est un jeu de trois lignes6. Elles sont verticales quand les instances se déroulent en parallèle, et horizontales quand elles se suivent, le marqueur étant alors le même tourné de 90 degrés6.
La différence avec la boucle est le nombre: les instances multiples créent un nombre d’instances déterminé à l’avance. Ce nombre vient d’une expression ou d’une collection de données fournie en entrée, dont le nombre d’éléments le fixe alors7.
« Consulter chaque fournisseur » est parallèle si les consultations partent ensemble, séquentiel si elles s’enchaînent. Le choix du marqueur est donc une affirmation sur le métier.
La compensation (compensation)
Le marqueur de compensation est une paire de triangles pointant vers la gauche, comme le rembobinage d’un lecteur de cassette6. Il désigne une activité qui défait le travail d’une autre, déjà terminée.
Une tâche de compensation est hors du flux normal: elle attend d’être déclenchée. C’est pourquoi le chapitre précédent la citait parmi les exceptions à la règle d’instanciation des objets de flux sans flux entrant. Le mécanisme complet, l’événement de compensation et son rattachement à l’activité à défaire, appartient au chapitre sur les événements de bord.
Une tâche porte un marqueur ou deux6: la boucle ou les instances multiples, jamais les deux, la compensation pouvant s’ajouter à l’une ou à l’autre.
Choisir un type
Le type présuppose une décision sur la façon dont le travail sera fait.
Le standard donne un repère utilisable. Sa classe de conformité descriptive, la plus restreinte, n’admet que trois formes d’activité simple: la tâche abstraite, la tâche utilisateur et la tâche de service2. La classe analytique y ajoute la tâche d’envoi et la tâche de réception, et les trois restantes, manuelle, de règle métier et de script, ne figurent dans aucune des deux2. Un modèle destiné à des interlocuteurs métier tient donc avec ces trois-là, et distingue déjà ce qu’une personne fait de ce qu’un système fait.
Cette figure porte toute sa lecture dans ses icônes.
Les chapitres sur les niveaux de modélisation et sur le style reviennent sur ce dosage, avec les règles de Silver qui l’encadrent.
Au-delà de la tâche
Une tâche est atomique par définition. Quand le travail se décompose, le symbole change: le sous-processus s’ouvre et se referme, et l’activité d’appel pointe vers un processus défini ailleurs.
Le chapitre suivant
BPMN: les sous-processus. Le sous-processus BPMN en vue réduite et développée, le marqueur ad hoc, l'activité d'appel, la tâche globale et la transaction: ce que chaque bordure impose.
Notes et références
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §10.3.3.1 « Types of Tasks ». Cette clause porte la tâche abstraite et son ancien nom BPMN 1.2, l’extensibilité de la liste, et la définition de chacun des sept types avec son marqueur. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §2.2.2 « BPMN Process Elements », tableau 2.1 « Descriptive Conformance Sub-Class Elements and Attributes », où figurent
task (None),userTasketserviceTask. Le tableau 2.2 de la même clause ajoutesendTasketreceiveTaskpour la classe analytique. ↩︎ ↩︎ ↩︎Bruce Silver, BPMN Method and Style, 2e édition: les icônes de type, dont l’engrenage de la tâche de service et le buste de la tâche utilisateur. Silver y ajoute un critère praticable, qu’une tâche démarrant sur un clic humain reste une tâche utilisateur. ↩︎
Bruce Silver, BPMN Method and Style, 2e édition: la tâche de script est exécutée par le moteur lui-même, et un processus non exécutable emploie une tâche de service pour tout travail automatisé. ↩︎
OMG, Decision Model and Notation (DMN), un standard distinct de BPMN. Le texte de BPMN 2.0.2 ne le mentionne pas. ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §10.3.3 « Tasks », pour les trois marqueurs d’activité et leurs combinaisons autorisées. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §10.3.8 « Loop Characteristics »:
testBefore,loopMaximumetloopConditionpour la boucle standard,isSequentialet la source du nombre d’instances pour les instances multiples. ↩︎ ↩︎ ↩︎