FR2793918A1

FR2793918A1 - Procede d'acces, dans un systeme informatique, a des objets d'un arbre de contenance

Info

Publication number: FR2793918A1
Application number: FR9906356A
Authority: FR
Inventors: Philippe Baudry
Original assignee: Bull SA
Current assignee: Bull SA
Priority date: 1999-05-19
Filing date: 1999-05-19
Publication date: 2000-11-24
Also published as: WO2000072510A1

Abstract

La présente invention a pour objet un procédé d'interrogation, dans un système informatique, par l'intermédiaire d'au moins une requête d'au moins un objet inclus dans au moins un arbre de contenance inclus dans au moins une machine se reposant sur le protocole de gestion de type CMIP, une requête consistant en une mise à jour ou en une consultation des objets de l'arbre de contenance, une requête incluant un contexte comprenant l'ensemble des paramètres (classes, attributs, opérateurs, variables, etc. ) décrivant tous les éléments d'une requête, au moins un paramètre se reposant sur la règle de compatibilité entre instances limitant le traitement de la requête à un sous-ensemble d'instances d'une classe, caractérisé en ce qu'il consiste, à créer un opérateur propre à inhiber, sur une classe donnée, les règles de compatibilité sur instances de façon à traiter la requête sur l'ensemble des instances de la classe sur lesquelles porte la requête.

Description

Titre: Procédé d'accès, dans un système informatique,à des objets d'un arbre de contenance.

La présente invention a pour objet, dans un système informatique, un procédé d'accèsà des objets d'un arbre de contenance.

L'arbre de contenance est inclus dans un système de gestion. Le système informatique peut contenir plusieurs systèmes de gestion. Le terme gestion sera utilisé pour être conformeà la traduction Afnor (Association Française de NORmalisation) de Management . Egalement, le terme arbre de contenance sera utilisé comme traduction du terme MIB (Management Information Base) issu de la norme OSI (Open Systems Interconnection).

Un système informatique comprend une machine ou plusieurs machines reliées au système de gestion par l'intermédiaire d'un réseau LAN (Local Area Network), WAN (Wide Area Network) ou INTERNET. Ce système peut être un système distribué ou non, hétérogène ou non.

Un système distribué est un environnement de système informatique qui fonctionne au moyen d'au moins deux systèmes d'exploitation identiques ou différents. Une machine est associéeà un système d'exploitation. Une machine comprend au moins une ressource physique (par exemple des réseaux, des concentrateurs, des segments, etc) ou logique (par exemple une base de données, etc.).

Un système informatique hétérogène contient en général une variété de protocoles de gestion. Dans ce système, chaque machine est associéeà au moins un protocole de gestion.

