Partie contrôle

Cette partie concerne les structures de contrôle. Le contrôle en LOTOS est décrit syntaxiquement par des expressions algébriques dites expressions

comportementales (ou comportements) construites à partir d’un ensemble d’opérateurs (composition séquentielle, composition parallèle, choix non déterministe, gardes, etc.). Ces dernières permettent la description des processus concurrents dont la synchronisation et la communication s’ef-fectuent uniquement par rendez-vous, sans partage de mémoire.

On appelle en LOTOS une porte (gate) un canal de communication per-mettant la synchronisation par un rendez-vous entre plusieurs tâches qui se déroulent en parallèle.

Un rendez-vous est dit simple s’il n’y a pas d’échange de valeurs (pas d’émission ni de réception de données), il s’agit d’une synchronisation pure. Dans le rendez-vous avec échange de valeurs, la porte est accompa-gnée d’offres d’émission ( !val) et/ou d’offres de réception ( ?var : Sorte). L’exemple 2.2 décrit un rendez-vous sur la porte action sur laquelle on précise le type d’accès (Load) à la donnée d’adresse adr et on reçoit son contenu dans la variable var.

Exemple 2.2 ACTION ! Load of ID_ACTION ! adr of Address ? val :Nat ;

Un rendez-vous est bloquant aussi bien pour l’émission que la récep-tion : l’exécurécep-tion d’un comportement qui attend un rendez-vous est sus-pendue et ne reprend qu’après que le rendez-vous a eu lieu.

LOTOS permet de conditionner le rendez-vous par une garde qui est soit une expression booléenne [v0], soit une équation simple [v0 = v₁]. Le rendez-vous n’a pas lieu si la condition définie par la garde n’est pas satisfaite. Par exemple le rendez-vous de l’exemple 2.3 n’a pas lieu si la valeur val est différente de 0.

Exemple 2.3 ACTION ! Load of ID_ACTION ! adr of Address ? val :Nat [val == 0] ; Remarque 2.1 On appelle un rendez-vous sur une porte uneaction.

On trouve dans LOTOS deux portes spéciales prédéfinies qui n’appar-tiennent pas à l’ensemble des portes définies par l’utilisateur [20] :

• Une porte invisible, notée "i". Elle peut apparaître dans les pro-grammes LOTOS, mais uniquement dans un contexte de l’opérateur " ;". Cette porte dénote une action interne modélisant un comporte-ment non-observable.

employée explicitement dans un programme LOTOS mais elle est utilisée dans la définition sémantique du langage.

La syntaxe des opérateurs LOTOS

Soient P et Q deux expressions comportementales, L l’univers des actions observables et a, a0, a′

0, a₁, a′

1, ... an, a′

n des actions de L∪ {i} et, soient

A⊂ Let A′ ⊂ Ldeux ensembles d’actions, avec n≥0 et,

• A={a0, a1, ... an} • A′ ={a′ 0, a′ 1, ... a′ n} • A:= A ={a0 := a′ 0, a1:= a′ 1, ... an:= a′ n}

Le tableau 2.1 illustre la syntaxe des opérateurs LOTOS que nous avons utilisé dans notre modélisation (il existe bien d’autres opérateurs).

Interaction stop

Terminaison avec succès exit

Action-préfixe a; P Choix P[ ] Q Composition séquentielle P>>Q Composition parallèle P_|[A_]|Q Renommage rename A := A′in P Abstraction hide A in P

Tab. 2.1 – La syntaxe du langage LOTOS

Le langage LOTOS possède des écritures simplifiées pour la composi-tion parallèle :

• P|||Qexprime P|[∅]|Q: les deux comportements P et Q sont exé-cutés de manière complètement indépendante. Il s’agit d’une com-position parallèle totalement asynchrone.

• P|| Qexprime P |[L]| Q: les deux comportements P et Q sont exé-cutés en parallèle de manière entièrement synchronisée, ils doivent se synchroniser sur toutes leurs interactions. Il s’agit d’une compo-sition parallèle totalement synchrone.

La sémantique dynamique de LOTOS

