URDOS (Using Rules for a Dynamic Object System) est "un outil générique (portable) permettant d'introduire la composante active dans un SGBD hôte virtuel" [Tchounikine93]. C'est un modèle très récent qui a été étudié et conçu au laboratoire SIG/IRIT de Toulouse
L'objectif de généricité de l'outil a donné naissance à un modèle simple dont les concepts ont des définitions diffèrentes de celles du modèle HIPAC. Le Schéma Actif est la partie de URDOS
qui a le plus retenu notre attention. Mais avant tout, voyons les définitions des termes E,C,A.
6.3.1 Le triplet <E,C,A>
URDOS dispose de deux types d'événements : les événements Base de Données et les événements temporels. Si les événements temporels sont semblables à ceux de HIPAC, les événements BD ont une définition très différente.
HIPAC et les systèmes que nous verrons par la suite proposent une modélisation de règles intégrée au système de base. Le mécanisme de déclenchement des événements est alors câblé dans le système. URDOS devant être portable, il n'était pas possible de coder le déclenchement des événements. Cette remarque et d'autres raisons [Tchounikine93] sont à l'origine d'une nouvelle définition de l'événement "BD".
URDOS déclenche un événement "BD" après une mise à jour de la base, lorsque le système fige la modification (au moment du "commit", qui permet de récupérer les identifiants des objets modifiés). URDOS ne déclenche pas un événement sur une opération spécifique, comme l'appel d'une méthode M, mais sur une opération générique qui est la modification de la base. L'outil permet pourtant d'exprimer une infinité d'événements en définissant un événement comme un état spécifique de la base. Les événements sont décrits par un triplet <I,S,CO> où :
• I est l'identificateur de l'événement,
• S est une requête définissant la source de l'événement. La source indique quels doivent être les objets modifiés pour déclencher cet événement. Elle obéit à la hiérarchie des objets. Si la source spécifie une classe C, elle englobe toutes les instances de cette classe, mais aussi toutes les instances de toutes les sous-classes de C.
• CO est la condition d'occurrence de l'événement. Elle spécifie l'état dans lequel doit se trouver la base (en particulier les objets modifiés) pour que l'événement soit déclenché.
Un exemple d'événement : E : I : "fin stock"
CO : l'attribut "quantité en stock" est en dessous du seuil.
L'événement "fin stock" est évalué à l'issue de toute modification d'une instance de la classe produit. Si la condition d'occurrence est satisfaite, l'événement est déclenché.
La condition est une requête booléenne exprimée dans le langage de requête du SGBD hôte ou le résultat d'une méthode booléenne. Toujours par souci de portabilité, l'action est une série de messages (appels de méthodes). L'objet mis à jour (déclencheur de l'événement) est une donnée commune à la condition et à l'action.
Une règle peut être active/armée ou inactive/désarmée. L'utilisateur peut aussi spécifier une priorité pour chacune d'elles. A cette priorité statique s'ajoute une priorité dynamique qui est calculée lorsque plusieurs événements sont déclenchés simultanément [Tchounikine93].
6.3.2 Le Schéma Actif
Les concepteurs d'Urdos ont constaté que l'activité d'un objet ne lui est pas intrinsèque, mais qu'elle dépend du contexte applicatif. Les règles sont alors représentées par des objets qui sont externes aux classes dont elles modélisent l'activité. Cette modélisation va aussi permettre d'écrire des règles multi-classes tout en libérant l'utilisateur du choix de la classe à laquelle est associée la règle.
URDOS représente l'activité des objets au sein d'un Schéma Actif qui est indépendant du schéma applicatif (Figure 6-10). Cette approche permet d'importer la définition des règles et des événements (le Schéma Actif) dans n'importe quel schéma d'application d'un SGBD hôte. Ensuite l'utilisateur pourra créer les règles qui modélisent l'activité de l'application.
AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Règles Objets Règles Objets Schéma Base Application 1 Application 2 Schéma Base Schéma Actif Importation
Le concept du Schéma Actif présente un avantage majeur, qui est la réutilisation des objets. En effet, lors de la modélisation du comportement actif d'un objet, la structure interne de celui-ci n'est pas modifiée. Cet objet peut alors être réutilisé dans une autre base, indépendamment de son activité.
Le Schéma Actif comprend en particulier une classe Règle dont toutes les règles seront les instances. Les événements sont aussi modélisés par des objets, qui peuvent être utilisés dans plusieurs règles. Réifier6
les événements, permet de les factoriser dans les règles et d’offrir une conception incrémentale de ces règles. En effet, l'utilisateur pourra définir un événement, ensuite les règles qui référencent cet événement. L’ensemble des types d’événements est représenté par une hiérarchie de classes (Figure 6-11).
Evénement Règle Evénement Temporel Evénement BD Evénement Absolu Evénement Relatif AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AA AA AAAAAAAAAAAAAAAAAAAAAA Lien de spécialisation
Figure 6-11 : Le schéma Actif
6.3.3 Bilan
Ce modèle est une illustration très simple du concept d'Objet Actif via des règles ECA : pas d'opérateur événementiel, ni de mode de couplage (pour l'instant) et des liens entre les trois composantes <E,C,A> réduits au minimum.
La définition particulière donnée à l'événement "BD" est surtout due au fait qu'URDOS est un outil générique. Cet outil se voulant portable sur tous les systèmes, le déclenchement des événements "BD" ne peut pas être associé aux méthodes, car il nécessiterait un mécanisme interne au système hôte.
Cependant la composante "Condition d'Occurrence d'événement" ("CO") nous paraît discutable. En effet, nous pensons qu'un événement doit correspondre uniquement à une opération sur la base de données, laissant aux règles le rôle de tester le contexte dans lequel s'est produit l'événement. Exprimer une condition dans l'événement ne permet que de factoriser, au niveau de celui-ci, une condition commune à plusieurs règles, ces dernières possédant aussi chacune une condition particulière.
6
Le concept de schéma actif nous paraît intéressant et compatible avec la philosophie de SHOOD, car il permet l'expression de règles multi-classes et la construction de schéma applicatif indépendant de son activité.