Dans ce système informatique, au moins un agent est, en général situé sur'une machine du système informatique. Un agent traite des requêtes qui lui sont adressées. Un agent logiciel gère et metà jour des données sur la machine sur laquelle il est situé. Chaque agent supporte un protocole tel que le protocole SNMP (Simple Network Managment Protocol), le protocole CMIP (Common Managment Information Protocol), le protocole DSAC (Distributed Systems Administration and Control) ou d'autres protocoles. Le système de gestion commande les agents, et l'agent répond et notifie des événements en utilisant un protocole de gestion identique SNMP, CMIS/CMIP ou DSAC/AEP (DSAC Administrative Exchange Protocol). Le système de gestion comprend plusieurs agents dits agents intégrateurs en ce sens qu'ils sont intégrés au système de gestion. Les agents et les agents intégrateurs du (des) système(s) de gestion coexistent et communiquent pour masquer l'hétérogénéité du réseau. Dans ce système informatique, un système de gestion de machines d'un système informatique de type OPENMASTER (marque déposée par la société BULL S.A.), connue de l'homme du métier, est particulièrement bien adapté. Ce système utilise des services CMIS (Common Managment Information Services) normalisés, connus de l'homme du métier. Ce système de gestion peut être assimiléà un ensemble de services qui interagissent entre eux pour donner une représentation virtuelle du monde réel qui est le système informatique. C'est une représentation virtuelle qu'un administrateur manipule (surveillance, action) pour gérer le monde réel. La représentation virtuelle porte sur des objets virtuels du monde réel et constitue un modèle objet. Cette représentation virtuelle est concrétisée par l'intermédiaire d'un arbre de contenance. Par définition, l'arbre de contenance est strictement hiérarchique. Le service CMIS (Common Managment Information Services) est bien adaptéà la structure hiérarchique de l'arbre de contenance. Dans l'exemple de mise en oeuvre, cet arbre est un logiciel conforme au protocole CMIP (Common Managment Information Protocol). Cet arbre comprend en ses noeuds l'ensemb[e des objets gérés par le système de gestion. Par définition, un objet géré est une vue abstraite, définie pour les besoins de gestion, d'une ressource logique ou physique d'un système. Une classe d'objets gérés est un ensemble nommé d'objets gérés partageant les mêmes propriétés. Un attribut est une caractéristique d'un objet géré qui a un type nommé et une valeur. La valeur d'un attribut d'un objet peut être consultée ou modifiée par une requête adresséeà l'objet. Nommer un objet d'une classe donnée, c'est choisir, conformément aux liens de nommage possibles, ce que l'homme du métier appelle le plus souvent son Full Distinguished Name FDN, c'est-à-dire choisir son supérieur dans l'arbre de nommage et choisir un nom que l'homme du métier appelle le plus souvent Distinguished Name DN vis-à-vis de ce supérieur. Le nommage des objets fait appelà un arbre de nommage. Chaque objet se situe dans l'arbre de nommage par rapportà un supérieur dont il est le subordonné. Cette relation entre subordonnée et supérieure est spécifiée au niveau des classes par un lien de nommage (name binding en anglais). Lors de la création d'un objet, il faut choisir un seul lien de nommage parmi les liens de nommage possibles pour les objets de cette classe. Plusieurs liens de nommage peuvent être définis pour une même classe, mais un objet ne peut avoir qu'un seul supérieur immédiat. En d'autres termes, chaque instance de l'arbre est identifié par un FDN et un DN. Le nom DN est un couple < attribut de nommage> < valeur> qui permet l'identification unique d'une instance de l'arbre de contenance par rapportà une instance père. Le nom FDN d'une instance est une suite de noms DN montrant le chemin de la racine jusque cette instance. De manière générale et connue de l'homme du métier, pour créer un objet dans cette base, il faut choisir sa classe, le nommer conformément aux liens de nommage relatifsà la classe, et donner une valeurà ses attributs. Un arbre de contenance est un arbre constitué d'instances de classes. Actuellement, il est possible de construire une requête de consultation ou de miseà jour de l'arbre de contenance et de l'exécuter. Un gros problème est que les opérateurs reposent sur une notion de compatibilté de noms FDN. Par définition, deux noms FDN sont compatibles si et seulement si leurs sous-FDN calculés sur le sous-arbre de classes commun depuis la racine sont identiques. On dira par la suite que deux instances sont compatibles si leurs noms FDN sont compatibles. Considérons un arbre de contenance comprenant une racine, quatre instances subordonnées al, a2, bl, etb2 à cette racine. Les instances (al,a2) appartiennentà la même classeA et (bl,b2) appartiennentà la même classe B. Considérons également que l'arbre comprend trois instances(dl, d2 etd3) subordonnéesà l'instance bl et trois instances (cl, c2 et c3) subordonnéesà l'instanceb2. Les instances(dl, d2 etd3) appartiennentà une classeD et les instances (cl, c2 et c3) appartiennentà la classeC.

Dans cet arbre, les instancesdl etd2 sont compatibles car elles admettent sur le sous-arbre commun des classes (classe B) le même nom distinctif FDN à savoir bl. Par contre, les instancesdl et c2 ne sont pas compatibles car elles admettent un sous-FDN respectif bl etb2 différent sur le sous-arbre commun des classes (classe B). Les instances bl etd3 sont compatibles car elles sont attachées par l'intermédiaire d'une branche dans l'arbre de contenance. De même les instances al etb2 sont compatibles car elles sont toutes deux directement attachéesà la racine de l'arbre de contenance. Cette notion de compatibilité découle naturellement B du modèle hiérarchique de données de l'arbre de contenance, a et face aux grands volumes de données inclus dans l'arbre, il traite et combine entre elles uniquement les instances ayant un lien de parenté (directement ou indirectement attachées par une branche de l'arbre de contenance). Le gros problème est que les traitements entre instances de classes différentes s'effectuent pour les réseaux évoqués précédemment entre instances compatibles entres elles (agrégation de variables externes, opérateurs de jointure,... ). Or, certains types de requêtes nécessitent une abstraction de ces règles de compatibilité de noms FDN, et nécessitent des calculs dans l'arbre de contenance non pas sur des instances compatibles entre elles mais sur des instances de classes quelconques de l'arbre. D'une manière générale, la règle de compatibilité intervient dès qu'une variable d'une requête fait référenceà une variable externe.Il en est de même pour les opérateurs (de jointure par exemple) et filtres spécifiant des variables dans leurs expressions. On qualifiera d'interne toute variable définie sur la classe courante et d'externe toute variable définie sur d'autres classes que la classe courante. Un premier but de la solution est donc de donner la possibilitéà un concepteur de requêtes de créer une requête dont le traitement ne se limite pasà un sous-ensemble d'instances d'une classe de l'arbre de classes. Un deuxième but visé est de procurer au système une puissance d'interrogation de l'arbre de contenanceà l'image des clauses dites Select du langage SQL connues de l'homme du métier. A cet effet, la solution a pour objet un procédé d'interrogation, dans un système informatique, par l'intermédiaire d'au moins une requête d'au moins un objet inclus dans au moins un arbre de contenance inclus dans au moins une machine se reposant sur le protocole de gestion de type CMIP, une requête consistant en une miseà jour ou en une consultation des objets de l'arbre de contenance, une requête incluant un contexte comprenant l'ensemble des paramètres (classes, attributs, opérateurs, variables, etc.) décrivant tous les éléments d'une requête, au moins un paramètre se reposant sur la règle de compatibilité entre instances limitant le traitement de la requêteà un sous- ensemble d'instances d'une classe, caractérisé en ce qu'il consiste,à créer un opérateur propreà inhiber, sur une classe donnée, les règles de compatibilité sur instances de façonà traiter la requête sur l'ensemble des instances de la classe sur lesquelles porte la requête.

Description d'un exemple illustrant la solution.

La solution apportée sera mieux compriseà la lecture de la description qui suit donnéeà titre d'exemple.

La solution peut s'appliquerà un système informatique distribué de type hétérogène. Dans l'exemple illustré, ce système inclut au moins un système gestionnaire et au moins une machine distante associéeà un protocole de gestion. Le système de gestion peut être compris dans une station de travail. Dans l'exemple, on a représenté une machine distante. Une machine comprend des objets manipulables. Une manipulation inclut des commandes connues de l'homme du métier. Le protocole de gestion de la machine peut- être indifféremment un protocole de type SNIVIP, CMIS/CMIP ou DSAC/AEP. Dans notre exemple, le système supporte un protocole de type CMIS conforme au modèle OSI (Common Managment Information service), connu de l'homme du métier. Cette application peut être lancée par l'intermédiaire d'un utilisateur de ce système de gestion. Un utilisateur peut être un administrateur.

Le système gestionnaire comprend également au moins un agent intégrateur associéà un protocole de gestion afin de masquer l'hétérogénéité du système informatique. Dans l'exemple illustré, un agent intégrateur est associé au protocole de gestion de la machine. De façon générale, un agent intégrateur est de type logiciel.Il procure des services. Un service peut être une conversion du protocole de gestion. Dans l'exemple illustré, l'agent intégrateur convertit le protocole de gestion du système de gestion en un protocole de gestion associéà la machine. Réciproquement, l'agent intégrateur convertit le protocole de gestion associéà la machine en un protocole de gestion associé au système de gestion. Un agent intégrateur ne se limite pasà ce type de service et procure d'autres services. De manière générale, une conversion de protocole de gestion s'effectue naturellement entre un système de gestion et une machine qui supportent des protocoles de gestion différents.

Naturellement, le serveur de gestion peut comprendre plusieurs agents intégrateurs. L'agent intégrateur est reliéà la machine par l'intermédiaire d'un réseau de type quelconque. Le réseau peut être de type LAN (Local Area Network) ou WAN (VVide Area Network). Un ensemble de couches logicielles s'interpose entre le système de gestion et le réseau et entre le réseau et la machine. Cet ensemble de couches logicielle repose sur le modèle OSI (Open System Interconnection) d'architecture en couche de VISO (International Organization for Standardization), connu de l'homme du métier.

Dans l'exemple illustré, une requête issue du système de gestion est transmiseà l'agent. Une requête est, de manière générale, une manipulation d'objets sur une machine distante. La construction d'une requête est expliquée dans la suite de la description.

Le système de gestion comprend aussi un arbre de contenance associé à l'agent.

L'arbre de contenance peut être entièrement compris dans l'agent. Cet arbre assure une représentation virtuelle du monde réel qui entoure le système de gestion. C'est une représentation virtuelle que l'utilisateur ou qu'un administrateur manipule (surveillance, action) pour gérer le monde réel. La représentation virtuelle porte sur des objets virtuels du monde réel et constitue un modèle objet. Dans l'exemple illustré, le monde réel est matérialisé par le machine.

Par définition, l'arbre de contenance est orienté objet et est constitué de noeuds et de branches. Cet arbre comprend en ses noeuds l'ensemble des objets gérés par le système de gestion. De manière générale et connue de l'homme du métier, pour créer un objet dans cette base, il faut choisir sa classe, le nommer conformément aux liens de nommage relatifsà la classe, et valoriser ses attributs. Un objet géré est une vue abstraite, définie pour les besoins de gestion, d'une ressource logique ou physique d'un système. Dans l'arbre de contenance, des noeuds appartiennentà une même classe. Un arbre de classes est créé. Dans l'exemple illustré, l'arbre de classes comprend3 classes: # une classe Inventaire, # une classe Network qui représente les réseaux découverts et est défini par des attributs: adresse IP du réseau, état du réseau (bloqué ou libre), nombre d'équipements pour le réseau, classe IP du réseau(A, ou B, ouC, ... ), adresse IP de l'équipement ayant permis la découverte du réseau, etc.

# une classe Equipement qui représente les réseaux découverts. Cette classe comprend des attributs: # adresse IP de l'équipement, # type de l'équipement (passerelle, concentrateur, etc.), # type d'équipement SNMP : oui/non # classe IP du réseau( IPA, ou IPB, ou IPC, etc.), # nom de l'équipement, # adresse IP de l'équipement ayant permis la découverte de l'équipement, # etc.

La valorisation de ces attributs conduità l'arbre de contenance. Cet arbre de contenance comprend la racine. Trois noeuds Il, Quartz, et 12 constituant des instances de la classe Inventaire sont des noeuds subordonnés à la racine. Trois noeuds NET1, NET2 et NET3 constituant des instances de la classe Réseau sont des noeuds subordonnés au noeud Quartz.

Enfin, dans cet arbre, chaque noeud NET1, NET2 et NET3 a des noeuds subordonnés respectifs (DEV1, DEV2, DEV3), (DEV4, DEV5, DEV6), (DEV7) instances de la classe Equipement. Considéronsà nouveau la requête Rl énoncée dans l'introduction: Dans l'inventaire Quartz, donner la liste des réseaux de classe IPB dont le nombre d'équipements est supérieurà la moyenne du nombre d'équipements des réseaux de classe IPA . Il est nécessaire d'apporter quelques définitions qui servirontà la compréhension de la description. Rappelons la définition d'un contexte de requête. Le contexte d'une requête se défini comme étant l'ensemble des paramètres décrivant tous les éléments d'une requête: # filtres # classes # attributs # opérateurs # variables, etc.

Considérons V une variable définie sur une classe X. Dans l'exemple illustré, la classe X peut être la classe Inventaire, la classe Réseau ou la classe Equipement. On qualifiera d'interne toute variable définie sur la classe X et d'externe toute variable définies sur d'autres classes que la classe X.

Une variable V peut avoir la forme suivante: V<B≥ attl ... < op> F(att2) ... < op> W... < op> G(Z) où attl, att2 sont des attributs de la classe X, W, Z sont des variables internes ou externesà la classe X F,G sont des fonctions qui s'appliquent sur des variables < op> est un opérateur arithmétique quelconque.

Rappelons qu'un filtre est un ensemble d'expressions basées sur les valeurs des attributs d'une classe donnée. Un filtre peut être décomposé en plusieurs expressions qui peuvent être combinées par l'intermédiaire des opérateurs booléenAND- OR- NOT connus de l'homme du métier. Rappelons également, dans l'exemple illustré, qu'au moins une variable est définie pour une classe donnée et que son évaluation repose sur des règles formelles citées ci-dessus. Par exemple, une expression ne peut renvoyer qu'à des attributs de la classe courante. De plus, une expression peut référencer des variables locales ou des variables externes définies sur une autre classe que la classe courante. La résolution de cette requête impose la décomposition en plusieurs sous-requêtes. Le gros problème, tel qu'énoncé dans l'introduction, est qu'il n'existe pas de moyens de décomposition d'une requête en sous-requêtes.

Le traitement de cette requête travaille sur deux sous-ensemble d'instances différents pour la même classe Réseau. Le premier sous-ensemble est constitué par les instances de la classe Réseau de classe réseau IPA et le deuxième sous-ensemble est les instances de la classe Réseau de classe IPB. Pour des raisons de simplifications de la description, les instances de la classe Réseau de classe réseau IPA et IPB seront notées réseauA et réseau B respectivement.

Cette requête pose un gros problème de conception avec les opérateurs actuels. Ainsi, la définition d'un filtre sur les réseauxA élimine les réseaux B, et vis versa. Dans l'exemple illustré, l'interprétation de la requête Rl conduit donc à créer deux sous-requêtes : # une première sous-requête SRO qui calcul, dans l'inventaire Quartz, la moyenne des équipements pour les réseauxA.

# une deuxième sous-requête SR1 qui sélectionne, toujours dans l'inventaire Quartz, les réseaux B dont le nombre d'équipements est supérieurà la moyenne calculée par l'intermédiaire de la première sous-requête SRO. Dans l'exemple illustré, la solution consiste en une suite d'étapes: Etape 1 : une première étape consisteà définir les opérateurs qui interviennent dans la requête Rl. Ces opérateurs sont pour la plupart inspirés de l'algèbre relationnel, complétés par le concept de variables permettant d'effectuer des calculs sur les données et de mettre en relation les classes entre elles. L'annexe1 donne un exemple d'opérateurs et la fonction associée que l'on trouve sur une machine de type OPENMASTER. Par exemple, on trouve des opérateurs fondamentaux comme le filtrage, la jointure, les tests ensemblistes (ls-in, Exists, Contains,...), le tri, le groupement (GROUP BY), l'opérateur Unique, etc. Des fonctions d'agrégation sur variables ou attributs comme SUM, MIN, MAX, COUNT, AVG, .... sont également disponibles.

Etape 2: une seconde étape consisteà déterminer la classe finale appelée aussi classe de sortie, pour la première et la seconde sous-requête. Cette classe de sortie est la classe sur laquelle on sélectionne les attributs et variables résultats. On détermine cette classe de sortie en fonction de la requête globaleà exécuter. Par opposition, lorsqu'une requête est exécutée, elle commence par une instance de la classe d'entrée.

Par construction, dans l'exemple illustré, les deux sous-requêtes admettent la même classe d'entrée, et donc seront lancées sur la même instance d'entrée. Dans l'exemple illustré, la classe d'entrée correspondà la classe Inventaire de l'arbre des classes. La requête globale porte sur une instance Quartz de cette classe Inventaire.

Dans un autre exemple, si les instances d'entrée sont différentes entre sous-requêtes, la requête globale doit donc avoir comme classe d'entrée la classe Racine.

De manière générale, une requête globale porte sur une ou plusieurs instances de base dont la classe doit correspondre avec la classe de départ de la requête globale.

La solution consisteà partager les données entre au moins deux sous- requêtes. Les deux sous-requêtes vont interagir en ce sens qu'elles vont toutes deux partager au moins une variable.

Etape 3 - Dans l'exemple illustré, la solution comprend une troisième étape de construction de la requête. Cette étape de construction peut être réalisée de deux manières.

- Un première manière consisteà créer la requête de manière unitaire. Plus précisément, on crée une sous-requête et on l'enregistre comme étant une sous requête d'une requête multiple. Successivement, on crée et on sauvegarde les autres sous-requêtes comme étant des sous-requêtes d'une même requête. Selon une variante préférée, le systèmeà la charge de créer dynamiquement des pointeurs qui vont lier toutes les sous-requêtes créées. Le lien de toutes les sous-requêtes constitue la requête multiple.

- Une seconde manière consisteà créer la requête de façon décomposée. On crée les sous-requêtes indépendamment l'une de l'autre. Afin de lier les sous- requêtes, l'utilisateur sélectionne la dernière requête créée et sélectionne ensuite une fonctionnalité du système propreà établir dans le contexte d'une requête un chaînage inverse. Ce chaînage inverse est procuré par l'intermédiaire de pointeurs.

Dans la description, on choisit comme exemple d'illustration le mode unitaire. Dans un exemple, la première sous-requête SRO a la forme suivante # Sur la classe Réseau: # Filtre: classe IP du réseau<B≥ A (1) # variable V-AVG=AVG (nombre d'équipements pour le réseau) (2) # Sur la classe Inventaire (classe d'entrée et classe finale) # variable moy-dev <B≥ V-AVG (3) # attributs résultat (facultatif): Identificateur de l'instance d'inventaire, moy_dev (4) Dans cette première sous-requête, l'expression(1) est un filtre sur l'attribut nommé classe IP du Réseau dont la valeur estA. Plus précisément, l'expression(1) est un filtre sur tous les réseauxA et élimine donc tous les réseaux B. Dans l'expression (2), la variable A-AVG est constitué d'une fonction d'agrégation AVG qui calcule pour tous les réseauxA la moyenne du nombre d'équipements. La requête comprenant une fonction d'agrégation, le traitement de cette requête ne porte alors que sur un sous- ensemble d'instances qui inclut l'attribut IPA. La définition du filtre réseauA élimine les réseaux B, et vis versa. La solution consiste donc a exporter, dans la première sous-requête SRO, le résultat obtenu sur la classe Réseau dans la classe finale Inventaire. La classe inventaire comprend une seule instance Quartz. On défini donc sur cette classe une variable moy_dev initialiséà la valeur obtenue V-AVG dans la classe Réseau.

Dans l'exemple illustré, les attributs résultats apparaissent dans une matrice Ml- On choisi de faire apparaître dans cette matrice l'identificateur de l'instance sur laquelle est lancée la requête multiple et la valeur obtenu moy_dev, c'est-à-dire la moyenne obtenue. Dans notre exemple, la seconde sous-requête SRI a la forme a Sur la classe Réseau (classe finale): Filtre: classe IP du réseau<B≥ B(5) nombre d'équipements> moy_dev (6) attributs résultats adresse IP du réseau, nombre d'équipements pour ce réseau, avgDev (7) a Sur la classe d'entrée Inventaire (classe d'entrée) variable: moy_dev <B≥ 100 (valeur arbitraire)(8) Le procédé de construction de cette deuxième sous-requête SRI est le même que précédemment. On effectue un double filtre. Un premier filtre sur les réseaux B et un deuxième filtre incluant un opérateur de comparaison l'expression(5) est un filtre sur les réseaux B. Concrètement, a l'expression(6) est un filtre sur l'attribut nombre d'équipement qui doit être supérieurà une moyenne.

