BPMN: niveaux de modélisation et classes de conformité

Un niveau de modélisation est le degré de détail auquel un modèle BPMN est poussé, avec la palette de symboles qui l'accompagne. On en distingue trois: descriptif, analytique et exécutable. L'OMG leur donne une contrepartie normative sous la forme de trois sous-classes de conformité, qui énumèrent les éléments et les attributs qu'un outil doit prendre en charge. L'usage prévu du modèle décide du degré auquel on s'arrête.

L’OMG définit trois sous-classes de conformité, qui disent ce qu’un outil doit prendre en charge¹. Les praticiens parlent de trois niveaux de modélisation, descriptif, analytique et exécutable, qui disent jusqu’où un modèle va. Les noms coïncident parce que les seconds ont précédé les premières et les ont nourries².

Les quatre types de conformité

Un logiciel peut revendiquer la conformité à BPMN 2.0 si et seulement s’il satisfait entièrement les points de conformité applicables. Celui qui ne les satisfait qu’en partie peut seulement se dire fondé sur le standard.

Quatre types sont définis: la conformité de modélisation de processus, la conformité d’exécution de processus, la conformité d’exécution BPEL et la conformité de modélisation de chorégraphie. Ils sont largement indépendants. Une implémentation qui revendique la modélisation de processus n’a pas à prendre en charge la modélisation de chorégraphie, et réciproquement; celle qui revendique l’exécution de processus n’a à être conforme ni à l’une ni à l’autre. L’implémentation qui satisfait les quatre revendique la conformité complète³.

Les deux conformités d’exécution

Un outil qui revendique la conformité d’exécution doit prendre en charge et interpréter intégralement la sémantique opérationnelle et le cycle de vie des activités, ainsi que le métamodèle sous-jacent. Il n’est pas censé prendre en charge les chorégraphies, ni la conformité de modélisation de processus: il peut employer des éléments graphiques, des formes et des marqueurs différents de ceux du standard⁴. Du côté des diagrammes, il doit seulement importer les types de diagramme de processus, collaboration définitionnelle comprise⁵. La conformité d’exécution BPEL est une forme particulière de la précédente, réservée aux outils qui prennent en charge la correspondance de BPMN vers WS-BPEL, le langage d’exécution de processus des services web, et elle exige la conformité d’exécution de processus dans son entier⁶.

Les paquets exigés par la conformité de modélisation

La conformité de modélisation de processus exige la prise en charge de quatre familles¹:

les éléments centraux de BPMN, ceux des paquets Infrastructure, Foundation, Common et Service;
les diagrammes de processus, avec les éléments des paquets Process, Activities, Data et Human Interaction;
les diagrammes de collaboration, avec les pools et les flux de message;
les diagrammes de conversation, avec les pools, les conversations et les liens de conversation, que le chapitre sur la chorégraphie et la conversation traite.

Le standard détaille ensuite l’inventaire complet⁷: tous les types de tâche, de passerelle et d’événement, les sous-processus intégrés, l’activité d’appel, le couloir, les participants, les données, les artefacts, les flux de séquence et de message, la corrélation, enfin les marqueurs de boucle, d’instances multiples, de transaction et de compensation. Une note dispense les implémentations des éléments de chorégraphie.

L’inventaire est lourd. Silver rappelle pourquoi les sous-classes ont été ajoutées: certains des paquets exigés pour la conformité complète contiennent des éléments réservés aux modèles exécutables, et tous contiennent des éléments obscurs et rarement employés⁸.

Les trois sous-classes

Comme alternative à la conformité de modélisation de processus complète, le standard définit trois sous-classes: descriptive, analytique et d’exécution commune (Common Executable).

La descriptive porte sur les éléments visibles et les attributs employés en modélisation de haut niveau; le standard la dit confortable pour les analystes qui ont pratiqué les outils d’organigramme des suites d’analyse de processus métier. L’analytique contient toute la descriptive et, au total, environ la moitié des constructions de la classe complète; elle repose sur l’expérience des formations BPMN, sur une analyse des usages dans le cadre d’architecture du département américain de la défense (DoDAF) et sur la normalisation prévue pour ce cadre. Toutes deux se concentrent sur les éléments visibles et sur un sous-ensemble minimal d’attributs de soutien. La sous-classe d’exécution commune vise ce qu’exigent les modèles de processus exécutables. Les éléments et les attributs absents des trois appartiennent à la classe complète¹.

Trois critères décident si un outil peut revendiquer une sous-classe⁷:

tous les éléments de la sous-classe doivent être pris en charge;
pour chaque élément, tous les attributs énumérés doivent l’être;
un attribut que la sous-classe passe sous silence et que le schéma n’exige pas reste hors de la sous-classe, les exceptions étant signalées.

La sous-classe descriptive

