Le langage TLA+

TLA+ (Temporal Logic of Action) est un langage de sp´ecification bas´e sur la th´eorie des ensembles et la logique temporelle lin´eaire (LTL) [SC85].

Les principaux op´erateurs utilis´es sont

– des op´erateurs bool´eens et arithm´etiques classiques, – des op´erateurs ensemblistes,

– et des op´erateurs temporels.

L’´etat d’une sp´ecification est d´efini par la valeur de toutes les variables de la sp´ecification. L’espace d’´etat d’une sp´ecification est l’ensemble de tous les ´etats possibles de cette sp´ecification. Un pr´edicat d’´etat est une simple fonction bool´eenne sur un ´etat de la sp´ecification. Un pr´edicat peut ˆetre param´etr´e par une liste de variables. Une action est un pr´edicat portant sur deux ´etats successifs (courant et suivant). Il s’agit d’une formule d´ecrivant l’´etat courant du syst`eme ainsi que l’´etat suivant `a l’aide de variables “pri-m´ees”. Soitx une variable du programme,x’d´esigne la valeur de la variable x dans l’´etat suivant. De mani`ere plus g´en´erale une expression enti`ere peut ˆetre prim´ee. Une action est donc un pr´edicat d´ecrivant une relation entre deux ´etats de la sp´ecification. Un comportement est d´efini comme une s´e-quence d’´etats telle qu’il y a toujours une action valide entre deux ´etats successifs : ces deux ´etats valident la relation associ´ee `a cette action.

Une sp´ecification contient toujours un ´etat initial et une actionnext d´e-finissant toutes les transitions possibles, cette action nextest g´en´eralement la disjonction de toutes les transitions atomiques d´efinies. Il s’agit l`a de la sp´ecification de la partie sˆuret´e qui d´efinie les propri´et´es toujours vraies.

Quant `a la vivacit´e, il est aussi possible de la sp´ecifier en indiquant l’´equit´e forte ou faible de chaque action [Lam02]. Informellement, la notion d’´equit´e permet de sp´ecifier un ordre sur le d´eclenchement des actions.

TLA+ introduit la notion de modules afin de structurer les sp´ecifications.

Un module contient des d´eclarations de constantes, variables, pr´emisses, et enfin de pr´edicats. Les pr´emisses sont principalement utilis´ees pour typer les constantes. On d´efinira toujours au moins trois pr´edicats, un pr´edicat d´efinis-sant le type des variables manipul´ees g´en´eralement appel´eTypeInvariant³, un pr´edicat d´efinissant l’´etat du module lors de l’initialisation g´en´eralement appel´eInit, et un pr´edicat d´ecrivant les transitions possibles g´en´eralement appel´eNext.

3On distingue en g´en´eral deux types de propri´et´es dans cet invariant. Les propri´et´es relevant du typage statique et les propri´et´es d’´etats qui r´esultent de la dynamique du syst`eme.

remarque : L’invariant de type en TLA+ est consid´er´e comme une pro-pri´et´e de sˆuret´e qui devra ˆetre v´erifi´ee au mˆeme titre que n’importe quelle autre propri´et´e. Le typage est donc v´erifi´e dynamiquement `a l’ex´ecution (lors de la phase de model-checking). On ne peut pas faire de v´erification statique de type lors de la compilation comme dans une approche typ´ee.

module NomModule constants

liste des constants assume

typage des constantes variables

liste des varaibles TypeInvariant =^∆

Invariant de typage Init =^∆

Initialisation Next =^∆

Transitions possibles

L’assemblage de modules ce fait `a l’aide de deux types de relations existent entre deux modules, l’extension et l’instanciation.

Le mot clef EXTENDSest suivi de la liste de modules ´etendus par le module courant. Une extension permet d’acc´eder aux variables, constantes et pr´edicats d´efinis dans le module ´etendu.

L’instanciation permet de d´efinir plusieurs instances d’un mˆeme module.

Chaque instance a un comportement identique, mais poss`ede un ´etat propre. Les variables de chaque instance doivent ˆetre d´efinies dans le module o`u a lieu l’instanciation. Au moment de l’instanciation, on assigne des variables du module courant aux variables du module ins-tanci´e. Cet assignement peut ˆetre implicite si le nom de la variable est le mˆeme dans les deux modules. Lorsque deux modules diff´erents doivent communiquer, on les instancie avec des variables communes.

Les pr´edicats d´efinis dans une instance peuvent ˆetre appel´es en utili-sant la syntaxeinstance !predicat().

Le temps r´eel en TLA Le principe utilis´e par Lamport[Lam05] pour d´e-crire une mod´elisation temps r´eel dans un langage standard est extrˆemement simple. On va ajouter une variable dont l’´evolution repr´esente l’´ecoulement

2.2. METHODES FORMELLES 21 du temps, Lamport nomme cette variable now. Une op´eration appel´ee tick fait ´evoluer cette variable. Afin de pouvoir exprimer des contraintes sur l’´ecoulement du temps trois types de timers sont d´ecrits :

– expiration timer : le tick ne change pas la valeur du timer. Il est po-sitionn´e `a une valeur now +τ et le timeout intervient lorsquenow = timer.

– count down timer : le tick fait d´ecroˆıtre le timer, le timeout a lieu lorsquetimer = 0

– count up timer : le tick augmente la valeur du timer. Le timeout a lieu lorsqu’il devient ´egal `a une valeur constante pr´ed´efinie.

Dans ses exemples, Lamport utilise principalement des count down ti-mers. Afin de faciliter la validation des sp´ecifications on pr´ef`ere utiliser de count up ou des count down timers car on peut facilement fixer leurs limites, en effet ils ne peuvent ´evoluer que entre z´ero et la valeur de leur borne. L’´evo-lution de now peut se faire de diff´erentes mani`eres, classiquement on la fait

´evoluer pas `a pas par incr´ement d’une unit´e. Mais une approche alternative est pr´esent´ee, en ´etudiant le syst`eme sp´ecifi´e, on peut calculer les dates aux-quelles auront lieu les prochaines actions. On peut donc pr´edire quand la prochaine action doit avoir lieu. Au lieu de faire avancer now d’une valeur pr´ed´efinie fixe, on peut faire des “ sauts ” jusqu’`a la prochaine action possible.

Cette technique permet de g´en´erer moins d’´etats lors du model-checking. Les timers vont nous permettre d’exprimer des gardes pour le d´eclenchement des op´erations.

Les timers ´evoluent en mˆeme que la variable now, ils sont donc modifi´es par l’op´eration tick, ils sont r´einitialis´es dans leNext.

Dans notre cas, on va associer deux timers d´ecroissants `a chaque thread de l’ensemble Thread, l’un exec timer repr´esentera le temps n´ecessaire `a l’ex´ecution du thread, l’autredeadline timerrepr´esentera l’´ech´eance. Lors-qu’un thread sera activ´e, on initialisera le premier avec la valeur du WCET du thread et le second avec sa deadline. L’op´eration tick en plus de faire avancernow, d´ecr´ementera tous les timers associ´es `a la deadline des threads dipatch´es (Ready) et le timer du thread en cours d’ex´ecution : computing tread.

else deadline timer[t]]

∧exec timer^′ = [t ∈Thread 7→

if t =computing thread then exec timer[t]−1

else exec timer[t]]

Remarque La variablenow n’est pas born´ee, cependant si le code utilisa-teur ne r´ef´erence pas cette variable, on notera que les timers sont born´es. Si on exclut la variablenow de l’analyse de l’espace d’´etat⁴, celui est born´e. Par suite, une v´erification de mod`ele exhaustive est (th´eoriquement) possible.