Comparaison des modélisations

S2_2 S2_3 movement(t) S2_4 S2_1 commBT(t) commTB(t) S3 stop(t) S4 * S4_2 S4_3 S4_4 S4_1 commBT(t) commTB(t) S5 stop(t) compute

figure 5.10 – Spécification d’un système ferroviaire en utilisant les _astd: Quatrième Raffinement

est dans un_astdmodélisant le comportement du sous-système au sol. Les transitions communes aux deux sous-systèmes (commBT, commTB et stop) sont synchronisées entre les deux _astd. La spécification du système est décrite à la figure 5.10.

Cette spécification contient exactement les mêmes étiquettes de transition que la spécification précédente. La modélisation des données du système contient donc exactement les mêmes événements qui modifient les données de la même manière. La spécification Event-B associée est donc identique.

5.1.4 Comparaison des modélisations

La méthode décrite dans le chapitre 2 et utilisée pour modéliser ce cas d’étude nécessite de montrer la cohérence de chaque niveau de spécification. La preuve de cette cohérence génère un grand nombre d’obligations de preuve. Afin de mesurer la difficulté de ces preuves et les apports des améliorations apportées par les règles de réécriture, nous avons modélisé plusieurs fois ce cas d’étude. Dans un premier cas, nous avons spécifié naïvement ce cas d’étude en traduisant les_astdselon les règles de traduction décrites dans la thèse de Milhau [Mil11]. Dans une deuxième modélisation, nous avons utilisé les règles de réécriture des _astd décrites dans le chapitre 4 avant de les traduire. Dans un troisième cas, nous avons modifié les spécifications de donnée en utilisant la définition du raffinement de la section 2.3.2. Enfin, afin de situer ces modélisations, nous avons modélisé ce cas d’étude sans les règles de traduction. Ces différentes méthodes de modélisation sont décrites dans les sections ci-dessous.

Spécification classique

Dans cette spécification, nous avons utilisé naïvement les règles de traduction données dans la thèse de Milhau. L’idée de cette traduction est de modéliser les états des_astdpar des variables d’état en B. Une variable d’état est associée à chaque_astd hiérarchique. Un outil de traduction automatique a été développé pour la traduction des _astd en langage B. L’avantage de cette traduction est que la spécification en B colle parfaitement à la spécification graphique. Il est donc facile de se représenter l’état B dans lequel est la machine en fonction de l’état de l’_astd. L’inconvénient principal de cette modélisation est qu’elle multiplie les variables d’état. Or, pour la preuve de la cohérence, il faut relier les variables d’état représentant l’état de l’_astd aux variables d’état de la spécification de donnée. Plus il y a des variables d’état, plus il faut ajouter d’invariant pour faire la preuve complète de la machine.

Prenons par exemple la spécification abstraite du système ferroviaire. La spécifica-tion_astdest visible à la figure 5.2. L’état de cet _astdest donné par deux variables :

State cbtc et State kleene. Puisque l’_astd est un entrelacement quantifié, ces deux variables sont des fonctions totales qui associent un état à l’ensemble des variables de l’ensemble de quantification :

State cbtc ∈TRAIN→ {S₁, S₂, S₃}

State kleene ∈TRAIN→ {started,notStarted}

D’après les règles d’inférences de la fermeture de Kleene (voir annexe A.4), la transitionStartpeut être exécutée dans trois cas. Si l’_astdest dans l’étatS₁, si l’_astd est dans l’étatS₃et quelque soit l’état de l’_astdsi l’état de la fermeture estnotStarted. Dans la spécification de données, l’événement associé à la transition Start est gardé par le fait que le train pour lequel la transition est exécutée n’a pas de position (tt /∈dom(position)). Dans la spécification B qui permet de vérifier la cohérence de la spécification, il faut donc relier la variable position aux variables qui encodent l’état de l’_astd. Il faut donc ajouter deux invariants : un premier invariant qui spécifie que les trains qui ont une position sont ceux qui sont dans l’état S₂ (dom(position) = dom(State cbtc{S2})) et un deuxième qui spécifie que si la fermeture de Kleene est

|||(t:TRAIN) * CBTC S3 stop(t) S2_1 S2_2 movement(t) S1 start(t) [position0 ∉ ran(position)] S1_1 compute_l(t) S2_3 compute_l(t) movement(t) stop(t) start(t) [position0 ∉ ran(position)]

figure 5.11 – _astd obtenu par la réécriture de l’_astd 5.5

