Comment une méthodologie innovante transforme l’intégration des PMs ?

La méthodologie d’intégration des PMs révèle des défis inattendus dans la coopération entre processus métiers. En utilisant des Automates Finis Déterministes, cette recherche propose une solution innovante pour harmoniser les interactions, essentielle pour les organisations cherchant à optimiser leur efficacité.

Deuxième partie Conception et Implémentation de

l’approche

CHAPITRE 4

CONCEPTION DE L’APPROCHE

Introduction

Dans le chapitre précédent nous avons exposé la problématique et nous l’avons positionnée par rapport aux travaux connexes. Dans ce chapitre, nous présentons notre contribution pour l’intégration et la coopération des PMs. Nous commençons par la présentation du fondements de la nouvelle approche pour l’intégration et la coopération, puis on discutera de l’architecture du système proposé. Après cela, la description du fonctionnement de la solution est abordée en détails.

Fondements de la nouvelle approche pour l’intégration et la coopération

Nous commençons par exposé les caractéristiques de l’approche proposé, puis nous présentons le modèle formel utilisé dans notre approche et nous terminerons la section par la spécification des notions et de concepts théoriques utilisés pour la formalisation de notre approche d’intégration et de coopération des PMs.

Caractéristiques de l’approche

Notre approche pour l’intégration et la coopération des PMs se base fondamentalement sur les aspects suivants :

• • • • L’analyse des spécifications contenues dans les schémas des PMs et la recherche d’éléments communs, nommés « Motifs » (patterns), qui par permettront d’assurer la jonction entre les différents PMs.
      • Identifier et cibler les éléments redondants qui serviront de connecter les processus à intégrer, du fait qu’ils apparaissent en tant que modèles partiels exprimant des règles de gestion communes entre deux au plusieurs processus.
      • Une fois ces éléments cernés et modélisés, ils serviront de briques de base pour aborder l’intégration et la coopération en se basant sur les modèles descriptifs des PMs.

Par la suite, les performances et la compétitivité de l’organisation seront améliorées.

Avant d’aborder notre analyse, nous commençons par la présentation du modèle formel adopté pour représenter les PMs.

Le modèle formel adopté pour la modélisation des PMs

L’approche utilisée pour traiter la question de l’intégration et la coopération des PMs passera inévitablement par le choix du modèle qui sera utilisé pour représenter les PMs. Comme nous avons déjà vu dans le premier chapitre, qu’il existe plusieurs modèles de représentation, tels que : AFD, BPMN, UML , Réseaux de petri, se pose alors la question du choix du modèle à utiliser.

Pour notre approche, nous utilisons les automates d’états finis déterministe (AFD) pour la représentation et la modélisation des PMs.

Les AFD sont très adéquats pour répondre à notre problématique, car ils permettent de décrire les flux d’activités, les échanges de messages et les exécutions des tâches. Par ailleurs, dans [54] le choix des AFD est motivé par les raisons suivantes :

• Ils sont simples et très populaires ;
• Ils sont des modèles graphique;
• Ils sont appropriés pour décrire le comportement réactif et les systèmes dynamiques;
• Existence des outils de vérification formels;
• Afin de permettre de rechercher les sous protocoles, les activités communes les parties à analyser.

En se basant sur la définition formelle d’un AFD, un processus métier peut être représenté par un AFD. Plus formellement par le tuple : P = (Q, q₀, F, M, R), tels que :

• Q est un ensemble fini d’états;
• q₀ ∈ 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 entre les états de l’automate.

A titre d’illustration, on donne ci-dessous un exemple concret d’un AFD qui représente le PM de réservation d’une chambre d’hôtel par un client.

Exemple 4.1 La figure 4.1 ci dessous montre un exemple d’un AFD qui schématise le PM de réservation d’une chambre d’hôtel par un client.

Dans le schéma de la figure 4.1, les états de l’automate (par exemple : hôtel sélectionné, chambre choisie) expriment les phases par les quelles transite le PM durant son exécution, et les messages (par exemples : choisir ville, choisir l’hôtel) correspondant aux actions(activités) exécutées par

[13_methodologie-integration-des-pms-approche-innovante_19]

