FR2805908A1 - Procede de manipulation d'objets inclus dans un arbre de contenance et systeme associe - Google Patents

Abstract

La présente invention concerne un procédé de manipulation d'objets inclus dans un arbre de contenance, les objets étant interrogeables par l'intermédiaire d'au moins une requête à affectation non statique caractérisé en ce qu'il comporte- une étape de définition pour une fonction EXECOND ou EXECONDVAL d'une variable test varTest ou d'un domaine test DomaineList pour effectuer un test défini par une opération varOper sur une instance (Xi) d'un objet de l'arbre de contenance et au moins une variable résultat (varElse, varDefaut),- une étape d'exécution d'au moins un test, et - une étape de délivrance d'un résultat conditionnel défini en fonction du résultat du test et exprimé par, soit la valeur de la variable résultat (varElse, varDefaut) si la condition définie par le test n'est jamais réalisée, soit par une autre valeur.

Description

<Desc/Clms Page number 1>

PROCEDE DE MANIPULATION D'OBJETS INCLUS DANS UN ARBRE DE
CONTENANCE ET SYSTEME ASSOCIE
La présente invention a pour objet, dans un système informatique, un procédé de manipulation d'objets inclus dans un arbre de contenance et le système associé.

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 est une entité réactive qui attend et 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 Management Protocol), le protocole CMIP (Common Management 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

<Desc/Clms Page number 2>

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) 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 de gestion utilise des services CMIS (Common Management Information Services) normalisés, connus de l'homme du métier. Ce système de gestion est une entité qui analyse et agit sur l'environnement à gérer, il répond aux requêtes des utilisateurs en les envoyant à la machine gérée. 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 qu'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. Le modèle de données implémenté est de type "objet", où l'on retrouve les principales caractéristiques propres à ce modèle à savoir : classes, objets, héritage, encapsulation, méthodes (ici actions) évènements, L'organisation des classes est ici hiérarchique, et on distingue : - l'arbre des classes, où une classe est définie subordonnée à une ou plusieurs classes pères, et - l'arbre des instances, où une instance est attachée à une ou plusieurs instances pères.

Cette représentation virtuelle est concrétisée par l'intermédiaire d'un arbre de contenance et d'un arbre de classe. Dans la figure 2, par exemple, les classes INVENTAIRE et RESEAU sont subordonnées à la classe RACINE; les instances DEV5 et DEV6sont subordonnées à l'instance NET2.

Un arbre de contenance est un arbre constitué d'instances de classes. Par définition, l'arbre de contenance est strictement hiérarchique. Le service CMIS (Common Management Information Services) est bien adapté à la structure hiérarchique de l'arbre de contenance. Cet arbre comprend en ses noeuds l'ensemble des objets gérés par le système de gestion. Par définition, un objet géré que l'on peut aussi appeler instance d'une classe 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 définies par cette classe. Un attribut est une caractéristique d'un objet géré qui a un type nommé et

<Desc/Clms Page number 3>

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éneur 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é et supérieur 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ée 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.

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.