dans l’étatnotStartedalors il est dans l’étatS₁ (dom(State kleene{notStarted}) = dom(State cbtc{S₁})).

Spécification obtenue avec les règles de simplification (Chapitre 4)

L’objectif des règles de simplification décrites dans le chapitre 4 est de réduire le nombre d’_astd hiérarchiques, pour réduire le nombre de variables nécessaires pour décrire en B l’état d’un _astd. Dans cette modélisation, avant de traduire en B les astd^{de la spécification, nous avons appliqué les règles de simplification sur les}astd^. La spécification _astd du deuxième raffinement par exemple (voir figure 5.5) est ré-écrite par l’_astd de la figure 5.11.

La spécification obtenue n’est pas vraiment plus lisible. La lisibilité d’une spéci-fication est une qualité difficilement mesurable mais on peut admettre ici qu’il est plus compliqué de voir les cycles de transitions qu’il est possible d’exécuter sur la spécification de la figure 5.11 que sur la figure 5.5. Cependant, l’état d’un_astdde la spécification de la figure 5.11 n’est caractérisé que par une seule variable d’état en B tandis que l’état d’un_astdde la figure 5.5 nécessite quatre variables d’état : les états possibles de l’automate de S₂, les états de la fermeture de Kleene de cet automate, les états de l’automate global et les états de la fermeture de Kleene de l’automate global. Les chiffres illustrant la simplification sont donnés ci-dessous (section 5.1.4).

Spécification obtenue avec la définition du raffinement étendu pour sim-plifier la preuve (voir section 2.3.2)

Dans la méthode, nous avons défini une méthode de raffinement qui permet de simplifier les preuves de la cohérence. La preuve de la cohérence d’un niveau de raffinement consiste à montrer que lorsqu’une transition doit être exécutée, alors la garde de l’événement associé est vraie. L’idée de la méthode de raffinement est la suivante : puisque le comportement de l’_astd concret est un comportement qui était admis par l’_astd abstrait, et puisqu’on a prouvé la cohérence pour l’_astd abstrait, il n’est plus nécessaire de montrer la cohérence pour l’_astd concret dans le cas où les gardes ne changent pas. Dans cette section, nous expliquons comment appliquer ce raffinement en nous intéressant à la relation de raffinement entre le premier et le deuxième raffinement. À ce niveau de raffinement, une transitioncompute l(t)permet de calculer une limite de mouvement pour chaque train. Cette limite de mouvement est stockée dans une variable appelée mal. Dans l’événement associé à la transition

movement(t), cette limite est utilisée pour déterminer la nouvelle position du train. Les deux spécifications de l’événement associé à cette transition sont données à la figure 5.12.

Dans l’événement associé à la transition Movement du troisième raffinement, la garde concernant la variable position ne change pas. La garde tt∈dom(position) de l’événement concret peut donc être déduite de l’événement abstrait. Pour montrer la cohérence du niveau concret, on peut donc retirer cette garde de l’événement concret et prouver la cohérence avec comme garde tt∈dom(mal).

Puisque la relation de raffinement entre le troisième raffinement et le quatrième raffinement ne suit pas la définition exacte du raffinement défini dans le chapitre 2, la méthode du raffinement étendu n’a pas été employée entre ces deux niveaux.

Spécification sans les règles de traduction

Afin d’avoir une idée du coût de l’utilisation des règles de traduction systéma-tiques, nous avons choisi de spécifier également ce cas d’étude sans utiliser ces règles. Dans cette modélisation, les _astd sont utilisés comme une spécification formelle de niveau supérieur. On suppose qu’ils correspondent à la spécification du comportement

Event Movement act =_b

any

tt

where

gu1 : tt∈T RAIN

gu2 : tt∈dom(position)

then

act1 : position:|(. . .)

end

(a)Movement act : premier raffinement

Event Movement act =_b

refines Movement act

any

tt

where

gu1 : tt∈T RAIN

gu2 : tt∈dom(position)

gu3 : tt∈dom(mal)

then

act1 : position:|(. . .)

end

(b)Movement act: deuxième raffinement

figure 5.12 – Événement associé à la transition Movement dans les deuxième et troi-sième raffinements

attendu d’un système que nous devons modéliser en B. Comme pour la spécification classique, une opération est créée pour chaque étiquette de transition et l’événement correspondant est appelé dans le corps de la transition.

