Les ECATNets récursifs pour la modélisation et l’analyse des processus workflows flexibles...

Post on 04-Apr-2015

110 views 7 download

Transcript of Les ECATNets récursifs pour la modélisation et l’analyse des processus workflows flexibles...

Les ECATNets récursifs pour lamodélisation et l’analyse des processus

workflows flexibles

Séminaire MeFoSyLoMa, le 12 Mai 2006

Awatef Hicheur

CEDRIC - CNAM Paris

Plan

Problématique Formalismes de base - Logique de réécriture et Maude

- ECATNets

- Réseaux de Petri récursifs

Les ECATNets récursifs - Modélisation et analyse de workflows flexibles

Conclusion et travaux futurs

Problématique

Expressivité des langages de modélisation des processus workflows

Flexibilité et dynamique dans l’exécution des processus worflows

Intégration de la vraie concurrence dans les modèles workflows

Automatisation partielle ou totale de processus de gestion dans lequel le transfert de données et de tâches, d’un participant à un autre, suit un ensemble de règles procédurales.

Champs d’application • Modélisation et coordination des processus de gestion, • Gestion des documents et des images• Support pour les processus ad hoc et les interactions de gestion inter-

organisationelles• Composition et orchestration des services Web : interaction B2B, B2C et

G4C

Workflow

Un Système de gestion de Workflow (Workflow Management System) est un système qui sert à définir, gérer et exécuter des procédures en exécutant des programmes dont l’ordre d’exécution est pré défini dans une représentation informatique de la logique de ces procédures.

Plus de 250 systèmes de gestion de workflow disponibles sur le marché : IBM WebSphere MQ (MQSeries), IBM Lotus Notes, SAP, Open Text LiveLink, etc

Les WFMS utilisent une large variété de langages et de concepts basés sur différents paradigmes (malgré les efforts de standardisation du WfMC)

Workflow

Vérification et analyse des processus workflows

Expressivité des langages de modélisation Difficile de modéliser les patterns de flots de contrôle :

- invoquant des instances multiples - de synchronisation avancée - d’annulation

Flexibilité et adaptabilité Situations et résultats inattendues dues aux déviations de l’environnement

Utilisation des méthodes formelles pour la spécification des workflows

(Réseaux de Petri, Machine à état, algèbres de processus..etc.)

Limitations des WFMS actuels

Modification dynamique, raffinement et spécification de la structure des processus en cours d’exécution

Le traitement de l’exception fait partie du processus workflow

Objectif

Construire un modèle formel pour la modélisation des processus workflows permettant :

de capturer de manière concise les patterns workflow les plus complexes.

d’introduire une flexibilité et une dynamique dans la planification et l’exécution des processus workflows

d’exprimer correctement l’exécution des workflows selon la sémantique de vraie concurrence

Le modèle développé : ECATNets récursifs

Combinaison saine des :

1) ECATNets

2) Réseaux de Petri récursifs

Sémantique décrite en termes de logique de réécriture.

Logique de réécriture (J. Meseguer, 1992) est une logique qui permet de raisonner correctement sur les changements d’états d’un système non déterministe et concurrent, selon une sémantique de vraie concurrence

Décrit un système concurrent ayant des états et évoluant en termes de transitions par une théorie de réécriture T=(Σ,E,L,R)

- États du système formalisés par une théorie équationnelle (Σ,E)

- Transitions locales formalisées par un ensemble de règles de réécriture

rl [l]: t t’ Une théorie de réécriture T=(Σ,E,L,R) est vue comme une spécification

exécutable du système concurrent qu’elle formalise

Maude (SRI International) http://maude.csl.sri.com/

Langage supportant les calculs en logique de réécriture

Logique de Réécriture : notions de base

Combinaison saine des : Types abstraits algébriques (Donnée) Réseaux de Petri (Comportement)

Sémantique décrite en termes de logique de réécriture

Vérification / simulation des propriétés via un raisonnement formel

Outils pour les ECATNets développés sur le système Maude

Les ECATNets

ECATNets : "Extended Concurrent Algebraic Term Nets ", (M. Bettaz,1993)

