V´ erification formelle

A cette ´etape du processus, nous allons d´efinir un certain nombre de propri´et´es comporte- mentales souhaitables pour notre syst`eme. Des exemples de propri´et´es souhaitables g´en´erales on ´et´e introduites `a la Section 2.6.2 du Chapitre 2. Nous en avons retenu quelques-unes qui nous paraissent pertinentes pour notre mod`ele.

- Disponibilit´e : Le portail de cr´edit est toujours prˆet pour accepter une demande de cr´edit. Cette propri´et´e se formalise comme suit :

𝐴𝐺([𝑙𝑜𝑔𝑖𝑛?𝑥𝑢𝑠𝑒𝑟]𝑡𝑟𝑢𝑒)

- R´eactivit´e : Chaque fois que le client requiert une ´evaluation de sa demande de cr´edit, il obtiendra toujours une r´eponse, `a moins qu’il annule sa propre demande.

- Pertinence de la corr´elation : Le client re¸coit toujours une r´eponse qui correspond `a sa demande de cr´edit. Ainsi, il ne doit pas arriver que le service lui envoie une ´evaluation li´ee `a une autre demande de cr´edit ou qu’il y ait un m´elange des donn´ees li´ees `a des demandes de cr´edit diff´erentes.

Les deux pr´ec´edentes propri´et´es peuvent s’exprimer grˆace `a la mˆeme formule : 𝐴𝐺([𝑔𝑒𝑡𝐶𝑟𝑒𝑑𝑖𝑡𝑅𝑒𝑞𝑢𝑒𝑠𝑡?(𝑥𝑖𝑑, 𝑥𝑚𝑜𝑛𝑡𝑎𝑛𝑡, 𝑥𝑐𝑢𝑠𝑡)]𝑡𝑟𝑢𝑒)

𝐸𝐹 ([𝑟𝑒𝑞𝑃 𝑟𝑜𝑐𝑒𝑠𝑠𝑖𝑛𝑔!(𝑥𝑖𝑑, , 𝑥𝑚𝑜𝑛𝑡𝑎𝑛𝑡, 𝑥𝑐𝑢𝑠𝑡)]𝑡𝑟𝑢𝑒 ∨ [𝑎𝑏𝑎𝑛𝑑𝑜𝑛?∗]𝑡𝑟𝑢𝑒)

A la r´eception d’une requˆete identifi´ee par 𝑥𝑖𝑑, le syst`eme r´epond au client identifi´e par 𝑥𝑐𝑢𝑠𝑡 avec le mˆeme identifiant 𝑥𝑖𝑑 sur le port 𝑟𝑒𝑞𝑃 𝑟𝑜𝑐𝑒𝑠𝑠𝑖𝑛𝑔, `a moins de recevoir une demande d’annulation sur le port 𝑎𝑏𝑎𝑛𝑑𝑜𝑛.

- Interruptibilit´e : Le client peut exiger l’annulation du processus de demande de cr´edit apr`es avoir choisi ce service.

𝐴𝐺([𝑔𝑒𝑡𝐶𝑟𝑒𝑑𝑖𝑡𝑅𝑒𝑞𝑢𝑒𝑠𝑡?(𝑥𝑖𝑑, 𝑥𝑚𝑜𝑛𝑡𝑎𝑛𝑡, 𝑥𝑐𝑢𝑠𝑡)]𝑡𝑟𝑢𝑒)𝐸𝐹 ([𝑎𝑏𝑎𝑛𝑑𝑜𝑛?∗])𝑡𝑟𝑢𝑒 D’autres propri´et´es comportementales plus sp´ecifiques `a ce cas peuvent ˆetre exprim´ees :

- Le client peut recevoir une offre seulement apr`es que sa demande de cr´edit ait ´et´e ´evalu´ee avec succ`es par un superviseur :

𝐴𝐺([𝑔𝑒𝑡𝐶𝑟𝑒𝑑𝑖𝑡𝑅𝑒𝑞𝑢𝑒𝑠𝑡?(𝑥𝑖𝑑, 𝑥𝑚𝑜𝑛𝑡𝑎𝑛𝑡, 𝑥𝑐𝑢𝑠𝑡)]𝑡𝑟𝑢𝑒)