Le protocole de communication entre un manager et une machine managée est CMIP (Common Management Information Protocol). Le service CMIS (Common Management Information Services) est bien adapté à la structure hiérarchique de la MIB, et propose un ensemble de services de base comme m-get (pour lire une instance), m~set (pour mettre à jour une instance)' m~delete (pour l'effacer), m~create (pour la céer). Ces services reposent sur la notion de filtrage (possibilité de filtrer les instances lues), et de scope ( préciser le degré de profondeur dans l'arbre des classes).

L'application Cmis Query Builder (CQB, Fig.1) située au niveau du manager ISM constitue un système d'interrogation graphique pour bases de données objets, ici dans un environnement CMIS. La base interrogée est la MIB accédée sur la

<Desc/Clms Page number 4>

machine managée. Elle permet visuellement de construire une requête de consultation ou de mise à jour de la MIB, de l'exécuter, et de l'archiver dans une base objet. Les cinq étapes de construction d'une requête sont, d'une manière très résumée.

- Représentation graphique de l'arbre des classes dans une fenêtre de dessin, un n#ud dans l'arbre représentant une classe managée.

- Définition d'opérateurs sur les classes intervenant dans la requête. Ces opérateurs sont pour la plupart inspirés de l'algèbre relationnelle, 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. Une interprétation sémantique de la MIB (vue) est donc possible, l'ensemble offrant au langage visuel un fort pouvoir d'expression. On retrouve les opérations fondamentales du relationnel comme le filtrage, la jointure, les tests ensemblistes Is-in (est-dans), Exists (existe), Contains (contient),..etc, les opérations d'unions, d'intersections entre classes, le tri, le groupement (GROUP BY), l'opérateur Unique. Des fonctions d'agrégation sur variables ou attributs comme SUM, MIN, MAX, COUNT, AVG, LENGTH, LIST..etc, sont également disponibles.

- Sélection de la classe de sortie, ou classe finale (classe sur laquelle on sélectionne les attributs et variables résultats).

- Exécution de la requête : celle-ci possède une classe de départ, souvent la classe racine de l'arbre des classes. L'exécution de la requête porte donc sur une ou plusieurs instances de base dont la classe doit correspondre avec la classe de départ de la requête.

- Visualisation des résultats : les résultats sont affichés par une matrice, les colonnes étant les attributs résultats sélectionnés, et les lignes des instances vérifient la requête.

Une requête de sauvegarde peut également être exécutée en mode programme, via une Interface de Programmation.

Le problème technique posé est le suivant : les règles d'évaluation des variables reposent toutes sur la forme d'une affectation statique de la forme Var : = <expression arithmétique>
L'évaluation de l'expression arithmétique pour une instance est figée, et n'est jamais soumise à des conditions. Ceci a comme conséquence de ne pouvoir répondre à certains cas de requêtes, comme celles nécessitant un calcul de variables avec une évaluation conditionnée par un test.

Un premier but de l'invention est de proposer un procédé permettant dans une MIB, un calcul de variables avec une évaluation conditionnée par un test.

<Desc/Clms Page number 5>

Ce but est atteint par le fait que le procédé de manipulation d'objets, inclus dans un arbre de contenance, les objets étant interrogeables par l'intermédiaire d'au moins une requête à affectation non statique est caractérisé en ce qu'il comporte : - une étape de définition pour une fonction EXECOND ou EXECONDVAL d'une variable test varTest ou d'un domaine test DomaineList pour effectuer un test défini par une opération varOper sur une instance (Xi) d'un objet de l'arbre de contenance et au moins une variable résultat (varElse, varDefaut), - une étape d'exécution d'au moins un test, et - une étape de délivrance d'un résultat conditionnel défini en fonction du résultat du test et exprimé par, soit la valeur de la variable résultat (varElse, varDefaut) si la condition définie par le test n'est jamais réalisée, soit par une autre valeur
Selon une autre particularité le procédé comporte une étape de définition pour le domaine test d'une liste de domaines DomaineList associée à une liste de valeurs de résultat à affectation conditionnelle valeurList et est caractérisé en ce que l'étape de test consiste: - à comparer avec l'opérateur varOper défini dans les paramètres de la fonction "EXECONDVAL" la valeur de la variable représentant l'instance Xi à chaque élément de la liste de domaine DomaineList, -à incrémenter un compteur de rang pour chaque élément comparé, -à retenir le rang i du dernier élément de la liste de domaine vérifiant la comparaison, l'étape de délivrance de résultat consistant à fournir pour autre valeur, la valeur de la liste de valeurs valeurList ayant le rang i retenu.

Selon une autre particularité, le procédé comporte une étape de délivrance de résultat pour une fonction EXECOND consistant à fournir pour autre valeur, la valeur définie par une variable, attribut ou constante varThen.

Selon une autre particularité du procédé, l'affectation sur test multivalué peut être une constante.

Selon une autre particularité du procédé, l'affectation sur test multivalué peut être une valeur calculée.

Selon une autre particularité du procédé la liste de valeur de résultat à affectation conditionnelle valeurList associée à la liste de domaine domaineList est définie par un second jeu de variables ou attributs (nbGateway, nbPc, nbNoSnmp) obtenus par l'application de fonctions de premier ou second type à un troisième jeu de variables

<Desc/Clms Page number 6>

Selon une autre particularité du procédé, la variable varTest ou les variables ou attributs de la liste valeurList sont elles-mêmes le résultat de l'application de fonctions classiques (EQU, SUM) à un troisième jeu de variables ou attributs (pcNum, gtw, noSnmpNb).

Selon une autre particularité du procédé, le résultat fourni par une fonction EXECOND ou EXECONDVAL est utilisé comme variable pour l'évaluation par une des 70 fonctions disponibles.

Selon une autre particularité du procédé, les résultats sont affichés par une matrice dont les colonnes sont les attributs résultats sélectionnés, et les lignes les instances qui vérifient la requête.

Un second but de l'invention est de proposer un système permettant de pallier les inconvénients de l'art antérieur.

Ce but est atteint par le fait que le Système SYS de manipulation d'objets comportant au moins un système gestionnaire SG et au moins une machine distante M1 associée à un protocole de gestion et comprenant des objets manipulables, un agent intégrateur AI pour convertir le protocole de gestion du système de gestion SG en un protocole de gestion correspondant à celui de la machine M1 et un agent AG de manipulation d'objets, d'une base de données objet organisée selon un arbre de contenance, ies objets étant classés selon une hiérarchie définie par un arbre de classes et étant interrogeables par l'intermédiaire d'une application CQB permettant la construction visuelle sur un dispositif d'affichage du système SYS d'au moins une requête à affectation non statique, est caractérisé en ce que l'application CQB comporte : - un programme d'exécution d'un premier type EXECOND ou d'un second type EXECONDVAL de fonction, sur une variable test varTest ou sur un domaine test DomaineList mémorisé dans des moyens de mémorisation pour effectuer, par des moyens de test, un test défini par une opération varOper sur chaque instance (Xi) d'un objet de l'arbre de contenance appartenant à une classe et des moyens pour produire au moins une variable résultat (varElse, varDefaut), - des moyens de délivrance d'au moins un résultat conditionnel défini en fonction du résultat du test et exprimé soit par la valeur de la variable résultat par défaut (varElse, varDefaut) si la condition définie par le test n'est jamais réalisée soit par une autre valeur.

<Desc/Clms Page number 7>

Selon une autre particularité, l'application CQB comporte : - des moyens de mémorisation d'une liste de valeurs de résultat à affectation conditionnelle valeurList mémorisée associée à la liste de domaine DomaineList - des moyens de test pour effectuer un test défini par une opération varOper consistant en des moyens de comparer avec l'opérateur varOper défini dans les paramètres de la fonction EXECONDVAL la valeur de la variable représentant l'instance Xi à chaque élément de la liste de domaine DomaineList, - des moyens d'incrémenter un compteur de rang pour chaque élément comparé, - des moyens de mémorisation du rang i du dernier élément de la liste de domaine vérifiant la comparaison définie par l'opérateur varOper, - des moyens de délivrance du résultat constitué par l'autre valeur, comportent des moyens de recherche dans la liste de valeurs de résultat à affectation conditionnelle valeurList, la valeur ayant dans la liste le rangi mémorisé.

Selon une autre particularité, la liste de valeur de résultat à affectation conditionnelle valeurList associée à la liste de domaine domaineList est définie par un second jeu de variables ou attributs (nbGateway, nbPc, nbNoSnmp) obtenues par l'application d'une fonction du premier ou second type à un troisième jeu de variables.

Selon une autre particularité, la variable varTest ou le jeu de variables ou attributs (nbGateway, nbPc, nbNoSnmp) de la liste ValeurList sont le résultat de l'application de fonctions classiques (EQU, SUM) à un troisième jeu de variables ou attributs (pcNum, gtw, noSnmpNb).

Selon une autre particularité, le résultat fourni par une fonction de premier type EXECOND ou de second type EXECONDVAL est utilisé comme variable pour l'évaluation par une des 70 autres fonctions disponibles par le programme de construction de requêtes (QUERY BUILDER).

Selon une autre particularité, les résultats sont affichés par une matrice, dont les colonnes sont les attributs résultats sélectionnés, et les lignes les instances qui vérifient la requête.

D'autres particularités et avantages de l'invention apparaîtront plus clairement à la lecture de la description ci-après faite en référence aux dessins annexés dans lesquels : - la figure 1 est une vue synoptique de l'architecture d'un système informatique sur lequel peut s'appliquer l'invention;

<Desc/Clms Page number 8>

- la figure 2 est une vue schématique d'un arbre de classe et d'un arbre de contenance ; - la figure 3 représente l'affichage de la liste des fonctions sur variables, réalisé sur les moyens d'affichage du système SYS ; - la figure 4 représente la fenêtre de saisie de la ou des vanables qui s'appliquent à cette fonction ; - la figure 5 représente la fenêtre d'attributs ou des variables constituant le résultat ; - la figure 6 représente la fenêtre d'affichage de la matnce résultat.

Sur la figure 1, on a représenté un système informatique SYS distribué de type hétérogène. Dans l'exemple illustré, ce système SYS inclut au moins un système gestionnaire SG et au moins une machine distante M1 associée à un protocole de gestion. La machine M1 comprend des objets manipulables. Une manipulation inclut les commandes connues de l'homme du métier évoquées ci-dessus. Le protocole de gestion de la machine M1 peut-être indifféremment un protocole de type SNMP, CMIS/CMIP ou DSAC/AEP. Dans notre exemple, le système SG supporte un protocole de type CMIS conforme au modèle OSI (Common Management 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 SG. Un utilisateur peut être un administrateur.

Afin de masquer l'hétérogénéité du système informatique, dans l'exemple illustré, un agent intégrateur AI est associé au protocole de gestion de la machine M1.

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 AI convertit le protocole de gestion du système de gestion SG en un protocole de gestion correspondant à celui de la machine M1. Réciproquement, l'agent intégrateur AI convertit le protocole de gestion associé à la machine M1 en un protocole de gestion associé au système de gestion SG. 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 SG et une machine qui supportent des protocoles de gestion différents.

Naturellement, le serveur de gestion SG peut comprendre plusieurs agents intégrateurs. L'agent intégrateur AI est relié à la machine M1 par l'intermédiaire d'un réseau RES1 de type quelconque. Le réseau RES1 peut être de type LAN (Local Area Network) ou WAN (Wide Area Network). Un ensemble de couches logicielles s'interpose entre le système de gestion SG et le réseau RES et entre le réseau et la

<Desc/Clms Page number 9>

machine M1. Cet ensemble de couches logicielles repose sur le modèle OSI (Open System Interconnection) d'architecture en couche de l'ISO (International Organization for Standardization), connu de l'homme du métier. Pour des raisons de simplification de la description, cet ensemble de couches logicielles n'est pas représenté sur la figure 1.

Dans l'exemple illustré, une requête issue du système de gestion est transmise à un agent AG. 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 SG comprend aussi, associé à l'agent AG, un arbre de contenance MIB mémorisé sur des moyens de grande capacité de mémorisation permanente. Une vue de cet arbre de contenance MIB est représentée sur la figure 2.

L'arbre de contenance peut être entièrement compris dans l'agent AG.

Pour simplifier la description, on a choisi de séparer, sur la figure 1, l'arbre de contenance MIB et l'agent AG. Cet arbre MIB assure une représentation virtuelle du monde réel qui entoure le système de gestion SG. 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 la machine M1.

Par définition, l'arbre de contenance MIB 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 SG. De manière générale et connue de l'homme du métier, pour créer un objet dans cette base MIB, 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 comprend 3 classes, - une classe INVENTAIRE, - une classe RESEAU (Network) qui représente les réseaux découverts qui sont définis chacun par les attributs : - networkld: adresse IP du réseau, - networkState: état du réseau (bloqué ou libre),

<Desc/Clms Page number 10>

- ipDeviceNumber: nombre d'équipements pour le réseau, - ipClass: classe IP du réseau (A, ou B, ou C,...), - NetSource : adresseIP de l'équipement ayant permis la découverte du réseau, - etc.

- une classe EQUIPEMENT (IpDevice) qui représente les réseaux découverts. Cette classe comprend les attributs : - ipPrimaryAdress : adresseIP de l'équipement, - ipType: type de l'équipement (passerelle(gateway), pare-feu (firewall), concentrateur, etc. ), - snmpSupported: type d'équipement SNMP : oui/non - classe IP du réseau ( IPA, ou IPB, ou IPC, etc. ), - deviceName: nom de l'équipement, - devSource: adresse IP de l'équipement ayant permis la découverte de l'équipement, - etc.

La valorisation de ces attributs conduit à l'arbre de contenance de la figure 2. Cet arbre de contenance comprend la racine RACINE, trois n#uds représentant les objets 11, Quartz, et 12 constituant des instances de la classe INVENTAIRE et qui sont des n#uds subordonnés à la racine, trois n#uds NET1, NET2 et NET3 constituant des instances de la classe Réseau qui sont des n#uds subordonnés au n#ud Quartz.

Enfin, dans cet arbre, chaque n#ud NET1, NET2 et NET3 a des n#uds représentant des objets équipements (DEVICES) subordonnés respectifs (DEV1, DEV2, DEV3, DEV4), (DEV5, DEV6), (DEV7, DEV8, DEV9) qui sont des instances de la classe EQUIPEMENT.

L'invention consiste en une amélioration de l'application Cmis Query Builder (CQB) située au niveau du manager ISM qui constitue un système d'interrogation graphique pour bases de données objets, ici dans un environnement CMIS. La base interrogée est la MIB accédée sur la machine managée M1. Elle permet visuellement de construire une requête de consultation ou de mise à jour de la MIB, de l'exécuter, et de l'archiver dans une base objet. Les étapes de construction d'une requête sont, d'une manière très résumée: - Représentation graphique de l'arbre des classes dans une fenêtre de dessin, un noeud dans l'arbre représentant une classe managée - Définition d'opérateurs sur les classes intervenant dans la requête. Ceux ci sont pour la plupart inspirés de l'algèbre relationnelle, complétés par le concept de variables permettant d'effectuer des calculs sur les données et de mettre en relation

<Desc/Clms Page number 11>

les classes entre elles. Une interprétation sémantique de la MIB (vue) est donc possible, l'ensemble offrant au langage visuel un fort pouvoir d'expression. On retrouve les opérations fondamentales du relationnel comme le filtrage, la jointure, les tests ensemblistes (Is-in, Exists, Contains,..), les opérations d'unions, d'intersections entre classes, le tri, le groupement (GROUP BY), l'opérateur Unique,.... Des fonctions d'agrégation sur variables ou attributs comme SUM, MIN, MAX, COUNT, AVG, . sont également disponibles. L'invention consiste à ajouter dans cette application CQB le programme permettant le traitement de requêtes faisant intervenir des fonctions d'un premier type "EXECOND" et d'un second type "EXECONDVAL" - Sélection de la classe de sortie, ou classe finale : (classe sur laquelle on sélectionne les attributs et variables résultats) - Exécution de la requête: Celle-ci possède une classe de départ, souvent la classe racine de l'arbre des classes. L'exécution dela requête porte donc sur une ou plusieurs instances de base dont la classe doit correspondre avec la classe de départ de la requête.

- Visualisation des résultats : Lesrésultats sont affichés par une matrice, dont les colonnes sont les attributs résultats sélectionnés, et les lignes les instances qui vérifient la requête.

Une requête sauvegarde peut également être exécutée en mode programme, via une Programmatic Interface.

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éfinit 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éfinie sur d'autres classes que la classe X.

Une variable V peut avoir la forme suivante :

<Desc/Clms Page number 12>

V = att1...<op> F(att2)...<op> W...<op> G (Z) où att1, 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éen AND, 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.

Revenons à l'écriture d'une variable :
V = att1...<op> F(att2)...<op> W...<op> G (Z) où att1, att2 sont des attributs de la classe X, la classe X pouvant être indifféremment la classe INVENTAIRE, la classe RESEAU ou la classe EQUIPEMENT, et att1, 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, 70 fonctions sont disponibles incluant les agrégats SCIL (MIN, MAX, SUM, AVG,...), des fonctions sur Listes (List, Ulist, ..), des fonctions booléennes (AND, OR, NOT, ..), des comparateurs ensemblistes ( ÉQUAL, ALL~GREATHER, IS~IN, IS-NOT~IN, ,..), .. 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 suivantes.

La variable V est calculée pour chaque instance de la classe X (Règle 1).

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 att1 est évalué avec la valeur d'attribut att1 de l'instance Xi (Règle 2), - la fonction F (att2) calculée avec (règle 3)

<Desc/Clms Page number 13>

- 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.

- 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.

- G(Z) sera évaluée avec (Règle 5) - la liste des valeurs de Z calculées pour l'ensemble des instances compatibles à Xi si Z est externe, - ou la valeur Zi calculée si Z est interne.

A titre d'exemple, considérons sur la classe EQUIPEMENT (ipDevice) une variable dev~Name définie par le nom de l'équipement : dev~Name =deviceName .

Considérons également, sur la classe RESEAU (ipNetwork) , pour une instance de la classe RESEAU, l'évaluation des variables suivantes : fDev = 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 RESEAU, 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 = LENGTH (dev~Name) . La fonction LENGTH étant une fonction d'agrégation, 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, allNetw = List (networkName). Selon la règle 3, l'attribut nom du réseau (networkName) est évalué avec la liste des noms de réseau pour l'instance père du réseau courant (ici l'entrée INVENTAIRE, à savoir tous les réseaux).

<Desc/Clms Page number 14>

Lors des règles d'évaluations de variables, la règle 3 é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.

La liste des fonctions sur variables ou attributs est la suivante.

- "DELTA", "SUM", "MAX", "MIN", "MUL", "AVG", "COUNT", "NB~OBJ", "ABS", "IS~NOT~IN", "LIST", "ULIST", "LLIST", "LISTNV", "LIST~GET", "FIRST", "LAST", 'SORT", "SUBSEQ", "SPOSITION", "POSITION", "CONCAT", "NB~EXIST", "GET FDN", "COERCE", "COERCE~STR", "COERCEJ NT", "COERCE~BOOL", "COERCE~SGTM", "COERCE~LGTM", "COERCE~GTMS", "INTER", "LENGTH", "IS~NULL", "IS~NOT~NULL", "IS~iN", "MATCH", "BETWEEN", "EQU", "NOT~EQU", "LESS", "LESS~EQ", "GREATER~EQ", "GREATER", "OR", "AND", "NOT", "GET~NIL", "GET~TRUE", "TIME", "DTIME", "GMTIME", "GENTIME", "UTIME", "AVGEXP", "ROUND", "LIMIT~VAL", "IDENT", "GLIST~GET", "GTMITIME", "ALL~EQ U", "ALL~NOT EQU", "ALL~GREATER", "ALL~GREATER~EQ" "ALL~LESS", "ALL~LESS~EGI", "PREVIOUS", "GETBYADDR", "GETBYNAME", "GET~MANAGER"
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 dites compatibles d'une classe donnée. Cette notion de compatibilité de fdn découle de l'organisation hiérarchique des objets de la MIB et de la notion de contenance sur instances. Cette notion intervient notamment lors de la définition des règles d'évaluations des variables. Nous définissons la compatibilité de fdns par l'énoncé suivant :
Deux 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 que deux instances sont compatibles si leurs fdn sont compatibles.

Dans l'exemple de la figure 1, les instances : - DEV1 et DEV2 sont compatibles, car elles admettent sur le sous arbre commun des classes (ici RESEAU) le même sous-fdn (ici dn(NET1) ) - DEV1 et DEV7 ne sont pas compatibles car elles admettent sur le sous arbre commun des classes ( ici INVENTAIRE) un sous-fdn différent (dn(NET1) et dn(NET3)).

- DEV1 et DEV3 sont compatibles, car DEV3 est attachée à NET1 - Il et QUARTZ sont compatibles car attachées à RACINE,..etc.

<Desc/Clms Page number 15>

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 de Query Builder spécifiant des variables dans leurs expressions : - filtres avec variables - opérateur de jointure Coin), opérateur de tests ensemblistes (IS-IN, EXISTS, CONTAINS, ..) dont l'expression générale est: - <attribut> <oper> <$variable>
La variable étant externe, pour une instance Xi traitée, cette variable $variable sera évaluée avec l'ensemble des valeurs calculées pour les instances compatibles à Xi.

De plus, les instances des autres classes non compatibles avec celles vérifiant l'expression de filtrage sont éliminées.

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.

A titre d'exemple, considérons la requête RO: RO) Dans l'inventaire QUARTZ, liste des réseaux avec la liste des équipements DEVi qui leur sont connectés et qui ont la même source de découverte. Pour traiter RO nous devons définir: Sur la classe EQUIPEMENT (ipDevice) :
Les variables sont : dev~Name =deviceName. v~devSource = devSource Sur la classe RESEAU (ipNetwork) : (Résultat)
La variable est : devList = LIST (dev~Name)
Et l'opérateur est : JOIN (netSource = v~devSource) Ici, pour une instance de réseau, la jointure sera évaluée avec l'ensemble des valeurs de v~devSource calculées pour les équipements DEVi attachés (compatibles) au réseau.

Le problème technique posé est le suivant : Les règles d'évaluation des variables reposent toutes sur la forme d'une affectation statique de la forme
Var ; <expression arithmétique>
L'évaluation de l'expression arithmétique pour une instance est figée, et n'est jamais soumise à des conditions. Ceci a comme conséquence de ne pouvoir

<Desc/Clms Page number 16>

répondre à certains cas de requêtes, comme celles nécessitant un calcul de variables avec une évaluation conditionnée par un test.

A titre d'exemple non limitatif, citons les requêtes suivantes R1 à R4: Requête R1 ) Dire pour chaque réseau network s'il appartient à la famille des réseaux dit'importants (avec un nombre de devices > à 1000) ou dit'faible (avec un nombre de devices < a 1 000) Pour traiter R1, une première approche serait: Sur la classe RESEAU ipNetwork. (Résultat) variable : famille = "important" si ipDeviceNumber >1000 = "faible" si ipt:DeviceNumber <1000
Une exploitation de cette variable famille pouvant être ensuite de classer les. réseaux en deux familles distinctes, important et faible. Ceci se traduit par la mise en #uvre de l'opérateur de groupement par type GROUP-BY sur la variable famille, ainsi que d'une variable supplémentaire networkList donnant alors la liste des réseaux pour une famille donnée. On a alors; Sur la classe ipNetwork. (Résultat) variable: famille: =- "important" si ipDeviceNumber >1000 = "faible" si ipDeviceNumber <1000 networklList = LIST (networkname)
Opérateurs : GROUP-BY (famille)
Néanmoins, cette écriture, compte tenu des programmes existants, n'est pas possible, les règles d'évaluation de variables ne prévoyant pas une affectation conditionnée. Cette requête, pourtant naturelle, n'est pas traduisible dans Query Builber avec le langage tel qu'il est défini.

Considérons un autre cas: .

Requête R2) Dans l'inventaire QUARTZ, liste des réseaux avec, pour chacun d'eux, la liste des équipements DEVi de types PC ainsi que le nombre de passerelles gateway.

Pour avoir la somme des passerelles pour chaque réseau, la solution classique consiste à écrire: Sur la classe Equipement ipDevice.

Variable : gateway= 1, puis à réaliser un filtre sur tous les équipements de type passerelles

<Desc/Clms Page number 17>

filtre: ipType = gateway Sur la classe RESEAU ipNetwork à obtenir comme résultat la variable nbGateway qui est la somme des équipements de type passerelle variable: nbGateway = SUM (gateway).

Un premier problème vient, du fait du filtrage sur la classe EQUIPEMENT ipDevice des équipements de type passerelles, les réseaux n'ayant pas de passerelles gateway sont éliminés du résultat (règle de base sur le filtrage) Ceci n'est pas le résultat escompté car l'énoncé de la requête précise plutôt un comptage nul pour les réseaux sans passerelles gateway, et non pas une élimination du réseau.

De même, pour avoir la liste des PCs par réseaux, on doit implémenter un filtrage sur le type de dispositif "device", ainsi qu'une variable listant les PCs.

Sur la classe ipDevice. variable: gtw = 1 pcName = deviceName filtre OR (ipType = gateway) (ipType = PC), filtre soit les équipements de type passerelles soit les équipements de type PC Sur la classe ipNetwork. (Résultat) variable: nbGateway = SUM (gtw) listePC = LIST (pcName)
Le problème ici est que l'on ne travaille pas sur deux ensembles distincts d' équipements devices, un qui serait l'ensemble des passerelles gateways et l'autre l'ensemble des PCs. L'évaluation des variables porte ici sur un ensemble de réseaux ayant en commun soit des passerelles gateways, soit des PCs, ce qui rend un résultat faux, puisque là aussi on élimine un certain nombre de réseaux.

Pour traiter cette requête, il nous faut encore une fois une affectation conditionnelle sur variable ,à savoir ici gtw = 1 si ipType = gateway
0 sinon pcName = deviceName si ipType = PC = 0 sinon
Le filtrage sur le type de dispositif device étant supprimé afin de travailler sur tous les équipements ou équipements devices du réseau courant.

Dans ce cas, pour un réseau courant:

<Desc/Clms Page number 18>

SUM (gtw) rend bien la nombre de passerelles gateway
LIST ( pcName) rend bien la liste des noms de PC
Mais pour pouvoir traiter ces types de requêtes, il faut une fonction supplémentaire sur variable permettant une affectation conditionnelle de valeur sur résultat d'un test, qui doit rendre ici les valeurs vrai ou faux.

Une autre difficulté est la prise en compte de tests multivalués sur plusieurs valeurs, qui ouvre également la porte à de nouveaux types de requêtes sans solution aujourd'hui. Le premier est la gestion des tests sur intervalles de valeurs. Soit par exemple la requête R3.

Requête R3) Classifier les réseaux en fonction du nombre de équipements devices avec les critères suivants: ipDeviceNumber: . [0-100]: very-small ]100-200]: small ]200-300] : medium ]300-400] : large ]400-+ : very-large
La résolution de cette requête passe encore par une affectation conditionnelle sur les résultats à valeurs multiples (ici multivalués) d'un test . Le fonctionnement de cette affectation conditionnelle est le suivant : variable familleNetwork <-- "very-small" si ipDeviceNumber ≤100 sinon <-- "small" si ipDeviceNumber ≤200 sinon <-- "medium" si ipDeviceNumber ≤300 sinon <.- "large" si ipDeviceNumber ≤400 sinon <-- "very-large"
L'affectation sur test multivalué peut être non pas une constante (large, medium,...) comme pour la requête R3, mais une valeur calculée, Considérons la requête R4: Requête R4 : pour chaque réseaux, rendre une valeur calculant :