Le tableau 2.1 énumère les éléments et les attributs de la sous-classe descriptive. Côté structure: le participant avec son pool, le jeu de couloirs, le flux de séquence inconditionnel et le flux de message. Côté travail: la tâche neutre, la tâche utilisateur, la tâche de service, le sous-processus dans ses vues réduite et développée, l’activité d’appel. Côté logique: la passerelle exclusive et la passerelle parallèle, avec leurs seuls id et name. Côté événements: le début et la fin neutres, le début et la fin de message, le début de minuterie, la fin de terminaison. Côté données et artefacts: l’objet de données, la référence de magasin de données, l’association, l’annotation textuelle et le groupe. Une ligne porte enfin la documentation, avec une note rappelant qu’elle est un attribut de la plupart des éléments plutôt qu’un symbole⁹.

Le traitement d'une réclamation dessiné avec la seule sous-classe descriptive. Les deux issues de la passerelle portent leur réponse en étiquette.

Le diagramme se lit entièrement. Ce qui manque tient dans le modèle: la condition qui décide de la sortie de la passerelle n’existe que dans l’étiquette oui, puisque le flux de séquence descriptif est inconditionnel⁹. Un lecteur métier valide ce diagramme; un moteur n’en ferait rien.

Silver décrit sa palette comme reprise pour l’essentiel de l’organigramme traditionnel et suffisante pour décrire la plupart des comportements de processus de façon compacte; à condition d’ignorer les comportements déclenchés par un délai ou par l’arrivée d’un message, elle peut suffire pour toute une carrière¹⁰. Elle laisse de côté les chemins d’exception, les conditions et la répétition.

La sous-classe analytique

Le tableau 2.2 ajoute à la descriptive une liste dominée par les événements. Le flux de séquence y gagne ses formes conditionnelle et par défaut, avec l’expression de condition et l’attribut default. La tâche d’envoi et la tâche de réception arrivent. Les caractéristiques de boucle et d’instances multiples deviennent disponibles sur les activités. Les passerelles inclusive et événementielle rejoignent les deux premières. Cinq déclencheurs s’ouvrent, le lien, le signal, l’erreur, l’escalade et la condition, chacun dans une sélection de positions que le tableau énumère ligne à ligne, et le message comme la minuterie gagnent leurs formes intermédiaires et de bord. La dernière ligne ajoute au flux de message l’attribut messageRef, qui reste optionnel et hors sous-classe sur les événements de message¹¹.

Le même processus au niveau analytique. La tâche « Répondre au client », jusqu'ici une tâche utilisateur, devient une tâche d'envoi, et une seconde tâche d'envoi ouvre le chemin du délai que la minuterie de bord déclenche.

Trois additions rendent explicite ce que la version précédente laissait ouvert. Le flux par défaut, marqué du trait oblique, dit que le refus est l’issue qui reste quand la condition échoue. L’événement de bord non interruptif, au double trait interrompu, dit qu’un délai déclenche une information au client pendant que l’examen se poursuit. La tâche d’envoi dit qu’un message part vers un participant extérieur. Une quatrième addition reste invisible: la sortie oui porte désormais une expression de condition, que le standard n’autorise que sur un flux issu d’une passerelle et qui peut être nulle¹¹.

Toutes les issues du processus sont désormais représentées. Selon Silver, l’analyste qui rédige des exigences de solution en a besoin, parce que le comportement déclenché par un événement est un fait des processus réels; il note que beaucoup d’outils n’en prennent toujours pas en charge la totalité¹⁰. Le modèle devient utilisable pour l’analyse de performance, contre un diagramme plus dense et un lecteur qui doit connaître les événements.

La sous-classe d’exécution commune

Cette sous-classe s’adresse aux outils capables d’émettre des modèles exécutables, et impose trois langages: XML Schema pour la définition des types de données, WSDL pour la description des interfaces de service, XPath pour la désignation des éléments de données à l’intérieur d’un document¹².

Sa liste d’éléments reste proche de la descriptive du côté des formes, en y ajoutant les éléments enfants et les attributs qui portent le détail d’exécution¹³. La tâche utilisateur y arrive avec ses rendus, son implémentation, ses ressources, sa spécification d’entrées et de sorties, ses associations de données, ses caractéristiques de boucle et ses références d’événements de bord. Un second tableau énumère seize classes de soutien, dont la ressource, le rôle de ressource, l’entrée, la sortie, la définition d’élément, l’opération, le message, l’erreur, l’affectation et trois définitions d’événement¹².

Ce qui en est absent compte autant. Silver relève que le pool, le couloir, le flux de message et le magasin de données, tous présents dans la descriptive, manquent ici, ce qui concorde avec le petit nombre de suites BPM qui prennent en charge les diagrammes de collaboration; que le seul événement de bord admis est l’erreur, vraisemblablement sur une tâche puisque l’événement de fin d’erreur ne figure pas dans la sous-classe; et que la gestion des exceptions y est réduite au minimum¹³.

