2. Organisation du cours
• Introduction
• Concepts et notations
• Modélisation des processus
• Analyse qualitative des processus
• Analyse quantitative des processus
• Systèmes de gestion de processus
• Processus transactionnels
• Découverte de processus
• Conclusion
4. Contenu (2)
• Le chapitre introduit la notion de
processus bien structuré et bien
parenthésé
• Il présente l’essentiel des concepts des
modèles UML, EventProcessChain et
Réseaux de Petri, pour modéliser des
processus
5. Dimensions de la modélisation
Logique
Organisationnel
Informationnel
6. Contenu (1)
• De fait, il existe assez peu d’approches de
modélisation spécifiques aux processus métiers
opérationnelles couvrant toutes ces dimensions
(voir cependant OSSAD http://dumas.univ-
tln.fr/Ossad/Appel%20vol%201.htm )
• Aussi, le chapitre présente plus des notations
formelles qu’une méthodologie
d’analyse/conception
• Mais, le fait de modéliser en se demandant si le
processus est bien structuré, bien parenthèse, à
choix libre … supporte une discipline de
conception efficace
7. Notion de processus bien
structuré
Bonnes pratiques, mais
fondements scientifiques aussi
(ex: « Well handled Petri Net)
8. Notion de processus bien structuré (1)
• Un seul point d’entrée et un seul point de
sortie
• Toute activité est sur un chemin allant du
point d’entrée au point de sortie
• Les connecteurs de flot de contrôle sont
bien parenthésés (AND-Split-AND-Join;
XOR-Split, XOR-Join; OR-Split-Jonction …)
10. Notion de processus bien structuré (3)
• Dans le cas (a), une parenthèse OR-Split est
fermée par une parenthèse AND-Join, il y a
risque de blocage : si une seule branche est
activée, la porte AND-JOIN n’est jamais franchie
– Le graphe de processus contient une « impasse »
• Dans le cas (b), une parenthèse AND-Split est
fermée par une parenthèse OR-Split. quel est
l’interprétation de cet OR-Split ?
– Le graphe de processus « manque de
synchonisation »
14. Tout processus peut-il être transformé un
processus bien structuré ?
• (Presque) oui …
• Certains ne peuvent être transformés
qu’en dupliquant des activités
• Il existe des cas non transformables …
mais très particuliers
18. UML : Principes de modélisation
• Ce sont les diagrammes d’activité qui sont au cœur de la
modélisation des processus métiers, en particulier du flot
de contrôle
• Les diagrammes de classes et d’objets sont
indispensables à la modélisation des flots de données
• Les diagrammes de séquence permettent ici d’étudier
les flots de contrôle alternatifs
• Mais tous les diagrammes peuvent être utilisés de façon
classique, en particulier dans une démarche
d’analyse/conception globale d’un logiciel plus large que
la modélisation d’un processus
27. Diagramme de classes
• Classique …
• Indispensable à la modélisation du flot de
données
• Utilisé pour la méta-modélisation
(modélisation des modèles de processus)
• Et la modélisation du modèle
organisationnel
39. Validation
• Le processus est-il bien structuré ?
• Est-il sain (sans blocage, borné) ? Peu
outillé, mais se poser néanmoins la
question et utiliser des principes de
modélisation qui limite les risques en
s’inspirant des RdP
41. Conclusion UML
• Moins adapté et outillé que les RdP
• Mais les diagrammes d’activités
empruntent aux RdP
• Permettent une bonne intégration à
l’analyse et à la conception avec les
autres aspects d’un logiciel, en particulier
dans le contexte de développement
orienté objet
47. Éléments du flot de contrôle
• Un modèle EPC est un graphe ordonné
d’événements et d’activités alternés et
connectés par des connecteurs de flot de
contrôle
58. Pourquoi les RdP ?
• Similarités avec les langages et outils BPM
choisi pour développer une sémantique formelle
de ces langages (EPC, diagrammes d’activité
UML, WS-BPEL)
• Fondements mathématiques techniques
d’analyse (voir chapitre 4)
• Notations graphiques plus facilement
accessible à des non spécialistes
• Plus implicite et compacte que les modèles à
transitions
60. Définition
On appelle réseau de Petri places/transition tout
triplet N = (P,T,W) où :
– P est un ensemble fini de places : P = {p1, …, pn}
– T est un ensemble fini de transitions, disjoint de P : T
= {t1, … , tm}
– W : PxT U TxP N (entiers naturels) est la fonction
de valuation des arcs
Graphiquement, par convention, les arcs de valuation nulle ne sont pas
représentés; les valuations égales à 1 sont omises (valeur par
défaut); dans les autres cas, les valuations sont explicites.
61. Place d’entrée et place de sortie
• Une place p est une place d’entrée d’une
transition t si (p,t) appartient à W.
– l’ensemble t = {(p,t,?) de W} définit les
places d’entrée de t
• Une place p est une place de sortie d’une
transition t si (t,p,?) appartient à W
– L’ensemble t = {(t,p, ?) de W} définit les
places de sortie de t
62. Marquage, transition tirable,
franchissement d’une transition
On appelle marquage d’un RdP (P,T,W) toute
fonction m : P N (entiers naturels).
Dans un RdP (P,T,W), une transition t est tirable
dans un marquage M si et seulement si, pour
toute place p de t, m(p) > w(p,t)
Le franchissement d’un transition t conduit à un
nouveau marquage tel que :
m’(p) = m(p) – w(p,t) + w(t,p)
63. Atteignabilité…
• Un état Mn est atteignable à partir d’un
marquage M1 (noté M1 -*-> Mn) si et
seulement si il existe une séquence s telle
que M1 -*-> Ms
65. Exemple « Service »
• Modélisation d’un service (imprimante,
coiffeur) …
Demande Service fait
Service
Service fait
Demande
Libre
En_cours
Service fait
Demande
En_cours
66. Exemple « Service » (P,T,W)
• P = {Demande, Libre, En_cours, Service
fait}
• T = {Début_service, Fin _service}
• W = {{Demande, Début_service, 1}, {Libre,
Début_service, 1}, {Début_service,
En_cours, 1}, {En_cours, Fin_service, 1},
{Fin_service, Libre, 1}, {Fin_service,
Services fait, 1}}
67. Exemple « Service » ( t, t )
– Début_service = {Demande, Libre}
– Fin _service = { En_cours}
– Début_service = {En_cours}
– Fin_service = {Service fait, Libre}
70. Vérification de ces propriétés
• Il existe un lien direct entre ces propriétés
des réseaux de Petri et la qualité du
processus modélisé
• Voir « Chapitre 4 : analyse qualitative des
processus »
72. Un processus comme un
Worflow-Net
• Un RdP est un WF-Net ssi :
– Une seule place d’entrée et une seule place
de sortie
– Chaque place et chaque transition se trouve
sur un chemin allant de la place initiale à la
place finale
– La consommation d’un jeton dans la place
initiale produit un et un seul jeton dans la
place finale
78. Représentation du flot de données
• Le flot de données est porté par (voir RdP
coloré) :
– les couleurs associées aux jetons
– le flot des jetons dans le RdP et les conditions
associées aux transitions
• Remarquons que plus les jetons portent
d’information, et plus les RdP ont
tendance à perdre leur lisibilité (graphique)
80. Les rôles comme des places, les
ressources comme des jetons
• On ajoute des places spécifiques pour définir les
rôles
• Les ressources sont les jetons dans ces places
spécifiques
• Les transitions qui représentent les activités
consomment ces ressources
• On peut associer des places/ressources à
plusieurs transitions
• L’ajout de ces places complexifie le RdP qui
devient moins lisible et plus difficile à valider
82. Limites des RdP classiques
• Passage à l’échelle
• Pouvoir d’expression limité
• Pas de modélisation du temps
RdP hierarchisés
RdP colorés
RdP temporisés
86. Raffinement d’une transition
• PN3 obtenu par raffinement de t+ de PN1 par PN2 :
– PN1 = (P1, T1, F1) et PN2 = (P2, T2, F2)
– T1 inter T2 = vide, P1 inter P2 = {i, o}, t+ E T1
– PN3 = (P3, T3, F3) avec P3 = P1 u P2 , T3 = (T1 {t+}) U T2
– F3 = {(x,y) E F1 | x != t+ et y != t+ } U {(x,y) E F2 | x != i et
y != o } U {(x,y) E P1 x T2 | {(x, t+) E F1 et (i,y) E F2 } U
{(x,y) E T2 x P1 | {(t+, y) E F1 et (x,o) E F2 }
(F est la fonction W sans « valuation » : tous les arc ont la valeur « 1 »)
88. … permettent de
• De qualifier les jetons avec des attributs
• De distinguer les cas
• Sur lesquelles peuvent porter des
conditions de franchissement
90. … permettent de
• D’associer des timestamps aux jetons
(date à partir de laquelle un jeton peut être
consommé)
• D’associer des temps de franchissement
aux transitions (d’exécution aux activités)
• D’ajouter des délais aux activités
• Pour faire de la simulation temporelle
91. Conclusion RdP
• Certainement le fondement principal pour
la gestion des flots de contrôle
• Quelques outils utiles, mais la validation
automatique est loin d’être atteinte
• … en particulier pour les réseaux colorés
• Les RdP sont souvent embarqués de
façon cachée dans bons nombres d’outils
associés aux SGWf.
92. Exemple (1)
Une compagnie d’assurance souhaite modéliser le
processus défini comme suit :
A l’arrivée d’une déclaration de sinistre, elle fait en parallèle
deux vérifications dans deux départements différents : la
police d’assurance couvre–t-elle le sinistre ? La
déclaration permet-elle de décider du remboursement ?
Si la police d’assurance couvre le sinistre (police
acceptée) et que la déclaration est acceptée, l’assurance
paye. Dans le cas où soit la police d’assurance n’est pas
valide, soit la déclaration n’est pas acceptée, un courrier
est envoyé à l’adhérent.
99. Conclusion (1)
• Le chapitre présente plus des notations
formelles qu’une méthodologie
d’analyse/conception comme introduite dans
• Cependant, le fait de modéliser en se
demandant si le processus est bien structuré,
bien parenthèse, à choix libre …supporte une
discipline de conception efficace
100. Conclusion (2)
• RdP est probablement le modèle formel le
mieux outillé
• UML est utilisé en phase d’analyse et de
conception lorsque le processus est
embarqué dans un contexte logiciel plus large
• EPC est très utilisé en pratique dans le
contexte ERP, mais les outils EPC
« emballent » les concepts des RdP
101. Références
• [AAL 00] VAN DER AALST W. M. P., TER HOFSTEDE A. H. M., « Verification of Workflow Task
Structures : A Petri-net-baset Approach », Inf. Syst., vol. 25, n˚ 1, p. 43-69, 2000.
• [AAL 02] VAN DER AALST W. M. P., VAN HEE K. M., Workflow Management : Models, Methods,
and Systems, MIT Press, Cambridge, 2002.
• [AAL 11] VAN DER AALST W. M. P., STAHL C. Modelling Business Processes : A Petri Net-
Oriented Aproach, MIT Press, Cambridge, 2011.
• [DON 05] VAN DONGEN B. F., VAN DER AALST W. M. P., VERBEEK H. M. W., « Verification of
EPCs : Using Reduction Rules and Petri Nets », CAiSE, p. 372-386, 2005.
• [DUM 12a] DUMAS M. and al. Understanding Business Process Models: The Costs and Benefits
of Structuredness, CAISE 2012
• [DUM 90a] DUMAS P., CHARBONNEL G., La méthode OSSAD : pour maîtriser les technologies
de l’information - Tome I : Principes, Editions d’Organisation, Paris, 1990.
• [DUM 90b] DUMAS P., CHARBONNEL G., La méthode OSSAD : pour maîtriser les technologies
de l’information - Tome II : Guide pratique, Editions d’Organisation, Paris, 1990.
• [EPC 08] EPC, « Event-driven Process Chain », en.wikipedia.org/wiki/Event-driven_Process-
Chains, 2008.
• [FAW 97] FAWLER M., Uml distilled. Applying the standard object modeling language, Addison-
Wesley, Reading, 1997.
• [FAW 05] FAWLER M., Uml distilled. A brief guide to the standard object modeling language,
Addison-Wesley, Reading, 2005.
• [FOS 05] FOSTER H., UCHITEL S., MAGEE J., KRAMER J., HU M., « Using a Rigorous
Approach for Engineering Web Service Compositions : A Case Study », IEEE Service Computing
Conference, p. 217-224, 2005.
• [FU 04] FU X., BULTAN T., SU J., « Analysis of interacting BPEL web services », Wold Wide Web
conference, p. 621-630, 2004.
• [GEF 08] GEFFROY J. C., Introduction aux réseaux de Petri,
cyranac.free.fr/pub/cours/cnamMOCA/CH10.pdf, 2008.
102. • [LIA 07] LIANG-JIE ZHANG JIA ZHANG H. C., Services Computing, Springer, Berlin, 2007.
• [MAR 95] MARSAN M. A., BALBO G., DONATELLI S., FRANCESCHINIS G., Modelling with
Generalized Stochastic Petri Nets, Springer-Verlag, Heidelberg, 1995.
• [OBE 96] OBERWEIS A., SANDER P., « Information system behavior specification by high level
Petri nets », ACM Transactions on Information Systems, vol. 14, n˚ 4, p. 380-420, ACM, 1996.
• [OMG 06] OMG, « Business Process Definition Metamodel », www.omg.org/docs/bei/03-01-
06.pdf, 2006.
• [PAP 07] PAPAZOGLOU M. P., VAN DEN HEUVEL W. J., « Business process development life
cycle methodology », Communication of ACM, vol. 50, n˚ 10, p. 79-85, 2007.
• [PET 08] PETRI, « Réseaux de Petri », fr.wikipedia.org/wiki/R%C3%A9seau_de_Petri, 2008.
• [RUM 00] RUMBAUGH J., BOOCH G., JACOBSON I., Le guide de l’utilisateur UML, Eyrolles,
Paris, 2000.
• [SAD 00] SADIQ W., ORLOWSKA M. E., « Analysing Process Models Using Graph
ReductionTechniques », Information Systems, vol. 25-2, p. 117-134, 2000.
• [SAL 04] SALAÜN G., BORDEAUX L., SCHAERF M., « Describing and Reasoning on Web
Services using Process Algebra », International conference on Web Services, 2004.
• [SAP 08a] SAP, « SAP NetWeaver », en.wikipedia.org/wiki/NetWeaver, 2008.
• [SAP 08b] SAP, « SAP R/3 », en.wikipedia.org/wiki/SAP_R/3, 2008.
• [SCH 98] SCHEER A. W., Business Process Engineering : Reference Models for Industrial
Enterprises, Springer-Verlag, Heidelberg, 1998.
• [TUR 07] TURNER K. J., « Representing and analysing composed web services using Cress », J.
Network and Computer Applications, vol. 30, n˚ 2, p. 541-562, 2007
Références
104. RdP réversible
• Un marquage a la propriété home-marking
s’il peut toujours être à nouveau atteint
• Un RdP est réversible si son état initial est
un home-marking
106. WF-net *
• Soit un WF-net WFN, on note WFN* WFN
étendu par une transition de la place de
sortie o à la place d’entrée i
107. RdP vivace
• Une transition est morte si et seulement si elle
n’est pas tirée dans aucun marquage possible
• Une transition est vivante si, depuis n’importe
quel marquage, on peut atteindre un marquage
dans lequel la transition est tirable
• Un RdP est vivace si et seulement si toutes ses
transitions sont vivantes
• Vivacité et terminaison s’excluent.
108. RdP qui termine
• Un RdP termine s’il atteint toujours un
marquage terminal duquel aucune
transition ne peut être tirée
• Un RdP avec graphe d’atteignabilité fini et
acyclique termine
• Vivacité et terminaison s’excluent.