Le mod`ele commun de l’information

Le mod`ele commun de l’information (CIM) [18] est une approche propos´ee par le DMTF2

pour la gestion des stations de travail, des r´eseaux et des services. CIM est en fait une double pro-position qui d´efinit un formalisme d’expression de l’information de gestion ainsi qu’un ensemble d’´el´ements r´eutilisables directement dans le cadre d’une infrastructure de supervision [57]. Le formalisme d’expression repose sur le paradigme orient´e objet et d´efinit une mani`ere graphique de repr´esenter les ´el´ements mod´elis´es sous une forme assez similaire `a l’approche UML³. Conjoin-tement `a cela, CIM d´efinit le langage MOF4 comme langage d’expression formel pour les objets g´er´es.

5.2.1 Les concepts de CIM

Un des objectifs de CIM est de permettre la sp´ecification et la mise `a disposition des applica-tions d’une description unifi´ee et extensible des ressources g´er´ees [57]. Pour cela, CIM comporte cinq ´el´ements principaux qui sont :

1. Un m´eta-mod`ele [39] qui d´ecrit les concepts du mod`ele qui servent de briques de base `a la construction des sp´ecifications. De par sa nature orient´ee objet, CIM d´efinit notamment les notions de classe, attribut, m´ethode, association, r´ef´erence, qualifieur et sch´ema, dont nous d´etaillons le sens ci-apr`es ;

2. Un nommage des composants g´er´es (classes, associations, qualifieurs et instances) qui re-pose sur deux principes : un sch´ema et un espace de nommage ;

3. Un langage support pour la sp´ecification des objets g´er´es. Il d´efinit la syntaxe d’expression des ´el´ements du m´eta-mod`ele ;

4. Un mod`ele de l’information de r´ef´erence servant de base `a la sp´ecification de nouveaux composants g´er´es, ainsi qu’un sous-ensemble repr´esentant les objets que tout serveur doit implanter ;

5. Un ensemble de recommandations sur l’int´egration des mod`eles de l’information issus d’autres approches. En effet, CIM se pr´esente comme un mod`ele unificateur capable de prendre en consid´eration les diff´erents domaines et approches de gestion de r´eseaux. Dans ce cadre, plusieurs m´ethodes de mise en correspondance et de traduction sont propos´ees. 2

Distributed Management Task Force - http ://www.dmtf.org

3

Unified Modeling Language

4

5.2. Le mod`ele commun de l’information

5.2.2 Illustration de quelques concepts