Le même processus rebâti dans la sous-classe d'exécution commune. L'enregistrement passe à une tâche de service, un objet de données circule entre deux tâches, une erreur de bord conduit à un événement de fin de terminaison et le chemin du délai a disparu.

Trois changements suivent de la liste d’éléments plutôt que d’une décision de modélisation. L’enregistrement devient une tâche de service, la sous-classe ne portant pas la tâche neutre côté travail automatisé. L’événement de début capture un message, ce qui dit comment une instance naît. Surtout, le chemin du délai a disparu: la minuterie de bord non interruptive de la figure précédente est indessinable ici, puisque l’erreur est le seul événement de bord admis. Une sous-classe d’exécution retire donc du comportement modélisé en même temps qu’elle ajoute des attributs.

Le reste du diagramme gagne en précision. L’objet de données rend explicite ce que l’examen consomme, condition posée par Dumas dès qu’un moteur doit passer le contrôle d’une tâche à l’autre¹⁴. La sortie oui porte une expression XPath. Trois informations ont quitté le dessin: le contenu des messages, l’affectation des tâches utilisateur et la définition du type qui sert de dossier. Silver mesure l’écart: l’essentiel de l’effort de rédaction de BPMN 2.0 a porté sur les éléments liés aux processus exécutables; il ajoute que BPMN 2.0 n’est pas un langage d’exécution comparable à BPEL et qu’il s’attend à le voir servir avant tout de format d’échange, chaque outil gardant son modèle objet interne¹⁵.

La conformité au-delà des éléments

Les listes d’éléments ne sont qu’une partie de la conformité de modélisation, que six autres sous-clauses complètent.

L’apparence visuelle. Une implémentation qui crée et affiche des diagrammes BPMN doit employer les éléments graphiques, les formes et les marqueurs illustrés par le standard, avec une latitude sur la taille, la couleur, le style de trait et la position des textes. Quatre extensions sont permises: ajouter des marqueurs ou des indicateurs, ajouter une forme d’artefact qui n’entre en conflit avec aucune autre, colorer un élément en donnant à la couleur une sémantique supplémentaire, changer un style de trait sans entrer en conflit avec un style exigé ailleurs. Une extension ne change jamais la forme spécifiée d’un élément ou d’un marqueur: un carré ne devient pas un triangle, des coins arrondis ne deviennent pas des coins droits¹⁶.

La conformité structurelle. Les connexions et les relations entre éléments graphiques suivent les spécifications et les restrictions du standard; là où une connexion dépend d’attributs, l’outil assure la correspondance entre le tracé et les valeurs. Le standard signale ces règles par une puce en losange¹⁷.

La sémantique. Une implémentation qui interprète un diagramme comme une spécification de processus le fait conformément à l’interprétation du standard. Elle n’est pas censée prendre en charge la sémantique d’exécution, qui relève des types d’exécution¹⁸.

Les attributs. Pour tout attribut obligatoire, une implémentation conforme fournit un mécanisme pour en créer et en afficher les valeurs, élément par élément; là où une représentation graphique est exigée, c’est celle du standard qui s’emploie¹⁹.

Les éléments optionnels. Les éléments non normatifs ou informatifs restent facultatifs, comme les fonctionnalités déclarées optionnelles. L’option porte sur la façon d’afficher, sur le fait d’afficher ou sur le fait de prendre en charge, et une fonctionnalité dont l’option ne porte que sur l’affichage doit être prise en charge²⁰.

L’échange visuel. L’un des buts principaux du standard est un format d’échange permettant de transporter modèle et mise en page d’un outil à l’autre, ce qui recommande la prise en charge du métamodèle des types de processus²¹.

Les trois niveaux de modélisation

Les niveaux sont nés d’une stratégie pédagogique dans la formation BPMN de Silver: la première journée se limitait à un jeu restreint de formes qu’il appelait la palette de niveau 1, la deuxième journée abordait le traitement des exceptions et demandait la palette de niveau 2¹⁰. L’OMG a repris son explication des niveaux comme matériel de référence pour son examen de certification OCEB en gestion des processus métier. Les éditeurs y ont ensuite trouvé leur compte, une palette limitée rendant l’échange de modèles praticable, et les niveaux sont entrés dans la version finale de la spécification BPMN 2.0, poussés en phase de finalisation par Robert Shapiro. Dans le vocabulaire du standard, le niveau 1 s’appelle sous-classe descriptive et le niveau 2 sous-classe analytique; la deuxième édition de son livre a ajusté ses palettes pour qu’elles correspondent exactement aux deux sous-classes officielles².

Le niveau 3, qu’il nomme BPMN exécutable, porte sur les détails XML absents du diagramme: modèles de données, expressions conditionnelles sur les données aux passerelles, logique détaillée d’affectation des tâches. Les niveaux 1 et 2 concernent les processus non exécutables et reposent uniquement sur l’information visible au diagramme¹⁰. De là sa formule: ce qui n’est pas dans le diagramme ne compte pas²².

