Stratégies d'évolution

Modélisation d’une stratégie

La modélisation des stratégies est réalisée en utilisant le concept de "Bases" du modèle actif (cf. Chapitre 7). A une stratégie correspond une base qui contient l'ensemble des règles ECA

générées par toute les règles d’évolution définies ou redéfinies de cette stratégie. Le lien de redéfinition des stratégies correspond au lien de spécialisation des bases (Figure 8-9).

R1.pré.vérification R1.pré.propagation R1.post.vérification R1.post.propagation

Stratégies de règles d'évolution ^{Bases de Règles ECA}

Se traduit par R1.pré.vérification R1.pré.propagation R1.post.vérification R1.post.propagation R2.pré.vérification R2.pré.propagation R2.post.vérification R2.post.propagation Base*S1 Base*S2 Bases_stratégies Spécialisation Redéfinition R1 R2 S2 R1 S1

Figure 8-9 : Correspondance stratégie-base

Afin d’établir une liaison, d’une part, entre une stratégie et une base de règles, et d’autre part, entre une stratégie et ses règles d’évolution, nous modélisons une stratégie par une classe qui référencera l’ensemble de ses règles d’évolution, ainsi que la base de règle correspondante (Figure 8-10 et Ecran 8-2).

Classe S1 regles_evolution = (R1 R2 ) base_regles = B*S1 Classe Strategie_defaut base_regles : un Meta_Base Lien de spécialisation Classe B*S1 Classe Bases Classe R1 Classe Regles_evolution Classe R2

Figure 8-10 : Modélisation d’une stratégie

Ecran 8-2 : Modélisation des règles et des strategies

Algorithmes d’activation et de désactivation d’une stratégie

Lorsque l’utilisateur active une stratégie donnée (s), dans un premier temps on désactive les autres stratégies et on active toutes les règles de s. Puis, on active les règles des super-stratégies directes et indirectes, sauf celles que s redéfinit. L’activation (resp. désactivation) d’une stratégie correspond à l’activation (resp. désactivation) des règles d’évolution définies ou redéfinies dans cette stratégie. Et l’activation (resp. désactivation) d’une règle d’évolution correspond à l’activation (resp. désactivation) des règles ECA

Activer_stratégie (si)

Soit Sj la stratégie courante. /* stratégie active */ Soit SK l’ensemble de toutes les stratégies que si redéfinit. /* super-stratégies */ Soit RI l’ensemble des règles (définies et redéfinies) de si.

Soit RL l’ensemble des règles redéfinies par si. Désactiver_stratégie (sj).

Pour tout sk ∈ _{SK :}

Soit Rk l’ensemble des règles de sk.

Pour tout rk ∈ _{Rk : /* Activer les stratégies SK*/} Activer-règle (rk, sk).

Pour tout rl ∈ _{RL : /* désactiver les règles RL dans SK*/} Désactiver_règle (rl, sk).

Pour tout ri ∈ RI :

Activer-règle (ri, si). /* Activer la stratégie si*/

Stratégie-courante : = si.

Fin-activer_stratégie Désactiver_stratégie (si)

Soit SK l’ensemble de toutes les stratégies que si redéfinit. Soit RI l’ensemble des règles de la stratégie si

Pour tout sk ∈ SK :

Soit Rk l’ensemble des règles de sk.

Pour tout rk ∈ Rk : /* Désactiver les stratégies SK*/ Désactiver-règle (rk, sk).

Pour tout ri ∈ RI :

Désactiver_règle (ri, si). /* Désactiver la stratégie si */ Stratégie_courante := S0 /* Stratégie par défaut */

Fin-désactiver_stratégie

Activer-règle (r, s) /* r représente une règle d'évolution */

Soit RI l'ensemble des règles de la base base*s /* Au maximum, il en existe 4*/ Pour tout ri ∈ RI : /* Activer les règles ECA suivantes de base*s */ (activer_regle ri) /* Appel à la fonction Lisp pour activer une règle ECA */

Pour tout ri ∈ _{RI :} /* Désactiver les règles ECA suivantes de base*s */ (désactiver_regle ri) /* Appel à la fonction Lisp pour désactiver une règle ECA */

Fin-désactiver-règle