∼ 𝐸𝐹 ([𝑟𝑒𝑞𝑃 𝑟𝑜𝑐𝑒𝑠𝑠𝑖𝑛𝑔!(𝑥𝑖𝑑, , 𝑥𝑚𝑜𝑛𝑡𝑎𝑛𝑡, 𝑥𝑐𝑢𝑠𝑡)]𝑡𝑟𝑢𝑒 ∧ [𝑎𝑛𝑠𝑤𝑒𝑟!∗]𝑡𝑟𝑢𝑒)

- Si une demande de cr´edit est accept´ee pour ´evaluation, (c’est `a dire qu’elle est ajout´ee `a une des deux listes de tˆaches) et que le client demande son annulation, alors le gestionnaire de compensation doit ˆetre activ´e, c’est `a dire la tˆache doit ˆetre retir´ee de la liste.

𝐴𝐺([𝑔𝑒𝑡𝐶𝑟𝑒𝑑𝑖𝑡𝑅𝑒𝑞𝑢𝑒𝑠𝑡?(𝑥𝑖𝑑, 𝑥𝑚𝑜𝑛𝑡𝑎𝑛𝑡, 𝑥𝑐𝑢𝑠𝑡)]𝑡𝑟𝑢𝑒)𝐸𝐹 [𝑎𝑏𝑎𝑛𝑑𝑜𝑛!∗] 𝐴𝐹 [𝐿𝑠𝑡𝐸𝑚𝑝? ∗ ∨𝐿𝑠𝑡𝑆𝑢𝑝?∗]𝑡𝑟𝑢𝑒

peut avoir lieu.

𝐴𝐺([𝑔𝑒𝑡𝐸𝑚𝑝𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑖𝑜𝑛!′𝑚𝑎𝑗′]𝑡𝑟𝑢𝑒 ∨ [𝑔𝑒𝑡𝑆𝑢𝑝𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑖𝑜𝑛!′𝑚𝑎𝑗′]𝑡𝑟𝑢𝑒) 𝐸𝐹 ([𝑔𝑒𝑡𝑈 𝑝𝑑𝑎𝑡𝑒!∗]𝑡𝑟𝑢𝑒 ∨ [𝑎𝑏𝑎𝑛𝑑𝑜𝑛!∗]𝑡𝑟𝑢𝑒)

- Avant le traitement d’une demande de cr´edit, le client doit introduire dans le syst`eme les informations de s´ecurit´e et les donn´ees sur son solde.

𝐴𝐺([𝑔𝑒𝑡𝐶𝑟𝑒𝑑𝑖𝑡𝑅𝑒𝑞𝑢𝑒𝑠𝑡?(𝑥𝑖𝑑, 𝑥𝑚𝑜𝑛𝑡𝑎𝑛𝑡, 𝑥𝑐𝑢𝑠𝑡)]𝑡𝑟𝑢𝑒) ∼ 𝐸𝐹 ([𝑝𝑢𝑡𝐸𝑚𝑝𝑇 𝑎𝑠𝑘𝐿𝑠𝑡?∗]𝑡𝑟𝑢𝑒 ∧ [𝑔𝑒𝑡𝐶𝑙𝑖𝑒𝑛𝑡𝐼𝑛𝑓 𝑜!∗])𝑓 𝑎𝑙𝑠𝑒) - Une demande de cr´edit doit toujours r´eussir.

𝐴𝐺([𝑔𝑒𝑡𝐶𝑟𝑒𝑑𝑖𝑡𝑅𝑒𝑞𝑢𝑒𝑠𝑡?(𝑥𝑖𝑑, 𝑥𝑚𝑜𝑛𝑡𝑎𝑛𝑡, 𝑥𝑐𝑢𝑠𝑡)]𝑡𝑟𝑢𝑒) 𝐸𝐹 ([𝑡𝑡𝐶𝑜𝑛𝑡𝑟𝑎𝑡!∗]𝑡𝑟𝑢𝑒 ∨ [𝑎𝑏𝑎𝑛𝑑𝑜𝑛!∗]𝑓 𝑎𝑙𝑠𝑒)