ECATNets : Syntaxe

Un exemple d’un ECATNet

P‘ : S’P : S

IC(p, t)

DT(p, t)

TC(t)CT(t, p’)

• IC(p, t) (Input Conditions)• DT(p, t) (Destroyed Tokens) • CT(t, p') (Created Tokens) • TC(t) (Transition Conditions) : terme booléen

multi ensemble de termes algébriques

- Condition : IC(p,t) (condition sur le marquage de la place d’entrée p) TC(t) (condition additionnelle booléenne)

- IC(p, t) est valide pour chaque place en entrée de la transition t - L’expression TC(t) est évaluée vraie

- Action : - Le marquage DT(p, t) est soustrait de chaque place d’entrée p de t - Le marquage CT(p‘, t) est créé dans chaque place de sortie p’ de t

ECATNets : Sémantique

P‘ : S’P : S

IC(p, t)

DT(p, t)

TC(t)CT(t, p’)

Un exemple d’un ECATNet

- Si IC(p,t) mTΣ,s(X) + (Condition contextuelle positive).

Cas 1. [IC(p, t)] = [DT(p, t)], cas usuel des réseaux de Petri t : <p, [IC(p ,t)]> <p', [CT(t, p')]>

Cas 2. [IC(p, t)] [DT(p, t)] = M t : <p, [IC(p, t)]> <p, [DT(p, t)]> <p, [IC(p, t)]> <p', [CT(t, p')]>

Cas 3. [IC(p, t)] [DT(p, t)] M

t1 : <p, [IC1(p ,t1)]> <p', [CT(t1, p')]> t2 : <p, [IC2(p, t2)]> <p, [DT2(p, t2)]> <p, [IC2(p, t)]> <p', [CT(t2, p')]> IC(p, t) = IC1(p, t1) IC1(p, t2), DT(p, t) = DT1(p, t1) DT1(p, t2) IC1(p, t1) = DT1(p,t1), IC2(p, t2) DT2(p, t2) = M

ECATNets : Règles de réécriture

Une transition t est décrite par une règle de réécriture ( t: M M’ ), M, M’ de sorte Marking

Notation : : union multi-ensembliste sur les pairs <p, [m]> (ACI axioms)

- Si IC(p,t) mTΣ,s(X) - (Condition contextuelle négative).

Tester si IC(p,t) n’est pas totalement inclus dans M(p)

t : <p, [DT(p,t)] [M(p)] <p',[CT(p',t)]>

if ([IC(p,t)] \ ([IC(p,t)] [M(p)] ))= M ) [false]

- Si IC(p,t) =M

t : <p,[DT(p,t)] [M(p)] <p',[CT(p',t)]> If ([M(p)] = M )[true]

- Si une conditition locale de franchissement TC(t) est associée à une transition t, la partie conditionnelle de la régle contiendra le compostant [TC(t) true]

ECATNets : Règles de réécriture

Une transition t est décrite par une règle de réécriture ( t: M M’ )

Les Réseaux de Petri récursifs (RdPR)

Extension stricte des réseaux de Petri introduisant la dynamicité dans la structure (S.Haddad et al.1996)

- Typage des transitions : élémentaire et abstraite

L'état courant d’un RdP récursif est un arbre de réseaux (processus) marqués (dénotant la relation créateur/créé)

- Chaque réseau a sa propre activité

- Franchissement d’une transition abstraite dans un réseau : - Consommation des jetons spécifiés par les arcs entrant

- Création d’un nouveau sous-réseau avec le marquage initial (paramétré)

associé

Réseaux de Petri récursifs (RdPR)

- Terminaison du réseau et de tous ses sous-réseaux fils- Production des jetons en sortie de la transition abstraite (dans le réseau père) qui lui a donnée naissance selon l’état de terminaison

- Un état de terminaison est atteint dans un réseau (étape de coupure):

- Franchissement d’une transition élémentaire dans un réseau :

- Consommation et production de jetons (transition ordinaire d’un RdP) - Destruction des sous-arbres engendrés par les transitions abstraites désignées