<Desc/Clms Page number 19>

si réseau de classe A : nombre de passerelles gateway si réseau de classe B --> nombre de PC si réseau de classe C : --> nombre d'équipements devices non snmp autre : -> nombre total d'équipements devices.

Ici encore, l'évaluation des variables sur des sous ensembles différents de réseaux rend l'écriture de cette requête non triviale.

Pour pouvoir traiter ces types de requêtes, Il faut faire appel à une fonction supplémentaire sur variable permettant une affectation conditionnelle sur résultats multivalués d'un test.

Ceci revient a introduire un degré supérieur d'abstraction et de calcul dans le langage visuel de query builder en introduisant un programme permettant le traitement de structures alternatives (if .. then' else. ) dans le calcul des variables.

En fonction des besoins cités dans les requêtes R1 à R4, l'invention consiste à ajouter au programme CQB le programme complémentaire pour permettre l'exécution des fonctions supplémentaires d'un premier type EXECOND et d'un second type EXECONDVAL d'affectation conditionnelle, qui s'exécutent en prenant en compte des variables ou attributs pour déterminer d'autres variables ou résultats. Ces fonctions sont ; EXECOND (varTest, varThen, varElse) EXECONDVAL (varTest, Oper, DomaineList, ValeursList, varDefaut)
L'évaluation de variables avec fonctions d'affectation conditionnelle reprend les règles de base définies plus haut. (calcul par instances, variables internes et externes, compatibilité de fdn).

