Vérication de services CPL

Cette section vise à illustrer chacune des propriétés présentées ci-dessus, en consi-dérant des services écrits en CPL.

Aucune duplication de redirection. Cette propriété assure que, dans un même chemin d'exécution, l'appel n'est pas redirigé deux fois vers la même personne (pro-priété NoTwiceRedirectToTheSameUri de la gure 9.7). La téléphonie est un domaine où le temps d'exécution du service est une donnée importante correspondant au dé-lai d'attente de l'appelant. Si, lors de l'exécution d'un service, une personne n'est pas joignable, il est peu probable qu'elle le soit une fraction de seconde plus tard. Cette pro-priété permet donc de détecter des opérations inutiles, mais aussi de réduire le temps d'exécution du service à son minimum. Pour cela, elle nécessite l'introduction d'une trace des opérations de signalisation pour formuler que deux actions d'un même che-min d'exécution ne sont jamais équivalentes. Cette trace est réalisée grâce à la variable d'état signalingActions, qui contient l'ensemble des adresses sur lesquelles le service a déjà redirigé les appels. La propriété revient donc à contrôler qu'aucun doublon parmi les diverses adresses de redirection n'est présent dans la séquence signalingActions.

Enn, cette formule doit toujours être vraie, comme indiqué par l'opérateur logique '' (voir annexe A pour plus de détails).

Aucune redirection sur l'appelant. Cette propriété (NoRedirectToTheCaller de la gure 9.7) vérie qu'il n'existe aucun chemin d'exécution où l'appel est redirigé sur l'appelant. En eet, cette situation n'est généralement pas souhaitable par le dévelop-peur dans la mesure où elle empêche implicitement l'appelé d'être joignable par cette personne.

Aucun chemin infaisable. La propriété Consistency assure qu'une cascade de tests est correcte dans le sens où chacun des tests est faisable. En eet, si syntaxiquement certains tests apparaissent totalement corrects, leur succession peut poser des problèmes de consistance. Deux types de ltrage CPL sont pris en compte : (1) les ltrages sur les adresses, c'est-à-dire les identiants des appelants et (2) les ltrages sur les dates.

Appel entrant

...

oui non

L’adresse de l’appelant provient-elle du domaine

"example.com" ?

Redirection de l’appel sur la boîte vocale de Bob Redirection de l’appel

sur le téléphone mobile de Bob

L’adresse de l’appelant provient-elle du domaine

"work.example.com" ?

Rejet de l’appel

oui non

2

5 3

7 6

4 1

Fig. 9.8 Service CPL inconsistant (adresses)

La gure 9.8 présente une représentation logique d'un service erroné concernant une succession de tests sur le domaine d'où provient l'appel. À l'arrivée d'un appel, si l'adresse de l'appelant appartient au domaine example.com (n÷ud 2), l'appel est redirigé sur le téléphone mobile de Bob (n÷ud 3). Dans le cas contraire (n÷ud 4), si l'appelant appartient au domaine work.example.com (n÷ud 5), alors l'appel est redirigé sur sa boîte vocale (n÷ud 6). Néanmoins, ce cas ne peut jamais se produire parce qu'il est inclus au niveau du n÷ud 2. Ainsi ce service est totalement correct du point de vue du langage CPL, mais il contient cependant une inconsistance dans les décisions sur les adresses entraînant l'infaisabilité de la séquence 1-2-4-5-6. En programmation, ce code correspond à du code mort. Cet exemple est similaire à celui présenté à la gure 4.2 de la section 4.4. Ce dernier repose non pas sur un problème d'identication du domaine mais directement sur l'adresse de l'appelant. Une telle cascade de tests est relativement fréquente au niveau de la programmation de services de téléphonie écrits en CPL.

Sur le même principe, il peut arriver qu'un enchaînement de tests sur des évènements d'un calendrier puisse produire le même type d'inconsistance. En eet, considérons le service illustré par la gure 9.9. Ce service traite les appels diéremment selon le jour de la semaine et notamment si ces derniers se produisent le mardi (e.g., jour de la réunion hebdomadaire). Si tel est le cas, le service teste par la suite si l'appel a lieu entre le 12/07 et le 17/07 an d'aiguiller l'appel sur la boîte vocale pendant cette période (e.g.,

vacances annuelles). Cependant, il n'y a aucun mardi pendant cette période et donc, là encore, le chemin 1-2-3-4-5 n'est pas réalisable.

Appel entrant

...

oui non

L’appel a-t-il lieu un mardi ?

Redirection de l’appel sur la boîte vocale de Bob