par la fonction partielle associée

P

tabs

P

P’1

P1

t1 t2

P3P2

Un exemple illustratif RdPR

P’2

<0> <1>

Marquages finaux : 0={M(P3)>0}1={M(P2)>0}

Etat du réseau : Arbre de marquage ( Marquage étendu )

Une famille indexée de représentations effective d’ensembles semi-linéaires de marquages

finaux

Transition élémentaire

Transition abstraite

Indice de terminaison

P1

Marquage initial

tabs

P

P’1

P1

t1 t2

P3P2

P’2

<0> <1>

Etat du réseau : Arbre de marquage ( Marquage étendu )

Exemple illustratif (suite)

P1

tabs

Marquages finaux : 0={M(P3)>0}1={M(P2)>0}

P1

tabs

P

P’1

P1

t1 t2

P3P2

P’2

<0> <1>

Etat du réseau : Arbre de marquage ( Marquage étendu )

Exemple illustratif (suite)

P3

tabs

Marquages finaux : 0={M(P3)>0}1={M(P2)>0}

P1

Coupure avec l’indice de terminaison <0>

tabs

P

P’1

P1

t1 t2

P3P2

P’2

<0> <1>

Exemple illustratif (suite)

P3

tabs

Etat du réseau : Arbre de marquage ( Marquage étendu )

Marquages finaux : 0={M(P3)>0}1={M(P2)>0}

P1

P’1

tabs

P

P’1 P’2

<0> <1>

Exemple illustratif

Etat du réseau : Arbre de marquage ( Marquage étendu )

Marquages finaux : 0={M(P3)>0}1={M(P2)>0}

P1

ECATNets récursifs (RECATNets)

RECATNets Intégration de la récursivité dans les ECATNets « ordinaires »

Un RECATNet est une structure RECATNet = (ECATNet, , K) tel que :

– T = Tabs Telt

– : une famille indexée de conditions sur des marquages finaux

– K : fonction partielle Telt Tabs

L’état d’un RECATNet est un arbre de réseaux marqués - Le franchissement d’une transition abstraite dans un réseau génère un

sous-réseau

- si état de terminaison atteint alors suppression du réseau généré (étape de coupure)

Sémantique : Un RECATNet est décrit par une théorie de réécriture

Franchissement d’une transition abstraite dans un réseau - Condition : - IC(p, t) est valide pour chaque place en entrée de la transition t - L’expression TC(t) est évaluée vraie

- Action : - Le marquage DT(p, t) est soustrait de chaque place d’entrée p de t - Création d’un sous-réseau fils avec CT(pt) comme marquage

initial

RECATNets : syntaxe et sémantique

CT(pt)

Transition abstraite

P‘ : S’P : S

IC(p, t)

DT(p, t)

CT/ i (p’,t)TC(t)

Production en sortie de la transition t paramétrée selon

l’état de terminaison i du sous réseaux créé lors de son

franchissement

Franchissement d’une transition élémentaire dans un réseau- Condition : - IC(p, t) est valide pour chaque place en entrée de la transition t - L’expression TC(t) est évaluée vraie

- Action : - Le marquage DT(p, t) est soustrait de chaque place d’entrée p de t - Le marquage CT(p‘, t) est créé dans chaque place de sortie p’ de t - Si K( t,tabsj)=i (défini), interrompre tous les sous-réseaux engendrés

par tabsj avec l’état de terminaison i

P‘ : S’P : S

IC(p, t)

DT(p, t)

TC(t)CT(t, p’)

Transition élémentaire

{tabsj, i }

RECATNets : syntaxe et sémantique

État d’un RECATNet

[Ms0, nullTransition ,

[Ms1, tabs1 , [Ms1.1, tabs1.1, …] … [Ms1.j, tabs1.j, … ] ]

[Ms2, tabs2, [Ms2.1, tabs2.1, …] … [Ms2.j, tabs2.j, … ] ] …

[Msn, tabsn, [Msn.1, tabsn.1, …] … [Msn.j, tabsn.j, … ] ] ].