Cette fonction EXECOND répond aux besoins des requêtes R1 et R2; Elle correspond à la forme basique d'affectation conditionnelle sur variable
EXECOND (varTest, varThen , varElse) avec varTest: qui est la variable ou l'attribut à tester. Appliquée à une instance, elle rend une valeur ou nil varThen: est la variable, l'attribut ou la constante dont la valeur calculée sera retournée si varTest est vrai (différent de nil)

<Desc/Clms Page number 20>

varElse la variable, l'attribut ou la constante dont la valeur calculée sera retournée si varTest est faux (= a nil).

Le programme permet, lorsqu'il détecte une fonction EXECOND à exécuter, de mettre en #uvre le fonctionnement suivant Soit une variable V dont la valeur est exprimée par
V = EXECOND (varTest, varThen, varElse)
Pour une instance Xi, la valeur de V pour Xi est notée val(V,Xi)
Vi : = si val (varTest, Xi) alors val(varThen, Xi) sinon val(varElse, Xi)
Ce qui précède signifie que la fonction EXECOND met en #uvre un programme de traitement qui, lorsqu'une telle fonction est reconnue par ce programme, effectue pour une instance un test varTest sur une variable définie par l'attribut à tester pour rendre, soit une valeur, soit l'information "rien" (nil).

