Awatef Hicheur CEDRIC - CNAM Paris

Présentation au sujet: "Awatef Hicheur CEDRIC - CNAM Paris"— Transcription de la présentation:

1 Awatef Hicheur CEDRIC - CNAM Paris
Les ECATNets récursifs pour la modélisation et l’analyse des processus workflows flexibles Awatef Hicheur CEDRIC - CNAM Paris Séminaire MeFoSyLoMa, le 12 Mai 2006

2 Plan Problématique Formalismes de base Les ECATNets récursifs
- 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

3 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

4 Workflow 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

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

6 Limitations des WFMS actuels
Vérification et analyse des processus workflows Utilisation des méthodes formelles pour la spécification des workflows (Réseaux de Petri, Machine à état, algèbres de processus..etc.) 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 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

7 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

8 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.

9 Logique de Réécriture : notions de base
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) Langage supportant les calculs en logique de réécriture Maude est un langage réflexif de haute performance et un système supportant à la fois la spécification et la programmation des logiques équationnelles et de réécriture pour un grand choix d'application. Maude est influencé d'une façon importante par le langage OBJ3, qui peut être vu comme un sous langage de la logique équationnelle. En plus de la spécification et de la programmation équationnelles, Maude supporte aussi les calculs en logique de réécriture.

10 Les ECATNets ECATNets : "Extended Concurrent Algebraic Term Nets ",
(M. Bettaz,1993) 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

11 Un exemple d’un ECATNet
ECATNets : Syntaxe P‘ : S’ P : S IC(p, t) DT(p, t) TC(t) CT(t, p’) Un exemple d’un ECATNet 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

12 Un exemple d’un ECATNet
ECATNets : Sémantique P‘ : S’ P : S IC(p, t) DT(p, t) TC(t) CT(t, p’) Un exemple d’un ECATNet 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

13 ECATNets : Règles de réécriture
Notation :  : union multi-ensembliste sur les pairs <p, [m]> (ACI axioms) Une transition t est décrite par une règle de réécriture ( t: M ® M’ ), M, M’ de sorte Marking 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

14 ECATNets : Règles de réécriture
Une transition t est décrite par une règle de réécriture ( t: M ® M’ ) 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]

15 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é

16 Réseaux de Petri récursifs (RdPR)
Un état de terminaison est atteint dans un réseau (étape de coupure): - 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 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

17 Un exemple illustratif RdPR
Etat du réseau : Arbre de marquage ( Marquage étendu ) Transition abstraite Marquage initial P P1 t1 t2 P3 P2 P tabs P1 <0> <1> Transition élémentaire P’1 P’2 Indice de terminaison Marquages finaux : 0={M(P3)>0} 1={M(P2)>0} Une famille indexée de représentations effective d’ensembles semi-linéaires de marquages finaux

18 Exemple illustratif (suite)
Etat du réseau : Arbre de marquage ( Marquage étendu )  P P1 t1 t2 P3 P2 tabs tabs P1 P1 <0> <1> P’1 P’2 Marquages finaux : 0={M(P3)>0} 1={M(P2)>0}

19 Exemple illustratif (suite)
Etat du réseau : Arbre de marquage ( Marquage étendu )  P P1 t1 t2 P3 P2 tabs tabs P1 P3 <0> <1> P’1 P’2 Marquages finaux : 0={M(P3)>0} 1={M(P2)>0}

20 Exemple illustratif (suite)
Etat du réseau : Arbre de marquage ( Marquage étendu )  P P1 t1 t2 P3 P2 tabs tabs P1 P3 <0> <1> Coupure avec l’indice de terminaison <0> P’1 P’2 Marquages finaux : 0={M(P3)>0} 1={M(P2)>0}

21 Etat du réseau : Arbre de marquage ( Marquage étendu )
Exemple illustratif Etat du réseau : Arbre de marquage ( Marquage étendu ) P’1 P tabs P1 <0> <1> P’1 P’2 Marquages finaux : 0={M(P3)>0} 1={M(P2)>0}

22 ECATNets récursifs (RECATNets)