Dans l'expression(7), on choisi les attributs que l'on souhaite afficher dans une matrice M2. Dans l'exemple illustré, les attributs adresse IP du réseau, nombre d'équipements pour ce réseau, avgDev apparaîtront dans cette matrice M2.

Dans l'expression(8), on défini une variable arbitraire. Comme cette variable est partagée avec la sous-requête SRO, son exécution diffère dans le cas de l'exécution de sous-requêtes conformémentà la première solution. Le choix de la valeur de cette moyenne dans la seconde sous-requête diffère selon que la moyenne est une variable partagée ou non. Conformément à la solution, si cette variable est partagée, la valeur de cette moyenne est la valeur calculée dans une sous-requête. Si cette variable n'est pas partagée entre deux sous-requêtes, la variable partagée est calculée normalement comme pour l'exécution d'une requête non multiple Pour cela, un autre aspect important de la solution est que si moy_dev est une variable partagée entre les deux sous-requêtes : Pour que SR1 ait une visibilité de cette variable partagée dans SRO, cette variable doit être définie sur la classe finale de SRO. Dans l'exemple illustré, la classe finale de SRO est la classe Inventaire. Etape 4: Les deux sous requêtes sont archivées dans une base de données. Etape 5 : Une autre étape consiste, lors de la validation des sous-requêtes, à établir un ordre temporel d'exécution des sous-requêtes età munir chaque sous-requête d'au moins un pointeur pour respecter l'ord-re d'exécution. Un pointeur peut être un attribut. Dans l'exemple illustré, la première sous-requête et la dernière inclut un seul pointeur. Eventuellement, si la requête multiple comprend au moins trois sous-requêtes, les sous-requêtes intermédiaires comprennent deux pointeurs. La fonction d'un pointeur est évoquée dans une des étapes suivantes. Dans l'exemple illustré, l'exécution de la sous-requête SRO précède l'exécution de la sous-requête SR1. Etape 6 : Une quatrième étape consisteà exécuter la requête. Cet exécution consisteà sélectionner et lancer la dernière sous-requête en ayant sélectionné l'instance de départ sur laquelle porte la requête multip!e. L'exécution d'une telle requête est possibleà la condition que les sous-requêtes admettent la même classe de départ, et donc sont lancées sur la même instance de départ. Dans l'exemple illustré, l'instance de départ est l'instance Quartz. Si les classes d'entrée diffèrent, on choisi la classe Racine comme classe d'entrée.

