Une règle multi-classe est une règle qui modélise le comportement d'objets issus de classes différentes. Comme pour les méthodes, les règles peuvent être multi-classes car il est souvent difficile de choisir la classe d'appartenance d'une règle.
On désigne par schéma applicatif, la modélisation de l’application dans le système SHOOD et par schéma actif l’ensemble des règles, événements et bases permettant de rendre actifs les objets du schéma applicatif. La modélisation du comportement d'un objet hors de sa classe permet une meilleure réutilisation des classes : les classes d'un schéma applicatif peuvent être réutilisées dans d'autres schémas actifs.
Les règles sont donc modélisées hors des classes des objets actifs. Mais afin de permettre une meilleure exploitation des règles, celles-ci seront regroupées dans des bases hiérarchisées.
7.2.2 Regroupement des règles
Afin de mieux organiser l'ensemble des règles, nous proposons de les regrouper dans des bases, que l’on pourra hiérarchiser. Le concept de "Bases" inspiré de NEOPUS [Pachet 92] permet de partitionner et de hiérarchiser un ensemble de règles. Aucun contrôle n'est effectué sur le regroupement des règles dans les bases. L'utilisateur est libre de choisir le thème associé à une base. L'un des critères consiste à regrouper les règles selon les objets actifs dont elles modélisent le comportement.
SHOOD disposant d'un mécanisme permettant de hiérarchiser les concepts, nous avons alors choisi de modéliser les bases de règles par des classes. A la notion de classes et sous-classes, nous faisons correspondre la notion de bases et sous-bases. La relation de spécialisation a pour sémantique l'héritage et la redéfinition des règles. Une base possède des règles qui lui sont propres et des règles héritées de ses super-bases : ainsi une sous-base possède un comportement plus spécifique que ses super-bases. Lors du choix de regroupement des règles, l'utilisateur va devoir tenir compte de cette hiérarchie. Le thème associé à une sous-base doit être plus spécifique que ceux associés aux super-bases de celle-ci (Figure 7-3)
Une classe étant une instance d'une méta-classe (Méta ou une de ses sous-classes), les règles traduisant la suppression d'une classe doivent être regroupées dans une base plus spécifique que celle regroupant les règles traduisant la suppression d'une instance (instance de Objet ou une de.ses sous-classes).
7.2.3 Héritage des règles
Une base B possède des règles qui lui sont propres et des règles héritées de ses super-bases si elles ne sont pas redéfinies par des règles propres à la base B. Nous parlons de redéfinition de règle dans le cas où une base possède une règle ayant le même nom qu'une règle appartenant à une super-base.
SHOOD autorise l'héritage multiple, ainsi une base peut posséder plusieurs super-bases directes. Afin de résoudre les problèmes de conflits d'héritage des règles, on applique le même procédé que pour les attributs, à savoir la notion de nom complet (cf. Chapitre 3). Nous identifions une règle en préfixant son nom par le nom de la base où elle est définie. De ce fait, quand une base hérite de deux règles de même nom, issues de deux bases différentes, elle
Objet
Méta Base_instance
Base_classe
E : Supprimer_instance (oid : Objet) C : ---
A :
---E : Supprimer_classe (oid : Méta) C : ---
A :
multiple, entre deux règles dont l'une redéfinit l'autre, seule la plus spécifique (définie dans une base plus spécialisée) est héritée. Illustrons l'héritage multiple par l'exemple suivant :
Valuer Attribut (VA)
Valuer Lien Exclusif (VLE)
Valuer Lien Partagé (VLP)
Valuer Lien Partagé et Exclusif (VLPE) VA.R1 VA.R2 VA.R1 VA.R2 VLP.R1 VA.R2 VA.R2 VLP.R1 VLP.R3 VLE.R3 VLE.R3 VLP.R3
Figure 7-4 : Héritage des règles dans un graphe de bases
Dans SHOOD, un attribut est vu comme une relation sémantique entre deux objets. Un lien de dépendance (partagé ou exclusif) est modélisé par un attribut avec un comportement spécifique (cf. Chapitre 3). La base VA définit deux règles R1 et R2 pour gérer la valuation d'un attribut quelconque, la base Valuer Lien Partagé (VLP) redéfinit R1 (VLP*R1) et définit une règle R3 (VLP*R3) et VLE définit une règle R3 (VLE*R3). Dans la base qui gère simultanément les liens partagés et exclusifs (VPEL), on hérite de VLP*R1, plus spécifique que VLE*R1 ; on hérite des deux règles R3 de VLE et VLP (VLE*R3 et VLP*R3). Au cas où une règle R3 aurait été définie dans VLPE, les deux règles VLE*R3 et VLP*R3 n'auraient pas été héritées. Et si VLE avait surchargé R1, VLPE aurait hérité des deux règles VLE*R1 et VLP*R1 (aucune n'est plus spécifique que l'autre).
7.2.4 L'inhibition des règles
Dans le § 7.1.3, nous avons défini une forme d’inhibition entre les règles de vérification et les règles de propagation. Dans ce paragraphe, nous verrons une autre forme d’inhibition entre les règles de même famille. Une règle d'une base qui redéfinit une règle de même famille d'une super-base inhibe celle-ci dans le cas où elles sont sélectionnées simultanément et que leurs conditions sont satisfaites. Au lieu de dire qu'une règle en redéfinit une autre, nous dirons qu'elle l'inhibe ; nous parlerons de lien d'inhibition entre les deux règles.
Pour les règles de propagation, un lien d'inhibition représente l'inhibition de l'action de la règle inhibée. En d'autres termes, si la condition d'une règle inhibitrice n'est pas satisfaite, le moteur exécutera l'action de la règle inhibée si cette dernière a sa condition satisfaite (voir Figure 7-5). Pour les règles de vérification, le lien d'inhibition permet d'indiquer que le message d'erreur de la règle inhibitrice est prioritaire sur celui de la règle inhibée.
Dans l’exemple ci-contre, B2*R1 inhibe implicitement B1*R1. Si la condition C2 est satisfaite, alors A2 est exécutée. Et A1 ne sera exécutée que si l’évaluation de C2 est fausse et de C1 vraie.
Ces deux sémantiques entraînent le principe suivant : une règle de propagation ne peut inhiber que d'autres règles de propagation, et une règle de vérification ne peut inhiber que d'autres règles de vérification.
La redéfinition d’une règle établit un lien d'inhibition implicite ; on peut aussi inhiber explicitement des règles de noms différents. Un lien d’inhibition ne peut être inhibé qu’en modifiant le nom de la règle. A partir des liens d'inhibition, nous reformulons le principe d'héritage multiple des règles dans les bases : Une base hérite de l’ensemble des règles les plus spécifiques de ses super-bases, si elles ne sont pas inhibées par une autre règle au niveau de la base elle-même. Exemple Parallélogramme attributs : angle coté1 coté2 Losange Rectangle Carré Spécialisation
Figure 7-6 : Une hiérarchie de parallélogramme
Dans ce qui suit, nous décrivons un exemple de classification automatique d'un parallélogramme dans la hiérarchie ci-contre. Cette classification est représentée par un ensemble de règles définies dans une hiérarchie de bases.
B a s e B 1
R 1 : < E , C 1 , A 1 >
B a s e B 2
R 1 : < E , C 2 , A 2 >
R e d é f i n i t
Base_parallélogramme
Base_losange Base_rectangle
Base_carré
E: Appel valuer_attribut oid : Parallélogramme nom_att (coté1, coté2, angle) C: Vrai
A: rattacher (oid, Parallélogramme)
E: Appel valuer_attribut oid : Parallélogramme nom_att (coté1, coté2, angle) C: $coté1 = $coté2
A: rattacher (oid, Losange)
E: Appel valuer_attribut oid : Parallélogramme nom_att (coté1, coté2, angle) C: $angle = 90
A: rattacher (oid, Rectangle)
E: Appel valuer_attribut oid : Parallélogramme nom_att (coté1, coté2, angle) C: ($coté2 = $coté1) and ($angle = 90) A: rattacher (oid, Carré)
Nom_règle = Classifier
Nom_règle = Classifier
Nom_règle = Classifier
Nom_règle = Classifier
Figure 7-7 : Classification d'un parallélogramme
Les 4 règles ont la même référence événementielle, donc elles seront sélectionnées simultanément. De plus, ces 4 règles ont le même nom (Classifier) donc elles sont liées par des liens d'inhibition ; Base_parallélogramme*Classifier est la plus générale et Base_carré*Classifier la plus spécifique. La règle Base_carré*Classifier sera évaluée en premier ; si sa condition est satisfaite, le parallélogramme sera rattaché à la classe Carré et les autres règles seront inhibées. Dans le cas contraire, les règles Base_losange*Classifier et Base_rectangle*Classifier seront évaluées et si elles sont insatisfaites le parallélogramme sera forcément rattaché à la classe Parallélogramme. La règle Base_parallélogramme*Classifier ne possède pas de condition.
Après avoir défini les règles ECA et les événements dans SHOOD et avoir hiérarchisé le comportement actif des objets à travers un graphe de bases, nous allons maintenant décrire la modélisation des événements, des règles et des bases.