23 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

24 RECATNets : syntaxe et sémantique
CT(pt) 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 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(pt) comme marquage initial

25 RECATNets : syntaxe et sémantique
P‘ : S’ P : S IC(p, t) DT(p, t) TC(t) CT(t, p’) Transition élémentaire {tabsj, i } 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

26 État d’un RECATNet 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, 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, … ] ] ]. Marquage du réseau racine Ms0 Transition abstraite engendrant le sous réseau tabs1 tabsn tabs2 Ms1 Ms2 Msn Marquage d’un sous-réseau tabsn.j tabs1.1 tabs1.j tabsn.1 Ms1.1 Ms1.j Ms2.1 Ms2.j Msn.1 Ms2.j

27 État d’un RECATNet L’état distribué des RECATNets est formalisé par la théorie équationelle suivante (syntaxe Maude) 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.

28 RECATNets : Règles de réécriture (1/3)
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. 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 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 ] 

29 RECATNets : Règles de réécriture (2/3)
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 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] ]

30 RECATNets : Règles de réécriture (3/3)
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 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]

31 Propriété comportementale : atteignabilité
Un RECATNet Une Théorie de réécriture Réécriture modulo ACI avec la règle de réécriture correspondante Franchissement d’une transition (abstraite ou élémentaire) ou d’une étape de coupure 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.

32 Les RECATNets pour la modélisation des workflows
L’objectif : modélisation de processus workflows flexibles dont la structure évolue selon le contexte d’exécution . 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

33 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

34 Avantages 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

35 Exemple : « online shopping workflow »
Service de carte de crédit Service de vente en ligne d’ordinateurs Commande en ligne Client Service recherche en stock du fournisseur (i)

36 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)] VerifandRequestProv [(N, code, listCmd, rejected)] [(N, code, listCmd, notAvailable)] [(N, code, listCmd,readyToBuilt)] [(N, code, listCmd,PcBuilt)] OrderReceived 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)  

37 Exemple : « online shopping workflow » Modélisation à l’aide des RECATNets
CodeOk CodeNotOk EndVerifCode NotOK Ok VerifCard CodeReceived ReceiveCode Code Order TestRequest ReceiveListRequest RepProv OK L =  L   RepProvNot OK <0> <1> RequestReady (Pr,Rq) SandRequest RProvid L Tail (L) <Request, (Pr,Rq)> RequestOk EndRequest (Pr,Rq,OK) (Pr,Rq,NotOK) RequestNotOk Request RequestReceived ReceiveRequest (Pr,Rq) 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)  

