Sp´ ecification des requis

Comme illustration de l’utilisation de la BP-logique, nous pr´esentons dans cette section la sp´ecification formelle de quelques propri´et´es temporelles d´esirables pour notre exemple. Cependant, pour r´ealiser cette v´erification sur l’outil HAL, il est n´ecessaire de traduire les propri´et´es exprim´ees dans la BP-logique en une syntaxe adapt´ee `a l’outil HAL (voir Chapitre 7, Section 7.4 pour plus de d´etails).

Nous avons soumis toutes les propri´et´es au model-checker HAL, et nous en avons tir´e les conclu- sions qui sont ´enum´er´ees ci-apr`es au fur et `a mesure du d´eploiement des propri´et´es.

R´eactivit´e (responsiveness) La propri´et´e indiquant que chaque fois que le Client envoie un ordre de vente, il obtiendra un plan de vente apr`es un temps fini, et chaque fois qu’un client accepte un plan de vente, et l’ordre est approuv´e par le service de Surveillance, il recevra un accus´e de r´eception, est une propri´et´e de r´eactivit´e. Cette propri´et´e peut ˆetre formalis´ee par la formule suivante :

𝜙1 & 𝜙2 ou :

𝜙1 = 𝐴𝐺({𝑠(𝑞𝑡𝑦)}𝐸𝐹 ({¯𝑝⟨𝑝𝑙𝑎𝑛⟩}𝑡𝑟𝑢𝑒))