Redirection de l’appel sur le téléphone de Bob

L’appel a-t-il lieu entre le 12/07

et le 17/07 ?

Redirection de l’appel sur le téléphone mobile de Bob

oui non

1 2

7

4

5 6

3

réunion hebdomadaire

vacances annuelles

Fig. 9.9 Service CPL inconsistant (dates)

La nature verbeuse de CPL (dialecte XML) ne facilite pas la détection de tels conits lors de services plus complexes. De plus, de multiples aspects du langage peuvent être testés de la même manière. Ces exemples montrent bien le besoin de vérication de services et notamment de faisabilité des branches d'exécution.

Pour compléter cette illustration, nous présentons à la gure 9.10 le résultat de la vérication du service CPL contenant une inconsistence au niveau des dates (gure 9.9). Cet extrait présente le rapport d'erreurs produit par TLC. Dans cette situation, TLC spécie qu'une propriété ne peut pas être vériée (ici Consistency, gure 9.7) et ache le numéro de la ligne où l'invariant a été violé, c'est-à-dire date 6= {}. Ensuite il génère un contre-exemple illustrant la séquence d'états qui a mené à la violation de l'invariant (état 4, avec date = {}). Cette illustration montre bien que la génération d'une spécication TLA+ à partir d'un service CPL permet de vérier de manière automatique des propriétés importantes pour le domaine.

Interaction de services. Si un service peut sembler correct individuellement, son insertion dans un environnement d'exécution nécessite la prise en compte du contexte et notamment des services déjà existants. En eet, l'interaction entre plusieurs ser-vices peut entraîner des comportements non souhaités, voire corrompre la plate-forme.

L'exemple le plus simple consiste à introduire une boucle innie entre les services. Sup-posons trois utilisateurs, Bob, Alice et John. Si Bob renvoie tous ses appels sur Alice, qui redirige tous ses appels sur John, qui les transfère à Bob, alors il est impossible de joindre l'une de ces personnes. L'appel va boucler indéniment au sein de la plate-forme, qui sans une détection de cette interaction va produire des appels, consommer des ressources et nir par s'eondrer. Or, au sein d'une spécication TLA+, il est tout à

TLC Version 2.0 of January 16, 2006 Model-checking

...

Finished computing initial states: 1 distinct state generated.

Error: Invariant line 143, col 23 to line 143, col 35 of module CPL is violated.

The behavior up to this point is:

STATE 1: <Initial predicate>

∧ callerTests = 〈 〉

∧ currentNode = "Incoming"

∧ signalingActions = 〈 〉

∧ date = {[day ↦ "sun", dayNum↦ 1, month ↦ "January"], ...

[day ↦ "sun", dayNum↦ 365, month ↦“December"] } STATE 2: <Action line 51, col 9 to line 53, col 60 of module CPL>

∧ callerTests = 〈 〉

∧ currentNode = "WeeklyMeeting"

∧ signalingActions = 〈 〉

∧ date = {[day ↦ "sun", dayNum↦ 1, month ↦ "January"], ...

[day ↦ "sun", dayNum↦ 365, month ↦“December"] } STATE 3: <Action line 98, col 9 to line 101, col 54 of module CPL>

∧ callerTests = 〈 〉

∧ currentNode = "AnnualHolidays"

∧ signalingActions = 〈 〉

∧ date = {[day ↦ "tue", dayNum↦ 3, month ↦ "January"], [day ↦... "tue", dayNum↦ 192, month ↦"July"], [day ↦ "tue", dayNum↦ 199, month ↦"July"],

...

[day ↦ "tue", dayNum↦ 360, month ↦"December"] } STATE 4: <Action line 110, col 9 to line 113, col 55 of module CPL>

∧ callerTests = 〈 〉

∧ currentNode = "RedirectToBobVoiceMail"

∧ signalingActions = 〈 〉

∧ date = {}

5 states generated, 5 distinct states found, 2 states left on queue.

The depth of the complete state graph search is 4.

Fig. 9.10 Rapport d'erreurs TLC concernant un service CPL

fait possible de manipuler d'autres spécications et d'interagir avec elles. Ceci permet, entre autres, de détecter ce type d'interaction de services. En eet, le fait de pouvoir explicitement déterminer quel service doit être exécuté permet de connaître la spécica-tion à vérier ultérieurement. Il sut alors de l'initialiser avec les valeurs des variables d'état de l'exécution de la spécication précédente pour introduire une continuation au niveau de la simulation. Ceci permet de vérier des propriétés supplémentaires et, par exemple, d'assurer qu'il n'y a pas de boucle entre les diérents services.