38 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)] VerifandRequestProv [(N, code, listCmd, rejected)] [(N, code, listCmd, notAvailable)] [(N, code, listCmd,readyToBuilt)] [(N, code, listCmd,PcBuilt)] OrderReceived Initial (<OrderReceived, (C01, C2210, (L1; L2), initialised)> [ < OrderReceived, (C01, C2210, (L1; L2), initialised)>, nullTransition, nullThread ]

39 Exemple : séquence de franchissement
CodeOk CodeNotOk EndVerifCode NotOK Ok VerifCard CodeReceived ReceiveCode Code Order TestRequest ReceiveListRequest RepProv OK L =  L   RepProvNot OK <0> <1> RequestReady (Pr,Rq) SandRequest RProvid L Tail (L) <Request, (Pr,Rq)> OrderResult Order Cust.Order <Rprov,ListCmd> <VerifCard, Code>  <Order, (N, code, listCmd, CmdState) > <2> <3> Built PC OrderAccepted <4> [(N, code, listCmd, CmdState)] VerifandRequestProv [(N, code, listCmd, rejected)] [(N, code, listCmd, notAvailable)] [(N, code, listCmd,PcBuilt)] [(N, code, listCmd,readyToBuilt)] OrderReceived Order ; VerifAndRequest Initial (<OrderReceived, (C01, C2210, (L1; L2), initialised)> [ < OrderReceived, (C01, C2210, (L1; L2), initialised)>, nullTransition, nullThread ] [ M, nullTransition, [ <Rprov, (L1; L2) >  <VerifCard,C2210>  <Order, (C01, C2210, (L1; L2), initialised >  <RepProvOk, >  <RepProvNotOk, > <TestRequest, >VerifandRequestProv , nullThread ] ]

40 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)] VerifandRequestProv [(N, code, listCmd, rejected)] [(N, code, listCmd, notAvailable)] [(N, code, listCmd,PcBuilt)] [(N, code, listCmd,readyToBuilt)] OrderReceived CodeOk CodeNotOk EndVerifCode NotOK Ok VerifCard CodeReceived ReceiveCode Code Order TestRequest ReceiveListRequest RepProv OK L =  L   RepProvNot OK <0> <1> RequestReady (Pr,Rq) SandRequest RProvid L Tail (L) <Request, (Pr,Rq)> ReceiveCode // (ReceiveListRequets ; ReceiveListRequets) [ 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 ] ]

41 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)] VerifandRequestProv [(N, code, listCmd, rejected)] [(N, code, listCmd, notAvailable)] [(N, code, listCmd,PcBuilt)] [(N, code, listCmd,readyToBuilt)] OrderReceived CodeOk CodeNotOk EndVerifCode NotOK Ok VerifCard CodeReceived ReceiveCode Code Order TestRequest ReceiveListRequest RepProv OK L =  L   RepProvNot OK <0> <1> RequestReady (Pr,Rq) SandRequest RProvid L Tail (L) <Request, (Pr,Rq)> RequestOk EndRequest (Pr,Rq,OK) (Pr,Rq,NotOK) RequestNotOk Request RequestReceived ReceiveRequest (Pr,Rq) RequestOk EndRequest (Pr,Rq,OK) (Pr,Rq,NotOK) RequestNotOk Request RequestReceived ReceiveRequest (Pr,Rq) (SandRequest ; SandRequest)  [ 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 ] ] ] [ M, nullTransition, [ <RequestReady, (Pr1, L1)  (Pr2, L2) >  <TestRequest, (Pr1, L1)  (Pr2, L2) ><CodeReceived,C2210> <Order, (C01, C2210, (L1; L2), initialised >  <RepProvOk, > <RepProvNotOk, > VerifandRequestProv , nullThread ] ]

42 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)] VerifandRequestProv [(N, code, listCmd, rejected)] [(N, code, listCmd, notAvailable)] [(N, code, listCmd,PcBuilt)] [(N, code, listCmd,readyToBuilt)] OrderReceived CodeOk CodeNotOk EndVerifCode NotOK Ok VerifCard CodeReceived ReceiveCode Code Order TestRequest ReceiveListRequest RepProv OK L =  L   RepProvNot OK <0> <1> RequestReady (Pr,Rq) SandRequest RProvid L Tail (L) <Request, (Pr,Rq)> RequestOk EndRequest (Pr,Rq,OK) (Pr,Rq,NotOK) RequestNotOk Request RequestReceived ReceiveRequest (Pr,Rq) RequestOk EndRequest (Pr,Rq,OK) (Pr,Rq,NotOK) RequestNotOk Request RequestReceived ReceiveRequest (Pr,Rq) CodeNotOk // ReceiveRequest // ReceiveRequest [ 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 ] ] ]

43 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)] VerifandRequestProv [(N, code, listCmd, rejected)] [(N, code, listCmd, notAvailable)] [(N, code, listCmd,PcBuilt)] [(N, code, listCmd,readyToBuilt)] OrderReceived 2  [<OrderResult, (C01, C2210, (L1; L2), Rejected)>, nullTransition, 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 ] ] ]

44 Exemple : Implémentation dans Maude
Plate-forme utilisée : version de Maude sous Linux

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

46 Travaux futurs 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)

47 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 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 [HaPo00] S. Haddad and D. Poitrenaud.Modelling and analyzing systems with recursive Petri nets. (WODES'2000), pages , Belgium Kluwer Academic Publishers. [Mes92] J. Meseguer, Conditional Rewriting Logic as Unified Model of Concurrency. TCS Vol. 96 pages , 1992