LOTOS possède une sémantique opérationnelle basée sur une relation de transition. Cette relation est définie par un système de dérivation dont les règles sont accompagnées d’explications en langage naturel. Elle spécifie comment construire le système de transitions étiquetées STE (aussi appelé

La sémantique associée à chaque expression de comportement P dé-crite en LOTOS un état dans le graphe, où la relation de transition est définie comme étant la plus petite relation qui satisfait l’une des règles du tableau 2.2. Tout comportement représente un automate à un nombre fini ou infini d’états. exit _→^δ stop a; P →^a P P_→^a P′ P|[A]|Q→^a P′|[A]|Q ^{(a∈/ A∪ {δ})} P_→^a P′ P[]Q→^a P′ (a_∈/A_{∪ {}δ}) Q|[A]|P→^a Q|[A]|P′ Q[]P→^a P′ P_→^a P′, Q_→^a Q′ P_|[A_]|Q_→^a P′|[A_]|Q ^{(a∈ A∪ {δ})} P_→^a P′ P>>Q_→^a P′ >>Q ^(a6=δ) P_→^a P′ hide A in P_→^a hide A in P′ (a_∈/ A) P_→^a P′

hide A in P _→ⁱ hide A inP′ (a_∈A)

P_→^a P′ rename A :=A′ in P_→^{a (a∈/A)} P_→^a P′ rename A := A′in P_→^{a′ (a:=a} ′∈ A:=A′) rename A :=A′ in P rename A := A′in P P_→^δ P′ P>>Q→ⁱ P′>>Q ^(a6=δ)

Tab. 2.2 – La sémantique opérationnelle du langage LOTOS

Remarque 2.2 Le renommage n’est pas une opération du LOTOS standard, il est effectué par le passage de paramètres porte dans les processus.

L’opérateur "rename a₀ := a′

0, a₁ := a′

1, ...a_n:= a′

n in P" dénote le

com-portement obtenu en modifiant les actions effectuées par P : l’action a_i est renommée en a′

i pour i∈ {0, 1, ..., n}, les autres actions restent inchan-gées. Quant à l’opérateur "hide A in P" il représente un cas particulier de "rename in", il dénote le renommage de toutes les actions de l’ensemble

Aen action interne i.

Les processus LOTOS

Par analogie aux langages algorithmiques qui nomment généralement un bloc d’instructions procédure, LOTOS désigne un comportement au moyen

note un comportement, il peut être paramétré par une liste de portes sur lesquelles il peut effectuer des rendez-vous, et/ou une liste de variables typées [20].

La construction suivante définit un processus proc paramétré par les portes G₀, . . ., G_n et la liste des variables formelles v₀, . . ., v_m de sortes respectives T0, . . ., Tm. Le corps du processus est le comportement B. Le non-terminal func spécifie la fonctionnalité du comportement B : exit pour une terminaison avec succès, et noexit pour une exécution sans fin (cas d’une boucle infinie ou d’un blocage). Chaque non-terminal bloc_i dénote une définition d’un sous-processus dont la visibilité est limitée à la défini-tion du processus proc.

process PROC [G₀, . . . , Gn] (v₀:T₀, ... , vm:Tm) : func := B where bloc₀ . . . blocq endproc

Exemple 2.4 Le processus send_proc défini ci-dessous est paramétré par une seule porte ac-tionet ayant pour fonctionnalité exit. Son comportement consiste en un rendez-vous sur la porte action pour une demande de lecture du contenu de l’adresse

adr, suivi d’un test : si la valeur lue est égale à 0 alors le contenu de l’adresse adr

est positionné à 1 (par un rendez-vous sur la porte action pour une écriture), sinon fin de l’exécution.

process SEND_PROC [ACTION] : exit :=

ACTION ! Load of ID_ACTION ! adr of Address ? val :Nat ;

(

[val == 0] -> ACTION ! Store of ID_ACTION ! adr of Address ! 1 of Nat ;

exit

[]

[val <> 0] -> exit )

endproc

Les spécifications LOTOS

LOTOS possède une structure de blocs imbriqués : chaque définition de processus peut contenir des définitions de processus ou de types qui lui sont locaux. Cependant, incorporer des types et des processus différents n’est possible qu’avec la définition de spécification :

specification SPEC [G₀, . . . , Gn] (v₀:T₀, ... , vm:Tm) : func := type₀, . . . , typep behaviour B where bloc₀ . . . blocq endspec

Chaque non-terminal type_i dénote une définition de type dont la visi-bilité s’étend à toute la spécification. Le comportement B est le corps de la spécification. Le non-terminal func spécifie la fonctionnalité de B. Chaque non-terminal bloc0dénote une définition de type ou de processus.

L’identificateur spec joue le rôle d’un commentaire ; ce n’est pas un identificateur de processus, il ne peut donc pas être utilisé dans une ins-tanciation.