Dans les fonctions Activer_règle et Désactiver_règle, on fait appel aux fonctions activer_regle et désactiver_regle du moteur d'exécution des règles ECA. Tous les algorithmes présentés ci-dessus sont implémentés par des fonctions Lisp utilisant l’interface programmable du système actif.

Les coûts des algorithmes d’activation et de désactivation sont en fonction du nombre moyen de règles d’évolution dans une stratégie et de la profondeur du graphe de stratégies. Quant aux algorithmes de traduction des règles et des stratégies d’évolution, ils sont assez coûteux mais leur exécution a lieu uniquement en création ce qui ne degrade pas les performances d’exécution.

L’évolution des règles et des stratégies d’évolution est assurée par une technique de correction ; elle est réalisée d’une part par des opérations de maniuplation et d’autre part par des règles ECA.

8.6 CONCLUSION

L'évolution dans SHOOD concerne l'évolution des classes et des instances. Elle est mise en œuvre par un ensemble d'opérations constituant le support d'évolution (cf. Chapitre 4). Ce dernier peut être étendu par des stratégies et des règles d'évolution. Les règles d'évolution permettent d'exprimer, de manière déclarative, la sémantique de l’évolution d'une classe ou d'une instance. Quant aux stratégies (ensemble de règles d’évolution), elles permettent de définir plusieurs sémantiques d'évolution différentes et d'en activer une seule. L’ensemble des stratégies est organisé dans un arbre de spécialisation (héritage simple) où la spécialisation a pour sémantique l’héritage ou la redéfinition des règles d’évolution. Cette organisation des stratégies offre une meilleure réutilisation des règles d’évolution.

Parmi les inconvénients de ce mécanisme de règles et de stratégies, le passage d'une stratégie à une autre peut introduire des comportements non désirés. En effet, en changeant de stratégie courante, l’utilisateur peut hériter de règles d’évolution non souhaités ; et cela peut survenir si le programmeur ne possède pas une vue globale des stratégies. Une interface graphique

Une extension de ce travail est de définir une bibliothèque de stratégies d'évolution. Il existe plusieurs stratégies d'évolution connues, généralement implémentées dans les systèmes tels que ENCORE [Skarra87], ORION [Banerjee87] et GEMSTONE [Penney87]. On pourrait répertorier ces stratégies pour qu'elles soient utilisables directement, et bien sûr redéfinissables par le programmeur. De cette manière, on pourrait simuler la stratégie

d'ENCORE (expérience réalisée dans le cadre de la thèse de [Ahmed-Nacer94]).

Une lacune est due au fait que la sémantique des règles est exprimée dans les conditions et dans les actions de manière procédurale. Cette lacune ne permet pas de vérifier que deux règles sont incompatibles, c’est-à-dire qu’elles ne peuvent s’exécuter simultanément. Une perspective, mais à plus long terme, serait alors de vérifier la cohérence d’une stratégie.

9. EXPERIMENTATION

‘expérimentation du système d’évolution se situe dans le cadre de la conception d’un système à base de connaissances pour des applications du bâtiment [Culet93]. L’objectif est de permettre la mise au point technique et économique d’un projet de construction par une mise en commun des propositions émises par les différents corps de métiers pour répondre au descriptif fourni par le maître d’oeuvre. La base de connaissances, appelée DUA (Dossier Unique Actualisé), se présente alors comme un document de dialogue, de validation et de stockage d’informations concernant une opération immobilière.

Notre démarche pour le développement du DUA consiste à mener en parallèle la modélisation des connaissances structurelles et comportementales communes ou particulières aux différents intervenants et le développement d'un prototype permettant une validation du système [Culet94]. En effet, la modélisation et le prototypage se font en parallèle ce qui nécessite, d’une part, une transformation sans perte entre le modèle et le système de représentation, et d’autre part, de bénéficier d’un outil informatique suffisamment évolutif pour que le prototypage puisse entrer dans le cycle de développement du système à base de connaissances.

Cette application est décrite dans cette thèse pour présenter une utilisation de la dynamique de SHOOD. L'évolution du système SHOOD a permis, d'une part, la réalisation d'une maquette par prototypage incrémental [Dieng90], et d'autre part, le contrôle de l'intégrité des descriptifs et la gestion des variantes de l'opération immobilière [Bounaas95b]. Cette application utilise principalement le support d'évolution de SHOOD, ainsi que les règles actives.