L’état courant d’un RECATNet RN est un arbre Tr de réseaux marqués représenté par le terme algébrique de la forme générale récursive :

Ms0

Ms1 Ms2 Msn

Ms1.1 Ms1.j Ms2.1 Ms2.j Msn.1 Ms2.j

Marquage du réseau racinetabs1

tabs2tabsn

tabs1.jtabs1.1 tabsn.1

tabsn.j

Marquage d’un sous-réseau

Transition abstraite engendrant le sous

réseau

fmod THREAD is Protecting STRUCTURE .Sorts Thread . op nullTransition : -> Transition .op nullThread : -> Thread . ***** Constante qui implemente le thread et l’arbre

vide ()

op [_,_,_] Marking TransitionAbs Thread -> Thread .op _ _: Thread Thread -> Thread [comm. Assoc id: nullThread]. op Initial : Making -> Thread .Var M : Marking .Eq Initial (M) = [ M, nullTransition, nullThread ] . endfm.

L’état distribué des RECATNets est formalisé par la théorie équationelle suivante (syntaxe Maude)

État d’un RECATNet

Cas 1: [IC(p,t)] = [DT(p,t)]

rl [telt] : [ M <p, IC(p,telt)> , T, mTh ]

[M <p’, CT(p’,telt)> CreateTokens(<p,CT/i (p,tabsj)>, mTh, tabsj, null), T, DeleteThread(mTh, tabsj)].

Cas 2: [IC(p,t)] [DT(p,t)] = M

rl [telt] : [ M <p, IC(p,telt)> <p, DT(p,telt)> , T, mTh ]

[M <p’, CT(p’,telt)> CreateTokens(<p,CT/i (p,tabsj)>, mTh, tabsj, null), T, DeleteThread(mTh, tabsj)].

RECATNets : Règles de réécriture (1/3)

Une transition t élémentaire interrompant une transition abstraite tabsj avec l’index i est décrite par une règle de réécriture (special elementary rule) (telt (tabsj / i) : Th Th’ ) avec Th, Th’ de sorte Thread

Une transition t élémentaire est décrite par une règle de réécriture (elementary rule) (telt : M M’ ) avec M, M’ de sorte Marking

Même forme pour les transitions des ECATNets ordinaires.

Cas 1: [IC(p, tabs)] = [DT(p, tabs) ] .

rl [tabsi] : [M <p, IC(p,tabs)> , T, mTh ]

[ M , T, mTh [<p, CT(p,tabs)> <pfinal1, > <pfinaln, >, tabsi,

nullThread ] ] .

Cas 2 : [IC(p, tabs) ] [DT(p, tabs)] = M

rl [tabsi] : [ M <p, IC(p,tabs)> <p, DT(p,tabs)> , T, mTh ]

[M <p, IC(p,tabs)>, T, mTh [<p, CT(p,tabs)> <pfinal1, >

<pfinaln, >, tabsi, nullThread] ]

Une transition t abstraite est décrite par une règle de réécriture (abstract rule) ( tabs : Th Th’ ) avec Th, Th’ de sorte Thread

RECATNets : Règles de réécriture (2/3)

Si l’étape de coupure est associée à un réseau différent de la racine de l’arbre Tr

crl [i] : [Mf, Tf, [M <pfinal, mpfinal >, tabsj, mTh] mThf ]

[Mf <p’,CT/i (p’,tabsj)>, Tf, mThf ]

if i True

Si l’étape de coupure est associée au réseau racine de l’arbre Tr

crl [i] : [M <pfinal, mpfinal >, nullTransition, mTh ] nullThread

if [i True]

Une étape de coupure est décrite par une règle de réécriture ( Pruning rule) (i : Th Th’ ) avec Th, Th’ de sorte Thread

RECATNets : Règles de réécriture (3/3)

Propriété comportementale : atteignabilité

Un RECATNet Une Théorie de réécriture

Franchissement d’une transition (abstraite ou élémentaire)ou d’une étape de coupure

Réécriture modulo ACI avec la règle de réécriture correspondante

Propriété d’atteignabilité Preuve de déduction dans son modèle (Catégorie)

