Dans cette partie nous ne faisons pas une description exhaustive des modèles, mais nous citons les particularités qui les différencient de HIPAC ou URDOS.
6.4.1 Le modèle Exact
Le modèle EXACT est issu de l'introduction du concept d'Objet Actif dans le SGBDOO ADAM
[Diaz91] [Diaz94]. Comme dans HIPAC et URDOS, les règles et les événements sont représentés par des objets. Mais ici, les règles suivent le paradigme objet à la lettre, elles sont encapsulées dans les classes dont elles modélisent le comportement actif. Comme les classes sont hiérarchisées suivant une relation de spécialisation, les règles sont elles aussi hiérarchisées. Ainsi les règles des super-classes sont héritées dans les sous-classes.
Une règle est un objet dont deux des attributs indiquent l'événement déclencheur : le nom de la méthode déclenchante (ou opération) et le moment du déclenchement (avant ou après l'exécution de la méthode). Un autre attribut de la règle indique les objets de la classe active (où elle est encapsulée) qui font exception au comportement actif modélisé par la règle. Une règle est sélectionnée lorsqu'un des objets de la classe active reçoit l'événement (l’appel de méthode), sauf si cet objet y fait exception.
Une dernière particularité de EXACT concerne la distinction de trois familles de règles : les règles utilisateur, les règles d'intégrité, les règles de propagation. Les règles de la première famille, comme leur nom l'indique, sont créées par l'utilisateur tandis que les autres sont générées par le système. Les règles d'intégrité correspondent aux contraintes d'intégrité spécifiées déclarativement par l'utilisateur. Les règles de propagation concrétisent la sémantique des relations (liens d'héritage, liens référentiels ... ) exprimée dans la base.
6.4.2 Les travaux de Medeiros
Les travaux de Medeiros7[Medeiros90] [Medeiros91] ont été implémentés sur le SGBDOO O2. Deux particularités le distinguent des autres : la définition de l'événement, la représentation des règles.
Deux types d'événements existent : les événements déclenchés par le système "d'envoi de messages" et les événements temporels. Le modèle possède l'opérateur événementiel de disjonction. L'expression d'un événement "envoi de messages" spécifie un filtrage sur sa source :
• E=C : désigne un message quelconque envoyé à n'importe quel objet de la classe C. • E=O : désigne un message quelconque envoyé à un objet précis O.
• E=(C,m) : désigne un message pour la méthode m de la classe C.
• E=(O,m) : désigne un message pour la méthode m à destination de l'objet O.
La saisie d'une règle donne naissance à une règle "externe" et à un ensemble de règles "internes". La règle "externe" est l'image de la spécification donnée par l'utilisateur ; elle est stockée sous forme d'objets. Ensuite, suivant l'expression événementielle de la règle, la règle est décomposée en règles "internes". Cette décomposition suit les trois étapes suivantes :
• Si l'expression événementielle est une disjonction d'événements, pour chaque opérande événementiel, une nouvelle règle est créée par duplication.
• Ensuite pour chaque règle dérivée, si l'événement ne précise pas une méthode, la règle est dupliquée pour chaque méthode appartenant à l'objet (ou la classe) spécifié.
• La dernière étape concerne l'héritage des règles. Pour chacune des règles dérivées, si l'événement spécifie une classe C, cette règle est dupliquée dans toutes les sous-classes de C.
L'ensemble des règles dérivées constitue les règles internes. La condition et l'action d'une règle interne sont compilées en une méthode (transparente à l'utilisateur). Cette méthode est ensuite liée à la classe spécifiée au niveau de l'événement de la règle interne. Cette approche présente l’inconvénient de diminuer les performances du système, car la gestion de l’espace des règles internes est complexe.
6.4.3 Sentinel
SENTINEL [Chakravarthy94] est une extension du système Open OODB (Texas Instrument)
avec des règles actives de type ECA. Le langage de spécification SNOOP [Anwer93] définit des événements de types primitifs (début et fin de méthode, transactionnel et temporels) et les événements composites formés par des opérateurs classiques tels que la conjonction, la séquence et la disjonction et des opérateurs sur les occurrences des événements (Periodic
Event Operators et Aperiodic Operators).
Afin de constituer le contexte de déclenchement de l'événement, qui peut être composé de plusieurs occurrences d'événements, Snoop propose quatre façons de procéder :
• recent : prise en compte de l’événement le plus récent seulement.
• chronicle : Les occurrences d'événements sont prises en compte dans l'ordre
chronologique.
• continious : toute occurrence d'événements est prise en compte comme le début potentiel
d'une composition d'événements.
• cumulative : tous les paramètres des occurrences d'événements sont pris en compte pour
construire un seul contexte d'un événement composite.
Afin d'éviter des mises à jour pendant l'évaluation de la condition, les événements générés pendant l'évaluation de la condition sont ignorés. Les règles et les événements étant modélisés par des objets, la création des règles peut être dynamique.
6.4.4 Samos
SAMOS, prototype en cours de développement à l'université de Zurich, offre la particularité de proposer un langage de spécification d'événements assez puissant [Gatziu92]. Il distingue les événements primitifs tels que les événements avant et après l'appel de méthode, temporels et externes, ainsi que les événements composites avec les constructeurs suivants : disjonction, séquence, conjonction, première occurrence, négation, etc.
Les règles peuvent être définies soit dans les classes (règles internes), soit en dehors (règles externes). Quant au modèle d'exécution, il est presque similaire à celui d'HIPAC.
6.5 LE SYSTEME NEOPUS
NEOPUS [Pachet92] est un système de représentation de connaissances alliant des objets "au sens classique"8
et des règles de production d'ordre 1. La description qui suit présente une infime partie des concepts de NEOPUS, car seule une partie de la modélisation des règles de production nous intéresse.
Les règles de production sont formées d'une composante "Prémisse" (condition) et d'une composante "Action" et sont identifiées par un nom. Elles sont compilées sous la forme de méthodes SMALLTALK [Goldberg83] et regroupées dans des bases selon le choix de l'utilisateur. Une base représente l'abstraction d'une certaine connaissance. Les bases sont des classes SMALLTALK.
Le langage SMALLTALK respecte le principe d'encapsulation : les méthodes sont intégrées dans les classes. Les classes sont arrangées dans un graphe d'héritage. Les sous-classes héritent des propriétés de leurs super-classes, en particulier des méthodes. Ces dernières peuvent être surchargées au niveau des sous-classes.
Les bases étant des classes, elles sont aussi hiérarchisées dans un graphe. Les règles sont les méthodes de ces classes. Comme pour les méthodes, les règles des super-bases sont héritées dans les sous-bases et peuvent y être redéfinies.
L'héritage dans les bases de règles est utilisé par le moteur d'inférence. La stratégie de contrôle, nommée HBR (Héritage de Bases de Règles) est la suivante : "Elle consiste à
préférer les règles définies dans la base la plus basse". Illustrons cette stratégie par un
exemple repris de la thèse de Pachet [Pachet92].
Soit A une base de règles, sous-base de B (figure ci-dessus). B définit deux règles r1 et r2. A définit deux règles r1 et r3 (r1.A surcharge r1.B).
Le mécanisme d'héritage et de redéfinition implique que A contient en fait trois règles : r1 (définie dans A), r2 (définie dans B) et r3 (définie dans A) En cas de conflit, la stratégie HBR va préférer systématiquement les règles de A par rapport à celles de B. Par exemple, si r1 et r2 sont déclenchables, r1.A sera choisie.