Source: URL

FIGURE 4.1 – Processus de réservation modélisé par un AFD.

passer d’un état à un autre.

Le fonctionnement du processus est décrit ci-après.

La réservation de la chambre est déclenchée lorsque le client invoque le processus. Cette instance débute son exécution par l’état initial (début). La première opération est « Choisir Ville » (CV) qui permet de passer de l’état « Début » à l’état« Ville sélectionnée ». Puis, cette instance passe à l’état « Hôtel sélectionnée » lorsque le client invoque l’opération« Choisir hôtel » (CH). Ainsi, et suivant cette logique de fonctionnement, l’invocation de chaque opération permet de passer d’un état de l’automate à un autre jusqu’à atteindre un des états finaux : Chambre réservée ou Réservation annulée.

Notions associées au modèle de PM

Nous introduisons dans ce qui suit, certains concepts liés au modèle de PM choisi (les AFD) et utiles dans notre contexte, tout en spécifiant leur définition formelle.

1. L’alphabet : Σ = {a, b, c, d, . . .} c’est l’ensemble des symboles correspond aux activités du processus métier, associé au différentes transitions de L’AFD.

La châine vide ϵ ∈ Σ désigne la transition nulle [54].

Par exemple, dans le PM de la figure 4.1, les activités sont exprimées par l’ensemble de symboles :

Σ ={CV,CH, STC, AN, INP, C, P,ID }. Nous commençons par rappeler la définition du langage d’un automate.

1. Langage d’un automate : On considère les machines d’états finis déterministes comme des automates, et on définit le langage associé, noté L(P), comme étant l’ensemble des mots acceptés (reconnus) par l’automate P. Une chaîne (mot) est accepté par l’automate s’il existe un chemin dans l’automate en question, qui commence par l’état initial, qui se termine à l’un des états finaux et qui reconnu ce mot symbole par symbole [55].

Nous introduisons, à présent, le concept d’exécution d’un protocole

1. Exécution et chemin d’exécution d’un PM : étant donné un protocole P = (Q; q₀; F; M; R), une exécution de P, notée e, est une séquence alternée d’états et d’activités de P,

telle que : e = q₀ : m₀ : q₁…q_n.m_n.q_n + 1, qui vérifie les trois conditions suivantes :

(i) débute par l’état initial q0 de P, (ii) se termine par un état qn + 1 de P, et (iii) respecte la relation de transition de P, i.e., (q_i; q_i + 1; mi) ∈ R, ∀i ∈ [0; n]

