|
|
REPUBLIC OF CAMEROON
REPUBLIQUE DU CAMEROUN PEACE - WORK - FATHERLAND
PAIX - TRAVAIL - PATRIE *********
********* UNIVERSITY OF
DSCHANG
UNIVERSITE DE DSCHANG *********
********* POST GRADUATE SCHOOL
ÉCOLE DOCTORALE
DSCHANG SCHOOL OF SCIENCES AND TECHNOLOGY
|
|
UNITE DE RECHERCHE EN INFORMATIQUE FONDAMENTALE, INGENIERIE ET
APPLICATIONS (URIFIA)
SUJET :
|
|
|
|
|
Mémoire soutenu publiquement en vue de l'obtention
diplôme de Master en Informatique
Option : Spécialité
:
Par
Matricule : CM-UDS-16SCI2468
Licence en Informatique Fondamentale
Sous la direction de :
Chargé de cours
|
du
Année académique 2020/2021
|
DÉDICACE
i
À mes parents TONLE IGNAS et NOUMBO
SÉRAPHINE.
ii
REMERCIEMENTS
Je voudrais adresser toute ma gratitude à
l'Éternel Dieu qui a permis que j'accomplisse ce travail, et à
toutes les personnes qui m'ont cru capable de pouvoir le faire. C'est
grâce à votre soutien que j'ai trouvé la force et le
courage pour réaliser ce mémoire. Mes sincères
remerciements :
-- Au Dr TCHOUPÉ TCHENDJI Maurice, mon encadreur, pour
la confiance qu'il m'a témoignée en acceptant la direction
scientifique de mes travaux. Je lui suis extrêmement reconnaissant de
m'avoir fait bénéficier tout au long de ce travail de ses
innombrables qualités de chercheurs. Votre esprit d'observation, votre
abnégation au travail ainsi que votre quiétude resteront de
grandes sources d'inspiration pour moi. Soyez assuré de mon attachement
et de ma profonde gratitude.
-- À tous les membres du jury, pour l'immense honneur
que vous m'accordez en acceptant d'examiner ce travail.
-- À tous les enseignants du département de
Mathématiques-Informatique de la faculté des sciences de
l'université de Dschang, pour tous vos enseignements et conseils
judicieux, en particulier au chef de département Pr NKENLIFACK Marcellin
Julius.
-- Au Pr TAYOU DJAMEGNI Clémentin, pour m'avoir
montré quelle peut être l'immense grandeur de la recherche
scientifique.
-- À mon mentor Dr ZEKENG NDADJI Milliam Maxime, en qui
j'ai retrouvé les traits d'un véritable modèle, de par son
immense bienveillance et son irrépressible envie de venir en aide
à ses cadets académiques. Vous êtes, sans conteste, mon
modèle.
-- À mes parents et ma famille pour le soutien
inconditionnel.
-- À mes amis et mes camarades qui m'ont poussé
à me surpasser afin de devenir une meilleure version de
moi-même.
-- À toute l'équipe Africa Systems,
particulièrement à mon oncle tonton ZEBAZE Pierre Roger, pour
toute la confiance qu'il m'accorde et le
REMERCIEMENTS iii
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
leadership qu'il m'inculque; et à monsieur WAMBA Chancel
pour sa bienveillance.
-- À l'équipe SmartCoders, particulièrement
à mon ainé M. MVAH Fabrice pour son coaching.
-- À toutes les personnes qui ont participé de
près ou de loin à mes travaux de recherche et à
l'élaboration de ce mémoire. Je vous serai éternellement
reconnaissant.
iv
TABLE DES MATIÈRES
Dédicace i
Remerciements ii
Table des matières iv
Liste des acronymes vii
Liste des tableaux viii
Table des figures ix
Résumé xi
Abstract xii
Introduction 1
Contexte du travail 1
Problématique étudiée 2
Organisation du manuscrit 3
Chapitre I ? Le Business Process Management
5
I.1 - Introduction 5
I.2 - Les principes clés du Business Process Management
6
I.2.1 - Définitions et exemples 6
I.2.1.1 - Définitions des concepts clés 6
I.2.1.2 - Exemple introductif d'un processus opérationnel
. . 7
I.2.2 - Les concepts de base du BPM 10
I.2.2.1 - Les classes de workflows 10
I.2.2.2 - Cycle de vie du BPM 11
I.3 - Généralités sur la modélisation
des processus opérationnels 12
I.3.1 - Concepts de base 12
I.3.1.1 - L'activité de modélisation 12
I.3.1.2 - Procédure de modélisation d'un processus
opérationnel 14
I.3.2 - Les langages de modélisation de processus 16
I.3.2.1 - La notation BPMN 16
I.3.2.2 - Les réseaux de workflows (Workflow-Nets) 18
I.3.2.3-LelangageYAWL 21
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
TABLE DES MATIÈRES v
I.4 - Les workflows structurés 21
I.4.1 - Définition 22
I.4.2 - Les propriétés des workflows
structurés 23
I.5 - Conclusion 24
Chapitre II Spécification des processus
administratifs avec une
approche orientée scénario 26
II.1 - Introduction 26
II.2 - Le langage de spécification LSAWfP 27
II.2.1 - Modélisation des scenarios à l'aide des
artefacts représentatifs 27
II.2.2 - Déduction du modèle grammatical de
workflow 29
II.2.3 - Acteurs et accréditations 30
II.3 - Méthodologie de spécification et
nécessité d'un outil de spécification 32
II.3.1 -
Méthodologie de spécification des processus LSAWfP . . . . 32
II.3.2 - Nécessité d'un outil de
spécification pour LSAWfP 32
II.4 - Revue des outils existants de spécification des
workflows 34
II.4.1 - Bizagi Modeler 34
II.4.2 - YAWL Process Editor 35
II.4.3 -
BPMN.io 36
II.5 - Conclusion 37
Chapitre III Facilitation de la spécification des
processus administratifs
avec une approche orientée scénario
38
III.1 - Introduction 38
III.2 - Présentation de LSAWfP Editor 39
III.2.1 - Architecture logicielle de LSAWfP Editor 40
III.2.2 - Modélisation graphique des processus 41
III.2.3 - Sauvegarde, visualisation et partage des
spécifications . . . 43
III.2.4 - Interopérabilité avec les autres outils
de LSAWfP 44
III.3 - Principe de conversion d'un GMWf en un diagramme de
workflow
équivalent 44
III.3.1 - Diagramme de workflow 45
III.3.2 - Conversion d'une spécification
non-récursive 45
III.3.3 - Conversion d'une spécification récursive
50
III.4 - Fonction d'export de LSAWfP vers le BPMN XML 2.0 55
III.5 - Conclusion 56
Conclusion générale 58
TABLE DES MATIÈRES vi
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
Problématique étudiée et bilan 58
Analyse critique des résultats obtenus 59
Quelques perspectives 59
Bibliographie 61
Annexe A ? Présentation du contenu des fichiers
générés par LSAWfP
Editor 67
vii
LISTE DES ACRONYMES
BPM Business Process Management;
BPMN Business Process Model and Notation;
DS(E)L Domain Specific (Embeded) Language;
GMAWfP Grammatical Model of Administrative Workflow Process;
GMWf Grammatical Model of Workflow;
LSAWfP Language for the Specification of Administrative
Workflow
Process;
P2PTinyWfMS Peer-to-Peer Tiny Workflow Management System;
UML Unified Modeling Language;
Wf-Net Workflow-Net;
WfM(S) Workflow Management (System);
WfMC Workflow Management Coalition;
XML eXtensible Markup Language;
YAWL Yet Another Workflow Management;
viii
LISTE DES TABLEAUX
I - Liste exhaustive des tâches du processus de
pré-soutenance d'une thèse
de doctorat et de leurs exécutants respectifs.
9
II - Accréditations des différents acteurs
prenant part au processus de pré-
soutenance 32
ix
TABLE DES FIGURES
1 - Les trois phases du cycle de vie BPM (source [1]).
11
2 - Les quatre activités clés du BPM (source
[1]) 13
3 - Quatre constructions de routage basique (source [2]).
14
4 - Procédure de modélisation (source [3])
15
5 - Éléments de base du BPMN (source [4]).
17
6 - Diagramme d'orchestration BPMN du processus de
pré-soutenance. . 19
7 - Constructions de routage d'un réseau de
workflow (source [2]). 20
8 - Exemple d'un réseau de workflow (source [5]).
20
9 - Éléments de base d'un diagramme YAWL
(source [6]). 21
10 - Processus de pré-soutenance speci~é
avec YAWL. 22
11 - Illustration des modèles de workflows
structurés(source [7]). 24
12 - Artefacts représentatifs du processus de
pré-soutenance d'une thèse de
doctorat 28
13 - Méthodologie de modélisation d'un
processus à l'aide de LSAWfP
(source [8]) 33
14 - Capture d'écran de Bizagi Modeler 35
15 - Capture d'écran de YAWL Process Editor
36
16-Captured'
écrandeBPMN.io
37
17 - Le logo de LSAWfP Editor 39
18 - L'architecture de LSAWfP Editor 40
19 - Panneau des artefacts et des scénarios sur
LSAWfP Editor 41
20 - Panneau d'edition des modèles sur LSAWfP
Editor 42
21 - Capture d'écran de LSAWfP Editor 43
22 - D'un GMWf vers un diagramme de workflow
équivalent 45
23 - Exemple d'un diagramme de workflow: Processus
d'expédition d'une
commande 45
24 - Équivalence entre les règles de
Thompson et les diagrammes de workflows 46
25 - Fonctionnalité d'export dans LSAWfP Editor
55
TABLE DES FIGURES X
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
26 - Visualisation du modèle BPMN
généré par LSAWfP Editor sur
BPMN.io 56
xi
RÉSUMÉ
Le travail réalisé dans ce mémoire
s'inscrit dans le cadre du projet SmartWorkflow [9, 10, 8, 11, 12],
initié par Tchoupé en collaboration avec Parigot. Ce projet
consiste précisément en la modélisation des processus
opérationnels avec une approche grammaticale; et en l'exécution
décentralisée et centrée artefact des
spécifications obtenues, sur une architecture orientée service.
Un langage de modélisation, une méthodologie de
spécification ainsi qu'un modèle d'exécution ont
déjà été proposés.
Avant d'être automatisé, un processus
opérationnel doit être spécifié dans un formalisme
décrivant l'ensemble des tâches qui le compose, les relations de
précédence d'exécution qui les lient, les données
qu'elles consomment et produisent, et les acteurs chargés de les
exécuter. Le processus de spécification est
généralement facilité grâce à l'emploi d'un
outil dit d'aide à la spécification. C'est ce à quoi nous
nous attelons dans ce mémoire : la production d'un outil d'aide à
la spécification des processus en LSAWfP (un langage de
modélisation des processus administratifs avec une approche
orientée scénario). Après une revue de la
littérature sur le Business Process Management (BPM) et sur les travaux
de modélisation effectués dans SmartWorkflow, nous
étudions et analysons les principales fonctionnalités
communément offertes par les outils d'aide à la
spécification. Nous proposons également une méthode de
conversion formelle des spécifications LSAWfP vers les autres langages
de workflows. Nous terminons par une application directe de cette
méthode à travers la proposition d'une fonction d'export de
LSAWfP vers le BPMN sous le format BPMN XML 2.0.
Mots clés : SmartWorkflow,
Spécification de workflow, LSAWfP, grammaires, processus
opérationnel, BPM, conversion de spécification, BPMN XML
xii
ABSTRACT
The work presented here belongs to the SmartWorkflow project
[9, 10, 8, 11, 12], initiated by Tchoupé and Parigot. This project
consists precisely of the modeling of business processes with a grammatical
approach; and in the decentralized and artifact-centered execution of the
resulting specifications, on a service-oriented architecture. A modeling
language, a specification methodology, and an execution model have already been
proposed.
Before being automated, a business process must be specified
in a formalism describing the set of tasks that compose it, the execution
precedence relations that bind them, the data that they consume and produce,
and the actors responsible for executing them. The specification process is
commonly facilitated using a BPM tool. This is what we are working on in this
thesis : the production of a BPM tool for LSAWfP (a business process modeling
language with a scenario-oriented approach). After a review of the literature
on Business Process Management (BPM) and on the modeling work achieved in
SmartWorkflow, we study and analyze the main functionalities commonly offered
by BPM tools. We also introduce a method for the formal conversion of LSAWfP
specifications to other workflow languages. We conclude with a direct
application of this method through the proposal of an export function from
LSAWfP to BPMN in the BPMN XML 2.0 format.
Keywords : SmartWorkflow, Workflow
specification, LSAWfP, grammars, business process, BPM, BPM tool, BPMN
XML
1
INTRODUCTION
SOMMAIRE
Contexte du travail 1
Problématique étudiée 2
Organisation du manuscrit 3
Contexte du travail
La gestion des processus opérationnels (Business
Process Management, en abrégé BPM) a suscité une attention
considérable ces dernières années en raison de son
potentiel d'augmentation significative de la productivité et de la
réduction des coûts des entreprises. Elle est définie par
Wil M. P. Van Der Aalst comme étant "la discipline qui combine les
connaissances issues des technologies de l'information et celles issues des
sciences de la gestion et les applique aux processus opérationnels des
entreprises" [1]. Le BPM vise à améliorer les processus
opérationnels en se concentrant sur leur automatisation, leur analyse,
leur implication dans les opérations de prise de décision
(management) et l'organisation du travail. C'est pourquoi il est souvent
accompagné de logiciels permettant de gérer, contrôler et
soutenir les processus opérationnels : ces logiciels sont appelés
Systèmes de Gestion de Workflow (SGWf) [13].
Traditionnellement, l'automatisation d'un processus
opérationnel passe par sa modélisation formelle dans un langage
compréhensible par un SGWf. Plusieurs langages ont de ce fait
émergé. Ces derniers permettent chacun dans un formalisme
spécifique, de modéliser l'ensemble des processus
opérationnels d'une entreprise. La notation Business Process
Model and Notation (BPMN) [14] et le langage Yet Another
Workflow Language (YAWL) [15] font partie des plus utilisés par les
professionnels du domaine. La spécification d'un processus
opérationnel à l'aide d'un langage de modélisation est
généralement simplifiée par l'utilisation d'un
PROBLÉMATIQUE ÉTUDIÉE 2
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
outil dit d'aide à la spécification. Ces outils
offrent de nombreuses fonctionnalités allant de la simple
création d'un modèle de processus à son partage, sa
validation, sa correction voire son export vers d'autres langages de
modélisation et son exécution. Ces outils au-delà de
l'aide à la spécification, jouent un rôle primordial dans
l'automatisation des processus.
Dans l'optique de rendre plus accessible l'automatisation des
processus et faciliter la gestion complètement
décentralisée de ceux-ci, Tchoupé et Parigot initient le
projet SmartWorkflow. Ce projet a pour but la gestion
décentralisée des processus opérationnels à l'aide
d'une approche grammaticale [9, 10, 8, 11, 12]. Du côté de la
modélisation, SmartWorkflow a fait naitre LSAWfP (a Language for the
Specification of Administrative Workflow Processes) [8], un langage de
spécification des processus administratifs avec une approche
orientée scénario. Basé sur une variante des grammaires
attribuées, ce langage permet de capturer parfaitement les modèle
de cycle de vie, informationnel et organisationnel des processus qu'il
spécifie. Il fournit un formalisme graphique simple permettant de
modéliser les scénarios d'exécution de chaque processus
sous la forme d'arbres annotés. Il met également un accent
particulier sur la modélisation des perceptions que les acteurs ont sur
les processus et leurs données. Un autre principal avantage de ce
langage est sa base mathématique solide, principalement
constituée d'un modèle grammatical qui peut être
étudié formellement de la même manière que les
réseaux de Petri et les autres langages de ce type. Côté
exécution, un modèle d'exécution distribué
centré artefact [10] ainsi qu'un prototype de SGWf (P2PTinyWfMS)
[11] ont vu le jour.
Problématique étudiée et
objectifs
En l'état actuel du projet, la modélisation
effective d'un processus administratif à l'aide de LSAWfP soulève
un problème : celui de l'absence d'un outil d'aide à la
spécification des processus modélisés avec ce dernier. En
effet, les concepts manipulés par LSAWfP (grammaires, artefacts,
accréditations) ne sont pas forcément évidents à
comprendre pour un concepteur lambda. De plus, l'approche orientée
scénario que prône ce dernier, est nouvelle et singulière
dans le domaine du BPM. Cette singularité constitue également un
frein, car LSAWfP pourrait rencontrer des difficultés à trouver
une place dans le quotidien des concepteurs de systèmes workflows,
habitués à d'autres langages.
Dans le présent travail, nous nous intéressons
à la facilitation de la spécification des processus
administratifs avec une approche orientée scénario. À cet
effet, nous
ORGANISATION DU MANUSCRIT 3
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
nous attelons à donner une réponse au
questionnement suivant : afin de réaliser une spécification
à l'aide de LSAWfP d'un processus administratif quelconque et sachant
que celle-ci passe par plusieurs étapes, certaines faisant intervenir
des notions propres aux grammaires, quels moyens peuvent être mis en
place pour faciliter autant que faire se peut la spécification de ce
processus?
La réponse immédiate qui nous vient à
l'esprit est la création d'un outil d'aide à la
spécification. Néanmoins cette réponse apparente nous
conduit naturellement à nous poser plusieurs autres questions : quelles
sont les principales fonctionnalités offertes par les outils existants
d'aide à la spécification? Quelles sont les
fonctionnalités que devra proposer le nôtre? Comment pourra-t-on
le rendre interopérable avec les outils de modélisation
existants?
Les réponses apportées à ces
différentes interrogations nous permettront d'atteindre notre objectif
principal à savoir, la production d'un outil interopérable d'aide
à la spécification des processus modélisés avec
LSAWfP. Nos objectifs spécifiques sont les suivants:
1. Proposer une architecture logicielle pour un
système de spécification des processus administratifs avec un
accent particulier sur la notion de scénario.
2. Mettre en place un DSEL (Domain Specific Embedded
Language) JSON (JavaScript Object Notation) pour la création, la
sauvegarde et le partage des spécifications LSAWfP.
3. Proposer une méthode formelle pour la conversion du
flot de contrôle des processus modélisés par LSAWfP vers
des diagrammes de workflows équivalents.
4. Créer un prototype du système que nous
proposons comme preuve de concepts; l'outil va utiliser le DSEL proposé
pour sauvegarder les spécifications faites sur ce dernier, et va fournir
une implémentation de la méthode de conversion dans le but
d'offrir une fonction d'exportation du flot de contrôle des
spécifications LSAWfP vers le format BPMN 2.0 XML.
Organisation du manuscrit
La suite de ce document est structurée en trois
chapitres, suivis d'une conclusion et d'une annexe. Elle est organisée
comme suit:
Chapitre 1 - Le Business Process
Management : nous présentons ici les différents concepts
autour du Business Process Management. Plus précisément,
ORGANISATION DU MANUSCRIT 4
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
nous présentons successivement les principes
clés du BPM, la modélisation des processus à l'aide de ce
dernier et les workflows structurés.
Chapitre 2 - La spécification des
processus administratifs avec une approche orientée scénario :
ici, nous présentons les contributions réalisées dans
le cadre du projet de Tchoupé et al, en lien direct avec les travaux que
nous menons. Nous présentons ensuite la nécessité pour
LSAWfP de disposer d'un outil d'aide à la spécification et nous
terminons par une revue de quelques outils existants d'aide à la
spécification.
Chapitre 3 - Facilitation de la
spécification des processus administratifs avec une approche
orientée scénario : dans ce chapitre, nous commençons
par présenter les fonctionnalités principales et l'architecture
logicielle de LSAWfP Editor, notre outil d'aide à la
spécification. Nous présentons ensuite la méthode formelle
que nous avons établie pour la conversion des spécifications
LSAWfP. L'on termine par la présentation d'une implémentation
directe de cette méthode au sein de notre outil de spécification
: une fonction d'export vers le BPMN XML 2.0.
Conclusion générale - Nous
effectuons ici un bilan de notre travail ainsi qu'une analyse critique des
résultats obtenus. Quelques perspectives d'amélioration de
résultats sont également présentées.
Annexe A - Présentation du contenu
des fichiers générés par LSAWfP Editor : dans cette
annexe, nous présentons des extraits de fichiers
générés par notre outil. Nous présentons
également l'entièreté du DSEL JSON que nous avons
proposé pour la sauvegarde des spécifications LSAWfP.
5
I
CHAPITRE
LE BUSINESS PROCESS MANAGEMENT
SOMMAIRE
I.1 - Introduction 5
I.2 - Les principes clés du Business Process Management
6
I.3 - Généralités sur la
modélisation des processus opérationnels 12
I.4 - Les workflows structurés 21
I.5 - Conclusion 24
I.1. Introduction
Le travail realisé dans ce memoire s'inscrit dans le
cadre du Business Process Management, un sous-domaine du génie logiciel
qui s'intéresse à l'automatisation des processus
opérationnels. Un processus opérationnel peut être
défini comme un ensemble de tâches réalisées dans le
but d'accomplir un objectif de business [13].
Le Business Process Management tire ses racines des
premières études réalisées au début du
siècle dernier, sur la conception organisationnelle [16]. Cet
intérêt initial s'est développé par la suite pour
devenir une discipline du génie industriel et est resté
axé sur l'analyse des activités opérationnelles dans le
secteur manufacturier. La montée des services et l'importance
grandissante des technologies de l'information pour la conception des processus
(qui sont au centre du fonctionnement des entreprises) ont élevé
ce domaine au rang de discipline complète du génie logiciel,
quittant ainsi le génie industriel. Du fait de cette émergence,
ce domaine s'est également retrouvé au coeur de plusieurs
recherches scientifiques, en raison du rôle capital qu'il joue à
présent, au sein de nombreuses organisations et entreprises.
I.2. LES PRINCIPES CLÉS DU BUSINESS PROCESS MANAGEMENT
6
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
I.2. LES PRINCIPES CLÉS DU BUSINESS PROCESS MANAGEMENT
7
Dans ce chapitre, nous présentons le BPM et les
principes clés qui y sont associés; la modélisation des
processus avec ce dernier, ainsi que les workflows structurés.
I.2. Les principes clés du Business Process
Management
I.2.1. Définitions et exemples
Pour mieux appréhender le Business Process Mangement,
il est essentiel de définir quelques concepts de base de ce dernier. Les
notions de workflow, processus opérationnel, langage de workflow,
système de gestion de workflows, etc. doivent être
élucidées afin d'avoir une vision concrète du BPM et des
perspectives qu'il offre.
I.2.1.1. Définitions des concepts clés
Un processus opérationnel peut être défini
de manière informelle comme un ensemble de tâches ordonnées
selon un modèle spécifique et dont l'exécution produit un
service ou un objectif d'entreprise particulier [13]. Lorsqu'un tel processus
est géré électroniquement, on parle de workflow.
L'objectif d'un workflow est de rationaliser, coordonner et contrôler les
processus opérationnels dans un environnement organisé,
distribué et informatisé. Le processus de recrutement ou encore
la demande de prise de congés sont des exemples courants de processus
opérationnels au sein d'une entreprise. Les termes "processus
opérationnels" et "workflows" sont employés comme synonymes dans
la suite de ce manuscrit. Cet amalgame est également fait dans la
plupart des travaux de recherche portant sur le BPM.
La Workflow Management Coalition 1 (WfMC)
[17] définit la gestion des workflows (GWf) comme la
modélisation et la gestion informatique de toutes les tâches et
des différents acteurs impliqués dans l'exécution d'un
processus opérationnel. La GWf est réalisée à
l'aide des Systèmes de Gestion de Workflow (SGWf) : il s'agit
de systèmes complexes dont le but est d'automatiser les workflows en
fournissant un cadre approprié pour faciliter la collaboration entre les
acteurs impliqués dans l'exécution de ces derniers [13, 1]. Les
SGWf sont composés d'outils logiquement orchestrés pour
spécifier, optimiser, automatiser
1. La réputation croissante des workflows a conduit
à la création, en 1993, de la Workflow Management Coalition
(WfMC) en tant qu'organisation chargée de développer des
normes dans ce domaine. Site officiel de la WfMC :
https://www.wfmc.org/.
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
et surveiller les processus opérationnels [17].
Techniquement, la gestion d'un processus selon la GWf se fait en deux phases
[18] :
1. la phase de modélisation du processus : le
processus est étudié puis spécifié à l'aide
d'un langage (généralement graphique) appelé langage
de workflow. La spécification qui en résulte est
nommée modèle de workflow;
2. la phase d'instanciation et d'exécution du
processus : le modèle de workflow est introduit dans un WfMS qui
instancie et orchestre ensuite l'exécution du processus sous-jacent.
Sachant que les SGWf sont des systèmes autonomes et
préconçus, automatiser un processus opérationnel revient
à le spécifier dans un langage de workflows.
La GWf se concentre principalement sur l'automatisation des
processus opérationnels. Elle ne s'intéresse pas
particulièrement à d'autres aspects tels que l'analyse, la
vérification et la gestion des workflows (modèles), contrairement
au BPM qui en a fait ses fondements [19]. La gestion des processus
opérationnels (BPM) est une discipline qui combine les connaissances des
technologies de l'information et celles des sciences de la gestion pour les
appliquer aux processus opérationnels [1]. Elle peut être
considérée comme une extension de la GWf, car en plus de la
prendre en charge, elle fournit des outils supplémentaires pour
améliorer les processus opérationnels. Raison pour laquelle le
terme "Gestion de workflows" tend à disparaître au profit de
"Gestion des processus opérationnels".
I.2.1.2. Exemple introductif d'un processus
opérationnel
Le BPM est une technologie importante, car elle simplifie
l'automatisation des processus opérationnels, qui sont à la base
du fonctionnement des entreprises et des organisations. Les processus
opérationnels sont omniprésents dans notre société.
Les exemples sont divers et comprennent les processus suivants:
-- La conception et le développement d'un logiciel par
une équipe (en
particulier lorsque les membres sont géographiquement
dispersés) [20]; -- La rédaction simultanée d'un article
scientifique ou la documentation d'un
produit par plusieurs chercheurs (édition
coopérative) [20];
-- Le suivi d'un dossier médical [21];
-- Le processus d'inscription des étudiants dans une
faculté; [22]
-- Le retrait d'une grosse somme d'argent au guichet d'une
banque;
-- La procédure de prise de congés dans une
institution gouvernementale;
-- Le processus d'examen par les pairs d'un article dans un
journal scientifique [9, 23];
I.2. LES PRINCIPES CLÉS DU BUSINESS PROCESS MANAGEMENT
8
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
-- Le processus de pré-soutenance d'une thèse de
doctorat. [24, 25, 26];
Le processus de dépôt d'une thèse de
doctorat présente toutes les caractéristiques du type de
processus (processus administratifs) étudié dans ce manuscrit. De
plus ce dernier reste non automatisé au sein de notre université.
Il sera par conséquent utilisé comme exemple courant tout au long
du manuscrit. Notre description de ce processus s'inspire de celles faites dans
[24, 25, 26], et d'une enquête menée auprès d'un enseignant
de la faculté des sciences :
Exemple 1 Le processus de dépôt d'une
thèse de doctorat au sein de l'université de Dschang (exemple
courant):
Le processus est enclenché lorsque le candidat
dépose son dossier de demande de pré-soutenance auprès de
son équipe dirigeante (les encadreurs). Ce dossier est constitué
de différents éléments tels que les exemplaires de
thèse, le résumé étendu, les photocopies
certifiées des reçus de paiement, le rapport des
séminaires et la décision d'admission en thèse.
-- Une fois le dossier de pré-soutenance
reçu, son équipe dirigeante le complètera en y associant
les pièces complémentaires (rapport scientifique du directeur de
thèse, liste des potentiels experts et rapport du responsable de
laboratoire)
-- Le dossier est par la suite envoyé au chef de
département. Avec l'aide d'un expert chargé d'approuver les
articles scientifiques produits par le candidat, le chef de département
vérifie la conformité de l'ensemble du dossier;
-- Si le dossier n'est pas conforme, il rédige un
rapport contenant le motif de rejet, puis l'envoie à l'équipe
dirigeante et le processus s'achève. Dans le cas contraire, il va
simultanément contacter divers experts dans le but de former un jury
d'expertise (composé de 3 experts dans notre cas);
-- Une demande d'expertise sera envoyée à
chaque potentiel expert. Après réception de son invitation,
chaque expert effectuera une pré-analyse de celle-ci, dans le but de
confirmer ou refuter sa participation;
-- Si un expert se retrouve indisponible pour
l'événement, il rédige un justificatif de
déclinaison et le fait parvenir au chef de département. Dans le
cas contraire, il mène une étude approfondie de la thèse,
rédige un rapport contenant ses corrections et ses
disponibilités, puis l'envoi au chef de département;
I.2. LES PRINCIPES CLÉS DU BUSINESS PROCESS MANAGEMENT
9
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
-- En cas de refus d'expertise, le chef de
département sélectionne un nouvel expert et lui transmet une
invitation pour l'évaluation de la thèse en cours de
traitement.
-- Une fois tous les rapports parvenus, le chef de
département les renvoie à l'équipe dirigeante et le
candidat. Une fois les corrections terminées, le chef de
département à l'aide des rapports, fixe une date et un lieu
convenant à l'ensemble des intervenants, et les notifie.
À partir de cette description, il est facile
d'identifier toutes les tâches à exécuter, leur
enchaînement, les acteurs impliqués et les tâches qui leur
sont attribuées. Dans le cas présent, huit acteurs sont
impliqués : le candidat (Cdt) qui est responsable de
l'initiation du processus, l'équipe dirigeante (ED), le chef de
département (CD) et les cinq experts (EX1,EX2 et EX3).
Un récapitulatif de l'attribution des tâches est
présenté dans le tableau I. Nous avons associé des
symboles aux tâches afin de pouvoir les manipuler aisément dans
les diagrammes qui suivront.
TABLE I - Liste exhaustive des tâches du processus
de pré-soutenance d'une thèse de doctorat et de leurs
exécutants respectifs.
|
Tâches
|
Symboles
|
Acteurs
|
|
Constitution et soumission du dossier de pré-A
soutenance à l'ED
|
|
Cdt
|
|
Complétion du dossier et soumission au CD
|
B
|
ED
|
|
Vérification de la conformité du dossier
|
C
|
CD
|
|
Rédaction du motif de rejet et renvoi à
l'ED
|
D
|
CD
|
|
Sélection d'un expert X, rédaction d'une
invitation et envoi
|
E1 (resp. E2, E3)
|
CD
|
|
Pré analyse de l'invitation et du projet
|
F1 (resp. F2, F3)
|
EX1 (resp. EX2, EX3)
|
|
Rédaction d'un justificatif de déclinaison et
renvoi au CD
|
G1 (resp. G2, G3)
|
EX1 (resp. EX2, EX3)
|
|
Expertise de la thèse
|
H1 (resp. H2, H3)
|
EX1 (resp. EX2, EX3)
|
|
Rédaction d'un rapport contenant les
corrections et les disponibilités, puis envoi au
CD
|
I1 (resp. I2, I3)
|
EX1 (resp. EX2, EX3)
|
|
Renvoi des rapports à l'ED et le
Candidat
|
J
|
CD
|
|
Choix de la date et l'heure de la pré-
soutenance et envoi aux différents
intervenants
|
K
|
CD
|
I.2. LES PRINCIPES CLÉS DU BUSINESS PROCESS MANAGEMENT
10
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
I.2.2. Les concepts de base du BPM
Une vue de haut niveau du BPM révèle que son
cycle de vie se compose de trois phases sur lesquelles il est possible
d'itérer indéfiniment : les phases de (re)conception,
d'implémentation/configuration, et d'exécution &
ajustement [1] (voir fig. 1). Au cours de ce cycle de vie, quatre
activités clés, à savoir la modélisation
(model), la mise en oeuvre (enact), l'analyse (analyse) et la
gestion (manage) (voir fig. 2), sont réalisées [1]. Dans
cette section portant sur les concepts de bases du BPM, nous commencons par une
revue de la litterature sur la classification des workflows et nous terminons
par une présentation du cycle de vie BPM selon Van der Aalst.
I.2.2.1. Les classes de workflows
Les auteurs de [13] mènent une étude sur la
classification des workflows. Dans celle-ci, ils signalent l'absence d'une
approche communément acceptée pour catégoriser les
workflows. Il existe donc plusieurs approches lorsqu'on souhaite les
classifier.
La classification des workflows en fonction de la nature et du
comportement des processus automatisés est l'une des plus courantes dans
la littérature. Selon elle, les workflows sont divisés en trois
groupes : les workflows de production, les workflows
administratifs et les workflows ad-hoc [27, 2]. Les workflows
de production sont ceux qui automatisent des processus
structurés qui ne subissent que très peu (voire pas du tout) de
modifications dans le temps : tous les scénarios sont connus à
l'avance et la plupart des tâches sont exécutées par des
systèmes. Les workflows administratifs s'appliquent aux
processus variables pour lesquels tous les cas sont connus, c'est-à-dire
les processus dont les tâches sont prévisibles et dont les
règles d'ordonnancement sont simples et clairement définies. Dans
ces workflows, les changements sont plus fréquents que dans ceux de
production et les acteurs humains sont plus impliqués dans
l'exécution des tâches. Notons que ce type de workflow apporte une
plus-value considérable aux organisations de l'administration publique
[28]. Notre exemple courant, le processus de pré-soutenance d'une
thèse de doctorat, est un processus administratif. Les workflows
administratifs sont à l'opposé des workflows ad-hoc, qui
automatisent des processus pour lesquels il n'est pas toujours possible de
définir l'ensemble des règles d'ordonnancement à l'avance.
Ces processus ne sont donc que partiellement spécifiés et peuvent
subir de nombreuses mises à jour au cours du temps.
Il existe de nombreux autres types de workflows dans la
littérature. Nous pouvons les workflows scientifiques [29], les
workflows orientés services [30] et
I.2. LES PRINCIPES CLÉS DU BUSINESS PROCESS MANAGEMENT
11
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
les workflows structurés [31, 32, 33]. Ces
derniers joueront un rôle particulier dans le cadre de notre travail,
raison pour laquelle ils seront présentés plus en détail
dans la dernière partie de ce chapitre. Les workflows restants ne seront
pas présentés, car ils ne sont pas d'un grand
intérêt pour le travail que nous effectuons.
I.2.2.2. Le cycle de vie du BPM
FIGURE 1 - Les trois phases du cycle de
vie BPM (source [1]).
L'automatisation d'un processus donné à l'aide
du BPM commence par sa modélisation à l'aide d'un ou plusieurs
langages de workflow [18]. Cette "modélisation" est
initiée pendant la phase de "(re)conception" du cycle de vie du
BPM. Les modèles de workflows obtenus au cours de cette activité
peuvent être analysés (activité "analyse") par des
simulations, ou des algorithmes de model checking2 (pour
vérifier si les modèles sont corrects). La figure 1 nous montre
que la phase de (re)conception est suivie de celle d'
"implémentation/configuration". Dans cette phase, les
modèles de workflows obtenus précédemment sont convertis,
si nécessaire, en modèles de workflow exécutables; puis
utilisés pour configurer le SGWf : ceci conclut l'activité de
modélisation. Après la phase
"implémentation/configuration" vient la phase
"d'exécution & ajustement". Au cours de cette
dernière phase, le workflow est instancié, exécuté
et géré en fonction des scénarios prévus lors de la
modélisation du processus (activités "mise en oeuvre" et
"gestion"). De plus, lorsqu'une instance de workflow est en cours
d'exécution, les données produites et enregistrées peuvent
être analysées (pour découvrir les éventuels goulots
d'étranglement, pertes et déviations) en vue d'une
2. Le model checking est une technique automatisée qui,
étant donné un modèle à états finis d'un
système et une propriété formelle, vérifie
systématiquement si cette propriété est valable pour (un
état donné dans) ce modèle [34].
I.3. GÉNÉRALITÉS SUR LA MODÉLISATION
DES PROCESSUS OPÉRATIONNELS 12
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
éventuelle amélioration. Si suffisamment
d'améliorations possibles sur le modèle de workflow sont
détectées, le cycle peut être relancé pour les
appliquer.
I.3. Généralités sur la
modélisation des processus opérationnels
Les processus opérationnels sont au coeur du
fonctionnement de toute organisation. Il est donc crucial pour ces
organisations de les affiner afin d'être aussi efficace que possible. La
compréhension des processus opérationnels est un facteur
clé lorsque l'objectif d'une organisation est de disposer d'un BPM
efficace. Afin de se concentrer sur ses points forts, de gérer les
ressources et d'éliminer les faiblesses d'une entreprise, les
organisations doivent modéliser et documenter leurs processus. Dans le
contexte du BPM, les modèles de processus jouent un rôle
primordial. La modélisation des processus, partie indissociable
du BPM, vise à décrire, normaliser et réorganiser les
processus opérationnels. Elle aide les organisations à mieux
comprendre leurs processus opérationnels et à distinguer les
processus à valeur ajoutée de ceux qui ne le sont pas. De plus,
elle révèle les processus opérationnels peu clairs ou
compliqués, les résultats défectueux ou les efforts
inutiles [35]. Cette section portera sur les concepts de base de la
modélisation des processus opérationnels, et la
présentation de quelques langages de modélisation de ces
processus.
I.3.1. Concepts de base
I.3.1.1. L'activité de modélisation
La modélisation des processus est une activité
cruciale dans la WfM/BPM. Comme mentionné ci-dessus (sec. I.2.2.2), elle
est réalisée à l'aide de langages
spécialisés appelés langages de workflow.
Plusieurs langages de workflow ont déjà été
développés. Certains d'entre eux (BPM, diagrammes
d'activité UML) sont informels (c'est-à-dire qu'ils
n'ont pas de sémantique bien définie et ne permettent pas
d'analyse [1, 36]) tandis que d'autres (WF-Net, YAWL) sont basés sur des
outils mathématiques (formels) puissants (réseaux de Petri).
Néanmoins, ils permettent tous d'exprimer dans un diagramme
(appelé modèle de workflow), les tâches qui composent un
processus donné et l'ordonnancement de ces tâches. Plus
précisément, les langages de workflows permettent de
décrire le comportement des processus à travers la
représentation (entre autres) [37] :
-- Des tâches qui constituent la partie principale du
processus;
I.3. GÉNÉRALITÉS SUR LA MODÉLISATION
DES PROCESSUS OPÉRATIONNELS 13
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
FIGURE 2 - Les quatre activités
clés du BPM (source [1]).
-- Des informations et des ressources relatives aux
différentes tâches;
-- Des séquences ou dépendances entre ces
tâches;
-- Des événements de déclenchement et de
fin des tâches.
Les tâches sont la base de tout workflow; une
tâche est la plus petite unité de décomposition
hiérarchique d'un processus [9]. Elle représente tout travail
effectué dans le cadre d'un processus. Le terme ressource quant
à lui fait référence à un système ou
à un humain qui peut exécuter une tâche. Il est
également reconnu comme acteur, participant, partie prenante, agent
ou utilisateur selon le contexte. Modèles de
routage
Pour atteindre ses objectifs, tout langage de workflow doit,
pour un processus donné, permettre au minimum d'exprimer ses
tâches et leurs acheminements (flot de contrôle). Le flot
de contrôle des tâches est communément appelé le
modèle de cycle de vie du processus étudié [38,
39]. Il existe un certain nombre de modèles de routage identifiés
dans la littérature comme modèles de base : ce sont les routages
séquentiels, parallèles, alternatifs ou conditionnels et
itératifs [2] (voir fig. 3).
-- Le routage séquentiel exprime le fait que les
tâches doivent être exécutées l'une après
l'autre (tâche A avant les tâches B et C
dans la figure 3(a));
-- Le routage parallèle est utilisé pour
spécifier l'exécution potentiellement simultanée de
certaines tâches. Les tâches B et C de la figure
3(b) peuvent être exécutées en même temps; dans ce
cas, les tâches A et D sont considérées
comme des passerelles : On dit que A est une passerelle
AND-Split tandis que D est une passerelle
AND-Join;
I.3. GÉNÉRALITÉS SUR LA MODÉLISATION
DES PROCESSUS OPÉRATIONNELS 14
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
FIGURE 3 - Quatre constructions de routage
basique (source [2]).
-- Avec le routage alternatif, on peut modéliser une
décision : c'est-à-dire le choix d'exécuter une
tâche plutôt qu'une autre à un moment donné. Dans la
figure 3(c), les tâches B et C ne peuvent pas
être exécutées toutes les deux; dans ce cas, A est
une passerelle OR-Split et D est une passerelle
OR-Join;
-- Dans certains cas, il est nécessaire
d'exécuter une tâche plusieurs fois. Dans la figure 3(d), la
tâche B est exécutée une ou plusieurs fois.
Lorsqu'un langage de workflow permet uniquement de
spécifier le routage des tâches, ne s'intéresse pas
à la modélisation des données consommées et
produites lors de l'exécution de ces tâches et n'accorde qu'un
rôle secondaire aux acteurs, on dit qu'il est centré
processus. C'est le cas pour tous les langages mentionnés
précédemment (BPMN, WF-Net, diagrammes d'activité UML et
YAWL). Ce type de langage de workflow est fréquemment appelé
"langage de workflow traditionnel". Certains feront l'object d'une
sous-section de la partie suivante.
I.3.1.2. Procédure de modélisation d'un
processus opérationnel
La modélisation des processus opérationnels
(Business Process Modeling) est la représentation analytique ou,
plus simplement, l'illustration des processus opérationnels d'une
organisation [40]. Comme dit ultérieurement, c'est au cours de la phase
"conception" du cycle de vie du BPM, que les processus
opérationnels du monde réel sont mis en correspondance avec les
modèles. La modélisation des processus opérationnels
est un concept clé du BPM, qui constitue un moyen de communication
entre les parties prenantes des processus et crée également une
compréhension commune et claire des processus modélisés
[41].
En général, les modèles de processus sont
caractérisés par trois propriétés de base, à
savoir le mapping, l'abstraction et enfin l'adéquation
à l'objectif (finalité) [18]. Le mapping des
processus fait référence au transfert des processus du
I.3. GÉNÉRALITÉS SUR LA MODÉLISATION
DES PROCESSUS OPÉRATIONNELS 15
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
monde réel dans des modèles. En outre, un
processus opérationnel a un niveau d'abstraction qui est choisi
par le modélisateur afin de cacher les détails non pertinents
pour le modèle résultant. Enfin, la finalité d'un
modèle est essentielle pour illustrer l'objectif de ce dernier. Dans le
but de modéliser les processus opérationnels, la procédure
de modélisation doit être prise en considération, ce qui
inclut les étapes à suivre pour modéliser ceux-ci.
Frederiks et Van der Weide [3] présentent une approche en quatre
étapes (voir fig. 4) pour la procédure de modélisation des
processus:
1. L'élicitation : Dès la
première étape, les informations qui doivent être
capturées dans les modèles de processus doivent être
collectées à partir de ce que l'on appelle l'univers du
discours. L'objectif de la phase d'élicitation est d'identifier les
exigences des parties prenantes du processus. Ensuite, les informations qui
sont explicitement disponibles doivent être transférées
dans un format convenu. Les rôles des parties prenantes des processus
sont complémentaires pour cette phase, car ils élicitent et
capturent les exigences de modélisation et leur contexte. Ces
informations peuvent être capturées par le biais d'entretiens ou
de brainstorming, qui sont des techniques d'élicitation couramment
utilisées.
FIGURE 4 - Procédure de modélisation (source
[3]).
2.
I.3. GÉNÉRALITÉS SUR LA MODÉLISATION
DES PROCESSUS OPÉRATIONNELS 16
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
La modélisation : Pendant cette phase,
les spécifications informelles sont transformées en
spécifications formelles. La découverte des concepts de
modélisation significatifs et de leurs relations aura lieu dans cette
phase de la procédure de modélisation. Compte tenu du format
unifié et du langage de modélisation
sélectionné, les instances et les activités du
processus doivent être identifiées et couvertes par les
modèles.
3. La vérification : Dans cette
phase, des contrôles de vérification sont effectués afin de
s'assurer que le modèle est syntaxiquement correct. Les
spécifications formelles sont vérifiées en matière
de cohérence, et d'exactitude.
4. La validation: Cette phase contrôle
les modèles de processus sur la base de l'exactitude sémantique
des spécifications.
I.3.2. Les langages de modélisation de processus
Les langages de modélisation de processus sont des
langages utilisés pour exprimer les modèles de processus
opérationnels. Ceux-ci se doivent de fournir une sémantique
claire permettant de définir les aspects clés d'un processus
opérationnel. Un langage de modélisation des processus
opérationnels doit fournir des structures pour la représentation
des objets métiers. Il doit également fournir des structures pour
les valeurs des types de bases appropriés en ce qui concerne la
représentation et le flux des données [42]. Ces structures
doivent être adéquates pour capturer les références
aux objets ou sources de données externes. Dans le cadre de nos travaux,
nous décrirons notamment le principe de trois des langages de
modélisation les plus populaires, à savoir: Le langage BPMN,
le langage WF-Net et le langage YAWL.
I.3.2.1. La notation BPMN
La notation Business Process Model and Notation (BPMN) est un
standard de la modélisation des processus opérationnels, qui
fournit une notation graphique pour spécifier les processus
opérationnels dans un Diagramme de Processus Opérationnel (DPO)
[43]. Ce diagramme est basé sur une technique d'organigramme similaire
aux diagrammes d'activité UML (Unified Modeling Language).
Développé à l'origine par la Business Process Management
Initiative (BPMI), le BPMN est maintenu par l'Object Management Group (OMG)
depuis la fusion des deux organisations en 2005. L'objectif principal du BPMN
est d'offrir une notation facilement compréhensible par tous les
utilisateurs : des analystes d'entreprise qui créent les
premières ébauches des processus, aux développeurs
techniques responsables de la mise en oeuvre de la technologie qui
exécutera ces
I.3. GÉNÉRALITÉS SUR LA MODÉLISATION
DES PROCESSUS OPÉRATIONNELS 17
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
I.3. GÉNÉRALITÉS SUR LA MODÉLISATION
DES PROCESSUS OPÉRATIONNELS 18
processus; et aux personnes qui géreront et
surveilleront ces processus. Ainsi, le BPMN crée un pont
normalisé entre la conception des processus opérationnels et leur
mise en oeuvre [14].
Les modèles BPMN sont exprimés par des
diagrammes simples construits à partir d'un ensemble limité
d'éléments graphiques. Pour les utilisateurs professionnels comme
le cas des développeurs, ils simplifient la compréhension du flow
et du processus opérationnel. On distingue trois principales
catégories de diagrammes à savoir : les diagrammes
d'orchestration, de chorégraphie et de
collaboration [14]. Parmi les nombreux éléments
graphiques qu'offre le BPMN, les plus utilisés sont [4] (voir fig. 5)
:
-- Les événements, qui sont
utilisés pour représenter un phénomène susceptible
de se produire. En particulier, l'événement de début
représente le moment où le processus opérationnel
commence, les événements intermédiaires
représentent un phénomène qui peut se produire
pendant l'exécution et les événements de fin sont
déclenchés lorsque le processus se termine.
FIGURE 5 - Éléments de base
du BPMN (source [4]).
-- Les activités, qui sont
utilisées pour représenter un travail générique que
les acteurs effectuent au sein du processus opérationnel. Elles peuvent
être atomiques ou non. Les types d'activités qui font partie d'un
modèle de processus sont : les sous-processus et les
tâches. Un sous-processus est une activité
constituée de plusieurs autres. Une tâche est
employée pour représenter une action à réaliser,
qui produit un résultat. Les activités sont
représentées graphiquement par des rectangles aux coins
arrondis.
-- Les passerelles, qui sont utilisées
dans le but de gérer le flot de contrôle pour les activités
parallèles et les choix. Il existe différents types de
passerelles.
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
La passerelle parallèle doit attendre que tous les flux
d'entrée démarrent, puis tous les chemins de sortie sont
lancés en parallèle. Elle peut se comporter comme une bifurcation
(AND-Split) ou comme une fusion (AND-Join). La passerelle de
fusion XOR (OR-Join) donne la possibilité de décrire des
choix dans le processus et d'en sélectionner un seul chaque fois que la
passerelle est atteinte. La passerelle de décision XOR (OR-Split)
donne la possibilité de choisir parmi plusieurs chemins de sortie
chaque fois qu'ils sont atteints. Les passerelles sont graphiquement
représentées par des losanges.
-- Les pools, qui sont utilisés pour
représenter un participant ou une organisation impliqué dans le
processus.
À titre d'illustration, on peut observer
ci-après (voir fig. 6), le modèle de workflow de notre exemple
courant, spécifié à l'aide du BPMN grâce à
l'ensemble des éléments graphiques précédemment
cités.
I.3.2.2. Les réseaux de workflows
(Workflow-Nets)
Les réseaux de workflows (WF-nets) sont une sous-classe
des réseaux de Petri (langage de modélisation
mathématique permettant la description des langages structurés)
destinés à modéliser le workflow des activités de
processus [2]. Les transitions de ces réseaux sont affectées aux
tâches ou aux activités, et les places sont affectées aux
prés et post conditions. Ses constructions de routage sont
présentées à la figure 7. Les réseaux de workflows
ont des exigences structurelles et opérationnelles
supplémentaires, principalement l'ajout d'une place d'entrée
(source) unique sans transition précédente, et d'une
place de sortie (puits) sans transition suivante (voir fig. 8). En
conséquence, on peut définir des marques de début et de
fin qui représentent l'état du processus. Ils ont la
propriété de consistance [2], indiquant qu'un processus avec un
marquage de départ de k jetons dans son site source, peut atteindre le
marquage d'état de terminaison avec k jetons dans son site puits.
Les réseaux de workflows possèdent de nombreux
avantages [15] :
-- Une sémantique formelle malgré la nature
graphique.
-- Une abondance de techniques d'analyse.
-- Ils sont basés sur les états contrairement
aux autres langages qui sont généralement (seulement)
basés sur les événements.
Malgré toutes ces qualités, l'emploi de ces
derniers dans la modélisation des processus n'offre pas un
résultat satisfaisant du point de vue du flot de contrôle. On note
trois principaux problèmes qui en sont à l'origine:
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO
URIFIA
I.3. GÉNÉRALITÉS SUR LA MODÉLISATION
DES PROCESSUS OPÉRATIONNELS
|
19
|
|
Présoutenance d'une thèse de doctorat
|
|
|
A
|
|
|
c O
·
c
no
|
|
|
|
U
|
|
|
cu
|
|
Q- W
|
fB~
|
|
|
|
+-,
|
|
|
|
|
|
C 1
|
|
D
|
|
|
E
v
a
|
|
|
|
v
|
ca a
|
|
|
|
|
|
|
0
w
v
|
|
|
|
|
|
U
|
|
El
|
|
|
E2
|
|
|
E3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
cu a
|
|
|
|
|
W (H1)
|
|
|
|
|
11 J
|
|
|
|
|
|
|
|
|
|
Expert 2
|
|
|
|
|
|
|
F2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
H2
|
|
|
|
|
|
|
|
12
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Expert 3
|
|
|
|
|
3,
|
|
|
|
|
|
|
|
|
|
|
|
|
1G3
|
|
|
|
|
|
|
|
|
l HI3 )
|
|
|
|
|
|
|
(r 13
|
|
|
|
|
|
|
4
|
|
|
|
FIGURE 6 -- Diagramme d'orchestration BPMN
du processus de pré-soutenance.
I.3. GÉNÉRALITÉS SUR LA MODÉLISATION
DES PROCESSUS OPÉRATIONNELS 20
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
FIGURE 7 - Constructions de routage d'un
réseau de workflow (source [2]).
FIGURE 8 - Exemple d'un réseau de
workflow (source [5]).
-- Il n'y a pas de support spécifique pour les
modèles impliquant des instances multiples. De plus, des
charges telles que garder la trace, diviser et joindre les instances sont
supportées par le concepteur.
-- Des modèles de synchronisation avancés sont
dif~ciles à modéliser en termes de réseau de
workflows, car ils ne prennent que deux types de jonctions en charge : la
jonction AND ou la jonction XOR.
-- Le déclenchement d'une transition est toujours
local, c'est-à-dire que l'activation est uniquement basée
sur les jetons dans les emplacements d'entrée et le déclenchement
n'affecte que les emplacements d'entrée et de sortie. Ceci rend
très difficile la modélisation de processus où ont lieu
des événements qui affectent tout le processus et par ricochet
l'ensemble du réseau.
C'est cet ensemble de problèmes qui pousseront [15]
à décrire un nouveau langage de modélisation basé
sur les réseaux de workflows et permettant la modélisation de
complexes processus opérationnels. Il fera l'objet de la section
suivante.
I.3. GÉNÉRALITÉS SUR LA MODÉLISATION
DES PROCESSUS OPÉRATIONNELS 21
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
I.3.2.3. Le langage YAWL
Le langage YAWL (Yet Another Workflow Language)
étend la classe des réseaux de workflows avec des
instances multiples, des tâches composites, la suppression des tokens et
des transitions directement connectées [15]. Il s'inspire des
réseaux de Petri, mais c'est un langage complètement nouveau avec
une sémantique indépendante. Ses éléments de bases
sont présentés à la figure 9.
FIGURE 9 - Éléments de base
d'un diagramme YAWL (source [6]).
YAWL utilise une condition de début et de fin unique
pour marquer le démarrage et la conclusion d'un processus. Les
conditions sont utilisées pour séparer les tâches (comme
les places dans les réseaux de Petri), mais elles n'ont pas besoin
d'être explicitement dessinées. Les tâches sont
représentées par des rectangles. Il existe des variantes de
tâches, par exemple les tâches d'instances multiples et
les tâches de sous-processus. Le comportement du routage est
défini par des petits blocs sur les côtés gauche et droit
des tâches. Les divisions et jointures XOR et AND
utilisent des symboles triangulaires.
À titre d'illustration, on peut observer
ci-après (voir fig. 10), le modèle de workflow de notre exemple
courant, spécifié à l'aide du langage YAWL grâce
à l'ensemble des éléments graphiques
précédemment cités.
I.4. LES WORKFLOWS STRUCTURÉS 22
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
FIGURE 10 - Processus de
pré-soutenance specifié avec YAWL.
I.4. Les workflows structurés
De nombreux langages de spécifications de processus ont
vu le jour avec l'avènement du BPM, entrainant de fait la
création de nombreux WfMS. S'il existe des similitudes entre les
langages de plusieurs de ces systèmes, il existe également des
différences significatives. Parmi celles-ci, on note le fait que bon
nombre de WfMS imposent des restrictions syntaxiques lors de la
spécification des processus. Les types de workflows les plus restrictifs
sont regroupés en une classe commune appelée workflows
structurés [32]. L'utilisation de cette classe de workflows
garantit certaines propriétés importantes que l'on verra.
I.4.1. Définition
Pour appréhender les workflows structurés, il
est essentiel d'établir une définition pratique de la syntaxe
d'un workow classique. [7] fournit une définition d'un workflow
classique de processus centré sur la syntaxe et se limitant aux aspects
de flot de contrôle.
Définition 1 Syntaxiquement, un
workflow W est défini par un ensemble P
constitué d'éléments du processus, et par une relation
transitive Trans ? P ×P. L'ensemble des
éléments du processus peut être divisé en un
ensemble de or-joins Oj, un ensemble de or-splits Os, un ensemble de
and-joins Aj, un ensemble de and-splits As et un ensemble
d'activités A.
Un certain nombre de propriétés sont
observées sur les workflows classiques [7]. Parmi toutes celles-ci,
l'une qui requiert le plus l'attention est le fait que les processus
modélisés à l'aide des workflows classiques peuvent se
retrouver dans une impasse (deadlock). C'est par exemple le
cas, lorsqu'un or-split est suivi d'un and-join. Le processus
modélisé ne s'achève pas et son déploiement devient
par conséquent impossible. De plus, les modèles de workflows
résultant de cette classe sont très souvent rejetés par
les WfMS standards et commerciaux.
I.4. LES WORKFLOWS STRUCTURÉS 23
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
I.5. CONCLUSION 24
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
Un workflow structuré est un workflow dont la
syntaxe est restreinte de diverses façons. Intuitivement, un
workflow structuré est un workflow où chaque
or-split a un or-join correspondant et chaque and-split
a un and-join correspondant. Ces restrictions garantissent
certaines propriétés importantes que l'on verra dans la section
suivante. De plus, elles correspondent également à celles
imposées par des WfMS commerciaux. Néanmoins, [7] propose une
définition formelle de cette classe de workflow.
Définition 2 Un
modèle de workflow structuré (MWS) est
défini de manière inductive comme suit:
1. Un workflow constitué d'une unique
activité est un MWS. Cette activité est à la fois
l'activité initiale et finale.
2. Soit X et Y des MWSs. La concaténation de ces
workflows, où l'activité finale de X a une transition vers
l'activité initiale de Y, est un MWS. L'activité initiale de ce
MWS est l'activité initiale de X et son activité finale est
l'activité finale de Y.
3. Soit X1,...,Xn des MWSs et soit j
un or-join et s un or-split. Le workflow avec comme activité initiale s
et activité finale j et les transitions entre s et les activités
initiales de Xi et entre les activités finales de Xi et j est un MWS.
L'activité initiale de ce MWS est s et son activité finale est
j.
4. Soit X1,...,Xn des MWSs et soit j
un and-join et s un and-split. Le workflow avec comme activité initiale
s et activité finale j et les transitions entre s et les
activités initiales de Xi, et entre les activités finales de Xi
et j, est un MWS. L'activité initiale de ce MWS est s et son
activité finale est j.
5. Soit X et Y des MWSs et soit j un or-join et s un
or-split. Le workflow avec comme activité initiale j et comme
activité finale s et avec des transitions entre j et l'activité
initiale de X, entre l'activité finale de X et s, entre s et
l'activité initiale de Y, et entre l'activité finale de Y et j,
est un MWS. L'activité initiale de ce MWS est j et son activité
finale est s.
Les différents cas de figure mis en oeuvre dans la
définition sont illustrés dans la figure 11.
I.4.2. Les propriétés des workflows
structurés
Comme le montre clairement la définition 1, tout
modèle de workflow structuré est également un
modèle de workflow classique. La sémantique des
constructions utilisée dans les modèles structurés est
donc la même que pour les modèles
FIGURE 11 - Illustration des
modèles de workflows structurés(source [7]).
classiques. On note également qu'un workflow
structuré admet toujours une seule activité initiale et finale.
De plus, de par sa propre définition (voir déf. 2), un workflow
structuré garantit deux propriétés très importantes
à savoir:
1. Un modèle de workflow structuré ne
deadlock jamais. On démontre facilement cela à l'aide de
l'induction structurelle [44].
2. Dans un modèle de workflow structuré, il
n'est pas possible d'avoir plusieurs instances d'une même activité
active au même moment. Cette situation est facilement observable
dans un workflow arbitraire si un and-split est suivi par un
or-join.
Ces propriétés sont la raison pour laquelle, une
grande majorité des WfMS commerciaux permettent uniquement
l'exécution des workflows structurés. Ce constat démontre
le rôle important que joue cette classe de workflow au sein du BPM,
raison pour laquelle elle a fait l'objet de la dernière partie de notre
chapitre portant sur le Business Process Management.
I.5. Conclusion
Dans ce chapitre, nous avons d'abord présenté
les principes clés du Business Process Management. Ceci a
été fait à travers une présentation des concepts de
base propres à cette discipline et la présentation de son cycle
de vie. Nous nous sommes par la suite, intéressés à la
modélisation des processus. Ceci nous a permis d'une part,
d'évoquer les phases clés du processus de modélisation
à l'aide de la modélisation des processus opérationnels
(Business Process Modeling). Puis de montrer d'autre part, comment s'effectue
la modélisation avec des langages de spécification de processus.
Notamment en présentant les éléments de bases de
I.5. CONCLUSION 25
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
divers langages tels que BPMN, Workflow-Nets et YAWL; ensuite
en modélisant des processus avec ces derniers. Nous nous sommes enfin
attardés sur le rôle capital que joue la classe des workflows
structurés au sein du BPM. Dans le chapitre suivant, nous allons
présenter un nouveau langage de modélisation des processus
administratifs; une méthodologie de spécification orientée
scénario associée à ce langage; ainsi qu'un
problème auquel sont confrontés les concepteurs, lors de la
modélisation effective d'un processus à l'aide de ce langage.
26
II
CHAPITRE
LA SPÉCIFICATION DES PROCESSUS
ADMINISTRATIFS AVEC UNE
APPROCHE ORIENTÉE SCÉNARIO
SOMMAIRE
II.1 - Introduction 26
II.2 - Le langage de spécification LSAWfP 27
II.3 - Méthodologie de spécification et
nécessité d'un outil de spécification 32
II.4 - Revue des outils existants de spécification des
workflows 34
II.5 - Conclusion 37
II.1. Introduction
Dans le Business Process Management, la spécification
des processus peut s'effectuer de diverses manières. Cependant, il
n'existe pas d'outils de modélisation communément
acceptés. Certains d'entre eux sont critiqués pour leur
incapacité à capturer à la fois le cycle de vie et les
modèles informationnels et organisationnels des processus. Pour
d'autres, la modélisation des processus se fait
généralement à l'aide d'un seul graphique, ce qui ne
facilite pas la modularité, la maintenance et
l'évolutivité. En outre, certains de ces langages sont
très généraux; par conséquent, leur application
à des processus de domaines spécifiques (tels que les processus
administratifs) est très complexe.
Dans le but de combler les différentes absences
observées dans les divers outils de modélisation
déjà mis en place, TCHOUPÉ TCHENDJI Maurice, ZEKENG NDADJI
Maxime et al. entreprennent un vaste projet visant à la gestion des
processus administratifs à l'aide d'une approche grammaticale [9, 10,
8]. Étant
II.2. LE LANGAGE DE SPÉCIFICATION LSAWFP 27
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
donné que les travaux que nous menons s'inscrivent dans
le cadre de ce projet, ce chapitre est majoritairement consacré à
la présentation des travaux déjà effectués en lien
direct avec les nôtres.
Ce chapitre est organisé comme suit : nous
commençons par décrire LSAWfP, le langage de Zekeng et al. pour
la spécification des processus administratifs; ensuite nous donnons une
méthodologie de spécification des processus LSAWfP avec une
approche orientée scénario. Nous montrons par la suite la
nécessité pour LSAWfP de disposer d'un outil d'aide à la
spécification. Nous terminons par une revue de quelques outils existants
de spécification, afin de déterminer quelles sont les
fonctionnalités de bases que doivent fournir de tels outils.
II.2. Le langage de spécification LSAWfP
LSAWfP (A Language for the Specification of Administrative
Workflow Processes) est un langage récent spécifiquement
conçu pour la modélisation des processus administratifs. Il
s'appuie sur une variante des grammaires attribuées pour fournir un
cadre de modélisation des principaux aspects conceptuels de ces
processus : il s'agit des aspects liés à l'ordonnancement des
tâches (modèle de cycle de vie), aux données
consommées et produites par les tâches (modèle
informationnel), et aux ressources en charge de l'exécution des
tâches (modèle organisationnel) [38]. De plus, LSAWfP met
un accent particulier sur la modélisation (à l'aide de vues) des
perceptions que les différents acteurs ont sur les processus et leurs
données afin de garantir la confidentialité. Pour
modéliser un processus donné avec LSAWfP, quatre étapes
clés doivent être suivies : (1) modéliser les
scénarios du processus à l'aide d'arbres annotés et (2)
dériver, à partir des arbres annotés, une grammaire
abstraite qui sera utilisée comme modèle de cycle de vie; puis
(3) identifier les acteurs impliqués dans l'exécution du
processus et (4) établir le rôle joué par chacun d'eux
à l'aide d'une liste d'accréditations.
II.2.1. La modélisation des scenarios à
l'aide des artefacts représentatifs
LSAWfP est fondé sur le principe selon lequel, par
définition, tous les scénarios d'exécution, tous les
acteurs et les rôles qu'ils jouent par rapport aux tâches d'un
processus administratif donné Pad, sont connus à
l'avance. LSAWfP propose donc de modéliser le scénario
d'exécution de chaque Pad à l'aide d'un arbre
annoté ti appelé artefact. Dans un tel arbre,
chaque noeud (étiqueté Xi) correspond
II.2. LE LANGAGE DE SPÉCIFICATION LSAWFP 28
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
potentiellement à une tâche Xi du
Pad et chaque décomposition hiérarchique (un noeud et
ses fils) correspond à un ordonnancement : la tâche
associée au noeud parent doit être exécutée avant
les tâches associées aux noeuds fils; ces derniers doivent
être exécutés selon un ordre - parallèle ou
séquentiel - qui peut être spécifié par des
annotations particulières ";" (est séquentiel à) et
"k" (est parallèle à). Ces annotations seront
appliquées à chaque décomposition hiérarchique.
L'annotation ";" (resp. "k") reflète le fait que les
tâches associées aux noeuds fils de la décomposition
doivent (resp. peuvent) être exécutées en séquence
(resp. en parallèle).
FIGURE 12 - Artefacts représentatifs
du processus de pré-soutenance d'une thèse de doctorat
Il arrive que l'ensemble des scénarios
d'exécution pour un processus administratif donné soit infini.
C'est le cas de notre exemple courant dans lequel nous pouvons itérer
sur les tâches E1,E2,E3 sans limite; comme
chaque itération donne lieu à un nouveau scénario
d'exécution, nous générons ainsi un ensemble infini de
scénarios d'exécution. On constate donc que l'utilisation des
artefacts n'est pas suffisante pour spécifier ce processus (car
on bouclera indéfiniment lors de la spécification des
différents scénarios). LSAWfP fait intervenir la notion
d'artefacts représentatifs pour la gestion de ces cas de
figure. Il s'agit d' un} ensemble fini æ =
{t1,...,tk} d'artefacts issus d'un ensemble fini ô =
{S1 ad,...,Sk ad de scénarios dits
représentatifs. L'ensemble æ des artefacts
représentatifs est défini de telle sorte que n'importe quel
artefact représentant un scénario d'exécution
peut être exprimé comme une "combinaison" des
éléments de cet ensemble.
II.2. LE LANGAGE DE SPÉCIFICATION LSAWFP 29
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
Pour la spécification de notre exemple courant avec
LSAWfP, nous avons trois scénarios représentatifs : le
premier est celui dans lequel le CD rejette le dossier de
pré-soutenance directement après avoir vérifié sa
conformité; le second est celui dans lequel les cinq premiers experts
sélectionnés valident leurs invitations; le dernier
scénario représentatif est celui dans lequel les cinq premiers
experts rejettent leurs invitations. Ces scénarios peuvent être
modélisés en utilisant les trois artefacts
représentatifs art1, art2 et art3 de la figure
12. Nous pouvons voir en particulier que art1 montre comment la
tâche "Constitution et soumission du dossier de pré-soutenance
à l'ED" assignée au Cdt, et associée au
symbole A (voir sec. I.2.1.2), doit être exécutée
avant les tâches associées aux symboles B, C et
D qui doivent être exécutées en séquence.
Comme dit plus haut, à partir de ces trois artefacts
représentatifs, il est possible de générer tous les autres
artefacts appartenant à ce processus administratif. Notons
également que des symboles supplémentaires appelés
symboles de (re)-structuration peuvent être ajoutés dans
les artefacts pour corriger l'ordonnancement des tâches : C'est le cas
pour art2 et art3 dans lesquels sont respectivement
rajoutés les symboles S et S1.
II.2.2. La déduction du modèle grammatical de
workflow
Après avoir modélisé les scénarios
du processus étudié à l'aide d'artefacts
représentatifs, LSAWfP propose d'en extraire une grammaire abstraite
appelée GMWf (Grammatical Model of Workflow). Pour ce faire, il
suffit de substituer l'ensemble des artefacts représentatifs par une
grammaire G (un GMWf) dans laquelle, chaque symbole se réfère
à une tâche et, chaque production p se présente
sous l'une des deux formes suivantes : p : X0 ?
X1 ; ... ; Xn ou p :
X0 ? X1 ... k
Xn. Ces deux formes de productions
modélisent parfaitement les deux types d'ordonnancement
(parallèle ou séquentiel) retenus dans la conception des
artefacts représentatifs. On note donc ti ? G pour exprimer le
fait que chaque artefact représentatif ti est conforme à
G. Les symboles racines des différents artefacts
représentatifs forment l'ensemble des axiomes de G. Un GMWf peut alors
être formellement défini comme suit [8] :
Définition 3 Un
Grammatical Model of Workflow (GMWf) est défini par
G = (S,P,A) où :
-- S est un ensemble fini de symboles grammaticaux
ou sortes 1 correspondant aux
différentes tâches à exécuter dans
le processus opérationnel étudié;
1. Un sorte est une donnée utilisée
pour définir les règles de structuration (syntaxe) dans un
modèle de document [45]. Exemple : un symbole non terminal dans
une grammaire non contextuelle, un ELEMENT dans un Document Type
Definition (DTD).
II.2. LE LANGAGE DE SPÉCIFICATION LSAWFP 30
-- A ? S est un ensemble fini de symboles
particuliers appelés axiomes, représentant les tâches qui
peuvent démarrer un scénario d'exécution (racines des
artefacts représentatifs);
-- P ? S ×S*
est un ensemble fini de productions décorées par les
annotations ";" (est séquentiel à) et "k" (est
parallèle à) : ce sont des règles de
précédence. Une production P =
(XP(0),XP(1),···XP(|P|))
est soit de la forme P : X0 ? X1
;...;X|P|, ou de la forme P : X0 ?
X1 k ... k X|P| avec
|P| qui désigne la longueur de la partie droite de P.
Une production avec le symbole X en membre gauche est appelée une
X-production.
En considérant le cas du processus de
pré-soutenance d'une thèse de doctorat dont les artefacts
représentatifs sont présents à la figure 12, le GMWf
dérivé est G = (S,P,A) dans lequel l'ensemble S
des symboles grammaticaux est S =
{A,B,C,D,E1,E2,E3,F1,F2,F3,G1,G2,G3,H1,H2,H3,I1,I2,I3,J,K}
(voir sec. I.2.1.2); la seule tâche initiale (axiome) est A
(donc A = {A}) et l'ensemble P des productions
est:
P1 : A?B;C;D
P2 : A ? B;C;S;J ;K
P3 : S ? E1 k E2 k
E3
P4 : E1 ? F1 P7 : E2
? F2 P10 : E3 ? F3 P13 :
F1 ? G1 P16 : G2 ? E2 P19
: B ? E P22 : I1 ?
E
P5 : F1 ? H1 P8 : F2
? H2 P11 : F3 ? H3 P14 :
G1 ? E1 P17 : F3 ? G3 P20
: C ? E P23 : I2 ?
E
P6 : H1 ? I1 P9 : H2
? I2 P12 : H3 ? I3 P15 :
F2 ? G2 P18 : G3 ? E3 P21
: D ? E P24 : I3 ?
E
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
II.2.3. Les acteurs et les accréditations
Identification des acteurs
L'identification des acteurs participant à
l'exécution du processus se fait facilement à l'aide de la
description textuelle du processus. Par exemple, selon la description du
processus de pré-soutenance, huit (k = 8) acteurs participent
à son exécution : un candidat (Cdt), une équipe
dirigeante (ED), un chef de département (CD) et cinq
experts (EX1,EX2 et EX3). Par simple
déduction, on obtient la liste des acteurs LPk =
{Cdt,ED,CD,EX1,EX2,EX3}.
Établissement de la liste des
accréditations
LSAWfP propose un mécanisme appelé
accréditation, inspiré de la nomenclature des droits
utilisée dans les systèmes de type Unix, pour assurer une
meilleure coordination entre les acteurs et garantir par la suite la
confidentialité
II.2. LE LANGAGE DE SPÉCIFICATION LSAWFP 31
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
de certaines actions et données. L'accréditation
d'un acteur donné fournit des informations sur ses droits (permissions)
par rapport à chaque tâche du GMWf du processus
étudié. Il existe trois types d'accréditation:
1. L'accréditation en lecture (r) : un acteur
accrédité en lecture sur le sorte X doit être
informé de l'exécution de la tâche associée; il doit
également avoir un accès libre à son statut
d'exécution (données générées pendant son
exécution). Nous appelons vue d'un acteur,
l'ensemble des sortes sur lesquels il est accrédité en
lecture.
2. L'accréditation en écriture (w) :
un acteur accrédité en écriture sur le sorte X
peut exécuter la tâche associée. Tout acteur
accrédité en écriture sur un sorte est
accrédité en lecture sur celui-ci.
3. L'accréditation en exécution (x) :
un acteur accrédité en exécution sur le sorte X
est autorisé à demander à l'acteur qui y est
accrédité en écriture de l'exécuter
(réalisation de la tâche associée).
Plus formellement, une accréditation est définie
comme suit:
Définition 4 Une
accréditation AAi définie sur un ensemble S de
symboles grammaticaux pour un acteur Ai, est un tripletAAi =
(AAi(r),AAi(w),AAi(x))
tel que, AAi(r) Ç S aussi appelé vue
de l'acteur Ai, est l'ensemble des symboles sur lesquels Ai est
accrédité en lecture, AAi(w) Ç
AAi(r) est l'ensemble des symboles sur lesquels Ai est
accrédité en écriture et AAi(x) Ç
S est l'ensemble des symboles sur lesquels Ai est accrédité en
exécution.
À partir de l'affectation des tâches pour le
processus de pré-soutenance dans notre exemple courant, il en
découle que l'accréditation en écriture de l'ED
est AED(w) = {B}. De plus, puisqu'il ne peut
exécuter la tâche B que si la tâche A
(exécutée par le Cdt) est déjà
exécutée (voir artefacts art1, art2 et art3,
fig. 12), il doit être accrédité en
exécution sur A pour pouvoir demander son exécution; il
doit également l'être sur la tâche C pour demander
au CD de procéder a la vérification du dossier. On a
donc AED(x) = {A,C}. En outre, afin de pouvoir
accéder à toutes les informations sur la constitution du dossier
(tâche A), les rapports de correction faits par les experts (tâche
J) et les honoraires de la pré-soutenance (tâche K). Ces
tâches, en addition de AED(w) 2 constitue
l'ensemble AED(r) = VED = {A,B,J,K} des
tâches sur lesquelles il est accrédité en lecture. En
faisant de même pour chacun des autres acteurs, nous déduisons
leurs accréditations. Celles-ci sont représentées dans le
tableau II et nous avonsLAk =
{ACdt,AED,ACD,AEX1,AEX2,AEX3}.
2. Rappel: tout acteur accrédité en écriture
sur une sorte est accrédité en lecture sur celle-ci.
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
II.3. MÉTHODOLOGIE DE SPÉCIFICATION ET
NÉCESSITÉ D'UN OUTIL DE SPÉCIFICATION 32
TABLE II - Accréditations des différents
acteurs prenant part au processus de pré-soutenance
|
Acteur
|
Accréditation
|
|
Cdt
|
Cdt = ({A,J,K},{A},{B})
|
|
ED
|
ED = ({A,B,J,K},{B},{A,C})
|
|
CD
|
CD = ({B,C,D,E1,E2,E3,G1,G2,G3,I1,I2,I3,J,K},{C,D,E1,E2,
E3,J,K},{F1,F2,F3})
|
|
EX1
|
EX1 = ({B,E1,F1,G1,H1,I1},{F1,G1,H1,I1},
ø)
|
|
EX2
|
EX2 = ({B,E2,F2,G2,H2,I2},{F2,G2,H2,I2},
ø)
|
|
EX3
|
EX3 = ({B,E3,F3,G3,H3,I3},{F3,G3,H3,I3},
ø)
|
Nous obtenons finalement le Modèle Grammatical
de Workflow du Processus Administratif : avec LSAWfP, la
modélisation d'un processus résulte en un triplet Wf =
(G,LPk,L k) (appelé Grammatical
Model ofAdministrative Workflow Process - GMAWfP -) dans lequel, G est le
GMWf, LPk est la liste des acteurs et L k est la
liste de leurs accréditations.
II.3. Méthodologie de spécification et
nécessité d'un outil de spécification
II.3.1. Méthodologie de spécification des
processus LSAWfP
La méthodologie de spécification proposée
par Zekeng et Tchoupé se déroule en quatre étapes suivant
la description ci-après [8].
Pour modéliser un processus donné à
l'aide de LSAWfP, il faut partir d'une description textuelle du processus et
effectuer les quatre activités illustrées à la figure 13.
Tout d'abord, l'ensemble des tâches et leurs relations de
précédence d'exécution doivent être
identifiées afin de produire un ensemble fini d'artefacts
représentatifs en suivant l'approche présentée à la
section II.2.1. Le GMWf doit ensuite être déduit de l'ensemble des
artefacts représentatifs ainsi produits. Ensuite, il faut identifier les
différents acteurs impliqués dans l'exécution du processus
modélisé, et enfin, il faut procéder à une
affectation cohérente des tâches aux acteurs et en déduire
leurs accréditations respectives.
II.3.2. Nécessité d'un outil de
spécification pour LSAWfP
En dépit de ses innombrables qualités, l'emploi
de LSAWfP dans son état actuel peut s'avérer très complexe
sans la présence d'un outil de spécification pour épauler
le concepteur. En effet, comme dit plus haut, spécifier un processus
à l'aide de LSAWfP revient à déterminer son GMAWfP Wf
= (G,LPk,L k). Pour une
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
II.3. MÉTHODOLOGIE DE SPÉCIFICATION ET
NÉCESSITÉ D'UN OUTIL DE SPÉCIFICATION 33
FIGURE 13 - Méthodologie de
modélisation d'un processus à l'aide de LSAWfP (source
[8]).
grosse procédure administrative, le GMAWfP obtenu peut
contenir une centaine de productions, voire bien plus. Il en est de même
pour les acteurs et les différentes accréditations. Cette
difficulté qui au premier abord semble liée uniquement à
LSAWfP est en fait un problème commun rencontré par tous les
autres langages de workflows. La solution générale qui en ressort
est celle selon laquelle, afin de pouvoir faciliter au mieux la
modélisation à l'aide d'un langage de workflow, il est
impératif que ce dernier bénéficie d'un outil de
spécification proposant à minima une interface graphique pour
simplifier la modélisation des processus opérationnels complexes.
À travers cet outil, le concepteur a une vision globale directe du
processus qu'il est train de spécifier, ce qui contribue largement
à réduire les erreurs de modélisation, et à rendre
le travail moins fastidieux. De plus les outils d'aide à la
spécification offrent des interfaces pratiques et intuitives,
éliminant ainsi le besoin d'experts en workflow, ce qui rend le langage
accessible à un plus grand nombre de personnes.
Comme autre raison justifiant la nécessité d'un
outil de spécification pour LSAWfP, on a le fait que les concepts
manipulés par ce dernier ne sont pas forcément évidents
à comprendre. En effet la modélisation d'un processus avec ce
langage requiert un certain nombre de connaissances sur les grammaires
(productions, axiomes...) dans son état actuel. De plus, l'approche de
modélisation orientée scénario prônée par
LSAWfP est nouvelle et singulière dans le domaine. Il serait donc plus
aisé pour tout concepteur de systèmes d'information
désirant utiliser l'approche LSAWfP, de disposer d'un outil logiciel
d'aide à la spécification des processus. Un tel outil se chargera
de rendre plus pratique la philosophie de LSAWfP tout en mettant à la
disposition des usagers, plusieurs fonctionnalités et
II.4. REVUE DES OUTILS EXISTANTS DE SPÉCIFICATION DES
WORKFLOWS 34
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
DSEL (Domain Specific Embedded Language) pour la
création, la sauvegarde et le partage des spécifications de
processus.
La dernière raison que nous pouvons évoquer est
la simplification de la spécification des processus dans
P2PTinyWfMs. En effet, l'utilisation de notre prototype de WfMS passe
nécessairement par la spécification du processus que l'on
souhaite simuler en langage JAVA. Le concepteur est donc contraint d'avoir un
minimum de bases en JAVA pour pouvoir profiter du simulateur. Ceci qui pose
problème, car l'idéologie véhiculée par le BPM, est
celle selon laquelle automatiser un processus opérationnel, revient tout
simplement à le modéliser, indépendamment d'un langage
de programmation. La mise sur pied d'un outil de spécification peut
être le premier pas vers l'indépendance des outils actuels et de
nos futurs outils, vis-à-vis des langages de programmation. Car cet
outil est le point d'entrée, lors de l'automatisation d'un processus.
En somme, ce sont là toutes les raisons qui nous ont
motivé à proposer comme contribution dans le cadre de ce projet,
un outil interopérable d'aide à la facilitation des processus
spécifiés à l'aide de LSAWfP. Ce dernier viendra rendre la
spécification des processus à l'aide de LSAWfP bien plus
intuitive qu'auparavant.
II.4. Revue des outils existants de spécification
des workflows
Cette partie nous permettra de faire le point sur ce que
proposent généralement les outils de spécifications
existants en termes de fonctionnalites. Pour ce faire, on procédera
à l'analyse de trois des plus célèbres outils de
spécifications à savoir : Bizagi Modeler, YAWL Process Editor
et
BPMN.io.
II.4.1. Bizagi Modeler
Développé par l'entreprise anglaise Bizagi,
cet outil de spécification graphique permet de modéliser des
processus sous le langage BPMN. Il se classe comme le plus
célèbre parmi ceux de sa catégorie, et fait partie d'une
suite d'outils proposé par Bizagi, dont le but est l'automatisation
complète (modélisation, vérification, exécution, et
ajustement) des différents workflows d'une entreprise. Bizagi Modeler
permet aux organisations de créer et de documenter des processus
opérationnels afin de mieux comprendre chaque étape et
d'identifier les possibilités d'amélioration des processus pour
accroître l'efficacité organisationnelle [46]. Il
II.4. REVUE DES OUTILS EXISTANTS DE SPÉCIFICATION DES
WORKFLOWS 35
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
s'agit de l'outil que nous avons utilisé pour la
modélisation de notre exemple courant en BPMN (voir fig. 6).
FIGURE 14 - Capture d'écran de
Bizagi Modeler
En ce qui concerne ses fonctionnalités de base, il
permet de créer, sauvegarder et partager les diagrammes de
workflow en utilisant la notation BPMN. Il permet également la
collaboration entre les membres d'une équipe sur des diagrammes de
processus créés en vue d'éventuelles améliorations.
Il offre aussi la possibilité d'importer et d'exporter des diagrammes
Microsoft Visio, IBM Bluewoks, XPDL, et BPMN. Une de ses principales
limites est son indisponibilité sur le système d'exploitation
macOS.
II.4.2. YAWL Process Editor
Développé par la YAWL Foundation, YAWL
Process Editor est un outil open source d'aide a la specification qui
permet de créer des workflows de processus oprerationnels pour
gérer l'activité d'une entreprise. En outre, les systèmes
peuvent être créés à partir d'une interface pratique
et intuitive, éliminant ainsi le besoin d'experts en workflow et
d'autres personnels spécialisés. Lors de la conception d'un
workflow, il propose des spécifications, qui décrivent la
tâche ou le processus que l'on souhaite representer. À
l'intérieur de l'application, ces spécifications sont
composées de réseaux qui peuvent être ajoutés
manuellement et personnalisés, en utilisant la souris pour dessiner un
schéma et reproduire le workflow de manière graphique. Il s'agit
de l'outil que nous avons utilisé pour la modélisation de notre
exemple courant en YAWL (voir fig. 10).
II.4. REVUE DES OUTILS EXISTANTS DE SPÉCIFICATION DES
WORKFLOWS 36
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
FIGURE 15 - Capture d'écran de YAWL
Process Editor
En ce qui concerne ses fonctionnalités de base, YAWL
Process Editor permet la création, la sauvegarde et le partage de
spéci~cations de processus couvrant toutes les perspectives
nécessaires à l'automatisation des workflows (voir fig. 15). En
plus de ce qui est visible dans la capture, il y a des variables de
données définies pour chaque tâche, en utilisant des
schémas XML. Les variantes de tâches peuvent être
créées et mappées à partir de variables globales
par de simples opérations de glisser-déposer [47]. En ce
qui concerne les accréditations, YAWL peut classer les ressources
humaines et non humaines en rôles, postes et groupes en fonction des
capacités organisationnelles. Sa principale faiblesse est sa structure
formelle liée aux réseaux de Petri, ce qui la rend un peu moins
accessible pour des concepteurs tiers, par rapport aux autres langages de
workflows.
II.4.3. BPMN.io
Développé par l'entreprise Camuda,
BPMN.io est outil de spécification
open-source et accessible depuis un navigateur web. Il permet principalement de
visualiser et modéliser des processus opérationnels
spécifiés en BPMN depuis le web. Ceci facilite grandement la
visualisation et le partage des spécifications sachant qu'avec l'aide de
ce dernier, la contrainte d'installer un outil sur son poste
disparait.
II.5. CONCLUSION 37
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
FIGURE 16 - Capture d'écran de
BPMN.io
Développé en JavaScript, il offre
également une bibliothèque, qui permet aux concepteurs d'inclure
des diagrammes BPMN dans leurs pages web. Sa principale faiblesse réside
dans son manque de fonctionnalités additionnelles lorsqu'on le
compare aux autres outils précédemment cités. Mais cette
faiblesse est largement compensée par sa facilité
d'utilisation et sa simplicité d'accès.
II.5. Conclusion
La spécification des processus peut être
envisagée sous plusieurs angles. Dans ce chapitre, nous avons
présenté le projet qui constitue la base de nos travaux, à
savoir la spécification des processus administratifs avec une
démarche grammaticale. C'est ainsi que nous avons exposé, en
accord avec [8, 9], les contributions majeures réalisées dans le
cadre de ce projet en lien avec notre travail. Il s'agissait notamment du
langage LSAWfP permettant la spécification des processus administratifs
avec une approche orientée scénario et d'une méthodologie
de spécification des processus pour ce langage. Nous avons
terminé par une revue de quelques outils existants de
spécification, après avoir présenté la
nécessité pour LSAWfP de disposer du sien. Dans le chapitre III,
nous allons présenter notre contribution en ce qui concerne la
facilitation de la spécification des processus administratifs.
38
III
CHAPITRE
FACILITATION DE LA SPÉCIFICATION
DES PROCESSUS ADMINISTRATIFS
AVEC UNE APPROCHE ORIENTÉE
SCÉNARIO
SOMMAIRE
III.1 - Introduction 38
III.2 - Présentation de LSAWfP Editor 39
III.3 - Principe de conversion d'un GMWf en un diagramme de
workflow
équivalent 44
III.4 - Fonction d'export de LSAWfP vers le BPMN XML 2.0
55
III.5 - Conclusion 56
III.1. Introduction
Étant donné un processus administratif
spécifié à l'aide du langage LSAWfP, le concepteur
à l'état actuel du projet, n'a d'autre choix que de devoir
spécifier individuellement et manuellement, l'ensemble des
éléments constituant le GMAWfP de son processus. Ceci dans le but
de pouvoir le simuler dans P2PTinyWfMS. Un tel procédé
devient très vite fastidieux lorsqu'on a affaire à une grosse
procédure administrative; car on se retrouve avec une quantité
colossale d'informations à devoir remplir l'une après l'autre.
De plus, l'étape de modélisation jouant un
rôle primordial au cours du procédé d'automatisation du
processus, la plupart des langages de spécification dispose d'outils de
spécification des processus. Comme vu précédemment, ces
outils ont
III.2. PRÉSENTATION DE LSAWFP EDITOR 39
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
III.2. PRÉSENTATION DE LSAWFP EDITOR 40
III.2. PRÉSENTATION DE LSAWFP EDITOR 41
III.2. PRÉSENTATION DE LSAWFP EDITOR 42
III.2. PRÉSENTATION DE LSAWFP EDITOR 43
pour principal but de faciliter la tâche au concepteur,
autant que faire se peut, durant tout le processus de modélisation. Pour
un langage tel que LSAWfP, basé sur les grammaires et faisant intervenir
un nombre conséquent de données au sein d'un GMAWfP, il est
crucial de pouvoir bénéficier d'un tel outil afin de faciliter la
spécification des processus. Dans l'optique de remédier à
ce problème, nous proposons dans ce chapitre, LSAWfP Editor, un outil de
spécification des processus administratifs avec LSAWfP. Un tel outil se
devant d'être fiable, robuste, efficace, extensible et surtout simple
d'utilisation, il est primordial de le concevoir minutieusement tout en
reposant sur des outils (langages, bibliothèques, frameworks...)
existants et présentant les caractéristiques recherchées.
Il se doit également d'être interopérable avec des outils
existants d'aide à la spécification.
FIGURE 17 - Le logo de LSAWfP
Editor
Ce chapitre est organisé comme suit : nous
commençons par présenter LSAWfP Editor à travers son
architecture et ses fonctionnalités de bases (modélisation
graphique, sauvegarde, visualisation, etc.). Nous présentons par la
suite, les formules mathématiques que nous avons établies pour la
conversion de nos spécifications. Nous terminons par une application
directe de ces formules dans notre éditeur LSAWfP Editor, à
travers une fonction d'export des GMAWfP vers le format BPMN XML 2.0.
III.2. Présentation de LSAWfP Editor
LSAWfP Editor peut être définit comme un outil de
spécification graphique des processus modélisés à
partir du langage LSAWfP. Développé en JAVA, cet outil
dédié à la conception des GMAWfP épouse
parfaitement la philosophie orientée scénario. La revue des
outils de spécifications existants nous a permis de faire une
déduction sur les fonctionnalités de bases que doit offrir LSAWfP
Editor, s'il souhaite se classer dans la même catégorie que les
autres. Les deux principales fonctionnalités qu'il doit proposer sont:
la modélisation graphique et la sauvegarde des spécifications
pour le partage de celles-ci. Une fonctionnalité additionnelle qu'il
pourrait également offrir, est celle de l'export vers un langage
existant.
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
III.2.1. Architecture logicielle de LSAWfP Editor
L'architecture de LSAWfP Editor implémente le design
pattern MVC (Model View Controller ou Modèle Vue Contrôleur
en français) qui est une référence en matière
de patron de conception. Dans cette architecture, les vues affichent des
résultats et récupèrent des entrées
(données, actions) qu'elles transmettent aux modèles à
travers les contrôleurs (qui les valident); les modèles
réalisent les traitements (édition des artefacts, sauvegarde,
export, etc.) puis notifient les vues pour rafraîchissement. Sous LSAWfP
Editor, le modèle, la vue et le contrôleur sont organisés
comme suit:
-- Le modèle est la pièce maîtresse
réalisant le plus gros du travail. C'est à ce niveau que se
déroule la mise en oeuvre de toutes les fonctionnalités offertes
par notre outil. Nous avons entre autres : la création d'une nouvelle
spécification, celle d'un nouveau scénario, la sauvegarde et
l'export des spécifications et les différentes actions
effectuées sur les artefacts.
-- La vue donne une représentation graphique des
artefacts représentatifs, et de l'ensemble des données
constituant le GMAWfP du processus. Ceci dans le but de permettre une
interaction conviviale entre LSAWfP Editor et ses utilisateurs. Elle dispose
donc de parseurs pouvant réaliser la correspondance entre les
données reçues et les données à afficher.
-- Le contrôleur quant à lui, est chargé
d'établir le pont entre la vue et le modèle.
La figure 18 résume l'architecture de LSAWfP Editor
ci-dessous présentée.
FIGURE 18 - L'architecture de LSAWfP
Editor
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
III.2.2. Modélisation graphique des processus
La modélisation graphique offre une interface graphique
dans laquelle le concepteur peut très souvent glisser-déposer les
éléments dont il a besoin, ou les placer et les disposer à
l'aide de boutons présents dans le panneau des outils. Cette
fonctionnalité peut être considérée comme la
fonctionnalité première que doit offrir tout outil d'aide
à la spécification. En effet elle facilite grandement la
modélisation, car l'utilisateur a directement en visuel, le
modèle qu'il construit, ce qui facilite grandement la
compréhension qu'il a, de ce qu'il est en train de faire. Raison pour
laquelle nous proposons dans LSAWfP Editor un vaste panneau dans lequel
l'utilisateur a la possibilité de placer des taches et les ordonnancer.
Il s'agit du panneau dans lequel figurent les différents artefacts
représentatifs du processus que l'on spécifie (voir A
dans fig. 19).
FIGURE 19 - Panneau des artefacts et des
scénarios sur LSAWfP Editor
LSAWfP adoptant une philosophie orientée
scénario, notre éditeur fait de même en permettant à
l'utilisateur de créer de multiples scénarios pour le même
processus opérationnel qu'il spécifie. Pour ce faire, on propose
dans la barre d'outils un bouton permettant de créer un nouveau
scénario. Nous mettons également en oeuvre un panneau regroupant
l'ensemble des scénarios déjà créés pour un
processus donné (voir B dans fig. 19).
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
Nous proposons pour terminer un panneau d'édition des
modèles, divisé en trois sections principales (voir fig. 20) :
FIGURE 20 - Panneau d'edition des
modèles sur LSAWfP Editor
-- la section d'édition des artefacts qui
permet d'ajouter des fils à un noeud et offre la possibilité de
les ordonnancer;
-- la section des informations sur une tache qui
permet d'associer un symbole à une tache, de changer son type ou encore
de lui ajouter une description;
-- la section sur les accréditations qui
permet de créer les différents acteurs intervenant dans le
processus, et de les assigner des accréditations suivant leurs
capacités organisationnelles.
À l'aide de tous les éléments graphiques
que nous proposons, un concepteur peut parfaitement modéliser l'ensemble
des éléments constituant le GMAWfP de son processus. La
spécification se retrouve grandement facilitée sachant que la
liste des symboles S, des axiomes A et des productions P
sont déduits de l'ensemble des artefacts provenant du panneau
des artefacts; tandis que la liste des acteurs et
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
des accréditations proviendra de la section sur les
accréditations. LSAWfP Editor assume donc pleinement son rôle
d'outil d'aide à la spécification des processus LSAWfP du
côté de la modélisation graphique.
III.2.3. Sauvegarde, visualisation et partage des
spécifications
FIGURE 21 - Capture d'écran de
LSAWfP Editor
La sauvegarde des spécifications faites est une autre
fonctionnalité clé d'un outil de spécification.
Sauvegarder permet non seulement de pouvoir reprendre et améliorer nos
spécifications, mais aussi de pouvoir les partager, ce qui est essentiel
quand on modélise un processus opérationnel en équipe.
LSAWfP Editor effectue la sauvegarde de ces spécifications à
l'aide d'un format créé par nous-même. Ce format suit
l'architecture logicielle de notre éditeur et contient l'ensemble des
éléments nécessaires pour parfaitement restituer
l'ensemble des artefacts modélisés. Une des forces de ce format,
est que contrairement aux autres formats de sauvegarde graphique (notamment le
BPMN XML 2.0 et le YAWL), celui-ci fait abstraction de la partie graphique (pas
besoin de spécifier les coordonnées graphiques des
différents éléments, ce qui facilite grandement la lecture
du fichier et réduit sa taille), et le diagramme est parfaitement
restitué lors de son ouverture. Ceci étant dû au choix
stratégique d'employer des arbres annotés pour représenter
les artefacts. L'extension du format de sauvegarde se nomme .ggmawfp
(Graphical Grammatical Model of Administrative Workflow Process). Une fois
la sauvegarde effectuée, LSAWfP Editor permet de visualiser le .ggmawf
obtenu, ce qui vient compléter la fonction de partage des
spécifications. En effet, un concepteur a
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
III.3. PRINCIPE DE CONVERSION D'UN GMWF EN UN DIAGRAMME DE
WORKFLOW
ÉQUIVALENT 44
la possibilité de sauvegarder son modèle, et
l'envoyer à un autre concepteur qui pourra le visualiser à l'aide
de notre outil. Le partage se retrouve ainsi assuré. Pour illustrer tout
ceci, on présentera en annexe un extrait du fichier de sauvegarde de
notre exemple courant, obtenu avec LSAWfP Editor.
III.2.4. Interopérabilité avec les autres
outils de LSAWfP
Lorsqu'on parle de spécification des processus, la
suite logique est l'automatisation des modèles obtenues. Ceci se
déroule à travers une phase de simulation et d'exécution
des spécifications. Le langage LSAWfP s'inscrit dans la même
logique et dispose déjà d'un simulateur (P2PTinyWfMS)
d'exécution pour les spécifications LSAWfP. Un
problème d'interopérabilité naitra immediatement entre
LSAWfP Editor, P2PTinyWfMS et les éventuels outils qui seront
proposés dans le cadre de notre projet. LSAWfP Editor prend les devants
dans la résolution de ce problème, en proposant un format
générique et abstrait pour le partage des spécifications
entre les différents outils. Contrairement au format de sauvegarde
graphique, ce format embarquera uniquement en son sein, les
éléments obligatoires pour restituer le modèle grammatical
de workflow, c'est-à-dire le GMWf, les acteurs et les
accréditations. Ce format sera par la suite utilisé par le
simulateur et les futurs outils de la suite LSAWfP.
L'interopérabilité entre ces derniers se retrouve ainsi
assurée. Ce format se nomme .gmawfp. Son sigle
qui est le même que celui du modèle grammatical de workflow d'un
processus administratif, vient renforcer l'idée que ce format se veut
générique et exploitable par tous les outils implémentant
le langage LSAWfP.
Pour illustrer tout ceci, on présentera en annexe un
extrait du .gmawfp de notre exemple courant, obtenu avec LSAWfP Editor.
III.3. Principe de conversion d'un GMWf en un diagramme
de workflow équivalent
La plupart des langages de spécifications ont en commun
l'utilisation d'un diagramme de workflow comme représentation graphique
de leurs spécifications. Quitter de LSAWfP vers ces autres langages
revient donc à convertir un modèle grammatical de workflow (GMWf)
en un diagramme de workflow équivalent. Ce diagramme pourra par la suite
être sérialisé en différents langages de
modélisation existants.
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
III.3. PRINCIPE DE CONVERSION D'UN GMWF EN UN DIAGRAMME DE
WORKFLOW
ÉQUIVALENT 45
FIGURE 22 - D'un GMWf vers un diagramme de workflow
équivalent
III.3.1. Diagramme de workow
Un diagramme de workflow est un diagramme qui permet
de représenter l'enchainement et l'ordonnancement des tâches d'un
processus. Ces diagrammes sont communs à bon nombre de langages de
workflows parmi lesquels BPMN et YAWL.
FIGURE 23 - Exemple d'un diagramme de
workflow: Processus d'expédition d'une commande
Les principaux éléments d'un diagramme de workflow
sont:
-- L'événement de début (cercle
vert)
-- L'événement de fin (cercle rouge)
-- Les activités (rectangles gris)
-- Les passerelles OR (losanges vides)
-- Les passerelles AND (losanges marqués du signe
+)
La réalisation d'un diagramme de workflow peut être
perçue de façon générique
comme un assemblage des différents éléments
cités ci-dessus.
III.3.2. Conversion d'une spécification
non-récursive
Principe de l'algorithme de
conversion
Pour pouvoir quitter d'un GMWf vers un diagramme de workflow
équivalent, nous nous sommes inspirés des constructions de
Thompson [48] qui permettent de quitter d'une expression
régulière vers un automate non déterministe
équivalent.
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
III.3. PRINCIPE DE CONVERSION D'UN GMWF EN UN DIAGRAMME DE
WORKFLOW
ÉQUIVALENT 46
L'algorithme de Thompson fonctionne de manière
récursive en divisant une expression en ses sous-expressions
constitutives, à partir desquelles l'automate sera construit
à l'aide d'un ensemble de règles(symbole, union,
concaténation) [49].
Notre algorithme se fonde sur un ensemble de similitudes
observées entre les règles de construction de Thompson et
l'assemblage des composants d'un diagramme de workflow. Ces similitudes sont
résumées dans la figure ci-dessous.
FIGURE 24 - Équivalence entre les
règles de Thompson et les diagrammes de workflows
Conversion des spécifications non
récursives
À l'aide des similitudes observées entre les
constructions de Thompson et les diagrammes de workflows, nous
définissons des fonctions prenant comme paramètres
d'entrée des éléments d'un GMWf et renvoyant en
sortie un diagramme de workflow. Ces fonctions une fois
combinées jouent le même rôle que les règles de
Thompson, en permettant de construire le diagramme de workflow
équivalent d'un GMWf. Nous en proposons six, pour la conversion des
specifications non récursives:
1 - La fonction DIAGM
La fonction DIAGM (Diagram Minimun) nous permet
d'obtenir le diagramme de workflow minimal d'une tache provenant du
GMWf.
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
III.3. PRINCIPE DE CONVERSION D'UN GMWF EN UN DIAGRAMME DE
WORKFLOW
ÉQUIVALENT 47
Définition 5 .
2 - La fonction
OR
La fonction OR nous permet de représenter une
alternative dans le diagramme de workflow.
Définition 6 Soit (G1,G2,G3,...,GN)
des Graphes (diagrammes de workflows):
1. OR(G1)=G1
2. OR(G1,G2,G3,...,GN) = G
3. OR(NULL,NULL,...,NULL) = NULL
3 - La fonction
AND
La fonction AND nous permet de représenter une
exécution parallèle dans le diagramme de workflow.
III.3. PRINCIPE DE CONVERSION D'UN GMWF EN UN DIAGRAMME DE
WORKFLOW
ÉQUIVALENT 48
Définition 7 Soit (G1,G2,G3,...,GN)
des Graphes (diagrammes de workflows):
1. AND(G1) = G1
2. AND(G1,G2,G3,...,GN) = G
3. AND(NULL,NULL,...,NULL) = NULL
4 - La fonction
CONCAT
La fonction CONCAT nous permet de
concaténer deux ou plusieurs diagrammes de workflow.
Définition 8 Soit (G1,G2,G3,...,GN)
des Graphes (diagrammes de workflows):
1. CONCAT(G1,G2,...,GN) = G
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
III.3. PRINCIPE DE CONVERSION D'UN GMWF EN UN DIAGRAMME DE
WORKFLOW
ÉQUIVALENT 49
Remarque : CONCAT concaténe
deux graphes si et seulement si le premier d'entre eux se termine. Sinon, il
retourne une erreur.
5 - Les fonctions DIAGR et DIAG
La fonction DIAGR (Diagram Right)
nous permet d'obtenir le diagramme de workflow complet, de la
partie droite d'une production de l'ensemble
P du GMWf.
La fonction DIAG quant à
elle, nous permet d'obtenir le diagramme de workflow complet
d'une tache. Ce diagramme démarre sur la tache en
entrée et s'achève lorsque tous les successeurs de la tache ont
été exécutés.
|
Définition 9
DIAGR(cx) =
Définition 10
|
?
???
???
|
E si, cx = E
CONCAT({DIAG(Xi)}1=
i = n)
si, cx = X1;
...;Xn
AND({DIAG(Xi)}1=
i = n)
si, cx = X1 || ... ||
Xn
|
|
DIAG(A)
=
|
?
??????
??????
|
E si, A =
E
CONCAT (
DIAGM(A), P1 :
A ?
X1;...;Xn
OR({DIAGR(rhs(Pi))}1=
i = n)
ou, P2 : A
? X1||..||Xn
...
) Pn : A
? ...
|
A partir du principe de fonctionnment de la fonction
DIAG, l'on déduit que pour obtenir le
diagramme de workflow d'un GMWf, il nous suffit de
déterminer:
OR
({DIAG(Ai)})
avec Ai les elements de A
Propriétés de la formule de
conversion
-- Le diagramme de workflow final retourné
par notre formule de conversion est un diagramme de workflow
structuré.
Démonstration : Les
fonctions de base (DIAGM, OR, AND,
CONCAT) de notre formule de conversion retourne toujours un
diagramme de workflow structuré en sortie; car elles lient chaque
passerelle ouvrante qu'elles créent à une passerelle fermante du
même type. Par induction structurelle, la
composition (ou combinaison) de ces fonctions retournera toujours un
worklow structuré. Raison pour laquelle les
fonctions DIAG et DIAGR
retournent elles aussi des diagrammes de workflows
structurés.
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO
URIFIA
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
III.3. PRINCIPE DE CONVERSION D'UN GMWF EN UN DIAGRAMME DE
WORKFLOW
ÉQUIVALENT 50
Conclusion: Sachant que le diagramme de workflow final
est déduit de la formule OR ({DIAG(Ai)}),
on conclut que tout diagramme de workflow retourné par
notre formule est structuré.
III.3.3. Conversion d'une spécification
récursive
La formule de conversion actuelle souffre d'une grosse limite.
Lors de la conversion d'une spécification LSAWfP dans laquelle un des
artefacts représentatifs est récursif, la formule entre dans une
boucle infinie pendant le calcul de OR ({DIAG(Ai)}). La
récursivité étant un concept clé et largement
rencontré au sein des processus administratifs, il est impératif
de pouvoir les prendre en charge au cours de la conversion des
spécifications. C'est cette principale raison qui nous pousse à
effectuer des ajustements sur la formule actuelle afin qu'elle puisse
parfaitement convertir des spécifications LSAWfP récursives.
Introduction de nouveaux éléments lors du
procédé de conversion
Pour que la conversion des spécifications
récursives puisse être possible, de nouveaux
éléments doivent être pris en compte lors du
procédé de conversion de ces spécifications. En effet, la
boucle infinie à laquelle on fait face lors de la conversion
résulte de notre incapacité à identifier chaque tache de
façon unique afin de déterminer si oui ou non, elle est
déjà en cours de conversion. Pour corriger cela, nous
introduisons:
-- Un adressage unique de chaque tache de nos
artefacts représentatifs
Ceci est fait dans le but d'identifier les taches
récurrentes c'est-à-dire les taches déjà en cours
de conversion. Cet adressage sera fait a l'aide de l'annotation de Dewey
[50].
-- Un historique des taches traitées lors
du parcours d' un chemin de l'artefact
Lorsqu'une tache sera en cours de conversion, elle sera
directement transmise à tous ses fils comme historique afin que ceux-ci
ne refassent plus son calcul s'ils la rencontrent une seconde fois. Cette
approche nous évite d'entrer dans une boucle infinie, car lors de la
rencontre d'une tache déjà en cours de conversion, une annotation
sera marquée sur la tache précédant sa seconde instance.
Ceci dans le but de représenter la relation ittérative
existante entre elle et la tache en cours de conversion.
III.3. PRINCIPE DE CONVERSION D'UN GMWF EN UN DIAGRAMME DE
WORKFLOW
ÉQUIVALENT 51
Une annotation peut tout simplement être perçue
comme un lien implicite entre deux éléments.
Redéfinition des différentes fonctions
de conversion
L'introduction de l'historique et de l'adressage nous conduit
à une redéfinition des fonctions précédemment
citées. On passe de 6 à 7 fonctions de conversion. Nous avons:
1 - Redéfinition de la fonction
DIAGM
La fonction DIAGM (Diagram Minimun) nous permet
d'obtenir le diagramme de workflow annoté minimal d'une tache
provenant du GMWf.
Définition 11 .
2 - Redéfinition de
la fonction OR
La fonction OR nous permet de représenter une
alternative dans le diagramme de workflow annoté.
Définition 12 Soit
(G1,L1);(G2,L2);...;(GN,LN) des couples de (Graphes, Liste Annotations) avec
L1,...,LN des listes contenant les annotations des éléments
récursifs (éléments en cours de conversion) faisant partie
des alternatives de la fonction OR :
1. OR((A,B)) = (A,B)
2. OR((NULL,L1);(NULL,L2);...;(NULL,LN)) = (G,NULL)
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
3. OR((G1,L1);(G2,L2);...;(GN,LN)) = (G,NULL)
III.3. PRINCIPE DE CONVERSION D'UN GMWF EN UN DIAGRAMME DE
WORKFLOW
ÉQUIVALENT 52
3 - Redéfinition de
la fonction AND
La fonction AND nous permet de représenter une
exécution parallèle dans le diagramme de workflow
annoté.
Définition 13 Soit
(G1,L1);(G2,L2);...;(GN,LN) des couples de (Graphes, Liste Annotations) avec
L1,...,LN des listes contenant les annotations des éléments
récursifs (éléments en cours de conversion) faisant parti
des taches à exécuter simultanément:
1.
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
AND((A,B)) = (A,B)
2. AND((NULL,L1);(NULL,L2);...;(NULL,LN)) =
(G,NULL)
3. AND((G1,L1);(G2,L2);...;(GN,LN)) = (G,NULL)
III.3. PRINCIPE DE CONVERSION D'UN GMWF EN UN DIAGRAMME DE
WORKFLOW
ÉQUIVALENT 53
4 - La fonction
JOIN
La fonction JOIN nous permet de concaténer un
graphe non vide et un graphe annoté.
Définition 14 Soit G1 un graphe non
annoté et (G2,L2) un couple (Graphes, Liste Annotations) avec L2 une
liste contenant les annotations des éléments récursifs
exécutés avant G2 :
1. JOIN(G1,(G2,L2)) = (G,NULL)
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
Remarque : JOIN concaténe deux graphes si et
seulement si le premier d'entre eux se termine. Sinon, il retourne une
erreur.
III.3. PRINCIPE DE CONVERSION D'UN GMWF EN UN DIAGRAMME DE
WORKFLOW
ÉQUIVALENT 54
5 - Redéfinition de la fonction CONCAT
La fonction CONCAT nous permet de
concaténer deux ou plusieurs diagrammes de workflows
annotés.
Elle consiste en une jointure deux à deux, des
différents graphes annotés pris en paramètres. La fonction
CONCAT s'arrête lorsqu'elle a joint tous les graphes, et renvoie
une erreur si elle rencontre une liste non vide d'annotations avant le dernier
paramètre.
Définition 15 Soit
(G1,L1);(G2,L2);...;(GN,LN)
des couples de (Graphes, Liste Annotations) avec Lk la liste contenant les
annotations des éléments récursifs qu'on exécute
avant Gk :
1.
CONCAT((G1,L1);(G2,L2);...;(GN,LN))
= (G,NULL)
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
6 - Redéfinition des fonctions DIAGR et DIAG
La fonction DIAGR (Diagram Right) nous permet
d'obtenir le diagramme de workflow annoté complet, de la partie
droite d'une production de l'ensemble P du GMWf.
La fonction DIAG quant à elle, nous permet
d'obtenir le diagramme de workflow annoté complet d'une tache.
Ce diagramme démarre sur la tache en entrée et s'achève
lorsque tous les successeurs de la tache ont été
exécutés.
Définition 16
|
DIAGR(a,u,H) =
|
?
???
???
|
E si, a = E
CONCAT({DIAG(Xi,u.i,H)}1< i < n)
si, a = X1; ...;Xn
AND({DIAG(Xi,u.i,H)}1< i < n) si, a
= X1 || ... || Xn
|
III.4. FONCTION D'EXPORT DE LSAWFP VERS LE BPMN XML 2.0 55
Définition 17
DIAG(X,u,H) =
?
????????????? ?
??????????????
å si, A = å
JOIN ( P1 : A --*
X1;...;Xn
DIAGM(X,u), P2 : A --*
X1||..||Xn
...
...
...
OR(
{DIAGR(rhs(Pi),u,H
u(X,u))}1< i < n ou,
)
) Pn : A --* ...
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
A partir du principe de fonctionnment de la fonction
DIAG, l'on déduit que pour obtenir le diagramme de workflow
d'un GMWf, il nous suffit de déterminer:
|
({ ( )} )
G = OR DIAG Ai,i,[ i avec Ai les elements
de A
i
|
Puis d'appliquer un post-traitement sur le diagramme
de workflow annoté complet G. Il aura pour but de remplacer les
annotations par des liens explicites vers les différentes taches
récursives de notre diagramme.
III.4. Fonction d'export de LSAWfP vers le BPMN XML
2.0
Lorsqu'on applique notre formule de conversion à un
GMWf, on obtient en sortie un diagramme de workflow qui n'est propre à
aucun langage de workflow. Il contient l'ensemble des taches du processus et
leurs relations de précédence. Il peut par conséquent
être sérialisé dans un langage de workflow
spécifique afin d'obtenir le modèle de workflow du processus dans
ce langage. Dans le cadre de notre étude, nous sérialisons ce
diagramme afin d'obtenir en sortie une spécification BPMN sous le format
BPMN XML 2.0. Cette sérialisation fait office de
fonctionnalité d'export dans LSAWfP Editor.
FIGURE 25 - Fonctionnalité d'export
dans LSAWfP Editor
III.5. CONCLUSION 56
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
Il devient à présent possible de
spécifier un processus à l'aide de LSAWfP dans LSAWfP Editor,
puis l'exporter en BPMN sous le format BPMN XML 2.0 et enfin le visualiser dans
un autre outil de spécification. À titre d'illustration, on peut
observer le résultat de l'export de notre exemple courant
spécifié sur LSAWfP Editor. Le fichier obtenu est
visualisé sur l'outil
BPMN.io, et on constate que son flot de
contrôle est en tout point identique au modèle que nous avons
spécifié manuellement dans la section portant sur le BPMN (voir
sec. I.3.2.1).
FIGURE 26 - Visualisation du modèle
BPMN généré par LSAWfP Editor sur
BPMN.io
LSAWfP Editor devient ainsi interopérable avec
les autres outils de modélisation déjà existants qui
permettent d'exécuter ou visualiser des spécifications BPMN.
III.5. Conclusion
Dans ce dernier chapitre portant sur la facilitation de la
spécification des processus administratifs avec une approche
orientée scénario, nous avons présenté LSAWfP
Editor, un outil d'aide à la spécification des processus
modélisés avec LSAWfP. L'outil proposé tire ses
fonctionnalités principales d'une revue des outils existants de
spécification. Il propose notamment une large palette d'outils
permettant une parfaite modélisation graphique des processus LSAWfP. Il
permet en plus la sauvegarde graphique et la visualisation des
spécifications,
CONCLUSION GÉNÉRALE 57
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
ce qui conduit à la fonctionnalité de partage de
ces dernières. Il offre enfin une fonctionnalité d'export vers un
format que nous proposons; ceci dans le but d'assurer
l'interopérabilité entre lui, les outils actuels et les
éventuels outils qui seront créés dans le cadre du projet.
Notre seconde contribution a été l'établissement d'une
formule mathématique permettant de convertir des GMWf en diagramme de
workflow. Une application de cette formule a été faite et
proposée sous forme de fonctionnalité dans LSAWfP Editor:
L'export vers le BPMN XML 2.0. Elle a été testée à
travers l'export de notre exemple courant. Nous avons obtenu un diagramme
d'orchestration BPMN généré équivalent à
celui que nous avions spécifié manuellement; d'où
l'interopérabilité effective entre LSAWfP Editor et les autres
outils de spécification.
58
CONCLUSION GÉNÉRALE
SOMMAIRE
Problématique étudiée et bilan 58
Analyse critique des résultats obtenus 59
Quelques perspectives 59
Nous allons pour conclure, rappeler la problématique
abordée dans ce mémoire, ensuite présenter les grandes
lignes de la solution proposée, ainsi que ses limitations et les
critiques qu'il convient d'en faire. Nous terminerons par la
présentation de quelques perspectives pouvant faire l'objet des travaux
futurs.
Problématique étudiée et
bilan
Dans ce mémoire, nous nous sommes
intéressés à l'automatisation des processus
opérationnels en utilisant les outils technologiques offerts par le BPM
(langage de modélisation, WfMS). Nous avons contribué à
l'ambition de rendre plus accessible, l'automatisation des processus
opérationnels à travers une approche grammaticale grâce
à cette technologie. Ceci dans le but d'accroître son
succès dans les secteurs d'activité utilisant des processus
administratifs, comme ce fut le cas dans d'autres secteurs (banques,
assurances, etc.). Nous avons principalement été guidés
par l'objectif de faciliter autant que faire se peut la modélisation des
processus administratifs avec une approche orientée scénario.
Pour ce faire nous avons proposé un outil
interopérable d'aide à la spécification des processus
LSAWfP. Nous avons opéré les mêmes choix
méthodologiques que ceux opérés dans [51]. Ces choix ont
été : l'étude minutieuse du langage (LSAWfP dans notre
cas) et une revue des fonctionnalités offertes par les outils de
spécification existants. Cette méthodologie nous a conduit
à la production de LSAWfP Editor, un outil d'aide à la
spécification des processus administratifs avec une approche
orientée scénario. Nous avons ensuite établi une
formule
QUELQUES PERSPECTIVES 59
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
de conversion des spécifications LSAWfP. Cette formule
a été redéfinie afin de pouvoir supporter les conversions
dans lesquelles figurent des artefacts représentatifs récursifs.
Pour terminer, nous avons proposé une application de cette formule de
conversion : une fonction d'export vers le BPMN XML 2.0. L'outil de
modélisation a été testé en l'utilisant pour la
spécification du processus de pré-soutenance d'une thèse
de PhD dans notre université. Le processus a été
parfaitement spécifié; son modèle sauvegardé et
partagé. La fonction d'export a elle aussi été
testée. Elle a été entièrement satisfaisante, car
notre exemple courant spécifié avec LSAWfP puis converti en BPMN
XML 2.0 a eu un flot de contrôle identique à celui que nous avons
spécifié manuellement en BPMN dans Bizagi Modeler.
Analyse critique des résultats obtenus
D'après nos expérimentations, l'outil
proposé est capable de modéliser n'importe quel processus
administratif sachant que ces derniers ont un nombre de scénarios et de
taches constant. La formule de conversion quant à elle est capable de
convertir n'importe quelle spécification LSAWfP (des plus simples ne
possédant aucun symbole de restructuration aux plus complexes qui
contiennent plusieurs taches récursives et des dizaines de symboles de
restructuration) en un diagramme de workflow équivalent, tant que cette
spécification est bien définie. La fonction d'export ne retourne
aucun résultat lorsque la spécification LSAWfP passée en
paramètre n'a pas de diagramme d'orchestration équivalent en
BPMN. Une étude approfondie doit être menée pour identifier
avec certitude ce genre de cas. Il reste malgré tout difficile de mener
une évaluation théorique de nos résultats sachant que
notre travail est centré sur le procédé de
spécification des processus.
Quelques perspectives
Le présent travail ouvre la voie à un ensemble
de travaux futurs qui pourraient faire l'objet d'études plus
approfondies. Nous pouvons citer entre autres :
-- Preuves mathématiques de l'equivalence de notre
formule de conversion : présenter les preuves mathématiques de la
validité des fonctions de conversions proposées ainsi qu'une
étude de leur complexité.
-- Fonction d'import des spécifications BPMN et YAWL
vers LSAWfP : afin de rendre notre outil entièrement
interopérable, en plus de la fonction
QUELQUES PERSPECTIVES 60
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
d'export, LSAWfP Editor doit embarquer une fonction d'import
des spécifications existantes vers notre langage de
modélisation.
Dans le cadre global de notre projet, des perspectives de
recherches peuvent également être faites. Nous avons
principalement:
-- Une méthodologie générale de
modélisation des processus avec une approche orientée
scénario
61
BIBLIOGRAPHIE
[1] Van Der Aalst WMP. Business Process Management : A
Comprehensive Survey. ISRN Software Engineering. 2013 Feb;2013 :507984.
Available from:
https://doi.org/10.1155/2013/507984.
[2] Van Der Aalst WMP. The application of petri nets to
workflow management. Journal of Circuits, Systems and Computers. 1998;08(01)
:21-66. Available from:
https://doi.org/10.1142/S0218126698000043.
[3] Frederiks PJM, van der Weide TP. Information modeling :
The
process and the required competencies of its participants. Data
&
Knowledge Engineering. 2006;58(1) :4-20. Application of
natural language to information systems (NLDB04). Available from :
https://www.
sciencedirect.com/science/article/pii/S0169023X05000753.
[4] Corradini F, Polini A, Re B. Inter-organizational
business process verification in public administration. Business Process
Management Journal. 2015 09;21 :1040-65.
[5] Acu B, Reisig W. Compensation in Workflow Nets. In :
Donatelli S, Thiagarajan PS, editors. Petri Nets and Other Models of
Concurrency - ICATPN 2006, 27th International Conference on Applications and
Theory of Petri Nets and Other Models of Concurrency, Turku, Finland, June
2630, 2006, Proceedings. vol. 4024 of Lecture Notes in Computer Science.
Springer; 2006. p. 65-83. Available from :
https://doi.org/10.1007/
11767589_5.
[6] van der Aalst WMP, Aldred L, Dumas M, ter Hofstede AHM.
Design and Implementation of the YAWL System. In : Persson A, Stirna J,
editors. Advanced Information Systems Engineering, 16th International
Conference, CAiSE 2004, Riga, Latvia, June 7-11, 2004, Proceedings. vol. 3084
of Lecture Notes in Computer Science. Springer; 2004. p. 142-59. Available
from:
https://doi.org/10.1007/978-3-540-25975-6_12.
[7]
BIBLIOGRAPHIE 62
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
Kiepuszewski B, ter Hofstede AH, van der Aalst WM.
Fundamentals of control flow in workflows. Acta Informatica. 2003;39(3)
:143-209. Available from:
https://doi.org/10.1007/s00236-002-0105-4.
[8] Zekeng Ndadji MM, Tchoupé Tchendji M, Tayou
Djamegni C, Parigot D. A Language and Methodology based on Scenarios, Grammars
and Views, for Administrative Business Processes Modelling. CoRR.
2020;abs/2010.13347. Available from:
https://arxiv.org/abs/2010.13347.
[9] Zekeng Ndadji MM. A grammatical approach to peer-to-peer
cooperative editing on a service-oriented architecture [Ph.D. thesis]. Dschang
: University of Dschang; 2021. Available from :
https://arxiv.org/abs/2106.00041.
[10] Zekeng Ndadji MM, Tchoupé Tchendji M, Tayou
Djamegni C, Parigot D. A Projection-Stable Grammatical Model for the
Distributed Execution of Administrative Processes with Emphasis on Actors'
Views. CoRR. 2021 02;abs/2102.10566. Available from :
https://arxiv.org/abs/2102.
10566.
[11] Zekeng Ndadji MM, Tchoupé Tchendji M, Tayou
Djamegni C, Parigot D. A Language for the Specification of Administrative
Workflow Processes with Emphasis on Actors' Views. In : ICCSA 2020 - 20th
International Conference on Computational Science and Its Applications. vol.
12254 of Lecture Notes in Computer Science. Cagliari, Italy: Springer; 2020. p.
231-45. Available from:
https://hal.archives-ouvertes.fr/hal-02968427.
[12] Tchoupé Tchendji M, Djeumen R, Atemkeng M. A
Stable and Consistent Document Model Suitable for Asynchronous Cooperative
Edition. Journal of Computational Chemistry. 2017;05 :69-82.
[13] Georgakopoulos D, Hornick M, Sheth A. An overview of
workflow management: From process modeling to workflow automation
infrastructure. Distributed and Parallel Databases. 1995 Apr;3(2) :119-53.
Available from:
https://doi.org/10.1007/BF01277643.
[14] OMG. Business Process Model and Notation (BPMN), Version
2.0.2; 2013. Available from:
http://www.omg.org/spec/BPMN/2.0.2.
[15] Van Der Aalst WM, Ter Hofstede AH. YAWL : yet another
workflow language. Information systems. 2005;30(4) :245-75.
[16] Jeston J, Nelis J. Business Process Management :
Practical Guidelines to Successful Implementations. Routledge; 2014. Available
from : https: //
books.google.cm/books?id=kQNcMAEACAAJ.
[17] BIBLIOGRAPHIE 63
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO
URIFIA
Hollingsworth D, Hampshire U. Workflow management coalition :
The workflow reference model. Document Number TC00-1003.
1995;19(16) :224.
[18] Dumas M, Rosa ML, Mendling J, Reijers HA. Fundamentals of
Business Process Management. 2nd ed. Springer Publishing Company, Incorporated;
2018.
[19] Van Der Aalst WMP, La Rosa M, Santoro FM. Business
Process
Management. Business & Information Systems Engineering.
2016
Feb;58(1) :1-6. Available from :
https://doi.org/10.1007/
s12599-015-0409-x.
[20] Imine A. Conception Formelle d'Algorithmes de
Réplication Optimiste Vers l'Edition Collaborative dans les
Réseaux Pair-à-Pair [Theses]. Nancy 1, France : Université
Henri Poincaré; 2006.
[21] Chaâbane M, Bouzguenda L, Bouaziz R, Gargouri F.
Spécification des processus workflows évolutifs
versionnés. Schedae Informaticae. 2021 06 :21-9.
[22] Zekeng Ndadji MM. Réconciliation par consensus
des mises à jour des répliques partielles d'un document
structuré. [Master]. University of Dschang; 2016.
[23] Eric B, Hélouët L, Kouamou GE, Morvan C. A
Grammatical Approach to Data-centric Case Management in a Distributed
Collaborative Environment. In : The 30th ACM/SIGAPP Symposium On Applied
Computing. The 30th ACM/SIGAPP Symposium On Applied Computing. Salamanca, Spain
:
ACM; 2015. p. 1834-9. Available from :
https://hal.inria.fr/
hal-01193222.
[24] Romdhani I, Tawse M, Habibullah S. Student project
performance
management system for effective final year and dissertation
projects supervision. London, Uk. Infonomics Society; 2011. Available from:
http: //
researchrepository.napier.ac.uk/id/eprint/4711.
[25] Yan Y, Han X, Yang J, Zhou Q. On the Design of an
Advanced Web-Based System for Supporting Thesis Research Process and Knowledge
Sharing. Journal on Educational Technology. 2012;5 :9.
[26] Sehurutshi B, Eyitayo OT. A Collaborative Tool for
MPhil/PhD Student Dissertation Workflow. Edited by Oduronke Eyitayo George
Anderson. 2016 :22.
[27]
BIBLIOGRAPHIE 64
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
McCready S. There is more than one kind of workflow software.
Computerworld. 1992;Nov. 2. Available from : https://ci.nii.ac.jp/
naid/10004324449/en/.
[28] Boukhedouma S. Adaptation et restructuration de
modèles de processus Worflow dans un contexte inter-organisationnel.
(Adaptation and restructuring of Workflow process models in an
inter-organizational context) [Theses]. University of Nantes, France; 2015.
Available from :
https://tel.archives-ouvertes.fr/tel-01688142.
[29] Juve G, Chervenak A, Deelman E, Bharathi S, Mehta G,
Vahi
K. Characterizing and profiling scientific workflows.
Future
Generation Computer Systems. 2013;29(3) :682-92. Special Section :
Recent Developments in High Performance Computing and Security. Available from
:
https://www.sciencedirect.com/science/article/
pii/S0167739X12001732.
[30] Piccinelli, Finkelstein, Williams. Service-oriented
workflow : the DySCo framework. In : 2003 Proceedings 29th Euromicro
Conference; 2003. p. 2917.
[31] Eder J, Gruber W. A Meta Model for Structured Workflows
Supporting Workflow Transformations. In : Manolopoulos Y, Navrat P, editors.
Advances in Databases and Information Systems. Berlin, Heidelberg : Springer
Berlin Heidelberg; 2002. p. 326-39.
[32] Kiepuszewski B, ter Hofstede AHM, Bussler CJ. On
Structured Workflow Modelling. In : Wangler B, Bergman L, editors. Advanced
Information Systems Engineering. Berlin, Heidelberg: Springer Berlin
Heidelberg; 2000. p. 431-45.
[33] Liu R, Kumar A. An Analysis and Taxonomy of Unstructured
Workflows. In : van der Aalst WMP, Benatallah B, Casati F, Curbera F, editors.
Business Process Management. Berlin, Heidelberg: Springer Berlin Heidelberg;
2005. p. 268-84.
[34] Baier C, Katoen JP. Principles of Model Checking
(Representation and Mind Series). The MIT Press; 2008.
[35] Biazzo S. Approaches to business process analysis : a
review. Business process management journal. 2000.
[36]
BIBLIOGRAPHIE 65
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
Muehlen Mz, Recker J. In : How Much Language Is Enough?
Theoretical and Practical Use of the Business Process Modeling Notation.
Berlin, Heidelberg: Springer Berlin Heidelberg; 2013. p. 429-43. Available
from:
https://doi.
org/10.1007/978-3-642-36926-1_35.
[37] Grigori D. Eléments de flexibilité des
systèmes de workflow pour la définition et l'exécution de
procédés coopératifs [Theses]. Université Henri
Poincaré - Nancy 1, France; 2001. Available from :
https://hal.univ-lorraine.
fr/tel-01748094.
[38] Divitini M, Hanachi C, Sibertin-Blanc C. In :
Inter--Organizational Workflows for Enterprise Coordination. Berlin,
Heidelberg: Springer Berlin Heidelberg; 2001. p. 369-98. Available from:
https://doi.org/10.1007/
978-3-662-04401-8_15.
[39] Hull R, Narendra NC, Nigam A. Facilitating Workflow
Interoperation Using Artifact-Centric Hubs. In : Baresi L, Chi CH, Suzuki J,
editors. Service-Oriented Computing. Berlin, Heidelberg: Springer Berlin
Heidelberg; 2009. p. 1-18.
[40] Business Process Modeling : Definition, Why, Technique
and Benefits; 2019. Accessed : 2021-06-18.
https://kissflow.com/workflow/bpm/
business-process-modeling/. Available from :
https://kissflow.
com/workflow/bpm/business-process-modeling/.
[41] Weske M. Business Process Management : Concepts,
Languages,
Architectures. Berlin, Heidelberg: Springer-Verlag; 2007.
[42] Thiagarajan RK, Srivastava AK, Pujari AK, Bulusu VK.
BPML : a process modeling language for dynamic business models. In :
Proceedings Fourth IEEE International Workshop on Advanced Issues of E-Commerce
and Web-Based Information Systems (WECWIS 2002); 2002. p. 222-4.
[43] Simpson R. An Xml Representation for Crew Procedures
Final Report Nasa Faculty Fellowship Program -2004; 2005..
[44] Hofstede AHMt, Kiepuszewski B. Formal Analysis of
Deadlock Behaviour in Workflows. Technical report, Queensland University of
Technology/Mincom, Brisbane...; 1999.
[45] Tchoupé Tchendji M, Zekeng Ndadji MM. Tree
Automata for Extracting Consensus from Partial Replicas of a Structured
Document. Journal of Software Engineering and Applications. 2017;10(05)
:432-56. Available from:
http://dx.doi.org/10.4236/jsea.2017.105025.
[46]
BIBLIOGRAPHIE 66
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO
URIFIA
Bizagi Modeler; 2021. Accessed : 2021-06-28.
https://www.bizagi.com/ en/platform/modeler. Available from :
https://www.bizagi.com/en/
platform/modeler.
[47] Adams M, Hense AV, ter Hofstede AHM. YAWL : An open
source Business Process Management System from science for science. SoftwareX.
2020;12 :100576. Available from : https://www.sciencedirect.com/
science/article/pii/S2352711020302892.
[48] Thompson K. Programming Techniques : Regular Expression
Search Algorithm. Commun ACM. 1968 Jun;11(6) :419-22. Available from :
https://doi.org/10.1145/363347.363387.
[49] Aho AV, Lam MS, Sethi R, Ullman JD. Compilers :
Principles, Techniques, and Tools (2nd Edition). USA : Addison-Wesley Longman
Publishing Co., Inc.; 2006.
[50] Tatarinov I, Viglas SD, Beyer K, Shanmugasundaram J,
Shekita E, Zhang C. Storing and querying ordered XML using a relational
database system. In : Proceedings of the 2002 ACM SIGMOD international
conference on Management of data; 2002. p. 204-15.
[51] Brambilla M, Butti S, Fraternali P. Webratio bpm : a
tool for designing and deploying business processes on the web. In :
International Conference on Web Engineering. Springer; 2010. p. 415-29.
67
ANNEXE
PRÉSENTATION DU CONTENU DES
FICHIERS GÉNÉRÉS PAR LSAWFP
EDITOR
Dans cette annexe, nous présentons des extraits de
fichiers générés par notre outil. Nous commençons
par le contenu du fichier de sauvegarde graphique (.ggmawfp) de notre
exemple courant. Nous présentons par la suite, le DSEL JSON que
nous avons proposé pour la sauvegarde des spécifications dans un
format interopérable, pour l'ensemble des outils du projet. À
titre illustratif, nous présentons le fichier de sauvegarde
interopérable (.gmawfp) de notre exemple courant. Nous
terminons par la présentation d'un extrait du fichier BPMN XML 2.0
de cet exemple, généré après export sur LSAWfP
Editor.
Extrait du fichier de sauvegarde graphique
|
1
2
3
|
"scenarios": [
{
"id": 1,
|
|
|
|
|
|
|
4
|
"name": "scen-min",
|
|
|
|
|
|
|
5
|
"beingEditedNode": {
|
|
|
|
|
|
|
6
|
"task": {
|
|
|
|
|
|
|
7
|
"symbol": "D",
|
|
|
|
|
|
|
8
9
|
"desc": "Redaction
renvoi a l' ED",
"type": "Classic"
|
du
|
motif
|
de
|
rejet
|
et
|
|
10
|
},
|
|
|
|
|
|
|
11
|
"status": "Closed",
|
|
|
|
|
|
|
12
|
"production": {
|
|
|
|
|
|
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO
URIFIA
13
|
14
15
|
PRESENTATION DU DSEL JSON
|
|
68
|
|
|
|
|
"prodName": "",
"prodLhs": "S2",
"prodRhs": {
|
|
|
|
16
|
"rhsType": "Sequential",
|
|
|
|
17
|
"rhsSymbols": [1
|
|
|
|
18
|
}
|
|
|
|
19
|
},
|
|
|
|
20
|
"sons": [1
|
|
|
|
21
|
},
|
|
|
|
22
|
"task": {
|
|
|
|
23
|
"symbol": "A",
|
|
|
|
24
25
|
"desc": "Constitution et soumission
de presoutenance a l' ED",
"type": "Classic"
|
du
|
dossier
|
|
26
|
},
|
|
|
|
27
|
"status": "Closed",
|
|
|
|
28
|
"production": {
|
|
|
|
29
|
"prodName": "",
|
|
|
|
30
|
"prodLhs": "S0",
|
|
|
|
31
|
"prodRhs": {
|
|
|
|
32
|
"rhsType": "Sequential",
|
|
|
|
33
|
"rhsSymbols": [1
|
|
|
|
34
|
}
|
|
|
|
35
|
},
|
|
|
Dans ce fichier, on remarque la présence
d'éléments tels que "scenarios", "beignEditedNode" et
"sons" qui n'appartiennent pas aux éléments constituant
un GMAWfP. Ils ont pour rôle de restituer les éléments
graphiques (artefacts représentatifs, noeuds édités, etc.)
lors de l'ouverture du fichier.
Presentation du DSEL JSON
|
1
|
enum
|
TaskType {
|
|
|
|
2
|
|
TASK_TYPE_CLASSIC
|
=
|
"Classic",
|
|
3
|
|
TASK_TYPE_VIRTUAL
|
=
|
"Virtual"
|
|
4
|
}
|
|
|
|
|
5
|
|
|
|
|
PRESENTATION DU DSEL JSON 69
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO
URIFIA
6 enum ProductionType {
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
PRODUCTION_TYPE_ SEQ = "Sequential",
|
|
PRODUCTION_TYPE_ PAR = "Parallel", PRODUCTION_TYPE_ NONE =
"None", PRODUCTION_TYPE_ EPS = "Epsilon"
}
interface PeerToPeerWorkflow { grammaticalModelOfWorkflow:
GrammaticalModelOfWorkflow , accreditations?: Map<String ,
Accreditation>, stakeholders?: Stakeholder[]
}
interface GrammaticalModelOfWorkflow { tasks: Task[],
axioms: String[],
productions: Production[]
}
interface Accreditation { readable: String[], writable: String[],
executable: String[]
}
interface Stakeholder { id: String,
desc?: String
}
interface Task { symbol: String, desc?: String, status?: String,
type: TaskType
}
|
|
EXTRAIT DU FICHIER .GMWAFP DE NOTRE EXEMPLE 70
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
interface Production { prodName: String, prodLhs: String,
prodRhs: ProductionRhs
}
interface ProductionRhs {
rhsType: ProductionType ,
rhsSymbols?: String[]
}
42
43
44
45
46
47
48
49
50
51
52
Ce DSEL contient uniquement l'ensemble des
éléments requis pour une spécification LSAWfP, et il les
matérialise à l'aide des types offerts par le TypeScript. Avec ce
dernier, l'on dispose d'une syntaxe claire et précise, nous
fournissant tous les éléments nécessaires pour
spécifier un processus avec LSAWfP. Le format .gmwafp
(basé sur ce DSEL) est donc parfaitement approprié pour
assurer l'interopérabilité entre les différents outils du
projet, sachant que contrairement au format .ggmawfp, il embarque
uniquement en son sein les éléments propres au GMAWfP.
{
"grammaticalModelOfWorkflow":{
"tasks":[
{
"symbol":"A",
"desc":"",
"type":"Classic"
},
{
"symbol":"B",
"desc":"",
"type":"Classic"
},
{
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Extrait du fichier .gmwafp de notre exemple
EXTRAIT DU FICHIER BPMN XML 2.0
GÉNÉRÉ 71
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO
URIFIA
"symbol":"C", "desc":"",
"type":"Classic"
},
{
"symbol":"D",
15
16
17
18
19
20
Comme le DSEL, ce fichier se divise en 3 principaux
éléments : le "grammaticalModelOfWorkflow", les
"accreditations" et les "stakeholders".
Extrait du fichier BPMN XML 2.0
généré
|
<?xml version="1.0" encoding="UTF -8"?>
<bpmn:definitions xmlns:bpmn="
http://www.omg.org/spec/
BPMN/20100524/MODEL" xmlns:bpmndi="http ://
www.omg.
org/spec/BPMN/20100524/DI" xmlns:dc="http ://
www.omg.
org/spec/DD/20100524/DC" xmlns:di="http ://
www.omg.
org/spec/DD/20100524/DI" xmlns:xsd="http ://
www.w3.
org/2001/XMLSchema" xmlns:xsi="
http://www.w3.org /2001/XMLSchema
-instance" targetNamespace=" LSAWfPEditor"
id="LSAWfP_Process_1621779960435_6"> <bpmn:process
id="ProcessId_1621779960435_1" name=" null">
<bpmn:documentation>null</bpmn:documentation>
<bpmn:startEvent id="StartEvent_945944692_7"> <bpmn:outgoing>
SequenceFlow_945944692618756840_8</bpmn: outgoing>
</bpmn:startEvent>
<bpmn:task id="Activity_618756840_1_9" name="A">
<bpmn:documentation />
<bpmn:incoming>
SequenceFlow_945944692618756840_8 </bpmn: incoming>
<bpmn:outgoing>
SequenceFlow_618756840889417478_10 </bpmn: outgoing>
|
MÉMOIRE - TONLE NOUMBO FRANCK BRUNO URIFIA
72
|
</bpmn:task>
<bpmn:exclusiveGateway id=" ExclusiveGateway_889417478_11"
gatewayDirection="Diverging">
<bpmn:incoming>
SequenceFlow_618756840889417478_10</bpmn: incoming>
<bpmn:outgoing>
SequenceFlow_8894174781239211939_12</bpmn: outgoing>
<bpmn:outgoing>
SequenceFlow_8894174782118728884_13</bpmn: outgoing>
</bpmn:exclusiveGateway>
<bpmn:task id="Activity_1239211939_1.1.1_14" name="B">
<bpmn:documentation />
<bpmn:incoming>
SequenceFlow_8894174781239211939_12 </bpmn: incoming>
<bpmn:outgoing>
SequenceFlow_12392119391372598191_15 </bpmn: outgoing>
</bpmn:task>
<bpmn:task id="Activity_1372598191_1 .1.2_16" name="C">
<bpmn:documentation />
<bpmn:incoming>
SequenceFlow_12392119391372598191_15 </bpmn: incoming>
<bpmn:outgoing>
SequenceFlow_13725981912139423180_17 </bpmn: outgoing>
</bpmn:task>
<bpmn:task id="Activity_2139423180_1.1.3_18" name="D">
|
| 