Le traitement de cette fonction se poursuit en retournant comme résultat de l'exécution de la fonction soit la variable définie par varThen, si le résultat du test était une valeur, soit la variable définie par varElse. La variable varThen sera retournée si le résultat du test est vrai (différent de nil), sinon la variable varElse est retournée lorsque varTest est faux, c'est à dire lorsque le résultat est égal à nil.

La fonction EXECONDVAL répond aux besoins des requêtes R3 et R4.

Elle complète la forme basique d'affectation conditionnelle sur variable de EXECOND en apportant une affectation multivaluée.

EXECONDVAL (varTest, varOper, DomaineList, valeurList, varDefaut), avec varTest: définit la variable ou l'attribut à tester. Le test appliqué à une instance, rend une valeur varOper: définit l'opération de test sur une variable ou une constante avec l'opérateur choisi qui doit être dans la liste suivante (=, >, <, ≥, ≤, <>) DomaineList: constitue la liste définissant le domaine des valeurs à tester valeursList: constitue une liste de valeurs de résultat à affectation conditionnelle, parmi lesquelles une valeur de résultat sera affichée comme résultat calculé; le nombre d'éléments de cette liste devant coïncider avec le nombre d'éléments du domaine

<Desc/Clms Page number 21>

varDefaut: définit la variable la constante ou l'attribut à retourner s'il n'y a pas de valeurs reconnues dans le domaine Le fonctionnement est le suivant: val(V = EXECONDVAL (varTest, varOper, DomaineList, valeurlist, varDefaut) Pour une instance Xi, la valeur de V pour Xi est notée val(V,Xi) varThen[i] étant le ième élément de la liste varThen n étant la dimension de la liste DomaineList Vi:= Pour j : = 1 à n si val (varTest, Xi) <varOper>DomaineList [j], alors k :=j finPour si k alors val(varThen[k]; Xi) sinon varDefaut, Xi).