Le niveau 1 a changé de définition entre les deux éditions. La première en faisait une palette restreinte accompagnée d’une attitude plus détendue envers les règles de BPMN, proche de l’organigramme traditionnel. Silver a cessé de l’enseigner ainsi, pour deux raisons: la validation automatique des règles de style met la correction à portée d’un débutant, et masquer les fondements conceptuels de BPMN aux modélisateurs de niveau 1 rend plus difficile la constitution d’un langage commun entre le métier et l’informatique²³. L’article de ce site sur les trois niveaux rappelle cette caractérisation d’origine, encore répandue chez les consultants.

Le choix d’un niveau

Dumas fournit le critère: l’usage prévu détermine le degré de détail du modèle. Pendant la découverte des processus, cet usage est de comprendre assez pour conduire l’analyse qui suit, ce qui rend inutile une documentation d’un détail extrême. Beaucoup d’organisations tombent dans ce piège, avec un effet négatif sur le coût du projet et surtout un report de l’amélioration. L’ajout des données et des exceptions relève de la même règle: on les capture explicitement lorsque le processus est destiné à être automatisé²⁴.

Le passage au niveau exécutable, chez lui, est une méthode en cinq étapes²⁵: identifier les frontières de l’automatisation, revoir les tâches manuelles, compléter le modèle, l’amener à une granularité adéquate, enfin spécifier les propriétés d’exécution.

La première repose sur un principe, tous les processus ne sont pas automatisables, et sur le tri des tâches en automatisées, manuelles et utilisateur²⁶. La deuxième liste les éléments pertinents au niveau conceptuel et inexploitables par un moteur: les objets et les magasins de données physiques, les messages qui transportent des objets physiques, les annotations textuelles, l’état d’un objet de données inscrit dans son étiquette, enfin les pools et les couloirs, qui portent souvent une affectation de ressources à gros grain. Quand l’outil les tolère, Dumas conseille de les laisser en place, parce qu’ils guident la spécification des propriétés d’exécution²⁷. La troisième repose sur deux autres principes: les exceptions sont la règle, et sans données il n’y a ni décision ni transmission entre tâches¹⁴.

Les niveaux selon eCH

Les standards suisses emploient les mêmes trois noms et les rattachent à un but.

eCH-0074 pose le principe d’adéquation: le but de la modélisation est à consigner explicitement, relevé de l’existant, modélisation de l’état visé, optimisation ou automatisation, et le degré de détail s’adapte à ce but. Une remarque du même paragraphe présente les trois niveaux de modélisation comme des niveaux d’abstraction que le standard BPMN 2.0 distingue et affecte à des buts différents: le descriptif vise la représentation métier correcte et sert de référence contraignante pour l’entente entre acteurs; l’analytique emploie une syntaxe et une palette de symboles étendues pour des exigences de conception plus complexes, événements et traitement des erreurs; l’exécutable ajoute des éléments de description spéciaux, qui décrivent et fixent exactement le comportement des systèmes de processus automatisés²⁸.

eCH-0158 reprend les trois niveaux de eCH-0074 et se limite au niveau descriptif. Il décrit ce niveau comme la vue métier du processus, avec le déroulement normal, l’événement de début et l’événement de fin, les divisions, les variantes de processus, les responsabilités et la communication avec les partenaires extérieurs, sur plusieurs niveaux de sous-processus s’il le faut. Ce qui le sépare des deux autres est la perspective métier et un jeu de symboles restreint, et le standard renvoie ici à Silver. Il renonce par exemple à l’événement intermédiaire de message en émission, au motif que l’envoi d’un message n’est pas automatique du point de vue métier et suppose toujours une activité, qu’il vaut mieux décrire comme telle²⁹. Les éléments BPMN du niveau descriptif occupent son chapitre 3, celui dont les conventions de pool et de couloir ont été citées plus haut.

Ce renoncement rencontre de front la sous-classe d’exécution commune. Celle-ci ne porte pas la tâche d’envoi, de sorte qu’un envoi de message y prend la forme d’un événement intermédiaire de message en émission, exactement le symbole que la convention suisse écarte du niveau descriptif. Les trois niveaux forment donc une gamme plutôt que trois palettes emboîtées: monter d’un cran écarte parfois ce que le cran précédent tenait pour la bonne écriture.

L’annexe 2 décrit l’extension de la palette de symboles de eCH-0158, s’adresse aux gestionnaires de processus, aux business analystes et aux architectes d’entreprise, et déclare viser le niveau analytique en renvoyant au paragraphe de eCH-0074 cité plus haut³⁰.