- Un superviseur peut toujours ˆetre requis pour ´evaluer une demande de cr´edit. 𝐴𝐺([𝑔𝑒𝑡𝐶𝑟𝑒𝑑𝑖𝑡𝑅𝑒𝑞𝑢𝑒𝑠𝑡?(𝑥𝑖𝑑, 𝑥𝑚𝑜𝑛𝑡𝑎𝑛𝑡, 𝑥𝑐𝑢𝑠𝑡)]𝑡𝑟𝑢𝑒) 𝐸𝐹 ([𝑡𝑡𝑆𝑢𝑝𝑒𝑟𝑣𝑖𝑠𝑒𝑢𝑟!∗]𝑡𝑟𝑢𝑒 ∨ [𝑎𝑏𝑎𝑛𝑑𝑜𝑛!∗]𝑓 𝑎𝑙𝑠𝑒)

Cette propri´et´e ne doit pas ˆetre v´erifi´ee par le syst`eme car un employ´e peut rejeter une demande avant qu’elle n’arrive au superviseur.

6.5 G´en´eration de code WS-BPEL

La g´en´eration (semi)-automatique de code WS-BPEL repose sur les transformations du chapitre 4. Nous indiquons la m´ethode pour le processus 𝑝𝑜𝑟𝑡𝑎𝑙 dont nous donnons ici le code g´en´er´e.

Le processus 𝑝𝑜𝑟𝑡𝑎𝑙 se pr´esente comme un scope :

{{𝑥𝑢𝑠𝑒𝑟, 𝑥𝑝𝑤𝑑, 𝑥𝑐𝑢𝑠𝑡}, 𝑃, 𝐻𝑝}

o`u 𝑃 est le processus principal du scope, et 𝐻 les gestionnaires (r´eduits dans ce cas, au seul gestionnaire d’erreurs).

Le gestionnaire d’erreurs se contente d’avertir le client de l’´echec de la connexion. Son BP-code est : 𝐻𝑝 = 𝐹 𝐻(𝑓𝐸𝑐ℎ𝑒𝑐𝐿𝑜𝑔𝑖𝑛).

Nous pouvons ainsi g´en´erer le code WS-BPEL suivant : <process name="Portal">

<scope>

<variable name="XUSER" messageType="string" /> <variable name="XPWD" messageType="string" /> <variable name="XCUST" messageType="string" /> </variables>

<faultHandlers>

<!-- Code du fault handler H1 --> <invoke> partnerLink="client" operation="auth" variable="EchecLogin" </invoke> </faultHandlers>

<!-- Code du processus principal --> </scope>

</process>

Le processus principal est :

𝑃 = 𝑙𝑜𝑔𝑖𝑛(𝑥𝑢𝑠𝑒𝑟, 𝑥𝑝𝑤𝑑, 𝑥𝑐𝑢𝑠𝑡) ⊳ 𝑎𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑖𝑜𝑛𝑖𝑛𝑣⟨𝑥𝑢𝑠𝑒𝑟, 𝑥𝑝𝑤𝑑⟩ ∣ ((𝑎𝑢𝑡𝑜𝑟𝑖𝑠𝑎𝑡𝑖𝑜𝑛(𝑥𝑢𝑠𝑒𝑟, 𝑟𝑒𝑝𝑜𝑛𝑠𝑒) ⊳ if (𝑟𝑒𝑝𝑜𝑛𝑠𝑒 = “𝑛𝑜𝑛′′) then 𝑡ℎ𝑟𝑜𝑤⟨𝑓𝑓 𝑎𝑖𝑙𝑒𝑑𝐿𝑜𝑔𝑖𝑛⟩) else 𝑆1 )