En d'autres termes, pour une instance Xi, la valeur val (varTest, Xi) de l'instance est comparée à chaque élément de DomaineList avec l'opérateur de comparaison varOper; seul le rang i du dernier élément de DomaineList vérifiant la comparaison est retenu. L'ordre des éléments dans le domaine est donc important.

Si ce rang i existe, alors la valeur retournée est le ième élément de la liste de résultat valeurList.

Sinon, c'est val (Xi,varDefaut), la valeur définie par la variable "varDefaut" pour l'instance Xi qui est retournée.

Pour permettre une meilleure compréhension de l'invention, le lecteur trouvera ci-après quelques exemples non limitatifs d'utilisation selon l'invention des fonctions de premier type EXECOND et de second type EXECONDVAL appliquées aux problèmes évoqués ci-dessus et non résolus par l'art antérieur.

Le premier problème que permet, par exemple, de résoudre la fonction d e premier type EXECOND est le type de requête R1 suivante : Dire pour chaque network s'il appartient à la famille des réseaux dit Importants (avec un nombre d'équipements devices > à 1000) ou dit'faible (avec un nombre de devices < à 1 000).

<Desc/Clms Page number 22>

Ici le test d'affectation prend 2 valeurs (> ou < a 1000) et se traduit donc par l'utilisation de EXECOND). L'écriture de cette requête R1 devient : Sur la classe RESEAU ipNetwork. (Résultat) On définit la variable varTest: moreThanMille = GREATER (ipDeviceNumber, 1000) vjmp = "important" v~fai = "faible" famille = EXECOND ( moreThanMille, v~imp, v~fai) Attributs résultats: famille, networkName
Chaque nombre d'équipements (device) d'un réseau portant le nom "networkName" va être qualifié d'important ou de faible en fonction du résultat de l' exécution de la fonction EXECOND.

La fonction EXECOND permet également de résoudre le type de requête R1 -bis suivante : Lister les réseaux networks groupés par famille important ou faible.

Sur la classe ipNetwork. (Résultat) La variable varTest est définie par: moreThanMille = GREATER (ipDeviceNumber,
1000) v- imp "important" v~fai = "faible" famille = EXECOND ( rnoreThanMille, v~imp, v~fai) networkList = List (networknames) Opérateurs : GROUP-BY(famille) Les attributs des résultats sont: famille, networkList
La fonction EXECOND permet aussi de résoudre le type de requête R2 suivant : Dans l'inventaire QUARTZ, donner la liste des réseaux avec, pour chacun d'eux, la liste des équipements devices de types PC ainsi que le nombre de passerelles gateway.

Les deux variables sont affectées par un test du type est ou n'est pas (gateway, PC); EXECOND répond donc à la question et on a :
Sur la classe EQUIPEMENT ipDevice.

L'opérateur définit la variable varTest par. is-gtw= EQU (ipType, Gateway)

<Desc/Clms Page number 23>

gtwNum= EXECOND (is-gtw, "1 ", "0") La variable gtwNum est le résultat de la fonction EXECOND sur is-gtw is-Pc = EQU (ipType, PC) namePc = EXECOND (is-Pc, deviceName) Sur la classe RESEAU ipNetwork. (Résultat) variables : nbGateway = SUM (gtwNum)
ListePc = List(namePc) Les attributs des résultats sont : networkName, nbGateway, ListPc
A titre d'exemple de résultat fourni par le traitement de la requête R2, si, un réseau NET1 possède quatre équipements "devices" avec les valeurs d'attributs suivants, la table ci-après montre l'évaluation des variables en EXECOND pour chaque device. Il en résulte que pour ce réseau, en accord avec les règles d'évaluations de variables précédemment citées (calcul de variables externes sur instances compatibles), on a 'nbGateway = 2 ; ListPc = (dev3, dev4)

<tb>
<tb> ipType <SEP> deviceName <SEP> snmp <SEP> gtwNum <SEP> namePc
<tb> noSnmpNb
<tb> gateway <SEP> dev1 <SEP> yes <SEP> 1 <SEP> () <SEP> 1
<tb> gateway <SEP> dev2 <SEP> yes <SEP> 1 <SEP> () <SEP> 1
<tb> PC <SEP> dev3 <SEP> yes <SEP> 0 <SEP> dev3 <SEP> 1
<tb> PC <SEP> dev4 <SEP> no <SEP> 0 <SEP> dev4 <SEP> 0
<tb>

Revenons sur l'exemple de la requête R3 qui est: Classifier les réseaux en fonction du nombre de devices avec les critères suivants ipDeviceNumber. [O-@OO]:very-small ]100-200]: small ]200-300]: medium ]300-400] ; large ]400-+] : very-large

<Desc/Clms Page number 24>

La fonction "EXECOND" ne suffit plus ici à traiter la requête R3 puisque l'on a un test sur intervalles; elle doit être traitée par la fonction "EXECONDVAL" de la manière suivante Sur la classe RESEAU ipNetwork. (Résultat)
La variable à tester est ipDeviceNumber par l'opérateur ">" dans le domaine fourni par la liste de variables DomaineList = LIST (0,100, 200, 300,400) à affectations multivaluées définie par une liste de résultats conditionnels valeurList = LIST ("very-small", "small", "medium", "large", "very-large") ou par une valeur par défaut "vDefault = GET~nil () familleNetw = EXECONDVAL (ipDeviceNumber, ">", DomaineList, valeurList, vDefault) Les attributs des résultats sont : famille, networkName :
Pour un réseau avec un ipDevice à 350, on voit, lors de l'évaluation de la variable familleNetw, que. ipDeviceNumber > 0 : ipDeviceNumber > 100 : ipDevicoNumber > 200 ; ipDeviceNumber > 300 : ipDeviceNumber > 400 : La dernière évaluation retenue ayant pour résultat "vrai" a ici le troisième rang, la valeur de résultat choisie pour l'affectation sera le troisième élément de la liste valeurList, à savoir "large".