Théorème : Étant donné un RECATNet RN associé à une théorie de réécriture RN-BEHAVIOR représentant un tel réseau et Tr, Tr’ deux états distincts de RN. L’état Tr est accessible à partir de Tr, si et seulement si, le réécriture [Tr] [Tr’] est prouvable dans la théorie RN-BEHAVIOR utilisant les règles de déduction appropriées.

Les RECATNets pour la modélisation des workflows

Les transitions élémentaires : tâches élémentaires

Les transitions abstraites : tâches abstraites définies sur la base de plusieurs plans d’actions à entreprendre :

1) Planification conditionnelle

- un plan d’actions est défini par :

- le contexte d’exécution (marquage initial)

- le résultat attendu (but à atteindre)

2) Définir des processus de synchronisation :

Synchronisation de processus avec ou sans connaissance a priori durant la phase d’exécution selon leurs états de terminaison

L’objectif : modélisation de processus workflows flexibles dont la structure évolue selon le contexte d’exécution .

Avantages Notation graphique, représentation explicite des états (ressources) et

fondation formelles (Logique de réécriture).

Abstraction des structures de données via les spécifications algébriques et sémantique de vraie concurrence via la Logique de Réécriture :

vérification formelle de propriétés exécution et analyse via l’outil MAUDE

Test des contextes négatifs et positifs

Modélisation via la récursivité des patterns de flot de contrôle les plus complexes :

invoquant des instances multiples de synchronisation avancée d'annulation

Via la création dynamique de réseaux

Via les étapes de coupures

Intégration une flexibilité et une dynamique dans la planification et l’exécution des workflows :

Alterner planification, modification de la planification et exécution du processus workflow

Dédoublement et création dynamique de processus

Traitement des exceptions : Incorporer le traitement de l’exception dans le processus workflow

Raffinement dynamique du processus

Redistribution des ressources

Avantages

Commande en ligne

Service de vente en ligned’ordinateurs

Service de carte de crédit

Service recherche en stock du fournisseur (i)

Client

Exemple : « online shopping workflow »

0 : (Pr, Rq, NotOk) M(PEndRequest) 1 : (Pr, Rq, Ok) M(PEndRequest)2 : M(PEndVerifCode) = NotOk 3 : [M(PEndVerifCode) = Ok ] [M(PRepProvOk)= M(PTestRequest)]4 : M(PRepProvNotOk)

Exemple : « online shopping workflow »Modélisation à l’aide des RECATNets

OrderResult

Order

Cust.Order

<Rprov,ListCmd> <VerifCard, Code> <Order, (N, code, listCmd, CmdState) >

<2><3>

Built PC

OrderAccepted

<4>

[(N, code, listCmd, CmdState)]

[(N, code, listCmd, CmdState)]

VerifandRequestProv

[(N, code, listCmd, CmdState)]

[(N, code, listCmd, rejected)]

[(N, code, listCmd, notAvailable)]

[(N, code, listCmd,readyToBuilt)]

[(N, code, listCmd,PcBuilt)]

[(N, code, listCmd,readyToBuilt)]

OrderReceived

RequestOk

EndRequest

(Pr,Rq,OK)(Pr,Rq,NotOK)

RequestNotOk

Request

RequestReceived

ReceiveRequest(Pr,Rq)

(Pr,Rq)

(Pr,Rq)(Pr,Rq)

CodeOk CodeNotOk

EndVerifCode

NotOK Ok

VerifCard

CodeReceived

ReceiveCode

Code

Code

CodeCode

Order

TestRequest

ReceiveListRequest

RepProv OK

L =

L

RepProvNot OK

<0><1>

RequestReady

(Pr,Rq) (Pr,Rq)

SandRequest

(Pr,Rq) (Pr,Rq)

RProvid

L

Tail (L)

<Request, (Pr,Rq)>

L

0 : (Pr, Rq, NotOk) M(PEndRequest) 1 : (Pr, Rq, Ok) M(PEndRequest)2 : M(PEndVerifCode) = NotOk 3 : [M(PEndVerifCode) = Ok ] [M(PRepProvOk)= M(PTestRequest)]4 : M(PRepProvNotOk)

