14_PM_chapitre3_Modelisation pour modélisation

Les processus métiers :
concepts, modèles et systèmes

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

Chapitre 3 :
Eléments de modélisation et
autres notations

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

Dimensions de la modélisation
Logique
Organisationnel
Informationnel

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

Notion de processus bien
structuré
Bonnes pratiques, mais
fondements scientifiques aussi
(ex: « Well handled Petri Net)

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 …)

• 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 »

Processus avec blocage (impasse)
[SAD 00]

Processus avec manque de
synchonisation
[SAD 00]

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

Modéliser avec
Unified Modelling Language
(UML)

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

UML
Modélisation du flot de contrôle.
Les diagrammes d’activité

Discordance du vocabulaire
• « Processus »  « Activité » en UML
• « Activité »  « Action » en UML

Modélisation du flot de contrôle

UML
Modélisation du flot de données

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

Diagrammes de classes (Exemple)

Diagramme de séquence
• Les différents scénarios permettent de
découvrir les différentes alternatives dans
le flot de contrôle

UML
Modélisation du modèle
organisationnel

Instance du modèle organisationnel

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

Processus UML bien structuré (2)

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

Modéliser avec
Event Process Chain (EPC)

Principes de modélisation
• 4 perspectives :
– Organisationnelle
– Donnée
– Activité
– Contrôle
• 3 niveaux d’abstraction
– Définition des besoins
– Conception
– Implantation

Perspectives et niveaux
d’abstractions

Flot de données et flot organisationnel

É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

Conclusion EPC
• Très utilisé dans le monde ERP, SAP
• Fondement dans les RdP

Modéliser avec
des Réseaux de Pétri (RdP)

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

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.

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

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)

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

Exemple « Service »
• Modélisation d’un service (imprimante,
coiffeur) …
Demande Service fait
Service
Service fait
Demande
Libre
En_cours
Service fait
Demande
En_cours

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}}

Exemple « Service » ( t, t )
– Début_service = {Demande, Libre}
– Fin _service = { En_cours}
– Début_service = {En_cours}
– Fin_service = {Service fait, Libre}

Exemple « Service » (Marquage)
• Marquage initial :
{m(Demande) =3, m(Libre) =1, m(En_cours) = 0, M(Service
fait) = 0}
• 1er pas :
– m’(Demande) = m(Demande) – w(Demande, Début_service)
+ w(Début_service, Demande) = 3 -1 + 0 = 2
– m’(Libre) = m(Libre) – w(Libre, Début_service) +
w(Début_service, Libre) = 1 -1 + 0 = 0
– m’(En_cours) = m(En_cours) – w(En_cours, Début_service)
+ w(Début_service , En_cours) = 0 -0 + 1 = 1

Propriétés souhaitées/ables
des RdP
• Vivacité
• Terminaison
• Borné
• A choix libre
• Bien formé
• Sans blocage (sans deadlock)
• Sain

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 »

En pratique
Modéliser des processus
avec des réseaux de Petri.

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

RdP
Modélisation du flot de contrôle

RdP
Modélisation du flot de données

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)

RdP
Modélisation des ressources

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

Modélisation de ressources avec
des RdP

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

… permettent de
• Plier/déplier un modèle
• De représenter le raffinement d’une
activité composée en sous-activité

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 »)

Les RdP colorés
Associer hôtel
et vol avec un
même numéro
de dossier

… permettent de
• De qualifier les jetons avec des attributs
• De distinguer les cas
• Sur lesquelles peuvent porter des
conditions de franchissement

… 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

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.

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.

Exemple (2)
En donner un modèle BPMN!

Exemple (3)
En donner un modèle BPMN!

Exemple (4)
Un concepteur a fait le réseau de Pétri suivant :
commentaires !

Exemple (5)
Autre solution …

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

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

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.