𝜙2 = 𝐴𝐺(({𝑎(𝑜𝑘){𝑏(𝑜𝑘)})𝐸𝐹 ({¯𝑟⟨𝑟𝑒𝑐𝑒𝑖𝑝𝑡⟩}𝑡𝑟𝑢𝑒))

Exprim´ee dans la syntaxe HAL1, cela donne :

define response1 = AG([s ?qty]EF([p !plan]true)) define response2 = AG([a ?ok]EF([r !receipt]true)) define response3 = AG([b ?ok]EF([r !receipt]true))

La propri´et´e a ´et´e valid´ee sur le mod`ele par l’outil HAL.

Disponibilit´e La propri´et´e indiquant que dans chaque ´etat le service de Courtage (Broker) peut accepter une demande est une propri´et´e de disponibilit´e. Cela peut ˆetre exprim´e par la formule suivante :

𝐴𝐺({𝑠(𝑞𝑡𝑦)}𝑡𝑟𝑢𝑒) Cette propri´et´e se traduit ainsi dans la syntaxe HAL :

define available = AG([s ?qty]true) La propri´et´e a ´et´e valid´ee sur le mod`ele par l’outil HAL.

Cependant une autre formulation est possible qui utilise le pr´edicat de terminaison : 𝐴𝐺({𝐵𝑟𝑜𝑘𝑒𝑟✓}𝑓 𝑎𝑙𝑠𝑒)

qui signifie que le service du Broker ne se termine jamais.

Fiabilit´e La propri´et´e indiquant que la r´eception d’une livraison est garantie `a chaque fois qu’un plan de vente a ´et´e envoy´e est une propri´et´e de la fiabilit´e. Cela peut ˆetre exprim´e par la formule suivante :

𝐴𝐺({𝑠(𝑞𝑡𝑦)}𝐸𝐹 {¯𝑝⟨𝑝𝑙𝑎𝑛⟩}𝑡𝑟𝑢𝑒) Cette propri´et´e a ´egalement ´et´e valid´ee sur le mod`ele par l’outil HAL.

´

Equit´e La propri´et´e indiquant que si un client envoie un nombre infini d’ordres de vente, il recevra un nombre infini de plans de vente et des re¸cus, est une propri´et´e d’´equit´e. Cela peut ˆetre exprim´e par la formule suivante :

𝜙1 ∨ 𝐴𝐺(𝜓1 & 𝜓2) ou :

𝜙1 = ∼ 𝐴𝐺(𝐸𝐹 {𝑠()}𝑡𝑟𝑢𝑒)

𝜓2 = 𝐸𝐹 ({¯𝑟⟨𝑟𝑒𝑐𝑒𝑖𝑝𝑡⟩}𝑡𝑟𝑢𝑒

𝜓2 = 𝐸𝐹 ({¯𝑝⟨𝑝𝑙𝑎𝑛⟩}𝑡𝑟𝑢𝑒

Sa syntaxe HAL est :

define fairness1 = AG(EF[s ?*]true) | (AG( EF<r !receipt>true & EF <p !plan>true ) )

Cette propri´et´e a ´egalement ´et´e valid´ee sur le mod`ele par l’outil HAL.

S´ecurit´e (Safety) Voici deux exemples de propri´et´es de s´ecurit´e applicables au cas du march´e des capitaux.

Par exemple, la propri´et´e qui indique qu’un re¸cu ne doit jamais ˆetre envoy´e avant qu’il n’ait ´et´e approuv´e par le service de Surveillance est une propri´et´e de s´ecurit´e. Cela peut ˆetre exprim´e par la formule suivante :

∼ 𝐸𝐹 (∼ 𝐸𝐹 ({¯𝑏⟨𝑜𝑘⟩}𝑡𝑟𝑢𝑒 & {𝑟()}𝑡𝑟𝑢𝑒) La syntaxe HAL de cette propri´et´e est donc :

define safety1 = EF( <b !ok>true & [r ?*]true)

Cette propri´et´e a ´et´e invalid´ee ; ce qui est acceptable, car un accus´e de r´eception est envoy´e uniquement si la d´ecision est favorable.

Le deuxi`eme exemple indique qu’une approbation ne doit jamais ˆetre envoy´ee au client avant qu’il n’ait re¸cu un plan de vente. Cela peut ˆetre exprim´e par la formule suivante :

∼ 𝐸𝐹 ({¯𝑝⟨𝑝𝑙𝑎𝑛⟩} ∼ 𝑡𝑟𝑢𝑒 & {𝑎(𝑜𝑘)}𝑡𝑟𝑢𝑒) Cette propri´et´e se traduit ainsi dans la syntaxe HAL :

define safety2 = EF(<p !plan>false & [a ?ok]true) Cette propri´et´e a ´egalement ´et´e valid´ee sur le mod`ele par l’outil HAL.

Vivacit´e Un exemple d’une propri´et´e de vivacit´e pertinente au cas d’utilisation du march´e d’ac- tion est le suivant : le syst`eme ex´ecutera l’action 𝑡⟨𝑜𝑟𝑑𝑒𝑟⟩ (v´erification de l’ordre d’achat) chaque fois qu’il aura ex´ecut´e l’action 𝑎⟨𝑜𝑘⟩ (approbation). Cela peut ˆetre exprim´e par la formule suivante :

𝐴𝐺({¯𝑎⟨𝑜𝑘⟩})𝐸𝐹 ({¯𝑡⟨𝑜𝑟𝑑𝑒𝑟⟩}𝑡𝑟𝑢𝑒) Cette propri´et´e a ´egalement ´et´e valid´ee sur le mod`ele par l’outil HAL.

Propri´et´es de tol´erance aux pannes

Les pannes sont mod´elis´ees directement par les actions des processus eux-mˆemes. Pour chaque action de panne, le mode de d´efaillance relative est ´egalement sp´ecifi´e. Par exemple, une d´efaillance dans un ´etat du processus ´etend le comportement du syst`eme en permettant `a cette d´efaillance de se produire dans cet ´etat. Plus pr´ecis´ement, une erreur est lanc´ee sur le canal 𝑡ℎ𝑟𝑜𝑤 et captur´ee par le gestionnaire d’erreurs. La survenance d’erreurs est incluse dans la sp´ecification du processus en d´efinissant les hypoth`ese pertinentes pour cette erreur. Cela permet d’´etudier le comportement du syst`eme tol´erant au pannes sous diff´erents sc´enarios d’erreurs. Voil`a ci-apr`es, quelques exemples de propri´et´es pertinentes pour le comportement du syst`eme de march´e des actions :

1. Le courtier apr`es avoir ´emis un signal d’erreurs sur le canal 𝑓𝑖, 𝑖 ∈ {𝑏𝑏, 𝑒𝑑, 𝑎𝑠𝑑}, invoquera

le gestionnaire d’erreurs et sera averti sur le canal 𝑟 que le gestionnaire a fini :

𝐴𝐺({ ¯𝑓𝑏𝑏⟨⟩} ∼ 𝑡𝑟𝑢𝑒 & { ¯𝑓𝑒𝑠𝑑⟨⟩} ∼ 𝑡𝑟𝑢𝑒 & { ¯𝑓𝑎𝑠𝑑⟨⟩} ∼ 𝑡𝑟𝑢𝑒 ∨ 𝐸𝐹 {¯𝑟⟨⟩} ∼ 𝑡𝑟𝑢𝑒)

2. Apr`es avoir ´et´e activ´e par l’interm´ediaire du canal 𝑒𝑓 ℎ le gestionnaire d’erreurs sera in´evita-

blement d´esactiv´e par l’interm´ediaire du canal 𝑑𝑖𝑠𝑓 ℎ :

𝐴𝐺({𝑒𝑛ℎ()} ∼ 𝑡𝑟𝑢𝑒 ∣ 𝐸𝐹 {𝑑𝑒ℎ()}𝑡𝑟𝑢𝑒)

La sp´ecification du cas d’´etude a ´et´e r´ealis´ee en tirant partie de toutes les facilit´es offertes par le BP-calcul. Elle a ensuite ´et´e v´erifi´ee en commen¸cant d’abord par une sp´ecification en BP-logique des propri´et´es d´esirables, puis leur v´erification dans l’outil HAL. L’introduction d’un scope au mod`ele a impliqu´e une plus grande complexit´e. La g´en´eration de l’automate par HAL pour le mod`ele sans scope a ´et´e r´ealis´ee en moins d’une demi-seconde et a abouti `a un automate de six ´etats. Alors que le mod`ele du courtier avec un scope, qui n’est qu’une partie de l’ensemble du mod`ele, a g´en´er´e un automate avec plus de 1000 ´etats en plus de 600 secondes. Ceci illustre le fait que le langage WS-BPEL est tr`es puissant mais sa v´erification formelle n’est pas une tˆache facile quand elle est appliqu´ee `a des cas lourds.