Exemple : « online shopping workflow »Modélisation à l’aide des RECATNets

Exemple : séquence de franchissement

OrderResult

Order

Cust.Order

<Rprov,ListCmd> <VerifCard, Code> <Order, (N, code, listCmd, CmdState) >

<2><3>

Built PC

OrderAccepted

<4>

[(N, code, listCmd, CmdState)]

[(N, code, listCmd, CmdState)]

VerifandRequestProv

[(N, code, listCmd, CmdState)]

[(N, code, listCmd, rejected)]

[(N, code, listCmd, notAvailable)]

[(N, code, listCmd,readyToBuilt)]

[(N, code, listCmd,PcBuilt)]

[(N, code, listCmd,readyToBuilt)]

OrderReceived

[ < OrderReceived, (C01, C2210, (L1; L2), initialised)>, nullTransition, nullThread ]

Initial (<OrderReceived, (C01, C2210, (L1; L2), initialised)>

CodeOk CodeNotOk

EndVerifCode

NotOK Ok

VerifCard

CodeReceived

ReceiveCode

Code

Code

CodeCode

Order

TestRequest

ReceiveListRequest

RepProv OK

L =

L

RepProvNot OK

<0><1>

RequestReady

(Pr,Rq) (Pr,Rq)

SandRequest

(Pr,Rq) (Pr,Rq)

RProvid

L

Tail (L)

<Request, (Pr,Rq)>

L

[ < OrderReceived, (C01, C2210, (L1; L2), initialised)>, nullTransition, nullThread ]

Initial (<OrderReceived, (C01, C2210, (L1; L2), initialised)>

[ M, nullTransition, [ <Rprov, (L1; L2) > <VerifCard,C2210> <Order, (C01, C2210, (L1; L2), initialised > <RepProvOk, > <RepProvNotOk, > <TestRequest, >VerifandRequestProv , nullThread ] ]

Order ; VerifAndRequest

Exemple : séquence de franchissement

OrderResult

Order

Cust.Order

<Rprov,ListCmd> <VerifCard, Code> <Order, (N, code, listCmd, CmdState) >

<2><3>

Built PC

OrderAccepted

<4>

[(N, code, listCmd, CmdState)]

[(N, code, listCmd, CmdState)]

VerifandRequestProv

[(N, code, listCmd, CmdState)]

[(N, code, listCmd, rejected)]

[(N, code, listCmd, notAvailable)][(N, code, listCmd,PcBuilt)]

[(N, code, listCmd,readyToBuilt)]

OrderReceived

CodeOk CodeNotOk

EndVerifCode

NotOK Ok

VerifCard

CodeReceived

ReceiveCodeCode

Code

CodeCode

Order

TestRequest

ReceiveListRequest

RepProv OK

L =

L

RepProvNot OK<0><1>

RequestReady

(Pr,Rq) (Pr,Rq)

SandRequest

(Pr,Rq) (Pr,Rq)

RProvid

L

Tail (L)

<Request, (Pr,Rq)>

L

Exemple : séquence de franchissement

[ M, nullTransition, [ <Rprov, (L1; L2) > <VerifCard,C2210> <Order, (C01, C2210, (L1; L2), initialised > <RepProvOk, > <RepProvNotOk, > <TestRequest, >VerifandRequestProv , nullThread ] ]

[ M, nullTransition, [ <RequestReady, (Pr1, L1) (Pr2, L2) > <TestRequest, (Pr1, L1) (Pr2, L2) ><CodeReceived,C2210> <Order, (C01, C2210, (L1; L2), initialised > <RepProvOk, > <RepProvNotOk, > VerifandRequestProv , nullThread ] ]

ReceiveCode // (ReceiveListRequets ; ReceiveListRequets)

OrderResult

Order

Cust.Order

<Rprov,ListCmd> <VerifCard, Code> <Order, (N, code, listCmd, CmdState) >

<2><3>

Built PC

OrderAccepted

<4>

[(N, code, listCmd, CmdState)]

[(N, code, listCmd, CmdState)]

VerifandRequestProv

[(N, code, listCmd, CmdState)]

[(N, code, listCmd, rejected)]

[(N, code, listCmd, notAvailable)][(N, code, listCmd,PcBuilt)]

[(N, code, listCmd,readyToBuilt)]

OrderReceived

Exemple : séquence de franchissement

CodeOk CodeNotOk

EndVerifCode

NotOK Ok

VerifCard

CodeReceived

ReceiveCodeCode

Code

CodeCode

Order

TestRequest

ReceiveListRequest

RepProv OK

L =

L

RepProvNot OK<0><1>

RequestReady

(Pr,Rq) (Pr,Rq)

SandRequest

(Pr,Rq) (Pr,Rq)

RProvid

L

Tail (L)

<Request, (Pr,Rq)>

L

[ M, nullTransition, [ <RequestReady, (Pr1, L1) (Pr2, L2) > <TestRequest, (Pr1, L1) (Pr2, L2) ><CodeReceived,C2210> <Order, (C01, C2210, (L1; L2), initialised > <RepProvOk, > <RepProvNotOk, > VerifandRequestProv , nullThread ] ]

OrderResult

Order

Cust.Order

<Rprov,ListCmd> <VerifCard, Code> <Order, (N, code, listCmd, CmdState) >

<2><3>

Built PC

OrderAccepted

<4>

[(N, code, listCmd, CmdState)]

[(N, code, listCmd, CmdState)]

VerifandRequestProv

[(N, code, listCmd, CmdState)]

[(N, code, listCmd, rejected)]

[(N, code, listCmd, notAvailable)][(N, code, listCmd,PcBuilt)]

[(N, code, listCmd,readyToBuilt)]

OrderReceived

RequestOk

EndRequest

(Pr,Rq,OK)(Pr,Rq,NotOK)RequestNotOk

Request

RequestReceived

ReceiveRequest(Pr,Rq)

(Pr,Rq)

(Pr,Rq)

(Pr,Rq)

RequestOk

EndRequest

(Pr,Rq,OK)(Pr,Rq,NotOK)RequestNotOk

Request

RequestReceived

ReceiveRequest(Pr,Rq)

(Pr,Rq)

(Pr,Rq)

(Pr,Rq)

[ M, nullTransition, [<CodeReceived, C2210> <TestRequest, (Pr1, L1) (Pr2, L2) > <Order, (C01, C2210, (L1; L2), initialised > <RepProvOk, > <RepProvNotOk, >, VerifandRequestProv , [ <Request, (Pr1, L1) >, SandRequest , nullThread] [ <Request, (Pr2, L2) >, SandRequest , nullThread ] ] ]

(SandRequest ; SandRequest) 

Exemple : séquence de franchissement

CodeOk CodeNotOk

EndVerifCode

NotOK Ok

VerifCard

CodeReceived

ReceiveCodeCode

Code

CodeCode

Order

TestRequest

ReceiveListRequest

RepProv OK

L =

L

RepProvNot OK<0><1>

RequestReady

(Pr,Rq) (Pr,Rq)

SandRequest

(Pr,Rq) (Pr,Rq)

RProvid

L

Tail (L)

<Request, (Pr,Rq)>

L

OrderResult

Order

Cust.Order

<Rprov,ListCmd> <VerifCard, Code> <Order, (N, code, listCmd, CmdState) >

<2><3>

Built PC

OrderAccepted

<4>

[(N, code, listCmd, CmdState)]

[(N, code, listCmd, CmdState)]

VerifandRequestProv

[(N, code, listCmd, CmdState)]

[(N, code, listCmd, rejected)]

[(N, code, listCmd, notAvailable)][(N, code, listCmd,PcBuilt)]

[(N, code, listCmd,readyToBuilt)]

OrderReceived

RequestOk

EndRequest

(Pr,Rq,OK)(Pr,Rq,NotOK)RequestNotOk

Request

RequestReceived

ReceiveRequest(Pr,Rq)

(Pr,Rq)

(Pr,Rq)

(Pr,Rq)

RequestOk

EndRequest

(Pr,Rq,OK)(Pr,Rq,NotOK)RequestNotOk

Request

RequestReceived

ReceiveRequest(Pr,Rq)

(Pr,Rq)

(Pr,Rq)

(Pr,Rq)

[ M, nullTransition, [<CodeReceived, C2210> <TestRequest, (Pr1, L1) (Pr2, L2) > <Order, (C01, C2210, (L1; L2), initialised > <RepProvOk, > <RepProvNotOk, >, andRequestProv , [ <Request, (Pr1, L1) >, SandRequest , nullThread] [ <Request, (Pr2, L2) >, SandRequest , nullThread ] ] ]

[M, nullTransition, [<TestRequest, (Pr1, L1) (Pr2, L2) > <EndVerifCode, NotOk> <Order, (C01, C2210, (L1; L2), initialised) > <RepProvOk, > <RepProvNotOk, >, VerifandRequestProv , [<RequestReceived, (Pr1, L1) >,SandRequest , nullThread ] [<RequestReceived, (Pr2,L2) >, SandRequest , nullThread ] ] ]

CodeNotOk // ReceiveRequest // ReceiveRequest

Exemple : séquence de franchissement

OrderResult

Order

Cust.Order

<Rprov,ListCmd> <VerifCard, Code> <Order, (N, code, listCmd, CmdState) >

<2><3>

Built PC

OrderAccepted

<4>

[(N, code, listCmd, CmdState)]

[(N, code, listCmd, CmdState)]

VerifandRequestProv

[(N, code, listCmd, CmdState)]

[(N, code, listCmd, rejected)]

[(N, code, listCmd, notAvailable)][(N, code, listCmd,PcBuilt)]

[(N, code, listCmd,readyToBuilt)]

OrderReceived

[M, nullTransition, [<TestRequest, (Pr1, L1) (Pr2, L2) > <EndVerifCode, NotOk> <Order, (C01, C2210, (L1; L2), initialised) > <RepProvOk, > <RepProvNotOk, >, VerifandRequestProv , [<RequestReceived, (Pr1, L1) >,SandRequest , nullThread ] [<RequestReceived, (Pr2,L2) >, SandRequest , nullThread ] ] ]

[<OrderResult, (C01, C2210, (L1; L2), Rejected)>, nullTransition, nullThread ]

Exemple : Implémentation dans Maude

Plate-forme utilisée : version 2.0.1 de Maude sous Linux

Conclusion

Intégration de la récursivité dans les ECATNets : intérêt dans la modélisation de processus workflows flexibles.

Logique de réécriture : exprimer la sémantique des RECATNets de manière naturelle

Le system Maude : créer un environnement d’exécution et d’analyse pour les RECATNets

- Dispose d’un ensemble d’outils permettant le raisonnement formel sur les spécifications produites

Model checking (on the fly LTL model checker)

Extension du modèle : Définir des mécanismes additionnels

- Paramétrer le marquage initial et l’état de terminaison des sous-réseaux par la profondeur de la récursion

Analyse comportementale - Vérification de propriété (Soundness property) Assurer le comportement correct du workflow sous jacent (pas de deadlock, pas de tâches irréalisables, terminaison propre)

- Model checking Définir formellement la relation entre les RECATNets et les RdPRs (La théorie des catégories)

Travaux futurs

Bibliographie de base

[AaHK00] W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros. Advanced Workflow Patterns. In LNCS volume 1901. Springer-Verlag, Berlin, 2000.

[BeMa92] M. Bettaz,M. Maouche « How to specify non determinism and true concurrency with algebraic terms nets », in LNCS, No 655, Springer-Verlag, 1992, pp. 164-180

[HaPo00] S. Haddad and D. Poitrenaud.Modelling and analyzing systems with recursive Petri nets. (WODES'2000), pages 449-458, Belgium 2000. Kluwer Academic Publishers.

[Mes92] J. Meseguer, Conditional Rewriting Logic as Unified Model of Concurrency. TCS Vol. 96 pages 73- 155, 1992