• [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

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

RdP
Principes de modélisation

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

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.

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.

RdP borné
• L’absence d’une borne limite pour le nombre de
jetons dans une place est généralement source
de problème
• Un RdP est k-borné (bounded) si, depuis le
marquage initial, il ne peut atteindre aucun
marquage dans lequel il y a plus de k jetons;
dans le cas contraire, il est non borné
• Un RdP borné a toujours un nombre de
marquages fini
• SI K=1, le RdP est dit sûr (safe).
©Les processus métiers: concepts, modèles et systèmes

Blocage, Boucle , Borne
• Un RdP est sans blocage s’il n’y a pas de
cas où l’activité finale ne peut pas
s’exécuter et où le processus ne peut plus
progresser
• Un RdP est sans boucle si tous les cas
terminent
• Un RdP est borné s’il n’existe pas un cas
où le nombre de jeton croit indéfiniment

Blocage, Boucle, Borne

RdP à libre choix
• Un RdP est à choix libre si toutes les
transitions en concurrence dépendent des
mêmes places
• (a) n’est pas à libre choix, (b) l’est

RdP bien formé
• Un RdP PN est bien formé si et seulement
il existe un état initial à partir duquel il est
vivace et borné

Chemin (élémentaire, sans
conflit)
• Soit N = P U T l’ensemble des nœuds d’un RdP PN, un
chemin C d’un nœud n1 à un nœud nk est une
séquence <n1, n2, …, nk> telle que <ni, ni+1> appartient
à PxT U TXP pour i de 1 à k-1.
• Un chemin C est élémentaire, ssi pour tout ni et nj de
C, i != j => ni != nj
• Un chemin C est sans conflit ssi, pour toute place nj et
toute transition ni de C, j !=i-1 => nj n’est pas une place
d’entré de ni
• If C = <n1, n2, …, nk>, alphabet (C) = {n1, n2, …, nk}

RdP fortement connecté
• Un RdP est fortement connecté ssi, pour
chaque paire de nœud x et y, il existe un
chemin de x à y

Well handled
• Un RdP est well handled ssi, pour chaque
paire de nœud x et y, où x est une place et
l’autre une transition, et pour chaque paire
de chemin élémentaire C1 et C2 de x à y,
alphabet(C1) inter alphabet(C2) = {x,y} =>
C1 = C2

RdP sans deadlock
• Un RdP est sans deadlock si et seulement
si au moins une transition peut être tirée
dans n’importe quel état

RdP
Validation

Processus sain
• Un processus sain est un processus qui ne
contient pas d’activité inutile et où chaque cas
se termine complètement sans laisser de
référence à lui-même
• La vérification brute de cette propriété conduit à
une explosion combinatoire
• Mais un WF-net, augmenté de o  i, qui est
vivace et borné est sain
• Un WF-net est vivace s’il est sans blocage et
sans boucle : on sait vérifier ces propriétés

WF-net bien structuré
• Un wf-net est bien structuré ssi WFN * est
« well handled »
• Décider si un WF-net bien structuré est
sain est calculable en un temps
polynomial
• Par construction, un RdP well handled et
fortement connecté est bien formé (vivace
et borné), donc sain

Raffinement d’un transition
• Propriétés:
– Si (PN1, i) est sûr et PN1 et PN2 sont sains,
alors PN3 est sain
– (PN1, i) et (PN2, i) sont sûrs (resp CL) et
sains ssi PN3 est sûr (resp. CL) et sain
– Si PN3 est à choix libre, resp. bien structuré,
alors PN1 et PN2 sont à CL, resp. BS
– Si PN3 est bien structuré et sain, alors PN1 et
PN2 sont bien structurés et sains

En pratique

Processus-RdP bien structuré
• Bonnes pratiques qui éliminent par
construction bien des risques
• En tous cas, diminue la complexité du
réseau
• En conséquence l’évaluation est plus
efficace

Bonnes et mauvaises structurations
de réseaux avec des RdP (1)

Bonnes et mauvaises structurations
de réseaux avec des RdP (2)
• (a) combine un AND_Split et un AND-join,
(b) combine un XOR-Split et un XOR-JOIN
(a) et (b) sont bien structurés
• (c) et (d) sont mal structurés

Well-structured WF-Net
Un WF-Net bien structuré est un WF-Net
bien parenthésé

RdP sains par construction
• On connaît un ensemble de RdP de base
sains
• Leur composition produit un RdP sain
Application : ayant un RdP, peut-on le
reconstruire en itérant la composition de
RdP de base sains

RdP de base sains

Et celui-ci ?

Analyse quantitative
• Analyse par simulation
– évaluation de propriétés recherchées
• par visualisation de cas
• évaluation de traces d’exécution
• Réseaux temporisés pour l’évaluation de
performance
• Réseaux stochastiques pour l’évaluation
de probabilités de franchissement d’une
transition …

Exemple (2)

Exemple (2)
• Dans la variante (a), plusieurs activités de
réservation d’hôtels et de vols s’exécutent
en parallèle, dans la variante (b) une seule
activité pour toutes les réservations
• L’analyse peut permettre d’évaluer quelle
est la stratégie la plus efficace,
éventuellement en fonction de circonstances

14_PM_chapitre3_Modelisation pour modélisation

Contenu connexe

Similaire à 14_PM_chapitre3_Modelisation pour modélisation

14_PM_chapitre3_Modelisation pour modélisation