Nous désignons par schéma actif l'ensemble des règles, bases et événements permettant de décrire l'activité d'un schéma applicatif (cf. 7.2.1). Dans cette section, nous décrivons la modélisation des concepts du schéma actif. Pour cette modélisation, nous utilisons les concepts du modèle SHOOD, en particulier, le niveau méta.
7.3.1 Modélisation
7.3.1.1 Les événements
Les événements sont hiérarchisés ; ils sont modélisés par des classes, instances de la méta-classe Méta_événement (Figure 7-8). La racine des événements est la méta-classe Evénements ; elle
possède trois sous-classes qui sont les racines respectives des graphes des événements de type appel méthode, retour méthode et utilisateur.
Nom_classe = Objet
Nom_classe Attributs
= Méta
= Nom_classe un Chaîne
Attributs ens Méta_attribut Nom_classe Attributs
= Evénements
= Règles ens Méta_règle
Nom_classe Statut Sémaphore Attributs = Appel*Supprimer_instance = Vrai = 0 = oid*type un Méta oid*valeurs ens Objet Règles ens Méta_règle
Nom_classe Attributs
= Evénements_utilisateur = Règles ens Méta_règle
Nom_classe Attributs
= Evénements_retour = Règles ens Méta_règle Nom_classe Attributs = Méta_événement Statut un Bool Sémaphore un Entier Nom_classe Attributs = Evénements_appel = Règles ens Méta_règle
Une RE: oid*type oid*valeurs Règles = Rectangle = = (R1) Lien de spécialisation Lien d'instanciation =
Figure 7-8 : Modélisation des événements
Les attributs d'une classe événement représentent la source de cet événement, et leurs instances sont des références événementielles (RE) (cf. § 7.1.2.1). Pour une RE, les valeurs des attributs désignent son filtrage. Comme deux filtrages (cf. § 7.1.2.1) sont possibles pour chaque paramètre de la source, à un paramètre correspond deux attributs, l'un pour renseigner le filtrage sur le type, l'autre pour renseigner le filtrage sur l'énumération des valeurs. C'est ainsi que dans la classe-événement Appel*supprimer_instance, on retrouve deux attributs (oid*type et oid*valeurs) pour la source oid (Figure 7-8). On retrouve aussi, un attribut "Règles" défini dans la classe Evénements et valué pour chacune des RE. Cet attribut permet au moteur d'exécution de connaître rapidement les règles à sélectionner lorsque le filtrage d'une RE est satisfait.
7.3.1.2 Les règles
Les règles sont modélisées par des classes instances de la méta-classe Méta-règle. Les attributs de cette méta-classe sont, entre autres, l'expression événementielle, qui n'est autre qu'un ensemble de RE, la condition, l'action, le statut de la règle (active ou inactive), les paramètres d'entrée, les variables locales et l'attribut Inhibe, qui indique les règles qui sont inhibées (implicitement et explicitement) (Figure 7-9).
Nom_classe Attributs = Objet = Nom_classe Attributs = Méta = Nom_classe un Chaîne Attributs ens Méta_attribut
Nom_classe = Règles Nom_classe Statut ... = Base_1*R1 = Vrai ... Nom_classe = Règles_propagation Nom_classe = Règles_vérification Nom_classe Attributs = Méta_règle Statut un Bool Sémaphore un Entier Inhibe ens Méta_règle Est_inhibe_par ens Méta_règle Evénements ens Evénements Paramètres ens Objet_lisp Variables ens Chaîne Condition un Code Action un Code Lien de spécialisation Lien d'instanciation 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 AA AA AA AA AA AA AA AA AA AA AA =
Figure 7-9 : Modélisation des règles
La modélisation des règles par des classes offre deux avantages : les instances d'une classe-règle permettent d'une part de sauvegarder le contexte d'exécution à travers les variables locales et les paramètres d'entrée, et d'autre part de garder une trace de l'exécution des règles dans la perspective d'expliquer le déroulement de l'exécution.
7.3.1.3 Les bases
Les bases sont modélisées par des classes ; elles sont instances d'une nouvelle méta-classe
Méta-Base, sous-classe de Méta. Cette dernière possède un attribut Règles qui permet
d'indiquer les règles définies au niveau de chaque base. Les classes-bases ne possèdent ni attributs propres, ni instances ; elles permettent seulement de hiérarchiser le comportement actif. La classe Bases est la racine du graphe des bases (Figure 7-10).
Nom_classe Attributs = Objet = Nom_classe Attributs = Méta = Nom_classe un Chaîne Attributs ens Méta_attribut
Nom_classe Attributs
= Méta_base
= Nom_classe un Chaîne Règles ens Méta_règle
Nom_classe = Bases Nom_classe Règles = Base_1 = (R1 R2) AAA AAA AAA AAAA AAAA AAAA AAAA AAAA AAAA A A A AAA AAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Lien de spécialisation AAA AAA AAAA AAAA AAAA AAAA AAAA AAAA A A Lien d'instanciation 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 AAA AAA AAA AAA AAA AAA
7.3.2 Le noyau du système actif
Le graphe de classes et de méta-classes décrits ci-dessous (Figure 7-11) représent le système actif minimal permettant de représenter le comportement actif d'une application. Remarquons que la modélisation de ce noyau n'a modifié aucun concept de SHOOD déjà existant. Le comportement actif des objets est regroupé dans des bases, et non au niveau des classes ou des méthodes. Evénements_utilisateur Règles_vérification Evénements_appel Règles_propagation Méta_base Méta_règle Méta_événement Objet Evénements Méta Bases Règles
Lien de spécialisation 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 A A A A A A Evénements_retour
Figure 7-11 : Le noyau du Système Actif
Le Schéma Applicatif est alors complètement indépendant du Schéma Actif, la réciproque étant fausse. Par exemple, quand une méthode change de nom, les classes des événements qui lui sont associées doivent aussi changer de nom. Cette dépendance fait des événements des objets actifs sensibles aux opérations réalisées sur les objets du Schéma Applicatif. Ce comportement est réalisé par des règles ECA. En effet, l'évolution des règles, des événements et des bases est assurée par un ensemble de règles. De ce fait, le système Actif devient évolutif, car il peut s'auto-modifier.
Soit un exemple de règle permettant le changement de nom d'une méthode : R : E : Retour Modifier_nom_classe (Classe Méta-méthode).
C : événements = extraire_événements_méthode (Classe).
A : MAPC ('modifier_nom_classe événements Classe).
Le schéma actif est sensible aux modifications des méthodes. La modification des connaissances modélisées par une méthode implique la modification des connaissances associées aux événements. Pour cette raison, nous introduisons un ensemble de règles pour gérer les vérifications et les propagations afin de maintenir la consistance du schéma actif. De même nous avons défini un ensemble de règles pour gérer l’évolution des règles et des bases de règles.
Gestion des événements
Un événement possède le même nom que la méthode correspondante. Si cette dernière change de nom, le nom de l’événement associé doit lui aussi changer. Si une méthode est créée et qu'elle possède des sous-méthodes dont les classes-événements existent (Figure 7-12), les événements appel et retour correspondants à la méthode créée doivent aussi être créés. La suppression d'une méthode entraîne celle des événements correspondants. Les deux graphes d'événements sont parallèles au graphe des méthodes. Aussi, si un lien de spécialisation est supprimé ou créé dans le graphe des méthodes, il doit aussi l'être dans les graphes des événements. Methodes M1 M2 M3 Evénements appel appel*M1 appel*M2 appel*M3 Methodes M1 M2 M9 Evénements appel Appel*M1 Appel*M2 Appel*M9 M3 Appel*M3 création de M9 Spécialisation
Figure 7-12 : Conséquence de la création d'une méthode
Le fait de créer la méthode M9 qui est super-méthode de M3 implique la création de la classe-événement "appel*M9" car la classe-classe-événement "appel*M3" existe et que cette dernière doit hériter de la source de l'événement appel M9. Si la événement "appel*M3" n'existait pas, la classe-événement "appel*M9" n'aurait pas été créée car elle ne possède pas de Réfénce Evénementielle et que sa source n'est pas héritée.
Comme les paramètres d'un événement sont définis à partir des arguments de la méthode, si un argument d'une méthode est modifié, la modification doit être répercutée sur les paramètres des événements correspondants. Les modifications prises en compte pour un argument sont le changement de nom, le changement de domaine, le changement de famille (entrée, sortie) et au niveau de la méthode même : la suppression ou la création d'un nouvel argument.
D’autres règles ECA
La Figure 7-13 présente le graphe de bases qui gère l’évolution du schéma actif. Lors de la suppression d'une base, la règle de vérification "confirmer_supp_base" demande confirmation
à l'utilisateur ; si celui-ci accepte, l'opération n'est pas interrompue et la règle de propagation "supprimer_regles_base" supprime alors les règles de la base.
Bases_système Gestion_événements Gestion_règles&bases Gestion_schéma_actif supprimer_règles_base confirmer_supp_base interdire_supp_base_sys interdire_supp_règle_sys interdire_supp_événement_sys Inhibition Spécialisation
Figure 7-13 : Les bases gérant l’évolution du schéma actif
Par l'intermédiaire des règles de vérification de la base "gestion_schema_actif_sys", nous interdisons à l'utilisateur la suppression des règles système, des bases système et des événements utilisateurs. Nous remarquons que le message d'erreur de la règle "interdire_supp_base_sys" est prioritaire sur celui de la règle "confirmer_supp_base", la contrainte étant plus stricte.