Etape 7 Lors de l'exécution de la dernière sous-requête SR1, le système détecte la présence d'une requête multiple. Un mécanisme de chaînage est exécuté par le système.

Le mécanisme de chaînage est logiciel et consiste - lors d'une première phaseà pointer successivement,à partir de la dernière sous-requête SR1 sélectionnée, vers la première sous-requête SRO, - et lors d'une seconde phaseà lancer séquentiellement les sous-requêtes de la première sous-requête SRO jusque la dernière sous requête SR1, une sous- requête étant activée seulement si l'exécution de la précédente sous-requête est terminée. Durant cette seconde phase, lors de l'évaluation de la variable partagée moy_dev sur la classe Inventaire pour l'instance réseau B, si il existe une valeur de moy_dev dans la première sous-requête SRO pour cette même instance, moy_dev-sera calculée dans SR1 avec cette valeurdéjà calculée. Dans le cas contraire, si la variable moy_dev n'est pas partagée et est calculée indépendamment de tout autre sous-requête selon des règles d'évaluation normale.

Lors des deux phases précitées, le passage d'une sous-requête à une autre est effectué par l'intermédiaire des pointeurs. Dans l'exemple de deux sous- requêtes (SRO, SR1), les deux sous-requêtes incluent un seul pointeur respectif (Rl,Pl). Lors de la première phase, le pointeur Pl pointe vers la première sous-requête SRO. Lors de la deuxième phase, le pointeur Rl pointe vers la deuxième sous-requête.