Pour traiter la requête R4 qui est de rendre une valeur calculant, pour chaque réseaux en fonction du type de classe, le nombre de passerelles, le nombre d'ordinateurs personnels pc, le nombre d'équipements non snmp, le nombre total d'équipements, ce que l'on exprime sous la forme : si réseau de classe A --> nombre de passerelles gateway ; si réseau de classe B --> nombre de PC; si réseau de classe C -> nombre d'équipements non snmp devices non snmp, autre : -> nombre total de devices; la fonction EXECONDVAL sera utilisée.

<Desc/Clms Page number 25>

- Sur la classe INVENTAIRE Inventory
La variable domaineList est définie par: domaineList = LIST ("class-A", "class-B", "class-C) -Sur la classe EQUIPEMENT ipDevice.

La variable is-gtw est définie par is-gtw = EQU (ipType, Gateway)
La variable gtwNum est le résultat de l'application de la fonction
EXECOND sur la variable is-gtw : gtwNum = EXECOND (is-gtw, 1,0).

Cette variable gtwNum a pour valeur "1" si l'équipement est une passerelle et "0" dans le cas contraire.

La variable "is-Pc" est définie par "is-Pc" = EQU (ipType, PC)
La variable pcNum est le résultat de l'application de la fonction "EXECOND" sur la variable is-Pc : pcNum = EXECOND is-Pc, "1", "O").

De même cette variable pcNum a pour valeur "1" si l'équipement est un ordinateur personnel type PC et "0" dans le cas contraire.

La variable no-snmp = EQU (snmpSupported, "no") définit les équipements qui ne sont pas du type snmp.

La variable noSnmpNb = EXECOND (no-snmp, "1 ", "0"). Cette variable noSnmpNb prend pour valeur "1"si l'équipement n' est pas du type snmp et "0" dans le cas contraire - Sur la classe RESEAU ipNetwork. (Résultat)
Les variables suivantes sont définies: nbGateway = SUM (gtwNum) nbPc = SUM (pcNurn) nbNoSnmp = SUM (noSnmpNb) nbDev = ipDeviceNumber La liste de valeur résultat est valeursList = LIST (nbGateway, nbPc, nbNoSnmp)
La variable familleNetw est définie par l'application de la fonction EXECONDVAL sur les attributs de ipClass de la classe RESEAU avec pour opérateur

<Desc/Clms Page number 26>

"=", pour domaine de comparaison la liste domaineList définie sur la classe INVENTAIRE et pour liste de résultats multivalués valeurList : familleNetw = EXECONDVAL (ipClass, "=", DomaineList, valeurList, nbDev) les attributs constituant les résultats sont: networkName, familleNetw
Le lecteur notera que: - La variable domaineList est définie sur la classe INVENTAIRE inventory afin d'être calculée une seule fois - Pour chaque réseau, la variable valeurList est évaluée comme une liste à trois valeurs - Lors du calcul de la variable familleNetw, pour un réseau de classe B.

L'attribut ipClass vérifie l'égalité avec le deuxième élément de domaineList, la valeur retournée sera donc le deuxième élément de valeurList, c'est à dire la valeur calculée pour la variable nbPc.

En conclusion, nous avons donc créé un nouveau concept dans un langage visuel d'interrogation qui est fondé sur l'évaluation de variables conditionnelles avec tests sur plusieurs valeurs (multivalués).

Même si certains langages graphiques gèrent à leur manière la définition de variables, ce concept n'a jamais été abordé dans ce type d'application. Même en faisant une comparaison entre le langage d'interrogation visuel de Query Builder et les autres langages non procéduraux comme SQL, on voit que ce dernier ne traite pas de ce nouveau concept.

Son implémentation est inhérente au fonctionnement et règles de calculs des variables dans Query Builder Elle se traduit par la mise en oeuvre des deux fonctions EXECOND et EXECONDVAL sur variables dont nous avons étudié le format.

Le mode de fonctionnement de ces fonctions est compatible et s'intègre bien avec l'existant.

<Desc/Clms Page number 27>

La notion de variables dans Query builder permet d'introduire dans notre langage de requête visuel un mode dit programme, permettant à l'utilisateur de faire des calculs a partir des données de la MIB - mettre en relation les classes entre elles et implémenter des opérateurs inter-classes
L'affectation conditionnelle de variables avec test multivalués apporte une autre dimension a ce programme, puisque qu'elle permet la définition d'instructions conditionnelles dans un langage visuel.

Le pouvoir d'expression du langage graphique s'en trouve largement renforcé et certains types d'interrogations telles que celles citées en exemple, jusqu'alors non traduisibles par Query Builder, trouvent avec ces deux fonctions rajoutées dans CQB, une solution d'écriture et de construction. Ainsi après avoir ajouté le programme de gestion des fonctions EXECOND et EXECONDVAL, l'interface de programmation permettant d'afficher sur l'écran du système les fonctions disponibles est modifiée pour faire apparaître dans le menu de fonction, les noms EXECOND et EXECONDVAL des fonctions. L'opérateur peut ensuite sélectionner une de ces fonctions parmi celles disponibles dans la fenêtre (31), comme représenté figure 3.

L'opérateur peut ensuite sélectionner, dans la fenêtre (30) du coin supérieur gauche de l'affichage, la classe sur laquelle s'applique la fonction et dans la fenêtre (32), il peut définir l'expression.

L'opérateur peut ensuite faire apparaître la fenêtre représentée à la figure 4 dans laquelle il va déterminer et saisir les variables sur lesquelles la fonction EXECOND ou EXECONDVAL va s'appliquer. Cette fenêtre fait apparaître dans le pavé un menu déroulant (41), l'expression de la fonction et dans le cadre (42) le nom de la variable sur laquelle s'applique la fonction. Enfin, l'opérateur saisit dans la fenêtre (5) en sélectionnant, les variables dans le cadre (51) et les attributs dans le cadre (52), qui constituent les résultats de la fonction. Une fois cette sélection effectuée et l'exécution de la fonction lancée en cliquant sur le bouton Apply (Appliquer) (53), le programme fait apparaître après l'exécution de la fonction sélectionnée EXECOND ou EXECONDVAL, la matrice résultat représentée à la figure 6.

Il doit être évident pour les personnes versées dans l'art que la présente invention permet des modes de réalisation sous de nombreuses autres formes

<Desc/Clms Page number 28>

spécifiques sans l'éloigner du domaine d'application de l'invention comme revendiqué. Par conséquent, les présents modes de réalisation doivent être considérés à titre d'illustration, mais peuvent être modifiés dans le domaine défini par la portée des revendications jointes, et l'invention ne doit pas être limitée aux détails donnés cidessus.

Claims (15)

REVENDICATIONS

1 - Procédé de manipulation d'objets inclus dans un arbre de contenance, les objets étant interrogeables par l'intermédiaire d'au moins une requête à affectation non statique caractérisé en ce qu'il comporte -une étape de définition pour une fonction EXECOND ou EXECONDVAL d'une variable test varTest ou d'un domaine test "DomaineList" pour effectuer un test défini par une opération varOper sur une instance (Xi) d'un objet de l'arbre de contenance et au moins une variable résultat (varElse, varDefaut), - une étape d'exécution d'au moins un test ,et - une étape de délivrance d'un résultat conditionnel défini en fonction du résultat du test et exprimé par, soit la valeur de la variable résultat (varElse, varDefaut) si la condition définie par le test n'est jamais réalisée, soit par une autre valeur.

2 - Procédé selon la revendication 1, caractérisé en ce qu'il comporte - une étape de définition pour le domaine test d'une liste de domaines DomaineList associée à une liste de valeurs de résultat à affectation conditionnelle valeurList et en ce que l'étape de test consiste: - à comparer avec l'opérateur varOper défini dans les paramètres de la fonction EXECONDVAL la valeur de la variable représentant l'instance Xi à chaque élément de la liste de domaine DomaineList, - à incrémenter un compteur de rang pour chaque élément comparé, - à retenir le rang i du dernier élément de la liste de domaine vérifiant la comparaison, l'étape de délivrance de résultat consistant à fournir pour autre valeur, la valeur de la liste de valeurs valeurList ayant le rang i retenu.

3 - Procédé selon la revendication 1, caractérisé en ce que l'étape de délivrance de résultat pour une fonction EXECOND consiste à fournir pour autre valeur, la valeur définie par une variable, attribut ou constante varThen.

4 - Procédé selon la revendication 1, caractérisé en ce que l'affectation sur test multivalué peut être une constante.

5 - Procédé selon la revendication 1, caractérisé en ce que l'affectation sur test multivalué peut être une valeur calculée.

<Desc/Clms Page number 30>

6 - Procédé selon la revendication 2, caractérisé en ce que la liste de valeur de résultat à affectation conditionnelle valeurList associée à la liste de domaine domameList est définie par un second jeu de variables ou attributs (nbGateway, nbPc, nbNoSnmp) obtenus par l'application de fonctions de premier ou second type à un troisième jeu de variables.

7 - Procédé selon la revendication 1 ou 2, caractérisé en ce que la variable varTest ou les variables ou attributs de la liste valeurList sont elles-mêmes le résultat de l'application de fonctions classiques (EQU, SUM) à un troisième jeu de variables ou attributs (pcNum, gtw, noSnmpNb).

8 - Procédé selon une des revendications 1 à 7, caractérisé en ce que le résultat fourni par une fonction EXECOND ou EXECONDVAL est utilisé comme variable pour l'évaluation par une des 70 fonctions disponibles.

9 - Procédé selon une des revendications 1 à 8, caractérisé en ce que les résultats sont affichés par une matrice dont les colonnes sont les attributs résultats sélectionnés, et les lignes les instances qui vérifient la requête,

10 - Système SYS de manipulation d'objets comportant au moins un système gestionnaire SG et au moins une machine distante M1 associée à un protocole de gestion et comprenant des objets manipulables, un agent intégrateur AI pour convertir le protocole de gestion du système de gestion SG en un protocole de gestion correspondant à celui de la machine M1 et un agent AG de manipulation d'objets, d'une base de données objet organisée selon un arbre de contenance, les objets étant classés selon une hiérarchie définie par un arbre de classes et étant interrogeables par l'intermédiaire d'une application CQB permettant la construction visuelle sur un dispositif d'affichage du système SYS d'au moins une requête à affectation non statique caractérisé en ce que l'application CQB comporte - un programme d'exécution d'un premier type EXECOND ou d'un second type "EXECONDVAL" de fonction, sur une variable test varTest ou sur un domaine test DomaineList mémorisé dans des moyens de mémorisation pour effectuer par des moyens de test un test défini par une opération varOper sur chaque instance (Xi) d'un objet de l'arbre de contenance appartenant à une classe et des moyens pour produire au moins une variable résultat (varElse, varDefaut),

<Desc/Clms Page number 31>

- des moyens de délivrance d'au moins un résultat conditionnel défini en fonction du résultat du test et exprimé par, soit la valeur de la variable résultat par défaut (varElse, varDefaut) si la condition définie par le test n'est jamais réalisée, soit par une autre valeur.

11 - Système selon la revendication 10, caractérisé en ce que l'application CQB comporte des moyens de mémorisation d'une liste de valeurs de résultat à affectation conditionnelle valeurList mémorisée associée à la liste de domaine DomaineList et en ce que les moyens de test pour effectuer un test défini par une opération "varOper" consistent : en : - des moyens de comparer avec l'opérateur varOper défini dans les paramètres de la fonction EXECONDVAL la valeur de la variable représentant l'instance Xi à chaque élément de la liste de domaine DomaineList caractérisé en ce quedes moyens d'incrémenter un compteur de rang pour chaque élément comparé, - des moyens de mémorisation du rang i du dernier élément de la liste de domaine vérifiant la comparaison définie par l'opérateur varOper, les moyens de délivrance du résultat constitué par l'autre valeur, comportent des moyens de recherche dans la liste de valeurs de résultat à affectation conditionnelle valeurlist, la valeur ayant dans la liste le rang i mémorisé.

12 - Système selon la revendication 11, caractérisé en ce que la liste de valeur de résultat à affectation conditionnelle valeurlist associée à la liste de domaine domaineList est définie par un second jeu de variables ou attributs (nbGateway, nbPc, nbNoSnmp) obtenues par l'application d'une fonction du premier ou second type à un troisième jeu de variables.

13 - Système selon la revendication 10 ou 11, caractérisé en ce que la variable varTest ou le jeu de variables ou attributs (nbGateway, nbPc, nbNoSnmp) de la liste ValeurList sont le résultat de l'application de fonctions classiques (EQU, SUM) à un troisième jeu de variables ou attributs (pcNum, gtw, noSnmpNb)

14 - Système selon une des revendications 10 à 13, caractérisé en ce que le résultat fourni par une fonction de premier type EXECOND ou de second type EXECONDVAL est utilisé comme variable pour l'évaluation par une des 70 autres

<Desc/Clms Page number 32>

fonctions disponibles par le programme de construction de requêtes (QUERY BUILDER).

15 - Système selon une des revendications 10 à 14, caractérisé en ce que les résultats sont affichés par une matrice, dont les colonnes sont les attributs résultats sélectionnés, et les lignes les instances qui vérifient la requête.