On dit que le chemin c est complet s’il se termine par un état final(q_n ∈ F). Alors qu’un chemin d’exécution est incomplet s’il ne se termine pas par un état final(i.e., q_n ∈/ tion.[54]

1. Dans ce dernier cas la trace est donc dite en cours d’exécution.

Exemple 4.2 Les chemins d’exécution associés aux instances de l’exemple 4.1 sont les suivantes :

• • C1 = Début.CV.Ville sélectionnée.CH.hôtel sélectionnée.INP.Données en cours.STC.Chambre choisie.AN.Réservation annulée.
  • C2=Début.CV.Ville sélectionnée.CH.hôtel sélectionnée.
  • C3= Début.CV.Ville sélectionnée.CH.hôtel sélectionné .INP.Données en cours.STC.chambre choisie.ID.formulaire renseigné.C.réservation confirmée.P.chambre réservée

1. Trace d’exécution d’une instance de PM : Soit P = (Q, q₀, F, M, R) le protocole d’un PM I une instance de P, et soit e = q₀.m₀.q1…q_n.m_n.q_n+1 l’exécution de I dans P.

Définition 4.1 La trace d’exécution ou historique d’exécution δ d’une instance I du protocole P est exprimée par son chemin d’exécution c = m₀.m₁…mn, extrait de l’exécution

e. Elle représente la séquence finie des activités historiques qui ont été exécutées par l’instance I, depuis le début de l’invocation du service jusqu’à l’état courant de I. Une trace d’exécution est dite complète si elle est issue d’un chemin d’exécution complet. [54]

Les noms des états correspondants du chemin d’exécution sont spécifiquement supprimés pour retrouver les traces d’exécution.

Exemple 4.3 On garde toujours le même sous-ensemble des chemins d’exécution de l’exemple 4.1, et on opère l’extraction des traces des instances, en tenant compte uniquement des noms des activités.

• δ (1) = CV.CH.INP.STC.AN
• δ (2) = CV.CH
• δ (3) = CV.CH.INP.STC.ID.C.P

1. Expression régulière : Les expressions régulières sont des formats utilisés pour décrire des chaînes de caractères selon une syntaxe précise et rigoureuse. Dans ce qui suit, on présente cette notion formellement.

Définition 4.2 Soit A = {a₁, a₂, …, a_n} un alphabet de symboles représentant les activités du PM, auquel on ajoute les caractères spéciaux suivants

• • ”.” : est l’opérateur de concaténation.
  • ∗ : est l’opérateur star-Kleene qui exprime la répétition d’un ou plusieurs caractères.[55] :
  • ”(”et”)” (parenthèse ouvrante et fermante) : pour l’application agrégé d’un opérateur.

Exemple 4.4 A titre d’illustration, on peut exprimer plusieurs expressions régulières de l’exemple 4.1

• • Reg₁ CV.CH.INP.STC.AN
  • Reg₂ CV.CH.(INP*).STC.AN
  • Reg₃ CV.CH.(INP*).STC.ID.C.P

Spécification d’un sous-protocole

Vue l’importance de la notion de sous-protocole dans le contexte de l’intégration et de la coopération, il exige une spécification formelle.

Un sous protocole au « sous processus » est un parti distincte et spécifique d’un processus métier global, Elle est particulièrement utile lorsqu’il s’agit de modifier une partie de la logique métiers, d’intégrer la fonctionnalité d’un partenaire ou de substituer une règle de fonctionnement à une autre. L’idée d’un sous protocole, que nous décrivons ci-dessous, est cruciale dans ce contexte.

Définition 4.3 Soit P = (Q, q₀, F, M, R) un protocole de service, et soit q ∈ Q un état de

P. Le sous-protocole CSP(P; q) de P est le protocole : CSP(P; q) = (Q′ ; q′ s; F′ ; M′ , R′ ),

obtenu à partir de P comme suit, citée dans[56] :

— q est l’état initial de CSP(P; q) ;

s 0 S S S

• Q′ ⊆ Q contient l’ensemble des états de Q accessibles à partir de q en utilisant la

s

relation R de P;

• F′ = Q′ ∩ F ;

s s

• R′ = (q; q′; m) ∈ Rc..dq; q′ ⊆ Q′ ;

s s

• M′ ⊂ M est constitué des messages M qui apparaissent dans les transitions de R′ .

s s

Selon cette spécification, le sous protocole CSP(P; q) permet de capturer toutes les exécutions possibles de P à partir de l’état q. C’est à dire qu’il cerne tous les chemins d’exécutions futurs de P qui commence par l’état q et qui se terminent à l’un des états finaux de P.

Exemple 4.5 En utilisant toujours le même AFD de la figure 4.1, et à partir de cet exemple on fait l’extraction du sous protocole illustré ci-dessous. Ce sous protocole décrit une séquence d’activités incluses dans la logique métier du protocole principal.

En se basant sur le modèle de protocole de PM choisi, dans la section suivante, nous allons aborder les différentes aspects relatifs à l’intégration des PMs.

Questions Fréquemment Posées

Quelle est la méthodologie d’intégration des PMs proposée dans l’article?

L’approche proposée se base sur l’analyse des spécifications contenues dans les schémas des PMs et la recherche d’éléments communs, nommés ‘Motifs’ (patterns), pour assurer la jonction entre les différents PMs.

Quels modèles formels sont utilisés pour représenter les processus métiers?

Pour notre approche, nous utilisons les automates d’états finis déterministes (AFD) pour la représentation et la modélisation des PMs.

Comment l’approche d’intégration des PMs améliore-t-elle les performances organisationnelles?

Une fois les éléments cernés et modélisés, ils serviront de briques de base pour aborder l’intégration et la coopération, ce qui améliorera les performances et la compétitivité de l’organisation.