Extensions de la méthode B — gestion du temps

Les diverses extensions présentées ci-après présentent plusieurs manières d’associer un flot de contrôle à un projet B ou event B. Elles ne se veulent pas exhaustives, mais donnent un aperçu assez complet des techniques utilisées pour y parvenir.

Étendre la logique

Lano et Dick [LD96] proposent d’étendre les clauses de B par les suivantes :

– Une clauseTRACESpermettant d’exprimer la trace d’exécution des opérations de la ma-chine. Ces traces sont par exemple de la forme (a; b; c)^∗, qui signifient que la machine n’a le droit que d’exécuter les opérations a, b et c, consécutivement, et ce un nombre arbitraire de fois.

– Une clauseGUARDSpermettant d’empêcher l’exécution de certaines opérations si elles ne vérifient pas une certaine contrainte. Cette clause semble a priori superflue, puisqu’il est

Chapitre 3. Méthode B et temporalité

déjà possible de spécifier des gardes en B. En fait, la différence se situe dans le fait que cette garde peut aussi contenir un connecteur count énumérant le nombre d’exécutions de l’opération. Cela permet ainsi d’exprimer des contraintes simples à propos de l’historique de l’opération ainsi gardée

– Une clause THREADS associant à des opérations des gardes et des commandes supplé-mentaires : lorsqu’une opération est appelée, la garde doit être vérifiée à ce moment, sinon l’appelant est bloqué tant qu’elle n’est pas vérifiée. Puis l’opération est exécutée, et lorsqu’elle est finie elle rend la main à la machine appelante (qui était bloquée tant que l’opération s’exécutait). Ensuite la commande correspondante est exécutée. De cette manière, la commande fonctionne en même temps que la suite des opérations dans la ma-chine appelante. Ce mécanisme permet de définir un opérateur pouvant faire fonctionner deux substitutions en parallèle

– Une clause HISTORY contenant des formules de logique temporelle discrète, pour ex-primer des contraintes d’équité et de vivacité sur les opérations de la machine.

Ils montrent ensuite que cette extension préserve le raffinement de B. Ils présentent une étude de cas (la cellule de production) reprenant toutes les nouvelles notions présentées avant. Pour résumer, cette extension définit une forme de concurrence en B, avec la possibilité d’ex-primer des contraintes sur les traces d’exécution, tout en conservant les mécanismes de raffine-ment de B. Certaines des notions introduites dans cette extension (déclencheraffine-ment d’opérations, équité) préfigurent d’ailleurs le B événementiel introduit quelques années plus tard.

Associer une autre logique

Il est également possible d’associer un fragment d’une logique temporelle à un projet B. Butler et Falampin [BF02] montrent comment utiliser une certaine classe des formules de TLTL (timed linear temporal logic) pour spécifier des propriétés temporelles avec les machines B. Cette classe correspond aux formules de type leadsto et permet de spécifier des propriétés de vivacité. Plus tard, Bodeveix [BFR04] reprend ce travail en ajoutant la possibilité d’exprimer la conjonction de plusieurs événements, et la possible répétition d’évènements. Soit la formule TLTL en figure 3.15, avec P et Q des prédicats et k une constante.

P ;≤kQ Le fait que la propriété P soit vraie à un temps t implique que la propriété Q sera vraie à un temps au plus t+ k.

FIG. 3.15 – Formule de type leadsto

Butler et Falampin [BF02] spécifient une façon de dériver une formule de logique classique pour l’utiliser dans un projet B. Cette formule a la forme : Ptime+ k ≤ t ⇒ Q signifiant que si

le compteur de temps t a dépassé la limite P_time+ k (temps où P était vraie plus la limite de

temps), alors la propriété Q est vraie.

Les ajouts de Bodeveix [BFR04] se font à deux niveaux :

– la formule B correspondante ne reflétait pas correctement de multiples activations possi-bles du même événement,

– La conjonction de plusieurs contraintes de temps (de la forme de la figure 3.15) n’était pas prise en compte