Etape 8 Une sixième étape consisteà afficher les résultats de préférence dans une matrice. Les colonnes représentent les attributs résultats sélectionnés et les lignes les instances qui vérifient la ou les sous-requêtes.

Par extension, une requête multiple RM peut être considérée comme la suite de n sous requêtes notées SRi, i variant de1 à n: RM <B≥ SRO + SR1 + SR1 + ...+ SRi + ... SRn L'exécution de RM consisteà lancer l'exécution de la dernière sous- requête SRn, plus précisément celle pour laquelle on désire obtenir les résultats. L'utilisateur lance donc de manière classique l'exécution de SRn en ayant sélectionné, au préalable, l'instance d'entrée sur laquelle porte la requête multiple RM.

Dans l'exemple illustré, les sous-requêtes SRO et SRn comprennent un pointeur respectif RO et Pn. Les sous requêtes intermédiaires SRj comprennent deux pointeurs Pi et Rj.

Le système détecte en SRn la présence d'une requête multiple RM.

On comprend que si la requête comprend n sous-requêtes, lors de la première phase, la sous-requête SRj inclut un pointeur Pj pour pointer vers la vers la sous-requête SRj-1 de position ü-1), et Le système lance ensuite l'exécution séquentielle des sous-requêtes SRi, en commencant par la première SRO, une sous-requête SRi étant activée si et seulement si l'exécution de la sous-requête SRi-1 de position (i-1) est terminée. Lors de cette seconde phase, la même sous-requête SRj inclut un autre pointeur Rj pour pointer vers la vers la sous-requête SRj+l de position #+1)- De façon générale, soit VPi une variable partagée entre SRi et SRj. Par exemple, la variable partagée VPi peut être un paramètre d'une fonction d'agrégation F dans la sous-requête SRj.

Pour que la sous-requête SRj ait une visibilité de la variable partagée VPi et puisse la prendre en compte lors de son exécution, cette variable partagée VPi doit donc être définie sur la classe finale de la sous-requête SRi.

Soit X cette classe finale.

Lors de l'exécution de SRj, l'évaluation de la variable VPi pour la sous-requête SRj sur la classe X pour une instance Xk de la classe X peut avoir deux valeurs: # s'il existe une valeur de VPi pour Xk dans la sous-requête SRi, la variable partagée VPi sera calculée avec cette valeur calculée, # dans le cas contraire, c'est-à-dire que l'instance Xk n'est pas une solution de la sous-requête SRi, la variable partagée VPi est calculée normalement comme pour l'exécution d'une requête non multiple. La solution donne la possibilité aux utilisateurs de concevoir des requêtes compliquées, beaucoup d'entre elles nécessitant une décomposition en sous-requêtes. Cette solution évite de recourirà une programmation du type SML-CMIS de leur applicatif qui est lourde, non trivial, et très coûteux en temps. Cette solution procure au système une gestion de sous-requêtes simple d'utilisation qui fournit un éventail considérable de possibilité d'interrogations non envisageables pour le concepteur de requêtes. D'autre part, cette solution permet de définir de manière naturelle un enchaînement de sous-requêtes. Ce concept fort doublé de la notion de partage de variables entre sous-requêtes apportent une autre dimension au pouvoir d'expression du langage, permettant ainsi des réponses simplesà des requêtes compliquées. Un deuxième gros problème est liéà la notion de comptabilité entre noms distinctifs de type FDN.

Revenonsà l'écriture d'une variable V<B≥ attl ... < op> F(att2) ... < op> W... < op> G(Z) où attl, att2 sont des attributs de la classe X, La classe X pouvant être indifféremment la classe Inventaire, la classe Réseau ou la classe Equipement, et attl, att2 pouvant être indifféremment des attributs de l'une des classes, W, Z sont des variables internes ou externesà la classe X, F,G sont des fonctions qui s'appliquent sur des variables, et < op> est un opérateur arithmétique quelconque.

L'évaluation des variables sur exécution d'une requête satisfaità des règles précises: En effet, la variable V est calculée pour chaque instance de la classe X (Règle1). Soient Vi la valeur calculée de la variable V pour l'instance Xi de la classe X, et Pi l'instance père de l'instance Xi. Entre autres, pour chaque valeur Vi calculée de l'instance Xi : # l'attribut attl est évalué avec la valeur d'attribut attl de l'instance Xi (Règle 2), # la fonction F(att2) est calculée avec (règle3) * la valeur de l'attribut att2 de l'instance Xi si F n'est pas une fonction d'agrégation * ou la liste des valeurs de l'attribut att2 des instances Xi subordonnées à Pi si F est une fonction d'agrégation.

a W sera évaluée avec (Règle 4) * la valeur Wi calculée si W est une variable interne, * ou la première valeur calculée de W pour une instance compatibleà l'instance Xi si W est une variable externe conformémentà la première solution.

F(W) sera évaluée avec (Règle5) * la liste des valeurs de W calculées pour l'ensemble des instances compatiblesà Xi si W est externe, * ou la valeur Wi calculée si W est interne.

A titre d'exemple, considérons sur la classe Equipement une variable dev-Name <B≥ nom de l'équipement . Considérons également, sur la classe Réseau, pour une instance de la classe Réseau, l'évaluation des variables suivantes: # fDev <B≥ dev-Name : cette variable dev-Name est une variable externe qui ne comprend pas de fonction d'agrégation. Selon la règle 4, pour une instance de Réseau, fDev prend la valeur de dev-Name calculée pour la première instance de la classe Equipement compatible ou attachéeà cette instance dans l'arbre.

# nbDEV <B≥ LENGTH (dev_Name) : cette variable dev-Name est une variable externe comprenant une fonction d'agrégation. Selon la règle 5, cette variable est évaluée avec la liste des dev-Name calculées pour les instances attachées (compatibles) au réseau courant. Comme la fonction LENGTH rend la longueur d'une liste, la variable nbDev sera donc le nombre d'équipements attachés au réseau.