La figure 5.1 illustre la repr´esentation graphique des classes CIM ainsi que leur traduc-tion dans le langage MOF. Plusieurs points sont remarquables : tout d’abord, une classe CIM poss`ede un nom compos´e de deux parties. La premi`ere identifie le sch´ema auquel la classe ap-partient, et la seconde, la classe `a proprement parler. Par exemple, dans la figure 5.1.b, la classe CIM ManagedElement appartient au sch´ema CIM et poss`ede le nom ManagedElement⁵. Ensuite, une classe est compos´ee d’attributs et de m´ethodes. Les attributs disposent de types standard (entier, flottant, chaˆıne de caract`eres, . . .). Les m´ethodes quant `a elles, sont prototyp´ees de ma-ni`ere classique par leur nom, des param`etres d’entr´ee et/ou de sortie et un param`etre de retour. Dans notre exemple, par souci de clart´e, nous avons seulement repr´esent´e des classes ne poss´e-dant pas de m´ethode. Par contre, concernant les attributs, on voit par exemple que l’attribut Caption de la classe CIM ManagedElement est une chaˆıne de caract`eres (type string). Le concept suivant que nous introduisons est celui de qualifieur. Un qualifieur est un mot cl´e qui s’applique `a une classe, un attribut ou une m´ethode, et qui permet d’ajouter une s´emantique suppl´ementaire ou de modifier la s´emantique originelle de l’´el´ement auquel il s’applique. On consid`ere `a nouveau l’attribut Caption qui poss`ede deux qualifieurs, not´es entre crochets. Le premier indique que sa chaˆıne de caract`eres ne pourra contenir plus de 64 ´el´ements (MaxLen (64)), le second apporte une description exhaustive de l’attribut (Description).

*

*

OperationalStatus: uint16[] {enum} StatusDescriptions : string[]

Status: string {enum, D}

[Abstract, Version ("2.7.0")] class CIM_ManagedElement { [MaxLen (64), Description ("...")] string Caption; string Description;

string ElementName; };

[Association, Abstract, Aggregation] class CIM_Component { [Aggregate, Key, Description ("The parent element (...).") ] CIM_ManagedElement REF GroupComponent;

[Key, Description ("The child element (...).") ] CIM_ManagedElement REF PartComponent;

};

[Abstract] class CIM_ManagedSystemElement : CIM_ManagedElement { // Attributs de la classe CIM_ManagedSystemElement

};

(a) (b)

Tab. 5.1 – Exemple de classes CIM et leur traduction dans le langage MOF. (a) Sp´ecification sous forme de diagramme de classes. (b) Traduction des classes dans le langage MOF.

Nous nous int´eressons maintenant `a la d´efinition des classes. Comme tout formalisme orient´e objet, CIM d´efinit la notion d’h´eritage, qui dans son cas est un h´eritage simple. Il est repr´esent´e par une fl`eche dans la figure 5.1.a et par la syntaxe <nom_classe_fille> : <nom_classe_m`ere> dans le langage MOF. Ensuite, CIM distingue plusieurs types de classes : les classes concr`etes, les classes abstraites et les classes d’association. Les classes concr`etes repr´esentent un ´el´ement physique ou logique entrant dans le cadre de l’infrastructure de gestion. Ces classes peuvent ˆetre instanci´ees `a travers un objet g´er´e. Ensuite, les classes abstraites, sp´ecifi´ees `a l’aide du qualifieur Abstract repr´esentent elles aussi un ´el´ement physique ou logique, mais de mani`ere g´en´erique et abstraite. Elle ne peuvent ainsi pas ˆetre instanci´ees directement. Enfin, les classes d’association, mentionn´ees `a l’aide du qualifieur Association, repr´esentent un lien particulier

5

entre deux classes concr`etes ou abstraites. La sp´ecification de cardinalit´es affine la s´emantique de l’association. Dans notre exemple, la classe CIM Component, de cardinalit´e * - * associe la classe CIM ManagedElement `a elle-mˆeme et signifie qu’un ´el´ement g´er´e peut ˆetre ´eventuellement compos´e de sous-´el´ements. De mˆeme, un ´el´ement g´er´e peut ´eventuellement appartenir des sur-´el´ements. Enfin, pour acc´eder `a une instance de classe particuli`ere, CIM d´efinit un sch´ema de nommage qui contient, en outre, les attributs qualifi´es de cl´e (key).

5.2.3 Le mod`ele commun de l’information

La proposition d’un formalisme commun pour la sp´ecification des ressources g´er´ees est un premier pas vers l’int´egration et l’interop´erabilit´e des diff´erentes approches de gestion de r´eseaux [57]. Cependant, il est aussi n´ecessaire de repr´esenter de mani`ere uniforme une mˆeme ressource. CIM permet cette uniformisation en proposant un ensemble de sch´emas qui d´efinissent les classes d’objets g´er´es inh´erentes `a diff´erents domaines de la gestion. Cet ensemble se scinde en deux niveaux :

Le mod`ele Core [40] d´efinit un ensemble de classes et d’association g´en´eriques `a tout domaine de gestion. Il d´efinit une structure de base pour tous les sch´emas futurs qui concernent des domaines particuliers. Ainsi, le mod`ele Core est stable et comporte des classes, au concept abstrait, dont le nombre est assez limit´e.

Le mod`ele Common d´efinit des classes et des associations ind´ependantes de toute implan-tation, relatives `a un domaine particulier de la gestion. Il se compose ainsi de diff´erents sous-mod`eles qui concernent les applications [47], les syst`emes [44], les r´eseaux [42], les politiques de gestions [43, 116, 115] ou la s´ecurit´e [45].

Conjointement `a ces deux mod`eles, des sch´emas extension permettent d’´etendre les classes existantes. Ces derniers sont tr`es utiles pour sp´ecialiser un sch´ema existant afin de prendre en compte les sp´ecificit´es d’´el´ements particuliers ou pour couvrir un nouveau domaine qui ne soit pas pris en compte dans le mod`ele Common.

5.2.4 El´ements du mod`ele Core

Le mod`ele Core d´efinit un ensemble de classes communes `a l’ensemble des domaines de gestion. La majorit´e des classes concr`etes qu’il d´efinit h´eritent de classes abstraites, g´en´e-riques, repr´esentant la racine du mod`ele. Comme le montre la figure 5.1, la classe abstraite CIM ManagedElement repr´esente de la mani`ere la plus g´en´erale, un ´el´ement g´er´e dans le cadre d’une approche de gestion. Celui-ci est d´efini par trois attributs qui renseignent sur son nom (ElementName) et deux descriptions, l’une courte (Caption) et l’autre longue (Description). En-suite, la classe abstraite CIM ManagedSystemElement repr´esente un ´el´ement quelconque distin-guable, d´efini dans le cadre d’un syst`eme particulier, comme par exemple, un fichier ou un processeur. Les attributs ajout´es par cette classe renseignent sur le nom de l’´el´ement6 (Name), un statut op´erationnel (OperationnalStatus qui rend obsol`ete l’attribut Status), une description textuelle de ce statut (StatusDescription) et la date d’installation de l’´el´ement (InstallDate).

A ce niveau d’h´eritage, CIM effectue une s´eparation entre les ´el´ements physiques et les ´el´ements logiques. Les premiers, mod´elis´es par le biais de la classe CIM PhysicalElement, repr´e-sentent des ´el´ements r´eels, soumis `a la loi de la pesanteur. Ils peuvent ˆetre, par exemple, une

6

Les attributs Name de la classe CIM ManagedSystemElement et ElementName de la classe CIM ManagedElement peuvent sembler concurrents, mais souvent, l’attribut Name est surcharg´e pour devenir une cl´e, alors que Element-Namerepr´esente un nom intelligible.