Il contient lui-mˆeme un scope 𝑆1 dont le mod`ele formel est :

𝑆1 = {{𝑠𝑒𝑠𝑠𝑖𝑜𝑛𝐼𝐷},

𝑙𝑜𝑔𝑔𝑒𝑑 ⟨𝑘𝑒𝑦, 𝑠𝑒𝑠𝑠𝑖𝑜𝑛𝐼𝐷⟩

∣ 𝑐𝑟𝑒𝑑𝑖𝑡𝑅𝑒𝑞𝑢𝑒𝑠𝑡(𝑠𝑒𝑠𝑠𝑖𝑜𝑛𝐼𝐷) ⊳ 𝑐𝑟𝑒𝑎𝑡𝑒𝐼𝑛𝑠𝑡 ⟨𝑠𝑒𝑠𝑠𝑖𝑜𝑛𝐼𝐷⟩ +... autres services fournis par le portail de credit ...), 𝐻𝑝1}

Donc 𝑃 se traduit comme suit : <sequence>

<receive name="ReceiveChoix" partnerLink="Client" operation="login" variable="XUSER" variable="XPWD" variable="XCUST" createInstance="no" /> <flow> <invoke> partnerLink="authentication" operation="auth" variable="XUSER" variable="XPWD" </invoke> <pick> <onMessage partnerLink="authentication" operation="autorized" variable="XUSER"> <throw faultName="tns:EchecLogin" /> </onMessage> <onMessage partnerLink="authentication" operation="autorized" variable="XUSER"> <!-- code du scope S1 --> </onMessage> </pick> </flow> </sequence>

Finalement, le code g´en´er´e pour le scope 𝑆1 est comme suit :

<scope name="S1"> <variables>

<variable name="SESSIONID" messageType="string" /> <variable name="KEY" messageType="string" />

</variables> <faultHandlers>

<!-- Code du fault handler --> </faultHandlers>

<invoke> partnerLink="authentication" operation="auth" variable="KEY" variable="SESSIONID" </invoke> <pick> <onMessage partnerLink="??" operation="creditRequest" variable="SESSIONID"> <invoke> partnerLink="??" operation="createInstance" variable="SESSIONID" </onMessage> <onMessage <!-- Autres services --> </onMessage> </pick> </flow> </scope>

Dans ce code g´en´er´e automatiquement `a l’aide des transformations du Chapitre 4, les r´ef´erences aux diff´erents espaces de noms est manquant. Elles sont donc ajout´ees manuellement.

Le code des autres services est g´en´er´e exactement de la mˆeme mani`ere. 6.6 Conclusion

Dans ce chapitre, nous avons montr´e sur une ´etude de cas significative traitant de la gestion d’une demande cr´edit dans un organisme bancaire, l’applicabilit´e du BP-calcul que nous avons introduit au Chapitre 3. Apr`es avoir donn´e une description informelle du probl`eme, nous l’avons formalis´e puis ´etabli un certain nombre de propri´et´es souhaitables du mod`ele exprim´ees dans la BP-logique.

La formalisation est compl`ete en ce sens qu’elle tient compte des diff´erents gestionnaires n´eces- saires `a l’application, ainsi que des m´ecanismes de corr´elation. En utilisant un processus it´eratif, nous pouvons v´erifier l’exactitude du syst`eme et proc´eder ensuite `a la g´en´eration semi-automatique du code WS-BPEL.

La principale contribution est d’avoir montr´e que le BP-calcul est suffisamment expressif et que, conjugu´e aux techniques inspir´ees du 𝜋-calcul appliqu´e, il permet de formaliser relativement ais´ement des cas d’´etudes complexes proches de ceux que l’on rencontre dans la vie r´eelle.

De mˆeme, nous avons montr´e que la 𝜋-logique, et son extension pour le BP-calcul, permettaient d’exprimer des propri´et´es d´ependantes du syst`eme ´etudi´e, mais qui peuvent aussi en ˆetre ind´epen- dantes. Plus encore, ces logiques permettent l’expression de tous types de propri´et´es et notamment des propri´et´es qui impliquent l’usage de la corr´elation.