Dans cette méthode de spécification, la spécification du comportement du système a été faite à la main. Aucun outil de traduction des_astda été utilisé, ce qui a permis de simplifier la modélisation du comportement beaucoup plus que si la traduction était automatique. Cependant, puisque cette spécification a été faite à la main, il n’est pas possible de prouver que la spécification B est équivalente à la spécification astd ^{de départ, alors que lorsque la spécification est traduite automatiquement, si} l’outil de traduction a été validé, la confiance dans la traduction obtenue est beaucoup plus grande.

Comparaison des spécifications

La tableau 5.1 résume le nombre d’obligations nécessaires pour la preuve de chaque niveau de spécification dans les 4 méthodes de spécification décrites ci-dessus. Pour chaque niveau, trois chiffres sont donnés. La colonne tot contient le nombre total

Classique Réécriture ^Raffinement étendu

Spécification à la main tot man usr tot man usr tot man usr tot man usr N 1 37 5 3 21 1 1 21 1 1 13 2 2 N 2 87 5 3 30 3 2 18 0 0 13 1 1 N 3 121 26 11 53 13 6 51 12 6 41 7 5 N 4 97 31 14 40 16 9 - - - 28 12 10 N 5 237 110 42 119 66 38 115 65 38 86 43 34 N 6 396 190 64 202 69 40 54 0 0 100 43 35 TOT 975 367 137 465 168 96 299 94 54 281 108 87

tableau 5.1 – Comparaison des obligations de preuves générées pour les différentes modélisations

d’obligations de preuve générées pour chaque niveau. Certaines de ces obligations de preuves sont prouvées automatiquement par les prouveurs de l’atelier B. La colonne

man contient le nombre d’obligations de preuves qu’il est nécessaire de prouver ma-nuellement à l’aide du prouveur interactif de l’atelier B. Enfin, lorsqu’une obligation de preuve est prouvée à l’aide du prouveur interactif, il est possible de sauvegarder la tactique de preuve et de l’utiliser pour essayer de prouver d’autres obligations. La co-lonneusr contient le nombre de tactiques différentes qu’il a fallu utiliser pour prouver la machine. Par exemple, pour prouver le niveau 6 de la spécification classique, 396 obligations de preuve ont été générées, 190 ont été prouvées manuellement à l’aide du prouveur interactif. Cependant, pour prouver ces 190 obligations, seules 64 tactiques ont été nécessaires.

On remarque d’abord que le nombre d’obligations de preuve générées pour prou-ver la cohérence de la spécification dans le cas de la spécification naïve est beaucoup plus important que dans le cas de la spécification traduite manuellement. En effet, la traduction automatique impose de générer du code qui pourrait être simplifié en traduisant intelligemment. Cela se retrouve par le fait que le nombre de tactique néces-saires à la preuve ne croît pas autant que le nombre total d’obligations de preuve. La seconde remarque est que, dans notre cas d’étude, les règles de réécriture permettent de diminuer significativement le coût du travail de preuve.

Enfin, on remarque que l’apport du raffinement étendu est important sur les ni-veaux 2 et 6. Les spécifications des nini-veaux 2 et 6 sont les spécifications dans lesquelles seul le comportement du système est raffiné (la spécification des données du système ne change pas). Dans ce cas, il est évidemment possible de retirer toutes les gardes, ce qui explique que la machine est entièrement prouvée automatiquement (les quelques obligations qui restent à prouver sont les obligations associées à la vérification des types).

Cependant, l’apport de cette relation de raffinement étendu est assez faible sur les autres niveaux. Pour prouver la cohérence du système, il est nécessaire d’ajouter des invariants qui lient les variables d’état du système à certaines variables d’état qui représentent les états de l’_astd. Cet invariant doit alors être montré pour chaque opération modifiant la variable d’état du système ou modifiant la variable d’état représentant les états de l’_astd. C’est la preuve de l’invariant qui génère autant d’obligations de preuve.

Dans le cas de la spécification de niveau 3, par exemple, on ajoute à la spécification de données la variable mal et dans la spécification du comportement, on ajoute une opérationcompute l. Les événements associés aux transitions Start etMovement ont une garde qui dépend de la variable position qui est identique à la garde abstraite. Cette garde peut donc être retirée dans la preuve de la cohérence. Cependant, dans la garde de l’événement associé à la transitioncompute l, il faut vérifier que le train pour lequel on calcule une limite a une position (t ∈ dom(position)). Il faut donc quand même relier la variable position aux variables d’état modélisant l’état de l’_astd. Le cas où le raffinement étendu est le plus efficace est le cas où les événements associés aux nouvelles transitions ajoutées au cours du raffinement ne modifient et ne lisent que des nouvelles variables ajoutées au cours du raffinement.