Les applications pratiques des AFD révèlent une avancée significative dans la modélisation des processus métiers, transformant la manière dont les entreprises gèrent les données massives. Cette approche innovante promet de surmonter les défis de l’intégration des données hétérogènes, avec des implications cruciales pour l’efficacité opérationnelle.
- Modélisation des processus métier
La première phase de modélisation des PMs consiste à les représenter de manière plus ou moins abstraite. Elle exige des modèles et des formalismes qui garantissent un niveau de prise en compte des spécifications et règles métiers de manière consistante. La littérature de recherche est très riche en modèles permettant de prendre en charge les différentes contraintes associées à la spécification des PMs. Certains sont formels, tels que les réseaux de pétri, les Automates d’états Finis Déterministes (AFD) et les graphes. D’autres modèles sont plutôt graphiques, comme les diagrammes de séquence et les diagrammes d’activités d’UML. Par ailleurs, même certaines catégories de langage offrent à leur tour des mécanismes pour modéliser les PMs.
Dans cette section, nous nous concentrons sur la présentation et l’analyse des différents modèles de représentation des PMs.
- Les modèles formels
Automates Finis Déterministe (AFD)
Les automates sont des objets mathématiques très utilisés en informatique pour modéliser un grand nombre de systèmes informatiques. D’une façon très simpliste, on considère un automate comme un ensemble d’états reliés entre eux par des transitions qui sont marquées par des symboles. Étant donné un mot fourni en entrée, l’automate lit les symboles du mot un par un et passe d’un état vers un autre conformément aux transitions spécifiées. Le mot lu est soit accepté par l’automate soit rejeté [10].
Les automates ont été intensivement utilisés dans l’algèbre des processus et dans le domaine des processus métiers. Formellement, un AFD est défini comme suit.
Définition 1.6 Automates finis déterministes [11]
Un automate fini déterministe est un tuple P = (Q, q0, F, M, R), tels que :
- Q est un ensemble fini d’états ;
- q0 ∈ Q est l’état initial du processus ;
- F ⊆ Q est l’ensemble des états finaux du processus (ou acceptant) ;
- M est un ensemble fini d’activités abstraites ;
- R ⊆ Q × Q × M est une relation de transition. Chaque élément (q, q′, m) ∈ R représente une transition d’un état source q vers un autre état cible q′, suite à l’exécution de l’activité m.
Exemple 1.2 La figure 1.3, ci-dessous illustre un processus métier modélisé par un AFD. Ce processus métier est relatif à la gestion des commandes client de la figure 1.1.
Comme il apparaît dans la figure, ce processus est composé d’un ensemble d’états (par exemple : utilisateur identifiée, Produit choisi, . . .) qui commence par un état initial (début), suite à la commande d’un produit et qui se termine par des états finaux (Commande annulée) dans le cas où la commande est annulée et (Fin) si la commande est livrée.
[4_applications-pratiques-des-automates-finis-deterministes_3]
Figure 1.3 – Exemple d’un PM modélisé par un AFD
Les Réseaux de Pétri (RDP)
Vu leur rôle important en tant qu’outils graphiques de représentation des phénomènes et mécanismes séquentiels, les réseaux de Pétri ont été largement exploités pour décrire les processus métiers [12].
Dans ce qui suit, on s’intéresse à ce mécanisme de modélisation.
Les éléments graphiques de bases utiles à la représentation des PMs par des réseaux de Pétri sont assemblés dans la figure 1.4 suivante.
[4_applications-pratiques-des-automates-finis-deterministes_4]
Figure 1.4 – Éléments de base pour modéliser un PM par un RDP
Le PM se présente sous la forme d’un graphe biparti dans laquelle les places sont représentées par des cercles ou des ronds, les transitions sont représentées par des nœuds et les arcs permettent de relier les transitions à des places.
D’une façon plus formelle on définit un réseau de pétri comme suit :
Définition 1.7 Un réseau est un triplet N =< P, T ; F > où :
- P est un ensemble fini de places ;
- T est un ensemble fini de transitions ;
- F est la relation de flux sur N, telle que : F ⊆ (P × T ) ∪ (T × P) (ensemble des arcs)
Exemple 1.3 La figure 1.5 illustre le même PM de commande client de la figure 1.1) qui est modélisé par un RDP. Ce réseau exprime les mêmes étapes, partant initialement de l’identification jusqu’à la livraison de la commande ou son annulation.
[4_applications-pratiques-des-automates-finis-deterministes_5]
Figure 1.5 – Représentation d’un processus de commandes client par un RDP
Les graphes
Les graphes sont des outils qui permettent de modéliser et de résoudre de nombreux problèmes et peuvent être utilisés aussi pour la représentation des PMs [13].
Ci-après, on va aborder les concepts de graphes et leur utilisation dans le contexte des PMS.
Définition 1.8 Graphe orienté
Un graphe orienté G = (X, U ) est défini par la donnée de deux ensembles :
- un ensemble X dont les éléments sont appelés ”sommets” ou ”nœuds”;
- un ensemble U dont les éléments sont des couples de sommets appelés ”arcs”;
Une autre définition plus détaillée est donnée par [14]
Définition 1.9 Le graphe G = (V,E) est défini par l’ensemble V = v1, v2, …, vn dont les
éléments sont appelés sommets et par l’ensemble des éléments E = e1, e2, . . . , em appelés arêtes. Une arête ei d’un ensemble E est définie par une paire de sommets, appelés extrémités. Si l’arête ei relie les sommets a et b, on dit que ces sommets sont adjacents, ou liés à ei, ou bien que l’arête ei relie les sommets a et b. On appelle ordre d’un graphe le nombre de sommets n de ce graphe.
Nous exposons ci-dessous quelques concepts associés au modèle de graphes.
- Une arête a est une paire de sommets (x, y) (un élément qui relie deux sommets ensemble).
- Les sommets x et y sont les extrémités de l’arête.
- Le nombre d’arêtes incidentes à un sommet est le nombre d’arêtes quittant ou entrant dans le sommet.
- Deux sommets d’un graphe sont adjacents s’ils ont au moins une arête incidente en commun.
- Deux arêtes d’un graphe sont adjacentes si elles ont au moins un sommet en commun.
- Le degré d’un sommet x de G est le nombre d’arêtes incidentes sur x. Il est noté
d(x).
- Un graphe est simple s’il ne contient pas d’anneaux ni d’arêtes multiples.
- Un graphe est connexe si tous les autres sommets sont accessibles depuis n’importe quel sommet.
- Un graphe complet est un graphe dans lequel chaque sommet est connecté à tous les autres sommets.
[4_applications-pratiques-des-automates-finis-deterministes_6]Exemple 1.4 La figure 1.6 illustre le même PM de commande client de la figure 1.1) qui est modélisé par un graphe. Ce graphe exprime les mêmes fonctionnalités du PM, mais exprimées par le formalisme des graphes.
Figure 1.6 – Représentation d’un processus de commandes client par un Graphe
- Les modèles Graphiques
Parmi les modèles graphiques les plus utilisés pour exprimer l’aspect dynamique des systèmes d’information, on distingue les diagrammes de séquences et les diagrammes d’activités de la méthode UML. Ces diagrammes intégrés sont utilisés par les développeurs informatiques pour la représentation visuelle des objets, des états et des processus dans un logiciel ou un système. La suite de cette section est dédiée à la présentation de ces deux diagrammes.
Diagramme de séquences
Il est considéré comme l’un des diagrammes UML les plus importants car il aide à comprendre le fonctionnement du logiciel et par conséquent le processus métier pris en charge. D’une part, il montre les interactions entre les objets dans l’ordre chronologique et d’autre part il spécifie les interactions entre objets à l’intérieur du système. Les diagrammes de séquences sont utilisés pour illustrer les cas d’utilisation au début du cycle de développement et constituent également un excellent moyen de communiquer les aspects dynamiques du système [15].
La figure 1.1 de l’exemple 1.1, représente un exemple d’un diagramme de séquences permettant de traiter les commandes client.
Diagramme d’activités
Le diagramme d’activités est principalement utilisé pour modéliser des processus métiers ou pour décrire des opérations complexes, y compris des flux de données. Son avantage est qu’il présente une vue macro et temporelle du système modélisé sous une forme proche d’un organigramme. Ainsi, il permet de modéliser le processus d’interaction d’un système donné et d’exprimer la dimension temporelle sur une partie du modèle [15].
Dans le contexte des processus métiers, un diagramme d’activités permet de représenter l’ensemble des activités séquentielles d’un PM donné du moment du déclenchement du processus jusqu’à son point d’arrivée.
Exemple 1.5 La figure 1.7, reprend le même processus de commande client de l’exemple
1.1 et le représente par un diagramme d’activités.
[4_applications-pratiques-des-automates-finis-deterministes_7]
Figure 1.7 – Diagramme d’activités pour le processus commande client
- Les langages de représentation des PMs
Certains langages offrent des primitives et des commandes permettant de modéliser et de spécifier la façon dont les différentes activités des PMs sont structurées et ordonnées avant leur exécution. Autrement dit, ces langages expriment les scénarios d’exécution des suites ordonnées d’activités. Parmi ces langages on distingue essentiellement BPMN et BPEL.
BPMN
La notation de modélisation BPMN (Business Process Model Notation) [7] est une norme de plus en plus adoptée pour la modélisation des PMs et qui prend de l’essor au sein de la communauté des professionnels de la technologie BPM. Cet interressement est motivé par la richesse du langage qui offre une multitude d’éléments de représentation pour exprimer les scénarios d’entreprise [16].
D´efinition 1.10 [7]
BPMN est une norme de notation pour la modélisation de processus métier permet de définir une notation graphique commune à tous les outils de modélisation.
En termes simples, BPMN est une représentation graphique du PM à l’aide d’objets standards. Ces derniers ne sont que des ensembles d’objets graphiques et de règles définissant les connexions disponibles entre les éléments manipulés. Son objectif est de fournir un cadre permettant de décrire un processus d’une manière commune à tous les utilisateurs et ce, indépendamment de l’outil utilisé. L’outil étant bien sûr censé supporter la norme.
Exemple 1.6 Dans l’exemple de la figure 1.8, notre PM de commande client (exemple 1.1) est modélisé par la notation de BPMN.
[4_applications-pratiques-des-automates-finis-deterministes_8]
Figure 1.8 – BPMN pour commande client
BPMN se compose des blocs de construction de base permettant de représenter un PM, qui sont les éléments nécessaires pour rendre la lecture de diagrammes BPMN compréhensibles [17]. Les éléments manipulés sont les suivants.
- Objets de flux : événements (cercles), activités (rectangles aux coins arrondis) et passerelles (losanges) ;
- Objets de connexion : composés principalement de flèches qui indiquent le flux de séquences (flèches pleines), le flux de messages (flèches en pointillés) et les associations ;
- Artefacts : objets de données, groupes et annotations ;
BPEL
Le langage BPEL (Business Process Execution Language ) est devenu une norme pour la mise en œuvre des processus métiers d’entreprise. C’est une extension des langages de programmation impératifs avec des constructions spécifiques aux implémentations utiles aux services web.
Une spécification d’un processus BPEL est décrite dans la partie Abstract d’un programme BPEL et elle relie de nombreuses activités par des structures de contrôle. Les activités peuvent être des activités de base ou des activités structurées. Les activités de base correspondent à des opérations atomiques, telles que [18] :
- invoke : déclenche une opération sur un service Web ;
- receive : permet d’attendre un message d’un partenaire ;
- quit, terminer l’intégralité de l’instance de service ;
- cancel : ne rien faire ;
Pour permettre la présentation de structures complexes, les activités structurées suivantes sont définies :
- sequence : définit l’ordre d’exécution ;
- flow, pour le routage parallèle ;
- commutateur : if … then …else : pour le routage conditionnel des activités ;
- select : pour les conditions basées sur le temps ou les déclencheurs externes ;
- scope pour regrouper les activités en blocs auxquels des gestionnaires d’événements et d’exceptions peuvent être attachés ;
BPEL utilise le standard XML comme modèle de données. Ces processus sont mis en œuvre en échangeant des messages structurés de types synchrone et asynchrone. Ces messages associés aux activités forment une séquence logique qui forme un processus, qui à son tour peut être synchrone ou asynchrone. De plus, il implémente son flux sous une forme de couches similaires aux autres langages de programmation (Java, C++, . . .), en tenant compte des différentes exceptions de gestion possibles.
Les processus BPEL ont des cycles de vie bien définis qui peuvent être contrôlés en appliquant des contraintes spécifiques. La force du langage BPEL réside dans sa structure de processus, qui se déroule sur un seul fichier XML.
Nous observons que les modèles de représentation précédents se concentrent essentiellement sur les activités réalisées. Or, ces activités manipulent lors de leur exécution des données. De ce point de vue, il est impératif de prendre en compte cette dimension des données et qui est indissociable de la gestion des PM. C’est ce que nous allons exposer dans la prochaine section.
________________________
Questions Fréquemment Posées
Qu’est-ce qu’un automate fini déterministe (AFD) ?
Un automate fini déterministe est un tuple P = (Q, q0, F, M, R), où Q est un ensemble fini d’états, q0 est l’état initial, F est l’ensemble des états finaux, M est un ensemble d’activités abstraites, et R est une relation de transition.
Comment les réseaux de Pétri sont-ils utilisés dans la modélisation des processus métiers ?
Les réseaux de Pétri sont utilisés comme outils graphiques pour représenter les phénomènes et mécanismes séquentiels, décrivant ainsi les processus métiers de manière visuelle.
Quels sont les modèles formels utilisés pour la modélisation des processus métiers ?
Les modèles formels incluent les Automates d’états Finis Déterministes (AFD) et les Réseaux de Pétri, qui permettent de représenter les processus métiers en tenant compte des spécifications et règles métiers.