Les niveaux eCH sont des niveaux de modélisation affectés à des buts, du ressort du modélisateur; les sous-classes du standard sont des classes de conformité qui engagent des outils. Les deux échelles portent les mêmes noms parce qu’elles descendent de la même source, Silver, que eCH-0158 cite. La motivation déclarée de eCH-0158 achève de les rapprocher: unifier l’application de BPMN, normalisé par ailleurs comme ISO 19510:2013, pour la représentation graphique des processus de l’administration publique suisse, qui admet un grand nombre d’options de modélisation et de degrés de liberté³¹. Les deux démarches procèdent de la même façon: restreindre la palette.

Au-delà des niveaux

Le niveau fixe la palette; il ne dit pas comment s’en servir. Les motifs courants rassemblent les assemblages qui reviennent d’un modèle à l’autre, et le chapitre sur le style et les erreurs fréquentes porte les règles que Silver ajoute au standard. Les conventions suisses prennent leur sens complet dans le chapitre consacré au standard eCH.

Le chapitre suivant

BPMN: les motifs courants. Huit assemblages BPMN qui reviennent dans les modèles: choix exclusif, mise en parallèle, boucle, échéance, demande et réponse, reprise, escalade, annulation.

Notes et références

OMG, Business Process Model and Notation (BPMN), version 2.0.2, §2.2.1 « BPMN Process Types »: les quatre familles de paquets exigées, à savoir les éléments centraux (Infrastructure, Foundation, Common, Service), les diagrammes de processus (Process, Activities, Data, Human Interaction), les diagrammes de collaboration avec les pools et le flux de message, les diagrammes de conversation avec les pools, les conversations et les liens de conversation; puis les trois sous-classes offertes en alternative, la descriptive portant sur les éléments visibles de la modélisation de haut niveau et jugée confortable pour les analystes venus des outils d’organigramme de l’analyse de processus métier, l’analytique contenant toute la descriptive et environ la moitié des constructions de la classe complète, appuyée sur l’expérience des formations BPMN, sur l’analyse des usages dans le cadre d’architecture du département américain de la défense et sur la normalisation prévue pour ce cadre, la sous-classe d’exécution commune visant les modèles exécutables; enfin la concentration des deux premières sur les éléments visibles et un sous-ensemble minimal d’attributs de soutien, avec le renvoi à la classe complète pour tout ce qui en est absent. La clause §2.2 « Process Modeling Conformance » se borne à annoncer les huit sous-clauses qui décrivent ce type de conformité. ↩︎ ↩︎ ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, Cody-Cassidy Press, 2011: les niveaux nés comme stratégie pédagogique de sa formation BPMN, leur reprise par l’OMG comme matériel de référence pour l’examen de certification OCEB en gestion des processus métier, leur seconde valeur pour les éditeurs, la limitation de la palette rendant l’échange de modèles possible, leur entrée dans la version finale de BPMN 2.0 obtenue en phase de finalisation par Robert Shapiro, la correspondance du niveau 1 avec la sous-classe descriptive et du niveau 2 avec la sous-classe analytique, enfin l’ajustement des palettes de la deuxième édition pour correspondre exactement aux sous-classes officielles. ↩︎ ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §2.1 « General »: la revendication de conformité subordonnée à la satisfaction entière des points de conformité applicables, la mention « fondé sur » réservée à une satisfaction partielle, les quatre types de conformité, l’indépendance mutuelle de la modélisation de processus et de la modélisation de chorégraphie, l’absence d’obligation faite au type d’exécution de processus d’être conforme aux deux types de modélisation, enfin la conformité complète définie par la satisfaction des quatre. Les renvois numériques de cette clause désignent les quatre types par les numéros 2.1 à 2.4, alors que leurs clauses sont §2.2 à §2.5; les numéros imprimés ici sont ceux des clauses elles-mêmes. ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §2.3.1 « Execution Semantics »: la prise en charge et l’interprétation intégrales de la sémantique opérationnelle et du cycle de vie des activités, la possibilité d’ignorer les éléments non opérationnels, la prise en charge intégrale du métamodèle sous-jacent, enfin la note dispensant l’outil des modèles de chorégraphie et de la conformité de modélisation de processus, avec la liberté d’employer d’autres éléments graphiques, formes et marqueurs. ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §2.3.2 « Import of Process Diagrams »: l’outil revendiquant la conformité d’exécution de processus doit prendre en charge l’import des types de diagramme de processus BPMN, y compris leur collaboration définitionnelle. ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §2.4 « BPEL Process Execution Conformance »: le type particulier de conformité d’exécution qui prend en charge la correspondance de BPMN vers WS-BPEL, avec la note exigeant la prise en charge intégrale de la conformité d’exécution de processus et dispensant l’outil des chorégraphies comme de la conformité de modélisation de processus. La conformité de modélisation de chorégraphie fait l’objet de §2.5 « Choreography Modeling Conformance ». ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §2.2.2 « BPMN Process Elements »: l’inventaire de la conformité de modélisation de processus, avec tous les types de tâche, les sous-processus intégrés, l’activité d’appel, tous les types de passerelle, tous les types d’événement, le couloir, les participants, l’objet de données avec entrées et sorties, le message, le groupe, l’annotation textuelle, le flux de séquence y compris conditionnel et par défaut, le flux de message, les conversations limitées au regroupement de flux de message et à l’association des corrélations, la corrélation et l’association y compris de compensation, puis les marqueurs de boucle, d’instances multiples, de transaction et de compensation pour les tâches et les sous-processus intégrés; la note dispensant les implémentations des éléments de chorégraphie tels que la tâche de chorégraphie et la sous-chorégraphie; enfin les trois critères à satisfaire pour revendiquer une sous-classe. ↩︎ ↩︎
Bruce Silver, BPMN Method and Style, 2e édition: sans l’ajout des sous-classes de conformité de modélisation de processus en phase de finalisation, il est douteux qu’un logiciel eût jamais pu revendiquer la conformité, certains paquets exigés contenant des éléments réservés aux modèles exécutables et tous contenant des éléments obscurs et rarement employés. ↩︎
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 »: participant (pool), laneSet, sequenceFlow (unconditional), messageFlow, exclusiveGateway et parallelGateway avec id et name, task (None), userTask, serviceTask, subProcess (expanded) et subProcess (collapsed), CallActivity, DataObject, TextAnnotation, association/dataAssociation, dataStoreReference, startEvent (None), endEvent (None), messageStartEvent, messageEndEvent, timerStartEvent, terminateEndEvent, documentation et Group. La note c du tableau précise que la documentation n’est pas un élément visible mais un attribut de la plupart des éléments. ↩︎ ↩︎
Bruce Silver, BPMN Method and Style, 2e édition: la palette de niveau 1 restreinte de la première journée de formation et la palette de niveau 2 de la deuxième journée consacrée au traitement des exceptions, la palette de niveau 1 reprise pour l’essentiel de l’organigramme traditionnel et suffisante pour décrire la plupart des comportements de processus de façon compacte, l’observation qu’elle peut suffire à qui accepte d’ignorer les comportements déclenchés par un délai ou par l’arrivée d’un message, le besoin de niveau 2 chez l’analyste métier qui définit des exigences de solution puisque le comportement déclenché par un événement est un fait des processus réels, la moitié environ du jeu complet couverte par le niveau 2 avec des outils qui n’en prennent pas tous la totalité en charge, le niveau 3 nommé BPMN exécutable et portant sur les détails XML absents du diagramme, dont les modèles de données, les expressions conditionnelles sur les données aux passerelles et la logique détaillée d’affectation des tâches, enfin les niveaux 1 et 2 concernant les processus non exécutables et reposant uniquement sur l’information visible. ↩︎ ↩︎ ↩︎ ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §2.2.2 « BPMN Process Elements », tableau 2.2 « Analytic Conformance Sub-Class Elements and Attributes », qui s’ajoute intégralement à la descriptive: le flux de séquence conditionnel avec conditionExpression et le flux par défaut avec default, sendTask et receiveTask, les caractéristiques de boucle et d’instances multiples, l’attribut default ajouté à la passerelle exclusive, les passerelles inclusive et événementielle, les événements intermédiaires de lien en capture et en émission, les événements de début et de fin de signal, les événements de message en capture, en émission, de bord interruptif et de bord non interruptif, la minuterie intermédiaire en capture et de bord dans ses deux variantes, l’erreur de bord et l’événement de fin d’erreur, l’escalade de bord non interruptive avec l’escalade intermédiaire en émission et l’événement de fin d’escalade, le signal dans ses formes intermédiaires et de bord, la condition en début, en intermédiaire de capture et de bord dans ses deux variantes, enfin l’attribut messageRef ajouté au flux de message. Les notes du tableau précisent que conditionExpression n’est autorisée que sur un flux de séquence issu d’une passerelle et peut être nulle, que default est un attribut d’une passerelle exclusive ou inclusive source, et que messageRef reste optionnel et hors sous-classe sur les événements de message. ↩︎ ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §2.2.2 « BPMN Process Elements », sous-section « Common Executable Conformance Sub-Class »: la destination aux outils capables d’émettre des modèles exécutables, l’obligation faite à XML Schema comme langage de définition des types de données, à WSDL comme langage de définition des interfaces de service et à XPath comme langage de désignation des éléments de données; le tableau 2.3 avec ses éléments et leurs attributs, dont la tâche utilisateur munie de renderings, implementation, resources, ioSpecification, dataInputAssociations, dataOutputAssociations, loopCharacteristics et boundaryEventRefs; le tableau 2.4 et ses seize classes de soutien, StandardLoopCharacteristics, MultiInstanceLoopCharacteristics, Rendering, Resource, ResourceRole, InputOutputSpecification, DataInput, DataOutput, ItemDefinition, Operation, Message, Error, Assignment, MessageEventDefinition, TerminateEventDefinition et TimerEventDefinition. ↩︎ ↩︎
Bruce Silver, BPMN Method and Style, 2e édition: la sous-classe d’exécution commune proche de la descriptive par ses formes et augmentée d’éléments enfants et d’attributs portant le détail d’exécution, l’absence du pool, du couloir, du flux de message et du magasin de données, concordante avec le petit nombre de suites BPM prenant en charge les diagrammes de collaboration, l’erreur comme seul événement de bord admis, vraisemblablement sur une tâche puisque l’événement de fin d’erreur ne figure pas dans la sous-classe, l’omission probablement involontaire de timeDuration sous TimerEventDefinition, enfin la gestion des exceptions réduite au strict minimum. ↩︎ ↩︎
Marlon Dumas et coll., Fundamentals of Business Process Management, 2e édition, §10.3 « Complete the Process Model »: les deux principes selon lesquels les exceptions sont la règle et l’absence de données implique l’absence de décision et de transmission entre tâches, avec l’obligation de modéliser tout objet de données dont le moteur a besoin pour passer le contrôle d’une tâche à l’autre et pour décider. ↩︎ ↩︎
Bruce Silver, BPMN Method and Style, 2e édition: l’essentiel de l’effort de rédaction de BPMN 2.0 consacré aux éléments liés aux processus exécutables, la liste des détails supplémentaires exigés par un processus exécutable (variables, données d’entrée et de sortie des tâches et leurs correspondances, formulaires et enchaînements d’écrans, logique d’affectation des exécutants, expressions conditionnelles, définitions d’événement, messages), leur invisibilité au diagramme, enfin le constat que BPMN 2.0 n’est pas un langage d’exécution comparable à BPEL et servira avant tout de format d’échange, chaque outil conservant son modèle objet interne. ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §2.2.3 « Visual Appearance »: l’obligation d’employer les éléments graphiques, formes et marqueurs illustrés par le standard, la note admettant une latitude sur la taille, la couleur, le style de trait et la position des textes sauf spécification contraire, les quatre extensions permises (marqueurs ou indicateurs nouveaux, forme d’artefact nouvelle sans conflit, coloration porteuse de sémantique, changement de style de trait sans conflit) et l’interdiction faite à une extension de changer la forme spécifiée d’un élément ou d’un marqueur. ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §2.2.4 « Structural Conformance »: la conformité aux spécifications et restrictions portant sur les connexions et les relations entre éléments graphiques, la correspondance à assurer entre connexions et valeurs d’attributs lorsque la connexion est conditionnelle, avec la note sur la puce en losange qui signale les spécifications structurelles dans le corps du document. ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §2.2.5 « Process Semantics »: l’interprétation d’un diagramme comme spécification sémantique de processus doit être conforme à celle du standard, et la note dispensant les implémentations qui revendiquent la conformité de modélisation de processus de la sémantique d’exécution. ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §2.2.6 « Attributes and Model Associations »: le mécanisme de création et d’affichage à fournir pour tout attribut obligatoire, élément par élément, l’emploi obligatoire de la représentation graphique spécifiée là où elle est exigée, et la liberté laissée là où elle est optionnelle ou absente, sous réserve d’absence de conflit. ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §2.2.7 « Extended and Optional Elements »: l’absence d’obligation portant sur les éléments non normatifs ou informatifs, les trois formes d’option (la façon d’afficher, le fait d’afficher, le fait de prendre en charge), et l’obligation de prendre en charge une fonctionnalité optionnelle dont l’option ne porte que sur l’affichage. ↩︎
OMG, Business Process Model and Notation (BPMN), version 2.0.2, §2.2.8 « Visual Interchange »: le format d’échange comme but principal du standard, portant le modèle du domaine et la mise en page du diagramme, avec la recommandation de prendre en charge le métamodèle des types de processus pour la portabilité des diagrammes d’un environnement éditeur à l’autre. ↩︎
Bruce Silver, BPMN Method and Style, 2e édition: les membres de chaque sous-classe définis en termes d’éléments et d’attributs XML représentant la seule information visible au diagramme, tous les détails d’exécution restant hors des sous-classes descriptive et analytique, et la formule qui en découle, si ce n’est pas dans le diagramme cela ne compte pas. ↩︎
Bruce Silver, BPMN Method and Style, 2e édition, préface: le niveau 1 impliquait dans la première édition, outre un jeu restreint de formes, une attitude plus détendue envers les règles de BPMN, proche de l’organigramme traditionnel; il ne l’enseigne plus ainsi, en raison de la validation automatique des règles de style, qui met la correction à portée d’un débutant, et parce que masquer les fondements conceptuels de BPMN aux modélisateurs de niveau 1 rend plus difficile la constitution d’un langage commun au métier et à l’informatique. ↩︎
Marlon Dumas, Marcello La Rosa, Jan Mendling et Hajo A. Reijers, Fundamentals of Business Process Management, 2e édition, Springer, 2018, §5.3.5 « Step 5: Identify Additional Elements »: l’ajout des objets métier et des gestionnaires d’exception selon l’usage prévu du modèle, la capture explicite des données et des exceptions lorsque le processus est destiné à être automatisé, le degré de détail déterminé par l’usage prévu, l’objectif de la découverte de processus limité à une compréhension suffisante pour l’analyse qui suit, enfin le piège des modèles très détaillés créés pendant la découverte, avec son effet sur le coût du projet et le report de l’amélioration. ↩︎
Marlon Dumas et coll., Fundamentals of Business Process Management, 2e édition, chapitre 10 « Process Implementation with Executable Models »: les modèles conceptuels intentionnellement abstraits, à retravailler systématiquement en modèles exécutables, et la méthode en cinq étapes, identifier les frontières de l’automatisation, revoir les tâches manuelles, compléter le modèle, l’amener à une granularité adéquate, spécifier les propriétés d’exécution, l’ensemble supposant un modèle syntaxiquement correct. ↩︎
Marlon Dumas et coll., Fundamentals of Business Process Management, 2e édition, §10.1 « Identify the Automation Boundaries »: le principe selon lequel tous les processus ne sont pas automatisables et la distinction des tâches automatisées, manuelles et utilisateur, les premières exécutées par le moteur ou par un service externe, les deuxièmes sans aucune assistance logicielle, les troisièmes avec l’assistance du gestionnaire de liste de tâches. ↩︎
Marlon Dumas et coll., Fundamentals of Business Process Management, 2e édition, §10.2 « Review Manual Tasks »: les éléments pertinents au niveau conceptuel et non interprétables par une suite BPM, à savoir les objets et magasins de données physiques, les messages transportant des objets physiques, les annotations textuelles, l’état d’un objet de données porté par son étiquette, ainsi que les pools et les couloirs, qui portent souvent une affectation de ressources à gros grain; et le conseil de les laisser en place lorsque l’outil les tolère, parce qu’ils guident la spécification des propriétés d’exécution. ↩︎
eCH-0074 version 2.2, Principes de modélisation graphique des processus métier, §2.2.6 « Principe d’adéquation et de proportionnalité »: le but de la modélisation à consigner explicitement, avec les exemples du relevé de l’existant, de la modélisation de l’état visé, de l’optimisation et de l’automatisation, le degré de détail à adapter à ce but, et la remarque présentant les trois niveaux de modélisation comme des niveaux d’abstraction que BPMN 2.0 distingue et affecte à des buts différents, le descriptif visant la représentation métier correcte et servant de référence contraignante pour l’entente entre acteurs, l’analytique employant une syntaxe et une palette de symboles étendues pour des exigences de conception plus complexes telles que les événements et le traitement des erreurs, l’exécutable mettant en outre à disposition des éléments de description spéciaux pour décrire et fixer exactement le comportement des systèmes de processus automatisés. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0074/2.2 ↩︎
eCH-0158 version 1.2, Conventions de modélisation BPMN pour l’administration publique, §1.7 « Niveaux de modélisation »: les trois niveaux repris de eCH-0074, la limitation explicite des conventions au niveau descriptif, la description de ce niveau comme vue métier du processus avec déroulement normal, événements de début et de fin, divisions, variantes de processus, responsabilités et communication avec les partenaires extérieurs, la possibilité de représenter des sous-processus sur plusieurs niveaux, la perspective métier et le jeu de symboles restreint comme différence avec les niveaux analytique et exécutable, avec renvoi à Silver, l’exemple du renoncement à l’événement intermédiaire de message en émission au motif qu’un envoi n’est pas automatique du point de vue métier et suppose une activité, enfin le renvoi au chapitre 3 pour les éléments BPMN du niveau descriptif. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎
eCH-0158 version 1.2, annexe Palette de symboles étendue pour la modélisation analytique, résumé et §1.4 « Niveau de modélisation »: l’extension de la palette de symboles de eCH-0158, standard de modélisation descriptive, aux fins de la modélisation créatrice et analytique des processus métier, le lectorat visé (gestionnaires de processus, business analystes, architectes d’entreprise), et la déclaration explicite du niveau analytique avec renvoi au chapitre 2.2.6 de eCH-0074. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎
eCH-0158 version 1.2, Conventions de modélisation BPMN pour l’administration publique, §1.2 « Positionnement »: l’unification de l’application du standard ISO Business Process Model And Notation (ISO 19510:2013) pour la représentation graphique des processus métier de l’administration publique suisse, standard qui admet un grand nombre d’options de modélisation et de degrés de liberté. Le texte de référence est allemand; la traduction française est la nôtre. https://www.ech.ch/fr/ech/ech-0158/1.2 ↩︎