# enfin, aliNetw <B≥ List (nom du réseau). Selon la règle3, l'attribut nom du réseau est évalué avec la liste des noms de réseau pour l'instance père du réseau courant (ici l'entrée Inventaire),à tous les réseaux.

Lors des règles d'évaluations de variables, la règle3 énonce que F(att2) est calculée avec la liste des valeurs de l'attribut att2 des instances Xi subordonnéesà Pi si F est une fonction d'agrégation.

Le gros problème est que si la requête comprend une fonction d'agrégation, le traitement de cette requête ne porte que sur un sous-ensemble d'instances compatibles d'une classe donnée. D'une manière générale, la règle de compatibilité intervient dès qu'une variable d'une requête fait référenceà une variable externe.Il en est de même pour les opérateurs et filtres spécifiant des variables dans leurs expressions.

De la même façon, pour une requête comprenant au moins un filtre avec au moins une variable ou au moins un opérateur (opérateur de jointure, opérateur de tests ensemblistes), la règle de compatibilité entre instances est utilisée automatiquement, ce qui pose problème.

De tels opérateurs et filtres reposent sur une notion de compatibilité de noms distinctifs FDN limitant le traitement d'une requêteà un sous-ensemble d'instances d'une classe donnée.

Or, une requête peut porter sur des instances quelconques d'une classe de l'arbre de contenance.

A cet effet, la seconde solution consisteà créer un opérateur supplémentaire NoComp permettant d'inhiber sur une classe donnée les règles de compatibilité sur instances afin de traiter une requête, non pas sur un sous- ensemble d'instances de la classe, mais sur l'ensemble des instances d'une classe. Afin d'illustrer ce second problème, une requête R3 concerné par le problème cité ci-dessus peut être du type: Pour chaque réseau, donner le pourcentage du nombre d'équipements enregistré dans l'arbre de contenance par rapport au nombre total d'équipements de type SNMP . La sémantique de la requête qui en résulte peut être du type - Sur la classe Equipement: variable: dev-Name <B≥ Nom de l'équipement filtres: SNMP <B≥ oui - et sur la classe Réseau (classe résultat) Variables nbDev <B≥ LENGTH (dev-Name) prctDev <B≥ Nombre d'équipementsinblDev. La fonction LENGTH est donnée en annexe1. Cette fonction d'agrégation est choisie comme exemple d'illustration du fait que son exécution repose sur les règles de compatibilité. Ce choix est arbitraire en ce sens qu'une autre fonction d'agrégation se reposant sur les mêmes règles aurait pu être choisieà titre d'exemple. PrctDEV calcul le pourcentage du nombre d'équipements enregistrés dans un réseau donné par rapport au nombre total de réseau.

L'écriture de cette requête pose deux problèmes: - les réseaux ne comprenant pas d'équipements SNMP sont éliminés, - et le nombre nbDev calcule, pour un réseau, le nombre d'équipements compatibles et non sur le nombre total d'équipements de type SNMP.

Selon la seconde solution, l'utilisateur construit la requête en faisant abstraction des règles de compatibilité, dans le calcul de variables, ou dans l'exécution de certains opérateurs.A cet effet, un opérateur NoComp de type logiciel est créé.

Considérons, par exemple, une classe X et VX une variable de cette classe X. Ce nouvel opérateur Nocomp a pour fonction, entre autres, - d'évaluer toute variable externe (c'est-à-dire une variable d'une autre classe que la classe X) référençant la variable VX de manière agrégée avec les valeurs de la variable VX calculées pour l'ensemble des instances lues sur la classe X, - d'évaluer une variable de la classe X référençant un attribut avec une fonction d'agrégation avec les valeurs de l'attribut de l'ensemble des instances lues de la classe X.

- et si un filtre est défini sur la classe X, la règle de compatibilité des instances des autres classes n'est pas appliquée et les instances des autres classes non compatibles avec les instances concernées de la classe X ne sont pas éliminées.

Dans notre exemple, la seconde solution peut consister en une série d'étapes étape1 : Premièrement, l'utilisateur analyse la requêteà traiter et détermine si la règle de compatibilité doit être inhibée en fonction de ce qui précède.

Si l'utilisation de la règle de compatibilité est justifiée, l'exécution de la requête R3 s'effectue normalement.

Si l'utilisation de la règle de compatibilité n'est pas justifiée, l'exécution de la requête R3 est différente. En effet, dans l'exemple illustré, le concepteur insère l'opérateur d'inhibition Nocomp dans la requête. Cet opérateur peut être appliqué sur n'importe quelle classe où sont définies des variables.

Dans l'exemple illustré, la requête a la forme suivante Sur la classe Equipement variable: dev-Name <B≥ Nom de l'équipement filtres: SNMPstate <B≥ SNMP-supporté opérateur: NoComp Sur la classe Réseau (classe résultat) Variables nbDev <B≥ LENGTH (dev-Name) prctDev <B≥ Nombre d'équipements/nbDev. Ainsi, avec la seconde solution, les réseaux n'ayant pas de réseaux de type SNMP ne sont pas éliminés. Au contraire, la variable nbDev calcule bien pour un réseau le nombre total d'équipement de type SNMP. Etape 2 Une deuxième étape consisteà lire toutes les instances concernées par la requête. On extrait,à partir des instances lues, la valeur de l'attribut objetde l'interrogation qui est inclus dans l'instance respective. Etape 3 Une troisième étape consisteà mémoriser, dans une mémoire quelconque du système, les valeurs des attributs des instances lues.

Etape 4- Une quatrième étape consisteà exécuter la requête en tenant compte des valeurs obtenuesà l'étape3. L'opérateur créé propreà la seconde solution donneà un utilisateur la possibilité d'inhiber les règles de compatibilité sur instances. Un requête ne se limite plusà un sous-ensemble d'instances d'une classe. Au contraire, l'utilisateur peut désormais considérer dans une seule requête l'ensemble des instances d'une classe. L'opérateur peut désormais appliquer un opérateur de jointure ou un test ensembliste sur des instances non compatibles de l'arbre de contenance par l'intermédiaire d'une unique requête. L'utilisateur n'est pas contraint de dupliquer les variables, cette duplication étant lourdeà mettre en #uvre et surchargeant l'écriture de la requête. Un troisième gros problème, évoqué dans l'introduction, est liéà la présence d'une même classeà des niveaux différents dans l'arbre de classes. En effet, le modèle GDMO permetà une même classe d'objet d'être subordonnéeà plusieurs classes différentes dans l'arbre de classes A titre d'illustration, cet arbre comprend trois types de classe. La classe racine est, par exemple, la classe Inventaire. Deux classes Note et Réseau de cet arbre sont subordonnéesà la classe Inventaire. Enfin, la même classe Note est subordonnéeà la classe Réseau. On s'aperçoit donc que cet arbre de classes comprend une même classe Note qui se situeà des niveaux différents de l'arbre. Un autre arbre de contenance comprenant des instances de l'arbre de classes. Une instance Quartz est une instance de la classe Inventaire. Trois instances Notel, Note2 et Note3 de la classe Note sont subordonnéesà l'instance Quartz. Une instance K de la classe Réseau est subordonnéeà l'instance Quartz. Enfin, deux instances Notelet Note4 sont subordonnéesà l'instance K. On constate également qu'une même instance d'une même classe peut se situerà deux niveaux différents de l'arbre de contenance.

