• Aucun résultat trouvé

Figure 8.15 : Contraintes pour spécifier le passage à Niveau

9.2 Module de Spécification et de Simulation des Systèmes Réactifs

9.2.1 Le Système VALID

Contrairement à certains systèmes de modélisation des systèmes concurrents tels que LOTOS et ESTELLE, VALID présente un formalisme qui s’apparente d’avantage au langage Maude. D’abord, il ne fait appel qu’à une seule théorie pour la spécification formelle des structures de données et de la dynamique des systèmes. Le langage adopté par VALID peut être considéré comme un sous-ensemble du langage MAUDE, aussi minime soit-il mais toute fois très expressif. Il s’agit d’une généralisation de la programmation fonctionnelle orientée objet. La principale différence entre VALID et MAUDE est que VALID retient un seul concept de base qui est le module formel. Un module formel peut décrire un module de façon similaire telle que OBJ1, OBJ2 et OBJ3. Le module formel une fois instancié est utilisé pour générer, filtrer et réduire les entités syntaxiques qui le concernent dans les phases du système formel correspondant.

Le système VALID, durant le processus de spécification considère tout objet comme un système complexe composé si nécessaire d’autres objets. Le processus de décomposition est défini alors comme une suite hiérarchique de composants. Dans ce cas, un module formel peut faire appel pour sa spécification à d’autres modules formels, ce qui forcément met en place un mécanisme de prise en charge de la notion de niveau et de visibilité qui est similaire à la notion de métarègles telles que définies dans les systèmes experts. C’est-à-dire qu’un système A est d’un niveau immédiatement supérieur à un niveau B, si le système B intervient directement dans la composition du système A. De cette façon le système A ne connaît alors que les attributs des systèmes de son niveau qui sont rendus visibles ou publiques.

9.2.1.1 La Signature du Langage VALID

La figure 9.1 donne la grammaire du formalisme textuel pour la spécification des systèmes concurrents temps réel de VALID.

140

. Figure 9.1 : Signature des Systèmes Concurrents supportés par VALID

Cette signature précise la construction syntaxique du système formel. Neaumoins elle ressemble un tout petit peu à une partie de la grammaire de MAUDE. Nous pouvons très facilement faire une correspondance, à titre d’exemple du mot clé « Type » de VALID est le mot réservé « sort » de MAUDE. Il n’est pas nécessaire d’introduire les définitions de chaque partie de cette syntaxe, le lecteur est invité à consulter les travaux de Attoui et al. [AS96, Has97].

La description d’un système consiste à instancier les méta-types des éléments du vocabulaire (Object, Attributs, Msg, …), en fonction de la réalité perçue de façon à définir les objets qui le compose ainsi que les messages ou les évènements susceptibles d’agir sur le comportement de l’objet ou de l’interaction de plusieurs objets.

9.2.1.2 Les règles de réécriture dans VALID

Un objet en VALID peut être sollicité pour un service. Cette sollicitation est représentée par un message qui peut contenir des paramètres. L’effet d’un message sur un objet est décrit à travers une règle. Un tel message ne peut être émis que par des objets du même niveau ou du niveau supérieur. Un message peut être intercepté par une règle et redirigé vers n’importe quel niveau. Les règles dans ces conditions permettent de raisonner par changement d’états des objets du système et de tirer des conclusions valides sur l’évolution. Une règle indique ainsi que le système passe d’une configuration à une autre exactement comme dans le langage MAUDE. Une règle peut aussi être activée lorsque toutes les conditions sont réunies. La forme générale d’une règle dans VALID est donnée par :

Messages1 .. n Objets1..m Î ObjetS1..k NewObjetsS1..p NewMessages1..q [Timing] Pour comprendre le comportement d’une telle règle, il vaudrait mieux pour nous de se refferer au langage Maude.

Pour mieux appréhender la syntaxe et la sémantique de VALID un exemple simple est sollicité dans ce cas. Nous rappelons l’exemple traité dans la partie MAUDE, il s’agit de la gestion de comptes bancaires qui sera réécrit dans le langage VALID, cette spécification est représentée par les deux modules formels suivants (Figure 9.2) :

141

ModuleFormel COMPTE :

