Règles d’évolution

La correspondance entre une règle d'évolution et plusieurs règle ECA se fait facilement. En effet, une opération correspond à une référence événementielle où l'événement est celui déclenché à l’appel (pour représenter les pré-opérations) ou au retour (pour représenter les post-opérations) d'une méthode d'évolution (qui représente l'opération). A chaque pré-opération et post-pré-opération, on fait correspondre une règle de vérification et une règle de propagation mettant en œuvre respectivement la condition et l’action. Donc, à toute règle sont associées au plus deux règles de vérification et deux règles de propagation.

Traduction d’une règle d’évolution en règles actives

Soit REV = (nom_rev, op_rev, var_rev, pre_op_rev, post_op_rev), où : nom_rev : le nom de la règle d’évolution

op_rev = (nom_op, para_op) : le nom de l’opération et les paramètres associés var_rev : ensemble des variables de REV

pre_op = (condition1, action1) : la pré-opération post_op = (condition2, action2) : la post-opération

Soient, REAV1 et REAV2 deux règles actives de vérification, et REAP1 et REAP2 deux règles actives de propagation.

Avec : REAxy _{(x = V ou P, y = 1 ou 2)} = (nom_rea, type_rea, re_rea, var_rea, cond_rea, act_rea) nom_rea : le nom de la règle active

type_rea : le type de la règle (verfication ou propagation) re_rea : la référence événementielle

var_rea : les variables locales cond_rea : la condition act_rea : l’action Et : REAV1 = nom_rea = nom_rev.pre.verification type_rea : verfication

re_rea : Appel nom_op (para_op) var_rea : var_rev

cond_rea : (NOT Condition1) /* Interruption si la Condition1 est fausse */ act_rea : (“Incohérence dans la pré_opération de nom_rev”)

REAV2 =

nom_rea = nom_rev.post.verification type_rea : verfication

re_rea : Retour nom_op (para_op) var_rea : var_rev

cond_rea : (NOT Condition2)

act_rea : (“Incohérence dans la post_opération de nom_rev”) REAP1 =

nom_rea = nom_rev.pre.propagation type_rea : propagation

re_rea : Appel nom_op (para_op) var_rea : var_rev cond_rea : Vrai act_rea : Action1 REAP2 = nom_rea = nom_rev.post.propagation type_rea : propagation

re_rea : Retour nom_op (para_op) var_rea : var_rev

cond_rea : Vrai act_rea : Action2

Les paramètres spécifiés au niveau de l'opération correspondent aux filtrages types et valeurs de l'événement (cf. Chapitre 7). Pour les règles de vérification, la chaîne de caractères spécifiée au niveau de l'action représente le message d'interruption.

ECA ci-dessous.

Les règles ECA générées pour une règle d’évolution seront définies dans la même base de règles. Nous verrons plus loin que toutes les règles ECA d’une même stratégie seront définies dans la même base (cf. 8.5.2).

Exemple

Si nous traduisons la règle d'évolution sur la suppression de classe : nom_règle = règle_suppression_classe1

opération = supprimer_classe (oid : Méta)

Pré-opération = (C : (not (utilise_par oid meta_attribut "domaine"))

A : (pre_declarer (ex_super_comm oid) (ex_nom_attributs_propres oid)))

Post-opération = ( C : (), A : (Message " la suppression de classe est terminée")). On obtient les trois règles ECA suivantes :

Nom_règle = règle_suppression_classe1.pré.vérification

Référence-événementielle = Appel supprimer_classe (classe Meta) Type = Vérification

Condition = (not (not (utilise_par oid meta_attribut "domaine")) Action = "Incohérence dans règle_suppression_classe1"

Nom_règle = règle_suppression_classe1.pré.propagation Référence-événementielle = Appel supprimer_classe Type = Propagation

Condition = Vrai

Action = (pre_declarer (ex_super_comm oid) (ex_nom_attributs_propres oid))

Nom_règle = règle_suppression_classe1.post.propagation

Référence-événementielle = Retour supprimer_classe (classe Meta) Type = Propagation

Condition = Vrai

Action = (Message " la suppression de classe est terminée")

Pour cet exemple, il n’y a que trois règles ECA car la post-opération ne possède pas de condition.

Modélisation d’une règle d’évolution

par une classe qui référencera ses règles ECA et qui aura pour attributs les variables. Cette classe sera sous-classe de la classe Regle_evolution, laquelle définit quatre attributs ayant pour domaine la classe Regles. De cette façon, toute instance d'une règle d'évolution pourra référencer les instances des règles ECA (voir Figure 8-7) . En effet, lors de la détection de l'événement (donc de l'opération d'évolution), une instance de la règle d'évolution est créée pour référencer les instances des règles ECA et contenir les valeurs des variables. Ces variables sont consultées et mise à jour par les règles ECA.

Classe Rev_sup reglesECA = (R1 R2 R3) attributs : var1 : un objet_lisp varn : un objet_lisp Rev_sup_1 pre-verification = ri1 post-verification = ri2 post-propagation = ri3 var1 =??? varn = ??? Lien d'instanciation Classe Regle_evolution attributs : pre-verification : un Regles pre-propagation : un Regles post-verification : un Regles post_propagation : un Regles Classe Meta_regle_evolution super = (Meta)

attributs = reglesECA : ens Meta_regles

Lien de spécialisation Classe R1 Classe R3 Classe R2 Classe Regles ri1 ri3 ri2

Figure 8-7 : Modélisation d'une règle d'évolution

Pour permettre l'accès aux bonnes variables par les règles ECA, on insère un code dans ces règles pour accéder à l'instance de la règle d'évolution correspondante.

Code à insérer dans la condition et l’action d’une règle ECA rea:

Soit rev la règle d’évolution qui référence rea. Pour chaque variable var de rea : générer_variable (var)

Exécution d’une règle d’évolution

Pour l'exécution d'une règle d'évolution, nous utilisons le moteur d'exécution des règles ECA

moyennant une modification pour prendre en compte les variables d'une règle d'évolution. L'exécution de cette dernière se déroule ainsi :

Détection de l'événement (Opération)

Les règles ECA sont référencées par une règle d'évolution

Création éventuelle d'une instance de la règle d'évolution (rev_1) *

Liaison des instances des règles ECA avec rev_1

Exécution des règles ECA

Fin d'exécution des règles ECA. Destruction éventuelle de rev_1 *

Oui ^Non

Fin

La détection de l’exécution d’une opération est assurée par le moteur d’exécution du modèle actif. Lors de la détection de l’événement correspondant, si une des règles sélectionnées est une règle référencée par une règle d’évolution, le moteur crée une règle d’évolution et établit une liaison de référence avec la règle active en cours d’exécution. Lorsque toutes les règles

ECA d’une règle d’évolution sont exécutées, le moteur détruit la règle d’évolution correspondante. Pour les étapes *, l'instance de la règle d'évolution rev_1 ne sera pas créée si elle existe déjà et elle ne sera pas détruite tant que toutes les règles ECA correspondantes ne sont pas évaluées.