Le problème réside ici dans le traitement de la différence, ou de l'intersection ou de l'union dans une même requête sur des instances d'une même classe situéesà différents niveaux de l'arbre.

A titre d'exemples, considérons une première requête R4à traiter donner la liste des instances de la classeNOTE attachéesà l'instance Quartz de la classe Inventaire .

On constate que le résultat réel correspondà l'ensemble des instances de la classe Note subordonnéeà la classe Inventaire, mais également l'ensemble des instances de la classe Note directement ou indirectement attachées par l'intermédiaire d'une ou plusieurs instances d'autres classes distinctes de la classe Note dans l'arbre. En l'espèce, les instances subordonnéesà l'instance K de la classe Réseau sont une solution.

Un autre exemple de requête R5 peut être du type: Donner, pour une instance Quartz de la classe d'Inventaire, la liste des instances de la classe Note attachées, mais n'apparaissant dans aucune autre classe Note indirectement subordonnée. .

Le résultat de cette requête comprend l'ensemble des instances de la classe Note attachéesà l'instance Quartz, en retirant les instances qui apparaissent sous les classes indirectement attachéesà la classe Réseau.

Un dernier exemple de requête R6 peut être du type: Donner pour l'instance Quartz, la liste des instances de la classe Note directement attachéesà cette instance Quartz et apparaissant dans chacune des autres classes Note indirectement subordonnées. Le résultat de cette requête est l'ensemble des instances de la classe Note attachéesà l'instance Quartz de la classe Inventaire et qui apparaissent également sous les classes indirectement attachéesà l'instance Quartz. A cet effet, la troisième solution consisteà fournir trois nouveaux opérateurs: # un opérateur d'union propreà unifier des instances d'une même classe situéesà différents niveaux de l'arbre de classe, # un opérateur de différence propreà effectuer une soustraction entre instances d'une même classe situéesà différents niveaux de l'arbre de classe, # un opérateur d'intersection propreà réaliser une intersection entre instances d'une même classe situéesà différents niveaux de l'arbre de classe.

La troisième solution consiste doncà disposer d'opérateurs permettant l'union, la différence, et l'intersection de classes situéesà un niveau quelconque dans un environnement objets hiérarchique.

Selon un exemple de réalisation, la troisième solution peut consister en une autre série d'étapes.- Cet exemple de réalisation fait appel au mécanisme de variable et donc aux règles d'évaluation de variables et donc aux règles de compatibilité sur instances, Etape 1 : Une première étape consisteà introduire ces trois opérateurs dans la liste des opérateurs existants (voir annexe1).

Etape 2: Une interface graphique visible sur un écran d'ordinateur visualise l'arbre des classes. Une classe de cet arbre apparaît par exemple sous la forme d'icône. Les icônes sont, par exemple, reliés par des branches. L'utilisateur peut donc manipuler les noeuds de l'arbre par l'intermédiaire d'une souris.

Etape 3 : - La troisième étape consisteà sélectionner les classes situéesà des niveaux différents de l'arbre de contenance et sujettesà l'union, la différence ou l'intersection. On appellera classe source la classe d'où part l'opération (classe finale). De même, on appellera classe cible la classe pointée par une opération.

De préférence, dans l'arbre de classes, la sélection d'une classe est réalisée en cliquant sur un bouton de la souris, cette sélection entraînant la surbrillance de l'icône associé dans l'arbre.