3.3. B et l’expression de problèmes temps-réel

La méthode utilisée revient à dériver une machine B représentant la formule temporelle dont il est question. Cette machine contient des variables représentant le moment de l’activation d’un événement, le fait que l’événement est activé ou non (pour garder trace des activations multiples) et une variable représentant le temps. Elle contient aussi la formule B correspondant à la formule temporelle, en utilisant les variables de la machine.

Le modèle prenant en compte la conjonction de formules est obtenu quant à lui en générant une machine pour chaque interaction entre deux événements. En effet, Bodeveix [BFR04] sup-pose qu’il y a une formule temporelle pour chaque interaction entre deux événements, possi-blement le même. Le modèle de machine B résulte de la conjonction parallèle des différentes opérations correspondant à un même événement d’origine, et ce pour chaque événement, i.e. si

P₁, P2, . . . , Pnsont des événements, alors il y aura une opération OP_iqui sera la conjonction par-allèle Pi; P1, . . ., Pi; Pn, pour chaque événement Pi. Les opérations d’avancement du temps sont réunies de la même manière. Enfin le modèle final est obtenu en composant parallèlement l’opération d’origine et l’opération contenant la contrainte temporelle.

Les avantages d’une telle extension sont la disponibilité des contraintes temporelles de type vivacité sans devoir changer la méthode B elle-même, puisque ces mêmes contraintes tem-porelles sont exprimables par des machines B. Les deux principaux inconvénients sont en re-vanche la multiplication des machines dans le cas de la conjonction de formules temporelles, comme indiqué plus tôt, et la limitation justement à cette seule classe de contraintes temporelles. Associer un autre formalisme

Schneider et Treharne [TS99, TS00, ST02] utilisent CSP pour décrire le contrôle d’exécu-tion des opérad’exécu-tions de machines B. Les opérad’exécu-tions des machines B deviennent des événements pour les termes de CSP, et l’enchaînement des différents événements est décrit en utilisant la syntaxe de CSP. La sûreté d’un tel système est obtenue en vérifiant un invariant de boucle de

contrôle : cette formule spécifie les conditions selon lesquelles le système ne peut pas se

blo-quer. Cet invariant modélise les schémas d’exécution selon lesquels les machines B appelées devront fonctionner, indéfiniment (d’où la dénomination boucle de contrôle). Plus précisément, la modélisation est séparée en trois étapes :

– Le comportement du modèle, et la façon dont il évolue au cours du temps. À cet effet, une machine introduisant une variable de temps ainsi que des opérations de consulta-tion/avancement du temps est modélisée. Une machine peut donc « avancer le temps » pour indiquer ses propriétés temporelles. C’est nécessaire du point de vue de la modélisa-tion du foncmodélisa-tionnement du modèle, mais il s’agit d’un paradoxe pour le sens commun. En effet les opérations du modèle devraient être « soumises » au temps plutôt qu’être capables de le faire avancer.

Les machines B qui décrivent le comportement du modèles font appel à cette « machine-horloge » pour spécifier comment elles évoluent, temporellement parlant.

– Les contraintes du système, spécifiées via des machines non-temporisées. Celles-ci sont ensuite incluses dans des machines au dessein similaire, mais rajoutant les contraintes temporelles, comme mentionné ci-dessus.

– Un modèle CSP décrivant les interactions entre les différentes machines, où les passages de messages correspondent aux opérations des machines.

Chapitre 3. Méthode B et temporalité

– Ce que font les éléments du système (machines B à la base du fonctionnement du système) – Les contraintes temporelles sur l’évolution du système (les machines B « temporisées ») – Le comportement global du système (ordonnancement de l’activation des différents

élé-ments du système).

Valider un tel projet revient à valider d’abord les machines B, puis à générer les traces d’exécution depuis le modèle CSP et de vérifier la correction de ces traces d’exécution par rapport à des contraintes temporelles sur le système dans son ensemble. Les traces d’exécution correspondent aux séquences d’appels d’opérations B autorisées par le modèle CSP.