(Importe Date, Montant, Liste, Compte ; Signature

{

Type Compte, Id.Compte, ObjectId, Msg, Valeur, Configuration ; SousType Id.Compte < ObjectId < Valeur ;

SousType Msg.Compte < Msg ;

SousType Msg, Compte < Confgration ;

Op <_ : Compte / solde : _, écriture : _> : Id.Cmpte Montant Liste[Coupe[Date, Montant]] Æ Compte ; Op (créditer_de_) : Compte Montant Æ Msg.Compte ;

Op (débiter_de_) : Compte Montant Æ Msg.Compte ;

Op (solde de_pour _) : Compte Montant ObjetId Æ Msg .Compte; Op (solde de_est _pour) : Compte Montant ObjetId Æ Msg .Compte; Op _ _ : Configuration Configuration Cnfiguration [Assoc, Com, Id= Nul] } Règles { Var C : Compte ; M, S : Montant ; H : Triplet ; I : Oid ;

(créditer C de M) <C : Compte / solde : N, écriture : N, écriture : H> ==> <C : Compte / : N + M, écriture : (date_aujourd’hui, +M) H> ; (débiter C de M) <C : Compte / solde : N, écriture : H> ==>

<C : Compte / : (solde : N – M) >= 0, écritures : (date_aujourd’hui, -M) H> ; (solde de C pour I) <C : Compte / solde : N, écriture : H> ==>

<C : Compte / solde :: N, écriture : H> (le solde de C est N pour I) ; }

}

ModuleFormel BANQUE {

Importe Compte, Montant, Date, Nat, Liste, Triplet, Pourcentage ; Signature

{

SousType Cpt_dépôt < Compte ; SousType Cpt_librett < Compte ;

SousType Codevi < Cpt_livret , Compte ; SousType Cpt_courant < Cpt_livret ;

142

Op (Triplet) : Cpt_dépôt Æ Liste[Triplet[Date, Nat, Argent]] ; Op (Taux_) : Cpt_livret Æ Poucentage ;

Op (plafond_) : Codevi Æ Montant ; Op (datefermeture_) : Codevi Æ Date ;

Op (chèque à enregistrer numéro _ de valeur _ sur le compte _) : Nat Montant Compte Æ Msg.Cpt.dépôt ; Op (intérêt de ) : Compte Æ Cptlivret ;

Op (fermet _ dans _) : Compte Compte Æ Msg.Codevi ; Op (transférer _ de _ dans _) : Argent Compte Compte Æ Msg ; } Règles { Vars C, CV : Compte ; N : Montant ; N : Nat ;

(chèque à enregistrer numéro N de valeur M sur le compte C) <C : Cpt_dépôt/Triplet :H> = => C :Cprt_dépôt / Triplet : insérer(date_aujourd’hui, N, M) dans H)> (débiter C de M) ;

(intérêt de C) <C :Cpt_livret / taux : R> = = > <C :Cpt_livret / taux : R> (créditer C de (solde de C)* R) ;

(fermer CV dans C) <CV : Codevi /plafond : P, date_fermeture :D> = = > (créditer C de (solde de CV)) si D < date_aujourd’hui sinon (créditer C de (/*formule permettant le calcul des intérêts*/)) ;

(transferet M de C dans CV) = = > (débiter C de M)(créditer CV de M) ;

Figure 9.2 : Spécification des comptes bancaires dans VALID

Nous pouvons remarquer que l ‘alphabet de ce module formel est constitué d’objets complexes importés (Date, Montant, Liste et Couple etc.). Il existe par contre un deuxième type de module dit module fonctionnel dont la description est tout à fait identique à celle d’un module orienté objet. La seule différence entre les deux types de modules au niveau conceptuel, réside dans leur comportement. Un module fonctionnel à un comportement purement fonctionnel. Il sert à définir un type abstrait de données qui représente une classe d’entités qui ne change pas dans le temps (statique). Un module de ce genre contiendra les éléments qui permettent de construire, d’interroger et de manipuler ses éléments. Dans ce module le terme « équation » est utilisé au lieu de « règle ».

En outre VALID permet de déclarer des règles synchrones et asynchrones juste pour différencier entre le vrai parallélisme et celui d’interleaving.

Le système VALID admet une représentation particulière des règles dite internes, elle se présente sous cette forme :

Oi = = > Oi m … On Mq … Mr [T].

Ce type de règles permet d’exprimer les changements d’états dus non pas à une excitation externe, mais à une logique interne qui n’est pas visible à ce niveau. Elles concernent donc un objet complexe actif, qui peut évoluer dans le temps suite à une activité interne. Cela permet de spécifier, entre autres, le comportement de certains objets qui obéissent à des lois internes quelconque, on introduit l’indéterminisme dans le comportement.

143

9.2.2 Processus de Modélisation dans VALID