Etape 4 Une quatrième étape consisteà afficher sur la classe finale, un menuMEN présentant les différents opérateurs présents dans le système. Ce menu inclut les opérateurs objets de la troisième solution. Cette étape consisteà sélectionner un opérateur dans le menu qui peut être l'Union, la Différence ou l'Intersection sur la classe finale. Sur sélection de l'un des opérateurs booléens objets de la troisième solution, les icônes sélectionnés et coïncidant avec la classe finale sont mémorisés pour l'opération (une fenêtre de type filtre apparaîtà l'écran). Etape 6 Une sixième étape consisteà appliquer l'opérateur età afficher les résultats. Un opérateur conformeà l'invention effectue une opération entre noeuds de même classe de l'arbre de classes, plus précisément entre la classe source et au moins une classe cible. Soit X la classe finale sur laquelle s'applique les requête R4, R5, et R6.

Le résultat diffère selon le choix de l'opérateur: A) Le fonctionnement de l'opérateur Union est défini par les définitions suivantes: # a- L'opérateur Union ne peut s'appliquer que sur la classe finale X de la requête, # b- les classes cibles de l'union doivent appartenirà la même classe que la classe source, # c- le résultat de l'opération est l'union des instances qui sont résultats de la classe X et des instances des classes compatibles avec les instances de la classe source (classe finale X), # d- et il n'y a pas de contrôle de duplication d'instances pour le résultat. B) Le fonctionnement de l'opérateur Différence est défini par les définitions suivantes # a- L'opérateur Différence ne peut s'appliquer que sur la classe finale X de la requête, # b- les classes cibles de cet opérateur doivent appartenirà la même classe que la classe source, # c- le résultat de l'opération est la différence de noms DN entre les instances qui sont résultats de la classe finale et entre les instances compatibles des classes cibles. C) Le fonctionnement de l'opérateur Intersection est défini par les définitions suivantes: # a- Cet opérateur ne peut s'appliquer que sur la classe finale X de la requête, # b- les classes cibles de cet opérateur doivent appartenirà la même classe que la classe source, # c- le résultat de l'opération est l'intersection de noms DN entre les instances qui sont résultats de la classe finale et entre les instances compatibles des classes cibles.

NotelD est un attribut de nommage DN défini précédemment. Dans l'exemple illustré, Le termeID est une valeur numérique. Concrètement, dans l'exemple illustré, la requête R4 peut être construite conformémentà cette suite d'étapes.

Premièrement, on Sélectionne avec la souris des classes ciblesNOTE dans l'arbre de classes.

Deuxièmement, on sélectionne l'opérateur Union qui correspondà la requête R4 sur la classe Note subordonnéeà la classe Inventaire. Troisièmement, on obtient le résultat de la requête R4. Le résultat est les instances Notel, Note2 et Note3 subordonnéesà Vintance Quartz et les instances Note1 et Note4 subordonnéesà l'instance K.

Dans ce résultat, conformément aux fonctionnement de l'opérateur Union, deux instances du résultat ont le même nom DN (Notel) avec des noms FDN différents. En effet, le nom DN pour les instances résultats est Notel et les noms FDN respectifs pour les instances résultats sont FDN <B≥ quartz / NotelD <B≥ Notel FDN <B≥ quartz / K/ NotelD <B≥ Notel Compte tenu de ces définitions, dans l'exemple illustré, la requête R5 peut être construite.

Deuxièmement, on sélectionne l'opérateur Différence qui correspondà la requête R4 sur la classe Note subordonnéeà la classe Inventaire. Troisièmement, on obtient le résultat de la requête R5. Le résultat est les instances Note2 et Note3 subordonnéesà l'instance Quartz et l'instance Note4 subordonnéesà l'instance K.

Le résultat de cette requête R5 montre que l'instance Notel n'est pas incluse dans le résultat car le nom DN des deux instances Notel dans l'arbre est le même.

Compte tenu des définitions, dans l'exemple illustré, la requête R6 peut être construite. Premièrement, on Sélectionne avec la souris des classes ciblesNOTE dans l'arbre de classes.

Deuxièmement, on sélectionne l'opérateur Intersection qui correspondà la requête R6 sur la classe Note subordonnéeà la classe Inventaire. Troisièmement, on obtient le résultat de la requête R6. Le résultat est l'instance Notel. En effet, l'instance Notel subordonnéeà l'instance Quartz est la seule instance de la classe Note (classe finale) pour laquelle son nom DN figure dans les instances des autres classes Note indirectement subordonnées à l'instance Quartz. D'une manière générale, la deuxième solution a pour objet un procédé d'interrogation, dans un système informatique, par l'intermédiaire d'au moins une requête d'au moins un objet inclus dans au moins un arbre de contenance inclus dans au moins une machine se reposant sur le protocole de gestion de type CMIP, une requête consistant en une miseà jour ou en une consultation des objets de l'arbre de contenance, une requête incluant un contexte comprenant l'ensemble des paramètres (classes, attributs, opérateurs, variables, etc.) décrivant tous les éléments d'une requête, au moins un paramètre se reposant sur la règle de compatibilité entre instances limitant le traitement de la requêteà un sous-ensemble d'instances d'une classe, caractérisé en ce qu'il consiste,à créer un opérateur propreà inhiber, sur une classe donnée, les règles de compatibilité sur instances de façonà traiter la requête sur l'ensemble des instances de la classe sur lesquelles porte la requête. La deuxième solution consiste, une fois les règles de compatibilité inhibées,à lire les attributs des instances sur lesquelles portent la requête, et en ce qu'il consisteà mémoriser ces valeurs dans une mémoire quelconquedu système informatique.

Le procédé de la deuxième solution consiste, par exemple, au moment de l'exécution de la requêteà prendre en compte ce nouvel opérateur et lors de l'exécutionà traiter la requête avec les valeurs des attributs des instances lues au préalable sans utiliser les règles de compatibilité. L'exemple de réalisation qui précède montre que l'opérateur évalue toute variable externe référençant une variable VX d'une classe X de manière agrégée avec les valeurs de la variable VX calculées pour l'ensemble des instances lues sur la classe X. De même, l'opérateur évalue une variable de la classe X référençant un attribut avec une fonction d'agrégation avec les valeurs de l'attribut de l'ensemble des instances lues de la classe X. On a vu, par ailleurs, dans notre exemple d'illustration que si un filtre est défini sur la classe X, la règle de compatibilité des instances des autres classes par rapportà la classe X n'est pas appliquée et les instances des autres classes non compatibles avec les instances concernées de la classe X ne sont pasà éliminer. Enfin, on a vu que le procédé de la deuxième solution consisteà appliquer l'opérateurà une classe où sont définies des variables.

Cette troisième solution offre un avantage certain en ce sens qu'elle donne la possibilité d'effectuer des unions, des différences et des intersections entre classes dans un environnement objet hiérarchiqueà l'image des clauses d'union et de différences du langage SQL.

Claims

REVENDICATIONS 1- Procédé d'interrogation, dans un système informatique, par l'intermédiaire d'au moins une requête d'au moins un objet inclus dans au moins un arbre de contenance inclus dans au moins un système de gestion se reposant sur le protocole de gestion de type CMIP, ledit système de gestion étant connectéà au moins une machine par l'intermédiaire d'un réseau, une machine comprenant au moins une ressource physique et/ou logique, un objet de l'arbre constituant la représentation d'une ressource, une requête consistant en une miseà jour ou en une consultation des objets de l'arbre de contenance via le réseau et incluant un contexte comprenant un ensemble de paramètre (classes, attributs, opérateurs, variables, etc.) décrivant tous les éléments d'une requête, au moins un paramètre se reposant sur la règle de compatibilité entre instances limitant le traitement de la requêteà un sous-ensemble d'instances d'une classe, caractérisé en ce qu'il consisteà créer un opérateur propreà inhiber, sur une classe donnée, les règles de compatibilité sur instances de façonà traiter, lors d'une miseà jour ou d'une consultation, la requête sur l'ensemble des instances de la classe sur lesquelles porte la requête. 2- Procédé d'interrogation selon la revendication1, caractérisé en ce qu'il consiste, une fois les règles de compatibilité inhibées,à lire les attributs des instances sur lesquelles portent la requête, et en ce qu'il consisteà mémoriser ces valeurs dans une mémoire quelconque du système informatique. 3- Procédé d'interrogation selon l'une des revendication1 ou 2, caractérisée en ce qu'il consiste au moment de l'exécution de la requêteà prendre en compte ce nouvel opérateur et lors de l'exécutionà traiter la requête avec les valeurs des attributs des instances lues au préalable sans utiliser les règles de compatibilité. 4- Procédé d'interrogation selon r'une des revendications1 à 3, caractérisé en ce que l'opérateur évalue toute variable externe référençant une variable VX d'une classe X de manière agrégée avec les valeurs de la variable VX calculées pour l'ensemble des instances lues sur la classe X. 5- Procédé selon l'une des revendications1 à 3, caractérisé en ce que l'opérateur évalue une variable de la classe X référençant un attribut avec une fonction d'agrégation avec les valeurs de l'attribut de l'ensemble des instances lues de la classe X. 6- Procédé d'interrogation selon l'une des revendications1 à 3, caractérisé en ce que, si un filtre est défini sur la classe X, la règle de compatibilité des instances des autres classes par rapportà la classe X n'est pas appliquée et les instances des autres classes non compatibles avec les instances concernées de la classe X ne sont pasà éliminer. 7- Procédé d'interrogation selon l'une des revendications1 à 3, caractérisé en ce qu'il consisteà appliquer l'opérateurà une classe où sont définies des variables.